Guía del panorama de herramientas de datos para desarrolladores

• Para un desarrollador de software que se incorpora por primera vez al campo de datos, se organiza el panorama completo para que no solo memorice nombres de herramientas, sino que entienda el rol de cada una y sus conexiones en las etapas de recolección/almacenamiento/procesamiento/uso de datos
• Los roles de datos se dividen, a grandes rasgos, en análisis/ciencia/ingeniería/machine learning, y abarcan distintos problemas y herramientas: desde SQL y BI hasta modelos estadísticos y notebooks, infraestructura de pipelines y despliegue de modelos en producción
• Los repositorios se clasifican en data warehouses, que ofrecen análisis rápidos y comodidad; data lakes, económicos y flexibles; y lakehouses, que agregan ACID y gestión de esquemas mediante un formato de tablas
• El procesamiento de datos se expande desde transformaciones SQL como dbt, procesamiento local con pandas y DuckDB, procesamiento batch distribuido con Spark, hasta procesamiento de streams con Kafka y Flink; orquestadores como Airflow gestionan el orden de ejecución de tareas independientes y la recuperación ante fallas
• Los datos procesados se usan no solo en dashboards, sino también en tareas de ventas/soporte, análisis ad hoc, machine learning, funciones analíticas dentro de productos y venta de datos; a medida que aumenta la escala, catálogos/capas semánticas/linaje/gobernanza se vuelven la base clave para mantener el significado y la responsabilidad sobre los datos

---

Alcance que debe conocer un desarrollador

• Es una guía general para desarrolladores preparada por un ingeniero de software que se unió a una empresa de datos sin experiencia previa en el área, para entender para qué sirven las herramientas y cómo interactúan con los notebooks
• No cubre cómo crear dashboards, fundamentos de estadística, operación de clústeres Spark ni comparativas profundas de productos dentro de una misma categoría
• Sigue de dónde surgen los datos y cómo se procesan, almacenan y muestran, distinguiendo las etapas del ciclo de vida que cubre cada herramienta

Cuatro tipos de roles de datos

• En la práctica, los límites entre roles son difusos, especialmente en empresas o equipos pequeños, pero para entender el panorama general pueden dividirse en cuatro tipos
• El tipo analítico interpreta datos con SQL y hojas de cálculo, y visualiza insights
  • Data analyst y BI analyst son los representantes típicos, y usan herramientas como Tableau y Excel
  • Un ejemplo sería consultar datos de clientes para calcular la tasa de churn por región y crear un dashboard en Tableau junto con una propuesta de campaña de retención
• El tipo científico aborda preguntas más profundas que los reportes superficiales, o predicciones, mediante estadística, modelos y experimentos
  • Data scientist es el rol típico, y usa principalmente Python, pandas, scikit-learn y notebooks
  • Puede explorar los factores de churn, crear un modelo de probabilidad de churn por cliente y luego diseñar y analizar una prueba A/B de una campaña de retención
• El tipo ingeniería recolecta, depura y estandariza datos de origen para cargarlos en warehouses o lakes, y opera herramientas de datos y bases de datos
  • Data engineer es el rol típico, y usa Python, Apache Spark, bases de datos, warehouses y la nube
  • Puede escalar resultados analíticos a un pipeline de ETL inverso repetible, o integrar datos de transacciones de múltiples fuentes y gestionar esquemas, consultas y controles de calidad
• El tipo machine learning crea y opera modelos de IA, desde modelos de clasificación hasta LLM
  • Es una categoría que agrupa a ML scientist y ML engineer; como su ecosistema de herramientas es amplio, no se aborda en detalle en el texto
  • Ensambla datos de entrenamiento para modelos de recomendación, entrena y ajusta modelos, los despliega como API, monitorea predicciones y los reentrena según cambios de comportamiento

ETL y ELT

• ETL (Extract-Transform-Load) es el flujo general de extraer datos de origen, depurarlos o combinarlos con otros datos, y luego cargar el resultado en un destino
• El orden de las etapas no es fijo; pueden repetirse o superponerse
• ELT primero carga los datos de origen en el warehouse, luego los transforma allí y guarda el resultado en tablas separadas
  • Puede aumentar los costos por el almacenamiento y la computación adicionales
  • Como se conserva el original, más adelante puede reprocesarse de otra manera

Formatos de archivo y memoria

• CSV es fácil de compartir para datos pequeños y puede abrirse en la mayoría de los programas de oficina, por lo que es adecuado para usuarios no técnicos
• Apache Parquet es un formato de archivo columnar con alta compresión, capaz de almacenar y transferir grandes volúmenes de datos de forma eficiente
  • La mayoría de las herramientas de datos lo soportan, por lo que funciona como formato común entre herramientas
  • Apache ORC resuelve un problema similar
• Apache Avro es un formato binario orientado a filas que se usa para transferir registros, especialmente en procesamiento de streams
• Apache Arrow es el formato en memoria estándar de facto, optimizado para procesamiento y transferencias zero-copy
  • Parquet se enfoca en archivos pequeños y en el escaneo de los elementos necesarios; Arrow se centra en el cálculo real aprovechando instrucciones de CPU/GPU y caché
  • Arrow usa más memoria, pero transfiere datos de forma eficiente entre herramientas como pandas y DataFusion de Rust
  • Puede usarse como backend opcional de pandas, y Polars y DataFusion se construyeron sobre Arrow desde el inicio

Data warehouse

• Un data warehouse se parece a bases de datos como PostgreSQL o MySQL, pero está optimizado para cargas analíticas
• Una base de datos OLTP como MySQL es adecuada para buscar una fila de usuario por ID, mientras que un warehouse OLAP es adecuado para agregaciones por columnas, como el total de ventas anual por región
• Tradicionalmente era el repositorio final de datos estructurados depurados, pero en ELT también se usa como primer punto de carga para datos crudos
• Como el formato de almacenamiento y el motor de consultas están estrechamente integrados, ofrece consultas rápidas de BI y reporting, pero entre los tres tipos de repositorios es el de mayor costo
• Entre los productos están Snowflake, BigQuery y Redshift
• Entre las opciones open source y autohospedadas están ClickHouse, Apache Doris y StarRocks
• Para proyectos pequeños, una base de datos tradicional también puede ser suficiente

Data lake

• Un data lake se parece a una gran carpeta en la nube que conserva datos estructurados, semiestructurados y no estructurados —como CSV, Parquet, JSON, correos e imágenes— con procesamiento mínimo
• Puede construirse guardando archivos en Amazon S3, Google Cloud Storage o Azure Blob Storage, definiendo reglas de nombres y particiones, y políticas de acceso
• Si no se gestiona correctamente, puede convertirse en un pantano de datos (data swamp) difícil de encontrar o aprovechar
• Entre las opciones gestionadas están Azure Data Lake y las funciones de data lake de Snowflake
• Para consultarlo sin buscar, descargar y parsear datos directamente, se necesitan un catálogo de metadatos y un motor de consultas
  • El catálogo registra nombres de tablas, esquemas y mapeos de archivos
  • El motor de consultas lee los archivos relevantes usando esos metadatos y ejecuta consultas como SQL
• Entre los catálogos están Hive Metastore, AWS Glue Data Catalog y Unity Catalog
• Entre los motores de consulta están Apache Spark, Trino y Amazon Athena

Data lakehouse

• Un data lakehouse agrega funciones cercanas a las de un warehouse sobre un lake barato y flexible
• Su componente clave, el formato de tabla, administra la forma de almacenamiento entre el motor de consultas y los datos sin procesar
  • Maneja escrituras concurrentes, errores durante la escritura y corrupción de datos mediante ACID
  • Los datos semiestructurados también deben tener un esquema definido, y los datos completamente no estructurados no obtienen los beneficios del formato de tabla
  • Soporta evolución de esquema y control de versiones
  • Puede acelerar las consultas mediante índices y optimización de particiones
  • Algunas implementaciones soportan time travel, para consultar snapshots de un momento específico
• Al estar basado en un lake, puede ser más barato que un warehouse y no queda atado a un motor de consultas específico, pero la comparación directa de precios es difícil porque también hay que incluir los costos de cómputo por separado
• Los principales formatos de tabla son Apache Iceberg, Delta Lake y Apache Hudi
• Entre los servicios administrados están Lakehouse for Apache Iceberg de Google, Databricks e IBM watsonx.data

Orígenes e ingesta de datos

• Los datos provienen de bases de datos de aplicaciones como PostgreSQL y Mongo, API externas como Stripe, eventos de analítica del navegador, dispositivos IoT, etc.
• Después de extraerlos, pueden procesarse de inmediato; en ELT, según su forma, tamaño e infraestructura, se puede guardar primero el original en un lake, lakehouse o warehouse
• Los scripts dedicados son flexibles, pero obligan a reimplementar código repetitivo de conexión, como autenticación, paginación y manejo de errores
• Las herramientas de ingesta de datos se encargan de ese trabajo repetitivo configurando conectores de origen y destino
  • Como los datos extraídos primero deben cargarse en algún lugar, tienden a encajar en flujos ELT
  • Productos representativos son Fivetran, Airbyte y dlt
• La captura de datos modificados (CDC) captura inserciones, actualizaciones y eliminaciones desde los logs de replicación de la base de datos, sin consultar repetidamente las tablas
  • Las herramientas de ingesta la usan internamente para orígenes de bases de datos
  • Debezium se usa ampliamente como componente open source independiente

Lenguajes de procesamiento de datos

• Python es el lenguaje estándar de facto para trabajos de datos, con una gran comunidad y un ecosistema de librerías nativas
  • Incluso herramientas creadas en otros lenguajes suelen ofrecer bindings para Python; Apache DataFusion, basado en Rust, es un ejemplo
• numpy ofrece arreglos multidimensionales de alto rendimiento y sirve de base para muchas librerías
• pandas es el estándar de facto que ofrece Series unidimensionales y DataFrame bidimensionales
  • Se puede visualizar con seaborn y Plotly, y crear apps interactivas con streamlit
  • Se pueden hacer consultas SQL con DuckDB o aplicar técnicas de machine learning de scikit-learn
• R se usa en el ámbito académico, Java y Scala en frameworks de big data como Spark, y Julia y Rust también se usan para trabajos de datos, aunque con menor adopción que Python
• SQL se usa ampliamente para consultas y transformaciones en warehouses, pero la sintaxis varía un poco según el entorno de ejecución

Procesamiento batch y en tiempo real

• El procesamiento batch procesa periódicamente grandes conjuntos de datos, como el consolidado de ventas del mes pasado, y es adecuado para trabajos cuyos resultados pueden esperar horas o días
• El procesamiento en tiempo real usa procesamiento de streams al llegar los datos o microbatches, por ejemplo en intervalos de 20 segundos
• Los pipelines donde la velocidad del resultado es importante, como la detección de bots, usan procesamiento en tiempo real para identificar y bloquear usuarios lo antes posible

Transformaciones basadas en SQL

• dbt y SQLMesh definen transformaciones con sentencias SQL select y las compilan para ejecutarse en el motor de consultas real
• Ambas herramientas no procesan datos directamente, sino que se encargan de la orquestación de transformaciones
• En comparación con scripts personalizados en Python, estandarizan la forma de transformar y permiten separar trabajos complejos en modelos pequeños con dependencias
• ref de dbt referencia modelos en lugar de nombres de tabla hardcodeados y los ejecuta en el orden correcto según el grafo de dependencias
• Los resultados normalmente se almacenan en el mismo warehouse, lakehouse o lake que los datos originales, aunque también pueden enviarse a otros destinos según la configuración del motor de consultas

DataFrames locales y DuckDB

• Un DataFrame es una abstracción de arreglo bidimensional para manejar datos tabulares; en Python, pandas es la opción más usada
• Otras implementaciones incluyen Polars en Python y Rust, DataFusion en Rust, DataFrames.jl en Julia, data.frame en R y tablesaw en Java
• pandas, data.frame y tablesaw usan ejecución eager, es decir, ejecutan las operaciones en cuanto se invocan
• DataFusion y LazyFrame de Polars acumulan operaciones como un plan lógico y las ejecutan en .collect()
  • Como el plan puede optimizarse antes de ejecutarse, existe la posibilidad de que sea más rápido
• Las librerías locales están limitadas por la memoria y la CPU
  • pandas procesa todos los datos en memoria, por lo que queda limitado por el tamaño de la RAM
  • El streaming de Polars puede manejar datos más grandes que la RAM, pero algunas operaciones deben cargar el conjunto de trabajo en memoria
• DuckDB es una base de datos OLAP in-process conocida como el “SQLite para analítica”
  • Permite consultar con SQL archivos CSV y Parquet locales, así como DataFrame de pandas, sin infraestructura adicional

Procesamiento distribuido a gran escala

• Cuando se superan los límites de una sola máquina, los datos se dividen en varias partes, se procesan en paralelo en un clúster y se escala horizontalmente según la carga de trabajo
• Apache Hadoop fue una herramienta representativa en sus inicios, pero hoy se considera legacy y suele verse en entornos antiguos
• Apache Spark es hoy el estándar de facto y se encarga de carga de datos, transformación, paralelización y optimización
  • PySpark ofrece una API de DataFrame y una capa compatible con pandas
  • SparkR fue retirado recientemente; también se ofrecen bindings para Java y Scala
  • Puede leer y escribir en diversos almacenamientos, por lo que se usa tanto como motor de consultas para data lakes como para trabajos de transformación a gran escala
• Dask escala código Python a clústeres manteniéndose cerca de las API familiares de pandas y numpy
• Ray es un framework de cómputo distribuido de propósito general, usado especialmente para entrenamiento de ML
• Apache Flink también procesa batch, pero su foco principal es el procesamiento de streams

Streaming de eventos y Kafka

• El procesamiento de streams es adecuado para casos en los que se necesitan resultados inmediatos, como la detección de fraude con tarjetas de crédito, o para validar eventos de analítica web al llegar, enriquecerlos con geolocalización por IP y cargarlos en ClickHouse
• Al procesarlos apenas llegan, puede que no sea necesario guardar por separado los payloads sin procesar hasta la siguiente ejecución por lotes
• Apache Kafka es una plataforma distribuida y tolerante a fallos de streaming de eventos que recibe eventos de productores, los almacena y permite que los consumidores los lean
  • A diferencia de una cola de mensajes, los eventos no se eliminan aunque un consumidor los confirme; varios consumidores pueden leerlos repetidamente hasta que expiren las reglas de retención
  • Kafka en sí no procesa datos; trabajadores separados los procesan como consumidores
• Kafka Connect conecta Kafka con sistemas externos, como bases de datos
• Kafka Streams es una biblioteca de Java y Scala que realiza transformaciones con estado, agregaciones por ventana y joins sobre Kafka
  • Se ejecuta embebida en la aplicación y solo funciona con Kafka
• Otras plataformas de streaming de eventos incluyen Apache Pulsar, Redpanda y AWS Kinesis Data Streams

Motores de procesamiento de streams

• Apache Flink recibe la definición de las fuentes de eventos y los procedimientos de procesamiento, y se encarga del despliegue en clúster, el escalado y la recuperación ante fallos
• Un pipeline puede incluir filtrado, mapeo de campos, agregaciones por ventana, eliminación de duplicados y salida hacia otros topics de Kafka o bases de datos
• Los trabajos desplegados no son lotes que terminan, sino que siguen procesando eventos nuevos
• Otras opciones incluyen Spark Structured Streaming, Google Cloud Dataflow y Azure Stream Analytics

Orquestación de trabajos

• Cuando aumentan las transformaciones de dbt, los trabajos de Spark y los scripts personalizados, un orquestador combina los pasos individuales en un solo pipeline
• Al definir cada trabajo y sus dependencias en código, principalmente en Python, se crea un DAG, un grafo acíclico dirigido
• El orquestador no procesa datos directamente; coordina la ejecución de scripts de Spark, llamadas a transformaciones de dbt, solicitudes HTTP, etc.
• Se pueden usar disparadores basados en horarios, eventos de Kafka, ejecuciones manuales desde la UI, solicitudes HTTP o plugins
• Puede ejecutar trabajos independientes en paralelo, reintentar solo los pasos fallidos y reanudar desde ese punto
• Como está pensado para procesamiento por lotes, que se ejecuta de inicio a fin, no encaja bien con pipelines de streams que permanecen activos; en ese caso se depende del propio motor de procesamiento, como Flink
• Los productos representativos son Apache Airflow, Dagster, Prefect y Luigi
  • Luigi es más antiguo y hoy tiene menor popularidad

Observabilidad y monitoreo de calidad

• La observabilidad de datos se divide entre el estado del pipeline y la calidad de los datos en sí
  • El monitoreo del pipeline verifica si se ejecutó, si falló y cuánto tardó
  • El monitoreo de datos revisa frescura, anomalías en el volumen de datos, cambios de esquema no anunciados, etc.
• Para los pipelines se pueden usar herramientas generales de observabilidad de aplicaciones como Prometheus, Grafana y ELK, además de las funciones propias del orquestador
• Las pruebas de calidad de datos se pueden implementar con Great Expectations, donde se define directamente el formato esperado, y con dbt tests
• Los productos automatizados aprenden los patrones normales de los datos y luego detectan anomalías; ejemplos son Monte Carlo, Bigeye y Metaplane

Cargas repetidas dentro del pipeline

• El destino final de carga en ETL es un warehouse, lake o lakehouse, pero los datos no se almacenan una sola vez al final del pipeline, sino varias veces en distintas formas
• La arquitectura medallion divide el nivel de refinamiento dentro del mismo almacenamiento en tres capas
  • Bronze son los datos sin procesar tal como llegan desde la fuente
  • Silver son datos refinados y estandarizados tras correcciones de tipos, eliminación de duplicados, combinación de fuentes, etc.
  • Gold son datos agregados y modelados para un propósito específico, como dashboards o reportes
• Los analistas suelen consultar tablas Gold, mientras que los ingenieros pueden bajar hasta Bronze para depurar pipelines

Modelado dimensional

• Si la estructura medallion representa el nivel de refinamiento de los datos, el modelado dimensional organiza la forma de las tablas del warehouse
• Es un enfoque popularizado por 《The Data Warehouse Toolkit》 de Ralph Kimball, que distingue entre tablas de hechos y tablas de dimensiones
• Una tabla de hechos almacena un evento o medición por fila, como pedidos, pagos o vistas de página
  • Es larga y angosta, contiene muchos números y claves foráneas a tablas de dimensiones, y crece continuamente
• Una tabla de dimensiones almacena el contexto en el que ocurrió el evento, como clientes, productos o fechas
  • Es más ancha y cambia relativamente despacio
• Cuando tablas de dimensiones rodean una tabla de hechos central, se obtiene un esquema en estrella
  • También existe el esquema copo de nieve, más normalizado y no relacionado con el producto Snowflake
• El grano (grain) define qué representa una fila: un pedido, un ítem de pedido o los pedidos diarios por cliente
• Un data mart es una parte del warehouse orientada a un equipo o tema específico, como marketing o finanzas, y normalmente se ubica en la capa Gold
• No todos los equipos lo siguen estrictamente; algunos aprovechan los warehouses modernos rápidos y el bajo costo de almacenamiento para crear una gran tabla única ampliamente desnormalizada por propósito

OLAP en tiempo real para aplicaciones

• Para dashboards internos suelen bastar las tablas Gold del warehouse, pero cuando se atiende a muchos usuarios en milisegundos, la latencia de consulta y el costo por operación pueden no ser adecuados
• Los datos que requieren alta concurrencia y respuestas rápidas, como analítica orientada a usuarios, monitoreo interno en tiempo real, rankings, elementos populares y medición de uso, se trasladan a una base de datos OLAP en tiempo real
• Apache Druid, Apache Pinot, ClickHouse y Apache Doris entran en esta categoría, y ClickHouse se usa ampliamente

ETL inverso

• El ETL inverso envía de vuelta a herramientas operativas, como un CRM, los datos procesados en el warehouse
• Si se calcula el valor de vida del cliente con datos de Stripe y se carga en HubSpot, el equipo de ventas puede identificar de inmediato a los clientes de alto valor
• Las herramientas dedicadas conectan tablas y columnas con los campos de destino, y gestionan fallos, reintentos, límites de velocidad, alertas y sincronización incremental
• Las opciones incluyen Airbyte Data Activation, Fivetran Activations, Hightouch y RudderStack
  • Fivetran Activations se llamaba Census antes de su adquisición

Catálogos de datos y capa semántica

• Un catálogo de datos para personas contiene el origen de los datos, sus propietarios, políticas de acceso e información de búsqueda, y aporta contexto de negocio a tablas y columnas
  • Tiene un propósito distinto al de un metastore para motores de consulta
  • Unity Catalog, DataHub y OpenMetadata son ejemplos representativos
• Una capa semántica almacena definiciones estándar de entidades de negocio, relaciones y métricas
  • Unifica aspectos como de qué tablas y columnas proviene el modelo de clientes, qué mercados pertenecen a EMEA o si los reembolsos se excluyen de los ingresos
  • Cuando se eligen las entidades y métricas correctas en una herramienta de BI o un agente de IA, las convierte en las consultas necesarias o aporta la información requerida para generarlas
• LookML de Looker, Cube, dbt Semantic Layer y las funciones semánticas de Unity Catalog son algunos ejemplos

Linaje de datos

• El linaje de datos (data lineage) rastrea cómo se transforman los datos a lo largo de un pipeline
• Puede recopilarse automáticamente a partir de DAG de orquestadores, el análisis de SQL de transformación y eventos o metadatos emitidos por trabajos de procesamiento
• A nivel de tabla, registra relaciones como que gold.orders se creó a partir de silver.orders y silver.customers
• A nivel de columna, llega a rastrear relaciones como que customers.life_time_value se calculó a partir de orders.total y subscription_payments.amount
• Se usa para evaluar el impacto aguas abajo de eliminar columnas, analizar la causa raíz de métricas incorrectas y cumplir normas sobre el uso de información de identificación personal
• Unity Catalog, DataHub y OpenMetadata admiten visualización de linaje, pero todo el pipeline debe proporcionar datos de seguimiento mediante conectores o eventos manuales
• En lugar de formatos específicos de cada proveedor, se puede usar el estándar OpenLineage, compatible con varios catálogos y herramientas de procesamiento

Dashboards e informes de BI

• Los dashboards y los informes son el destino de consumo más común de los pipelines de datos, y en empresas pequeñas pueden ser prácticamente el único caso de uso
• Las herramientas de BI se conectan a warehouses, lakehouses y bases de datos de aplicaciones para permitir crear gráficos y dashboards sin escribir código
• La clave es el autoservicio, que permite a usuarios no técnicos crear o explorar gráficos directamente en la interfaz sin pedirle todo el tiempo a un analista
• Se pueden enviar informes programados por correo electrónico o Slack, o activar alertas cuando una métrica supera un umbral
• Tableau y Power BI se usan ampliamente en grandes empresas y se enfocan en visualizaciones potentes y flexibles
• Looker está orientado a organizaciones técnicas en torno a la capa semántica de LookML
• Metabase se puede configurar rápidamente, incluso con self-hosting, y es accesible para usuarios no técnicos
• Looker Studio es un producto separado que no usa LookML y tiene menos funciones que Looker; recientemente volvió a llamarse Data Studio

Analítica operativa

• La analítica operativa entrega datos dentro de las aplicaciones que usan a diario los equipos no analíticos, no en informes para la dirección
• Algunos ejemplos de uso son los siguientes
  • Sincronizar agregados de uso con HubSpot para que el equipo de ventas haga upselling a los clientes adecuados
  • Sincronizar pedidos recientes, tickets de soporte y planes con Zendesk para que el equipo de soporte vea el contexto del cliente
  • Crear una app interna que muestre el estado de adopción del producto por cliente para el equipo de customer success
• El ETL inverso es el método de entrega representativo, pero una app interna de Customer 360 que consulta directamente el warehouse también cuenta como analítica operativa

Análisis ad hoc y exploratorio, y notebooks

• El análisis ad hoc (ad-hoc analysis) investiga preguntas puntuales con datos existentes, como las causas de una caída en las altas o la cohorte que provocó reembolsos
• El análisis exploratorio consiste en revisar los datos para encontrar insights sin una pregunta predefinida
• Como la siguiente operación cambia según los resultados y suele ser más compleja que simples filtros o agregaciones, las herramientas de reportes generales pueden no ser suficientes
• Se pueden usar Python con pandas o Polars, interfaces SQL del warehouse, Spyder, RStudio, entre otros
• Los notebooks combinan celdas de Markdown, código y SQL en un solo archivo, y colocan salidas de imágenes, gráficos interactivos y tablas junto al código
  • Son útiles para explorar paso a paso viendo los resultados de ejecución y para presentar los hallazgos
  • Jupyter, Google Colab, Deepnote y marimo son ejemplos representativos
  • Plataformas como Databricks y Snowflake también ofrecen sus propios notebooks

Consumo de datos en machine learning

• ML es un campo separado con feature stores, entrenamiento, seguimiento y herramientas de despliegue, pero también es un consumidor importante de datos
• Además de los LLM, existen modelos especializados como predicción de churn, recomendaciones, previsión de demanda y segmentación de clientes, que requieren datos de entrenamiento depurados antes de llegar a producción
• Un data scientist o ML engineer toma del warehouse features como la cantidad de pedidos de los últimos 30 días o los días transcurridos desde el último inicio de sesión para entrenar y desplegar modelos
• Los resultados de predicción luego se reutilizan en analítica operativa, como un puntaje de churn en el CRM, o en recomendaciones de productos orientadas a usuarios

Analítica embebida

• La analítica embebida ofrece dentro de una aplicación análisis como productos populares, regiones de clientes o ranking de búsqueda a los vendedores de un marketplace
• Si solo se necesitan cinco gráficos predefinidos y filtros limitados, se pueden implementar directamente las consultas, la UI y la biblioteca de gráficos
• Si los usuarios necesitan hacer consultas complejas, se pueden usar herramientas de BI como Metabase, Looker o Tableau, o productos centrados en embedding como Sisense y Luzmo
• La aplicación host se encarga de la autenticación y la autorización, y la herramienta embebida maneja la interfaz de consultas y el renderizado de gráficos

Vender los datos como producto

• Los datos pueden ser más que materia prima para funcionalidades: pueden convertirse en el producto en sí
• Se pueden recopilar, transformar e indexar datos de varias blockchains de criptomonedas y vender acceso a analistas, o recopilar resultados de búsqueda de Google y venderlos a especialistas en SEO
• Para vender datos y acceso a consultas, se necesitan pipelines sólidos que recopilen a tiempo y capacidades de consulta de alto rendimiento

Gobernanza de datos

• La gobernanza de datos gestiona quién puede acceder a datos sensibles, como información de identificación personal o información de salud, y los registros de acceso
• También incluye la propiedad de los datos, el tratamiento de datos personales como el derecho al olvido, la ubicación física de almacenamiento y los períodos de retención
• Puede apoyarse en tecnologías como roles y controles de acceso en el warehouse, información de propiedad en el catálogo y seguimiento del uso de PII mediante linaje
• No es solo un problema técnico: las personas y los procesos tienen un peso importante, y está estrechamente vinculada con los equipos legales, de cumplimiento y de seguridad
• Todo el panorama de datos puede verse como un flujo que recopila datos desde las fuentes, los almacena, los procesa y los utiliza; bajo cada categoría siguen surgiendo más herramientas y opciones detalladas