[{"content":"Si alguna vez te has sentido abrumado por términos como Data Lake, Metadata o Data Governance, entonces has llegado al lugar correcto.\nEntiendo que incluso un solo concepto puede tener diferentes interpretaciones, así que mi objetivo no es definir, sino explicar estos términos de manera sencilla con ejemplos o contexto.\nData Hechos, cifras o información en bruto que se recopilan y almacenan para su posterior análisis. Esto puede incluir hechos, números, mediciones, observaciones o cualquier otro detalle que se pueda utilizar para comprender un tema en particular.\nSi estás registrando la temperatura diaria en una ciudad durante el transcurso de un mes, podrías recopilar datos sobre la temperatura, la humedad, la velocidad del viento y las precipitaciones a lo largo del día. Los datos existen en diversas formas y se pueden encontrar en situaciones cotidianas.\nMetadata Es información que describe otros datos. Proporciona detalles sobre el contenido, la calidad, la condición, el origen y otras características de un elemento específico. En el contexto digital, los metadatos pueden incluir detalles como el autor, la fecha de creación, el tamaño del archivo y palabras clave.\nSi tienes fotos en tu smartphone, abre una imagen y podrás ver metadatos como la fecha en que fue tomada, el tamaño, la ubicación, etc. La foto en sí es el dato primario, mientras que los metadatos proporcionan información complementaria sobre la foto.\nDatabase Se trata de una colección organizada de información estructurada, que normalmente se almacena y se accede a ella electrónicamente desde un sistema informático. Permite el almacenamiento, la recuperación y la manipulación eficientes de los datos.\nEl ejemplo clásico es pensar en una biblioteca. Cada libro tiene su etiqueta con su título, autor, etc. En la biblioteca, se almacenan y organizan libros, pero en lugar de libros, piense en datos. Al igual que un sistema de archivos, una base de datos ayuda a mantener la información estructurada.\nStructured Data Se refiere a información que está organizada en un formato específico, lo que facilita su comprensión tanto para humanos como para computadoras. Consiste en elementos de datos organizados en filas y columnas, como una tabla.\nUna guía telefónica contiene datos estructurados porque organiza campos específicos como nombre, número de teléfono, dirección, etc.\nUnstructured Data Se refiere a información que no tiene un formato específico. Generalmente, los datos no estructurados carecen de una estructura predefinida, lo que hace que sean más difíciles de analizar y procesar en comparación con los datos estructurados.\nImagina una pila de cartas escritas a mano. Cada carta puede contener diferentes tipos de información, como historias personales, emociones u opiniones. Estas cartas no siguen un formato estandarizado y pueden variar en longitud, estilo de escritura o lenguaje.\nEn el mundo digital, los correos electrónicos, las publicaciones en las redes sociales, las imágenes, los videos, las grabaciones de audio y los documentos de texto de formato libre son ejemplos de datos no estructurados.\nSemi-structured Data Los datos semiestructurados se encuentran entre los datos estructurados y los no estructurados. Tienen cierta organización, pero carecen del formato predefinido estricto de los datos estructurados.\nPiensa en una bandeja de entrada de correo electrónico. Cada correo electrónico consta de elementos estructurados como remitente, destinatario, asunto y marca de tiempo. Sin embargo, el cuerpo del correo electrónico puede contener información no estructurada, como texto de formato libre, archivos adjuntos o diferentes estilos de formato. Esta combinación de estructura y flexibilidad representa los datos semiestructurados.\nData Testing Es el proceso de examinar y validar datos para garantizar su calidad, precisión y fiabilidad. Implica comprobar si los datos cumplen los estándares esperados y satisfacen los criterios deseados. Básicamente, la prueba de datos es como corregir los datos para detectar errores o inconsistencias, lo que garantiza que la información con la que se trabaja sea fiable y digna de confianza.\nImagina que trabajas como cajero en un supermercado y tu trabajo consiste en registrar los precios de los diferentes productos que se venden. Data testing en este contexto implicaría verificar que el precio que introduce para cada producto sea correcto, asegurándose de que no haya errores tipográficos ni equivocaciones. Puede comparar los precios introducidos con una lista de referencia o consultar con un compañero de trabajo para validar la precisión de los datos registrados.\nDuplicate Data Se refiere a tener múltiples copias idénticas o casi idénticas de la misma información dentro de un conjunto de datos o sistemas.\nConsidera el escenario en el que estás administrando tu lista de contactos. En esa lista, almacenas nombres, números de teléfono y correos electrónicos de tus amigos. Ahora, supongamos que agregas accidentalmente el mismo contacto dos veces con un typo, lo que da como resultado datos duplicados.\nOrphaned Data Se trata de datos que existen sin ningún contexto asociado o significativo. Básicamente, son datos que carecen de conexiones o relaciones adecuadas con otros elementos de datos.\nImagina una biblioteca en la que encuentras un libro al que le falta información sobre su autor, título, etc. Este libro se convierte en un libro huérfano porque no se puede categorizar ni utilizar adecuadamente, ya que carece de los detalles que lo harían valioso dentro del sistema de la biblioteca.\nDe manera similar, en el contexto de los datos, los datos huérfanos podrían ser una entrada sin ninguna información correspondiente, como un registro de cliente sin nombre ni datos de contacto. Estos datos se vuelven difíciles de analizar o utilizar de manera efectiva porque carecen del contexto necesario.\nIncomplete or Missing Data Se trata de datos que no están completamente disponibles o carecen de cierta información necesaria. Esto implica que existen lagunas en los datos que pueden dificultar su utilidad para el análisis o la toma de decisiones.\nImagina que estás viajando y utilizas una aplicación de navegación (como Google Maps) que proporciona tiempos de viaje estimados en función de datos históricos de tráfico. Sin embargo, si la aplicación no tiene información actualizada sobre el tráfico actual o los cierres de carreteras, no podrás predecir con precisión tu tiempo de viaje.\nEn este escenario, los datos incompletos o faltantes son la ausencia de información de tráfico en tiempo real. De manera similar, en el mundo de los datos, es posible que falten datos al analizar el comportamiento del cliente si no se capturan o registran ciertas variables.\nMislabeled Data Datos que han sido etiquetados o clasificados incorrectamente, lo que genera información inexacta o engañosa. Esto significa que los datos no representan con precisión su verdadera naturaleza o significado.\nEstás organizando una colección de fotos. Tienes una carpeta llamada \u0026ldquo;Vacaciones en Europa\u0026rdquo;, pero cuando la abres, encuentras imágenes de tus vacaciones en México. En el contexto de los datos, los datos mal etiquetados ocurren cuando se asignan etiquetas incorrectas.\nData Swamp Se trata de una situación en la que una gran cantidad de datos se desorganizan, desestructuran y dificultan su uso eficaz. Es un estado en el que los datos pierden valor y se estancan o se vuelven inutilizables debido a la falta de una gestión y organización adecuadas.\nImagina que estás en una habitación llena de diversos objetos, como ropa, zapatos, libros, etc. La habitación está desorganizada, lo que hace que sea muy difícil encontrar lo que necesitas. En este ejemplo, la habitación desordenada representa un pantano de datos.\nDe manera similar, en el ámbito digital, un pantano de datos puede surgir cuando hay una cantidad abrumadora de datos desorganizados almacenados en varios sistemas, bases de datos o archivos.\nData Temperature Es una clasificación que indica con qué frecuencia se accede y utiliza un conjunto de datos. Los datos \u0026ldquo;calientes\u0026rdquo; son de acceso frecuente, los \u0026ldquo;tibios\u0026rdquo; de acceso ocasional, y los \u0026ldquo;fríos\u0026rdquo; raramente se consultan. Esta clasificación ayuda a las organizaciones a optimizar el almacenamiento y los costos, manteniendo los datos más críticos fácilmente accesibles.\nImagina el refrigerador de tu casa. Guardas la leche y los alimentos que usas diariamente al frente (datos calientes), las sobras de ayer en el medio (datos tibios), y en el congelador al fondo tienes comida que raramente usas (datos fríos).\nEn el mundo empresarial, un banco mantendría las transacciones del día actual como datos calientes en sistemas rápidos, el historial del último año como datos tibios, y las transacciones de hace 10 años como datos fríos en almacenamiento más económico.\nData Lineage Es la capacidad de rastrear el origen y el movimiento de los datos a lo largo de su ciclo de vida. Esto le ayuda a comprender de dónde provienen los datos, cómo se transforman y a dónde van, lo que le permite rastrear y analizar el flujo de datos dentro de un sistema u organización.\nEn términos simples, el linaje de datos es como rastrear los pasos de sus datos, lo que le ayuda a comprender su recorrido de principio a fin y obtener información sobre cómo se usan y se transforman a lo largo del camino.\nImagina que pides un producto en línea. La plataforma de comercio electrónico procesa tu pedido, lo que implica varios pasos como la gestión de inventario, el procesamiento de pagos y el envío. El linaje de datos en este escenario implicaría rastrear el recorrido de los detalles de tu pedido desde el momento en que realizas el pedido hasta que llega a tu puerta.\nPor ejemplo, el linaje de datos podría mostrar que los detalles de tu pedido se originaron en la base de datos de la tienda en línea, luego se trasladaron al sistema de pago y, posteriormente, al departamento de logística para el envío.\nData Migration Es el proceso de transferir datos de un sistema, aplicación o ubicación de almacenamiento a otro. Implica mover datos desde su ubicación actual a un nuevo destino, asegurando su integridad, completitud y compatibilidad. En resumen, es como mover sus datos digitales de una ubicación a otra, de manera muy similar a mover elementos físicos de una casa a otra durante una mudanza.\nEs como mudarse de una casa antigua a una nueva. Como parte de la mudanza, debe transferir todas sus pertenencias, incluidos muebles, electrodomésticos y artículos personales de su antigua casa a la nueva. La migración de datos es similar a este proceso, pero en lugar de objetos físicos, implica mover datos digitales.\nDurante la migración, es importante considerar factores como la compatibilidad del formato de datos, la seguridad de los datos y la validación de los datos para garantizar una transferencia exitosa.\nData Model Es la representación estructurada de cómo se organizan, almacenan y relacionan los datos entre sí. Define la estructura lógica, las relaciones y las restricciones que deben seguir los datos. Funciona como un plano arquitectónico que guía el diseño y construcción de un sistema de datos.\nPiensa en el plano de una casa: muestra dónde van las habitaciones, cómo se conectan, y qué reglas existen (por ejemplo, la cocina debe estar cerca del comedor).\nEn datos, si diseñas un sistema para una escuela, tu modelo mostraría que cada estudiante tiene un nombre y matrícula, cada clase tiene un código y horario, y que existe una relación entre estudiantes y clases (un estudiante puede inscribirse en varias clases).\nEmpresas como Spotify usan modelos de datos para definir cómo se relacionan usuarios, canciones, playlists y artistas en su base de datos\nData Modeling Es el proceso de creación del modelo de datos. Implica analizar los requisitos, comprender las fuentes de datos y diseñar la estructura y las relaciones de los datos.\nEl \u0026lsquo;modelado de datos\u0026rsquo; puede considerarse como la actividad de traducir conceptos y entidades del mundo real en una representación formal de un modelo de datos.\nTienes una plataforma de comercio electrónico. Al crear un modelo de datos para dicha plataforma, el modelado de datos implicaría identificar y representar entidades, relaciones y atributos clave. Por ejemplo, un usuario representaría a una persona que se registra en la plataforma y puede tener atributos como ID, nombre, información de contacto y detalles del método de pago.\nSchema Es la estructura organizacional que define cómo se almacenan y relacionan los datos en una base de datos. Incluye las tablas, columnas, tipos de datos, restricciones y relaciones entre diferentes elementos. Funciona como el plano arquitectónico que establece las reglas de organización de la información.\nPiensa en un formulario de inscripción escolar: tiene campos específicos como nombre (texto), fecha de nacimiento (fecha), grado (número), y reglas como \u0026ldquo;el nombre es obligatorio\u0026rdquo; o \u0026ldquo;la fecha no puede ser futura\u0026rdquo;.\nUn schema hace exactamente eso con los datos. En una aplicación como Instagram, el schema define que cada usuario tiene un nombre de usuario único (texto), una fecha de registro (fecha), seguidores (número), y que cada foto tiene un usuario asociado (relación), garantizando que todos los datos sigan estas reglas y estructura consistente.\nSource System Es cualquier sistema, aplicación o base de datos que genera u origina datos que posteriormente serán consumidos por pipelines de ingeniería de datos. Puede ser una base de datos transaccional (OLTP), APIs, archivos, logs, sensores IoT, o aplicaciones SaaS. Comprender los source systems es crítico porque sus características (velocidad de generación, formato, schema) dictan las estrategias de ingesta y transformación downstream.\nImagina las fuentes de agua de una ciudad: manantiales, ríos, pozos, cada uno con diferentes características (calidad, volumen, constancia). Los sistemas fuente son igual de diversos.\nUna empresa de retail tiene múltiples source systems: su aplicación web genera eventos de clicks en tiempo real (streaming), su ERP guarda transacciones de ventas (base de datos transaccional), proveedores envían archivos CSV de inventario diariamente (batch files), y sensores en tiendas físicas registran tráfico de clientes (IoT). Cada uno requiere estrategias diferentes de ingesta: APIs para la web, CDC para el ERP, procesamiento batch para CSVs, y streaming para sensores, pero todos alimentan el ecosistema de datos de la empresa.\nSlowly Changing Dimensions (SCD) Son dimensiones en un data warehouse cuyo contenido cambia lentamente y de forma impredecible a lo largo del tiempo, requiriendo estrategias específicas para rastrear cambios históricos. Los tipos más comunes son: Tipo 1 (sobrescribir), Tipo 2 (agregar nueva fila con versión histórica), y Tipo 3 (agregar columna para valores previos). La elección del tipo depende de requisitos de negocio sobre si se debe mantener historial de cambios.\nImagina que llevas un registro de tus amigos: si uno se muda de ciudad, puedes simplemente actualizar su dirección borrando la anterior (Tipo 1), o agregar una nueva línea manteniendo su dirección anterior con fechas de vigencia (Tipo 2), o agregar una columna \u0026ldquo;dirección_anterior\u0026rdquo; (Tipo 3).\nUna empresa rastrea información de clientes: Juan Pérez vive en Ciudad A desde 2020. En 2023 se muda a Ciudad B. Con SCD Tipo 2, se crea un nuevo registro indicando que la dirección en Ciudad A fue válida de 2020-2023 (marcando fin de vigencia), y la dirección en Ciudad B es válida desde 2023-presente. Esto permite analizar históricamente: \u0026ldquo;¿Cuántas ventas tuvimos en Ciudad A cuando Juan vivía ahí?\u0026rdquo; manteniendo precisión histórica en los reportes.\nData Maturity Es el nivel de desarrollo y sofisticación de las capacidades de gestión de datos de una organización. Se refiere a qué tan bien una empresa recopila, almacena, analiza y utiliza sus datos para la toma de decisiones. La madurez se evalúa generalmente en niveles progresivos, desde inicial hasta optimizado.\nPiensa en aprender a cocinar: al principio sigues recetas básicas sin entender por qué (nivel inicial), luego experimentas y mejoras técnicas (nivel intermedio), y finalmente creas tus propios platillos optimizando sabores (nivel avanzado).\nUna startup podría comenzar guardando datos en hojas de cálculo sin análisis formal, mientras que empresas maduras como Amazon tienen sistemas automatizados que predicen demanda y optimizan inventarios en tiempo real basándose en datos históricos y patrones complejos.\nData Pipeline Se trata de una serie de procesos digitales que se utilizan para recopilar, modificar y entregar datos de un lugar a otro. Consiste en ingerir datos sin procesar de diversas fuentes, como aplicaciones, dispositivos y otros canales digitales, y trasladarlos a un repositorio de datos, como un Data Lake o un Data Warehouse, para su análisis.\nPiensa que estás en una tienda en línea. Cuando realizas un pedido, el sitio necesita procesar su pedido, verificar el inventario, generar una etiqueta de envío y enviarle un correo electrónico de confirmación. Todos estos pasos son parte de un data pipeline porque el sitio toma su pedido, pasa por varias etapas y, finalmente, recibe su correo electrónico de confirmación.\nETL Es el proceso de Extraer (Extract), Transformar (Transform) y Cargar (Load) datos desde fuentes originales hacia un destino como un data warehouse. La extracción obtiene datos de diversos sistemas, la transformación los limpia y adapta al formato deseado, y la carga los almacena en el sistema objetivo. Es uno de los procesos más tradicionales y fundamentales en gestión de datos.\nImagina que eres chef y necesitas preparar una ensalada: primero extraes ingredientes del refrigerador (Extract), luego los lavas, cortas y mezclas según tu receta (Transform), y finalmente los sirves en un plato (Load).\nEn el mundo empresarial, un banco extrae transacciones diarias de múltiples sucursales y cajeros automáticos, las transforma para estandarizar formatos de moneda y fechas eliminando duplicados, y finalmente las carga en un data warehouse central donde los analistas pueden generar reportes consolidados de operaciones del día.\nELT Es el proceso de Extraer (Extract), Cargar (Load) y Transformar (Transform) datos, donde a diferencia del ETL tradicional, los datos se cargan directamente en el destino en su forma cruda y se transforman después usando el poder de procesamiento del sistema objetivo. Es más rápido y flexible que ETL, especialmente para grandes volúmenes de datos y cuando se trabaja con data warehouses modernos en la nube.​\nImagina que estás mudándote de casa: con ETL sería organizar y empacar perfectamente todas tus cosas antes de transportarlas, con ELT es llevar todo tal como está a la nueva casa y organizarlo allá donde tienes más espacio y herramientas. En el mundo real, una empresa de comercio electrónico recibe millones de registros de clickstream diarios.\n*Con ELT, cargan todos esos datos crudos directamente en su data warehouse en la nube (como Snowflake o BigQuery), y luego diferentes equipos transforman los datos según sus necesidades específicas: marketing extrae métricas de conversión, producto analiza patrones de navegación, todo usando el poder de procesamiento masivo del warehouse sin necesidad de servidores intermedios.​\nEtLT Es un enfoque híbrido que combina Extract, transform (lite), Load, Transform, realizando una transformación ligera inicial para manejar datos sensibles o cumplir requisitos de seguridad, luego carga los datos en el destino donde se realizan transformaciones complejas finales. Resuelve las limitaciones de seguridad del ELT puro manteniendo velocidad y eficiencia.​\nImagina que trabajas en un hospital mudando archivos médicos: primero remueves información sensible como números de seguro social (transform lite), luego transportas todo a la nueva ubicación (load), y finalmente organizas y procesas la información completa ya en el destino (transform).\n*Una empresa de salud necesita analizar millones de registros médicos rápidamente pero debe cumplir regulaciones estrictas. Con EtLT, primero extraen los datos y realizan transformaciones rápidas para enmascarar información personal identificable (PII) como nombres y direcciones, cargan estos datos anonimizados en su data warehouse, y ahí realizan análisis complejos integrando múltiples fuentes para identificar patrones de enfermedades sin comprometer la privacidad de pacientes.​\nIdempotency Es la propiedad de una operación o proceso que puede ejecutarse múltiples veces produciendo siempre el mismo resultado, sin importar cuántas veces se repita. En ingeniería de datos, garantiza que si un pipeline falla y se reintenta, los datos no se duplican ni corrompen. Es fundamental para construir sistemas confiables y resilientes que manejen errores de forma segura.​\nImagina que enciendes un interruptor de luz: presionarlo una vez enciende la luz, presionarlo 10 veces más no hace que la luz se vuelva \u0026ldquo;más encendida\u0026rdquo;, el resultado es el mismo.\n*En datos, un banco procesa transferencias diarias mediante un pipeline. Si el pipeline falla a mitad de ejecución y se reintenta, una operación idempotente asegura que la misma transferencia no se procese dos veces. Por ejemplo, usar \u0026ldquo;UPSERT\u0026rdquo; (actualizar si existe, insertar si no) en lugar de \u0026ldquo;INSERT\u0026rdquo; simple, o nombrar archivos con fechas únicas para que sobrescriban en lugar de duplicar. Esto permite que plataformas como Uber o Netflix reinten operaciones fallidas confiadamente sin crear registros duplicados o métricas incorrectas.​\nIncremental Load Es una técnica de carga de datos que transfiere únicamente los registros nuevos o modificados desde la última ejecución, en lugar de recargar todo el dataset. Utiliza mecanismos como Change Data Capture (CDC), timestamps o flags de actualización para identificar cambios. Es más rápido y eficiente que full load, permitiendo actualizaciones frecuentes con menor consumo de recursos.​\nImagina que llevas un diario: en lugar de reescribir todo el diario cada día, simplemente agregas la nueva página del día actual. Una empresa de e-commerce con millones de productos actualiza su catálogo constantemente.\n*Con incremental load, cada hora el pipeline identifica solo los productos que cambiaron de precio, se agregaron o se marcaron como agotados en esa hora (usando un campo \u0026ldquo;última_modificación\u0026rdquo;), y actualiza únicamente esos registros en el data warehouse. Si solo 5,000 productos de 10 millones cambiaron, el pipeline procesa 5,000 en lugar de recargar 10 millones completos, reduciendo el tiempo de carga de horas a minutos y permitiendo análisis casi en tiempo real.​\nFull Load Es una técnica de carga de datos que transfiere el dataset completo desde la fuente al destino, sobrescribiendo toda la información existente. Garantiza consistencia total de datos y es simple de implementar, pero consume más recursos y tiempo. Se usa típicamente en cargas iniciales, cuando no hay mecanismo para detectar cambios, o en datasets pequeños.​\nImagina que estás haciendo respaldo de tu teléfono: en lugar de identificar qué fotos son nuevas, simplemente copias todas las fotos cada vez. Una pequeña startup que genera reportes mensuales de 50,000 registros de ventas hace un full load: cada inicio de mes, elimina la tabla completa del data warehouse y recarga todos los datos desde cero.\n*Aunque no es la técnica más eficiente, garantiza que no haya inconsistencias y es simple de mantener. También se usa en la carga inicial cuando implementas un nuevo data warehouse o cuando ocurre un error crítico y necesitas \u0026ldquo;empezar de cero\u0026rdquo; para garantizar integridad total de datos.​\nCDC (Change Data Capture) Es una técnica que captura y rastrea cambios (inserciones, actualizaciones, eliminaciones) realizados en una base de datos en tiempo real o casi real, permitiendo replicar o sincronizar estos cambios hacia otros sistemas sin necesidad de recargar todo el dataset. Utiliza logs de transacciones o triggers para identificar modificaciones desde la última captura, facilitando pipelines eficientes de integración de datos.​\nImagina que tienes un cuaderno donde anotas todas las correcciones que haces a tus apuntes: página 5 cambié \u0026ldquo;rojo\u0026rdquo; por \u0026ldquo;azul\u0026rdquo;, página 10 agregué un párrafo, página 3 borré una línea. En lugar de reescribir todo el cuaderno, solo compartes esa lista de cambios. Una empresa de e-commerce tiene una base de datos transaccional donde se actualizan precios, inventarios y órdenes constantemente.\n*Con CDC, cada cambio en la base de datos se captura automáticamente mediante los logs de transacciones (como el binlog en MySQL) y se transmite en tiempo real a sistemas analíticos o data warehouses. Si un producto cambia de precio de $100 a $80, CDC captura ese cambio específico y lo replica, sin necesidad de leer toda la tabla de productos cada vez.​\nDead Letter Queue (DLQ) Es un mecanismo de almacenamiento temporal para mensajes o registros que no pueden ser procesados exitosamente por un pipeline después de múltiples reintentos. En lugar de perder estos datos o detener el pipeline completo, los registros problemáticos se envían a una cola especial donde pueden ser investigados, corregidos y reprocesados posteriormente sin afectar el flujo principal de datos.\nImagina una línea de producción de una fábrica: si una pieza está defectuosa y no puede pasar por el proceso normal, en lugar de detener toda la línea, la apartan en una bandeja especial para revisión posterior.\nUn pipeline de ingesta de eventos de comercio electrónico procesa millones de transacciones diarias. Ocasionalmente llegan registros con formatos inesperados que causan errores. En lugar de fallar todo el pipeline, estos registros se envían automáticamente a una DLQ en Amazon SQS. El equipo revisa semanalmente la DLQ, identifica patrones de errores, corrige el código de validación, y reprocesa los registros corregidos sin haber perdido ninguna transacción ni interrumpido el servicio.\nData Deduplication Es el proceso de identificar y eliminar registros duplicados de un dataset para garantizar que cada ocurrencia se procese solo una vez. En pipelines batch, la deduplicación analiza el dataset completo; en pipelines streaming, utiliza ventanas de tiempo para mantener un estado de registros ya procesados. Requiere definir atributos de deduplicación que garanticen la unicidad de cada registro.​\nImagina que tienes un cuaderno donde anotas tus gastos diarios, pero a veces escribes la misma compra dos veces por error. La deduplicación sería revisar tu cuaderno y eliminar las entradas repetidas dejando solo una.\n*Una plataforma de streaming como Netflix recibe eventos de visualización de usuarios que, debido a reintentos automáticos de la red, pueden llegar duplicados. Un sistema de deduplicación identifica eventos con el mismo ID de usuario, video y timestamp, retiene solo el primero, y descarta los duplicados, asegurando que las métricas de visualizaciones sean precisas. Para streaming, el sistema mantiene una ventana temporal (por ejemplo, últimos 10 minutos) donde recuerda IDs ya procesados, balanceando precisión con uso de recursos.​\nData Compaction Es el proceso de optimizar el almacenamiento combinando múltiples archivos pequeños en archivos más grandes para mejorar el rendimiento de lectura y reducir overhead de metadatos. Es especialmente crítico en sistemas que escriben datos incrementalmente o en streaming, donde se generan miles de archivos pequeños que degradan el rendimiento de consultas. No modifica los datos, solo reorganiza su disposición física.​\nImagina que guardas documentos importantes: en lugar de tener 100 carpetas con una sola hoja cada una, es mejor consolidarlas en 5 carpetas con 20 hojas cada una, facilitando encontrar información.\n*Un pipeline de streaming procesa eventos de IoT cada minuto, generando 1,440 archivos pequeños diarios (uno por minuto). Después de un mes, acumula 43,200 archivos diminutos. Consultar este dataset se vuelve extremadamente lento porque el sistema debe abrir miles de archivos. Un proceso de compactación periódico (por ejemplo, cada hora) combina esos 60 archivos pequeños en uno solo más grande, reduciendo de 43,200 a 720 archivos mensuales, mejorando dramáticamente la velocidad de consultas sin perder información.​\nQuery Es una solicitud o consulta que se realiza a una base de datos para recuperar, manipular o actualizar información específica. Las queries se escriben típicamente en lenguajes especializados como SQL (Structured Query Language) y permiten filtrar, ordenar, agregar y transformar datos según las necesidades del usuario.\nImagina que estás en una biblioteca enorme y le dices al bibliotecario exactamente qué libro quieres: \u0026ldquo;Dame todos los libros de ciencia ficción publicados después del 2020\u0026rdquo;. Eso es una query.\nEn datos, si trabajas en una tienda de comercio electrónico y necesitas saber cuántos productos se vendieron ayer con un precio mayor a $100 en la región norte, escribirías una query que busca esa información específica en la base de datos y te devuelve exactamente esos resultados en segundos.\nData Contract Es un documento que define la estructura, el formato, la semántica, la calidad y los términos de uso para el intercambio de datos entre un proveedor de datos y sus consumidores. Ayuda a garantizar que los datos sean coherentes, confiables y comprensibles en diferentes sistemas.\nTu eres un chef que necesita otros ingredientes de un proveedor. En este caso, un contrato de datos sería una lista de compras detallada que especifica claramente el tipo de ingredientes, la cantidad necesaria, etc.\nAhora bien, en el campo de los datos, diferentes sistemas necesitan compartir o intercambiar datos. Para garantizar una comunicación fluida, un contrato ayuda a definir la estructura y las reglas para los datos que se comparten. Especifica aspectos como el formato de los datos (por ejemplo, CSV, JSON), los campos y sus tipos, cualquier regla de validación o restricción y el comportamiento esperado.\nData Entropy Describe la cantidad de incertidumbre o desorden en un conjunto de datos. Cuanto mayor sea la entropía, mayor será la aleatoriedad y la falta de patrones en los datos.\nTienes una baraja de cartas que está perfectamente ordenada del as al rey en cada palo. En este caso, la entropía de los datos es baja porque el orden es predecible y no contiene mucha aleatoriedad. Ahora, consideremos una baraja de cartas barajada donde las cartas están en un orden aleatorio. En este caso, la entropía de los datos es alta porque el orden es impredecible y contiene más aleatoriedad.\nData Debt Es la acumulación de problemas que surgen de prácticas inadecuadas de gestión de datos. Similar a la deuda técnica, resulta de descuidar el mantenimiento de activos de datos, generando inconsistencias, redundancias e imprecisiones. Con el tiempo, esta deuda se vuelve costosa de resolver y afecta la confiabilidad de las decisiones.\nImagina que empiezas guardando recetas en servilletas, post-its y cuadernos diferentes sin orden. Al principio funciona, pero después de meses no encuentras las recetas y tienes versiones contradictorias de la misma.\nEn el ámbito empresarial, un equipo de ciencia de datos presionado por entregar resultados rápidos decide acceder directamente a bases de datos de origen sin estándares ni mejores prácticas, creando pipelines improvisados. Con el tiempo acumulan múltiples versiones de la misma métrica, nadie sabe cuál es correcta, y los costos de mantenimiento se disparan.\nData Silo Los silos de datos son una colección de datos que está controlada por un departamento o unidad de negocios y aislada del resto de la organización. Normalmente, los datos terminan almacenándose en un sistema separado y, a menudo, son incompatibles con otros conjuntos de datos, lo que dificulta que los usuarios de otras partes de la organización accedan a ellos y los utilicen.\nImagina que tienes varias piezas de rompecabezas esparcidas en diferentes habitaciones de tu casa. Cada habitación representa un departamento diferente dentro de una empresa y las piezas del rompecabezas representan datos.\nEn el escenario del silo de datos, cada departamento tiene su propia pieza del rompecabezas que está separada de las demás. Las piezas de una habitación no son accesibles ni compartidas con otras habitaciones. Esto significa que cada departamento tiene su propio conjunto de datos que está aislado del resto de la organización.\nData Virtualization Es una tecnología que integra datos de múltiples fuentes creando una capa virtual unificada sin necesidad de mover o copiar físicamente la información. Permite a usuarios y aplicaciones acceder a datos en tiempo real desde su ubicación original, abstrayendo la complejidad técnica de dónde y cómo están almacenados. Incluye funcionalidades avanzadas como cacheo, seguridad y optimización de consultas.\nImagina que tienes fotos en tu teléfono, computadora y en la nube, pero usas una aplicación que te muestra todas juntas como si estuvieran en un solo lugar sin tener que copiarlas. En una empresa de retail, los datos de ventas están en un sistema, inventario en otro, y datos de clientes en la nube.\nCon virtualización, los analistas consultan todo desde una interfaz única que presenta los datos como si estuvieran en un solo lugar, obteniendo información en tiempo real sin crear copias costosas ni procesos ETL complejos.\nData Federation Es una técnica específica de integración que permite consultar y acceder a múltiples bases de datos distribuidas como si fueran una sola fuente unificada. Los datos permanecen en sus sistemas originales sin moverse, y las consultas se traducen y ejecutan en cada fuente, agregando los resultados de manera transparente para el usuario. Es un componente de data virtualization enfocado en bases de datos.\nImagina una red de bibliotecas públicas donde cada sucursal mantiene sus propios libros, pero tú puedes buscar en un catálogo unificado y solicitar cualquier libro de cualquier sucursal sin necesidad de visitarlas todas. Una empresa multinacional con oficinas en diferentes países mantiene bases de datos locales para cumplir regulaciones regionales.\nCon data federation, los ejecutivos globales pueden ejecutar reportes que consultan automáticamente todas las bases regionales simultáneamente, obteniendo resultados consolidados sin centralizar físicamente los datos ni violar regulaciones de residencia de datos.\nData Management Es el proceso de recopilar, almacenar, organizar y utilizar datos de una manera segura, eficiente y rentable.\nTienes una gran colección de fotos familiares almacenadas en tu computadora. Para administrar mejor tu colección, crea carpetas y subcarpetas para categorizar las fotos según eventos (probablemente separa las carpetas por cumpleaños, vacaciones, etc.). Si deseas encontrar una foto en particular, es mucho más fácil navegar hasta la carpeta correspondiente en lugar de buscar las fotos una por una.\nDe manera similar, en la administración de datos, los datos deben organizarse, etiquetarse y almacenarse en sistemas apropiados. Esto lleva a definir estructuras de datos, establecer convenciones de nomenclatura de datos, determinar controles de acceso e implementar mecanismos de copia de seguridad y recuperación de datos.\nMaster Data Management Es un proceso y un conjunto de prácticas destinadas a crear y gestionar un único \u0026lsquo;golden record\u0026rsquo; de entidades de datos importantes dentro de una organización para garantizar la coherencia, la precisión y la fiabilidad. Un MDM proporciona una visión unificada de los datos en varios sistemas para satisfacer las necesidades de una empresa.\nFormas parte de una empresa minorista que opera varias tiendas y una plataforma en línea. En esta empresa, tienes datos de clientes dispersos en diferentes sistemas y bases de datos (como registros de ventas, programas de fidelización y registros en línea). Sin una gestión de datos maestros adecuada, puedes terminar teniendo registros duplicados o inconsistencias en la entidad del cliente (por ejemplo, tiene a John Smith, y en el sistema de ventas tiene diferentes entradas, programa de fidelidad y sistema de registro en línea con diferentes variaciones en el nombre, información de contacto, etc.)\nEntonces, la empresa decide abordar este problema mediante la creación de un MDM. Decide crear un repositorio central que actúe como la única fuente de verdad para los datos de los clientes. En este sistema de gestión de datos maestros, se consolidan, estandarizan y eliminan los duplicados de distintas fuentes. De esta manera, en lugar de tener múltiples versiones de los registros de \u0026lsquo;Juan Hernandez\u0026rsquo;, el MDM garantiza que solo exista un registro consolidado y preciso.\nData Democratization Significa que todos en la organización pueden acceder, comprender y usar los datos para tomar decisiones sin depender exclusivamente de especialistas en datos o departamentos de TI. Elimina los silos de datos y promueve la colaboración entre diferentes usuarios, empoderando a los equipos con autoservicio analítico.\nImagina una biblioteca donde antes tenías que pedirle al bibliotecario cada libro que querías consultar, y él decidía si te lo daba. Democratización sería que ahora puedes entrar, buscar y tomar los libros tú mismo.\nUna empresa de comercio electrónico tenía un equipo de análisis centralizado donde marketing, ventas y operaciones debían solicitar e interpretar datos. Al implementar democratización, introdujeron herramientas de autoservicio con interfaces fáciles donde cada departamento ahora puede generar sus propios reportes y análisis sin involucrar al equipo de análisis en cada paso.\nData Catalog Es un inventario organizado de activos de datos que utiliza metadatos para ayudar a una organización a administrar sus datos. Piense en él como un repositorio centralizado donde puede encontrar información relevante para sus necesidades de datos, ya que lo ayuda a comprender qué datos están disponibles, dónde se encuentran y cómo puede acceder a ellos.\nEstás en una tienda minorista. Un catálogo de datos tendría información de varias fuentes de datos, como datos de ventas, datos de clientes, datos de inventario, etc. Esto tendría detalles como qué conjunto de datos tienen, cuándo se actualizó por última vez, quién lo administra y metadatos relevantes.\nUn catálogo de datos abarca una gama más amplia de información sobre varios activos de datos en toda la organización, incluidos metadatos, linaje de datos, calidad de datos e información de acceso. El objetivo es proporcionar una vista integral del panorama de datos de la organización.\nData Dictionary Se centra en proporcionar definiciones y descripciones de elementos de datos específicos dentro de una base de datos o conjunto de datos. Le ayuda a comprender el significado y el formato de los elementos de datos individuales.\nTienes una aplicación de gestión de contactos y desea almacenar información sobre tus amigos. Para cada amigo, deseas almacenar su nombre, número de teléfono y dirección de correo electrónico.\nUn diccionario de datos te ayudaría a obtener una descripción general de los datos disponibles, te ayudaría a identificar recursos relevantes y te permitiría ver detalles técnicos como esquemas, formatos de datos, mantenedores, etc.\nData Ops Es la aplicación de prácticas de DevOps (desarrollo y operaciones) al ciclo de vida de los datos, enfocándose en mejorar la colaboración, automatización, monitoreo y calidad de los pipelines de datos. Combina metodologías ágiles, control de versiones, integración continua, testing automatizado y observabilidad para entregar datos confiables más rápidamente y con menos errores.\nImagina una fábrica moderna con líneas de producción automatizadas, sensores que detectan defectos, y sistemas que alertan inmediatamente si algo sale mal, en lugar de una fábrica antigua donde todo se hace manualmente y los problemas se descubren días después.\nUn equipo de data engineering implementa DataOps cuando versiona sus pipelines en Git (como código), ejecuta tests automatizados antes de desplegar cambios en producción, monitorea la calidad de datos en tiempo real con alertas cuando aparecen anomalías, y puede revertir cambios problemáticos en minutos. Esto contrasta con equipos que modifican pipelines manualmente, descubren errores semanas después cuando usuarios reportan números incorrectos, y tardan días en identificar qué salió mal.\nData Orchestration Es el proceso coordinado de automatizar, programar y gestionar múltiples tareas y flujos de trabajo de datos para que se ejecuten en el orden correcto, con las dependencias apropiadas y en el momento adecuado. Actúa como el director de una orquesta que asegura que cada instrumento (pipeline, transformación, validación) toque en el momento preciso para crear una sinfonía armoniosa de flujo de datos.\nImagina organizar una cena grande: primero compras ingredientes, luego preparas entradas mientras el plato principal se cocina, y finalmente sirves el postre cuando todos terminan. No puedes servir el postre antes de las entradas. La orquestación de datos funciona igual: coordina tareas secuenciales y paralelas.\nUna empresa de e-commerce ejecuta diariamente: extraer datos de ventas a las 2 AM, transformarlos a las 3 AM (después de la extracción), cargar métricas a las 4 AM, y finalmente enviar reportes ejecutivos a las 6 AM. Herramientas como Apache Airflow o Prefect automatizan esta coordinación, reintentando tareas fallidas, enviando alertas cuando algo falla, y asegurando que cada paso espere a que el anterior complete exitosamente antes de ejecutarse.\nData Governance Son las políticas, reglas y prácticas que garantizan la calidad, integridad y seguridad de los datos dentro de una organización. Incluye la catalogación de datos, la definición de estándares, y los procesos que regulan cómo se utilizan, acceden y mantienen los datos.\nImagina una biblioteca pública bien organizada: hay reglas sobre quién puede sacar libros, cuánto tiempo pueden tenerlos, y cómo se catalogan.\nEn el mundo empresarial, un hospital implementa gobernanza cuando establece quién puede acceder a los registros médicos, cómo se protegen, qué información es confiable para decisiones médicas, y quién es responsable si surgen problemas con los datos de pacientes.\nData Owner El individuo o entidad que tiene la responsabilidad y el control final sobre activos de datos específicos. El propietario de los datos suele ser responsable de determinar quién tiene acceso a los datos, garantizar su precisión y seguridad, y definir su uso permitido.\nUn ejemplo podría ser un hospital, donde el médico jefe o el administrador del hospital pueden ser designados como el propietario de los datos de los registros médicos de los pacientes. Serían responsables de supervisar quién puede acceder a los registros, mantener su confidencialidad y garantizar el cumplimiento de las normas de protección de datos.\nData Steward Se trata de una persona responsable de gestionar y garantizar la calidad, la seguridad y el uso de los activos de datos de una organización. Por lo general, establece y aplica políticas y procedimientos de gestión de datos, supervisa la integración de datos y facilita el cumplimiento normativo.\nEres la persona a cargo de una institución financiera que supervisa la protección y privacidad de los datos de los clientes. Es responsable de garantizar que los datos de los clientes se gestionen de acuerdo con los requisitos legales, los estándares de la industria y las políticas internas, actuando así como un administrador de datos para los datos financieros confidenciales de la organización.\nData Guardian Hace referencia a una función, política o tecnología específicamente designada para proteger la integridad, confidencialidad y disponibilidad de los datos. Esto podría incluir la gestión de permisos, la implementación de medidas de seguridad y el control del acceso a los datos.\nImagina que has dejado tu casa al cuidado de un vecino de confianza mientras estás de vacaciones. Este vecino vigila tu casa, riega tus plantas y se asegura de que no entren visitantes no deseados. En este escenario, tu casa y tus pertenencias son tus datos, y el vecino es el guardián de los datos que mantiene todo seguro y en orden hasta que regreses.\nEn un entorno de datos, un guardián de datos es crucial. Un guardián supervisaría los registros de los pacientes, los tipos de datos sensibles que requieren una protección rigurosa. El guardián se aseguraría de que los datos médicos estén encriptados, de que el acceso se registre y analice para detectar actividades no autorizadas, y de que los datos se compartan de forma segura con las partes autorizadas.\nData Security Se refiere a la protección de los datos digitales contra el acceso no autorizado, la corrupción o el robo a lo largo de su ciclo de vida. Implica la implementación de medidas como el cifrado, los controles de acceso y la supervisión para salvaguardar la información confidencial y evitar infracciones o divulgaciones no autorizadas.\nUna institución financiera cifra los datos financieros de los clientes e implementa controles de acceso estrictos para evitar que personas no autorizadas vean o modifiquen los datos. Esto ayuda a proteger la información financiera confidencial de los clientes de las amenazas cibernéticas y las posibles infracciones de datos.\nData Privacy Se trata de respetar los derechos y preferencias de las personas en relación con el uso y el manejo de sus datos personales. Es el manejo responsable de la información personal de las personas, garantizando que sus datos estén protegidos contra el acceso, uso o divulgación no autorizados.\n\u0026ldquo;No necesitas privacidad si no tienes nada que ocultar\u0026rdquo;. Esta es una mala manera de interpretar la privacidad porque crea la sensación de que las personas que exigen privacidad deben ser delincuentes. Todos sabemos lo que pasa cuando vas a bañarte pero aún así cierras la puerta. Un ejemplo de privacidad de datos es cuando un minorista en línea recopila información personal de los clientes para procesar pedidos, pero garantiza que estos datos se almacenan de forma segura y que se obtiene el consentimiento de los clientes para las comunicaciones de marketing.\nData Lifecycle Se refiere a las etapas por las que pasa la información desde su creación o captura inicial hasta su eliminación o archivo final. Estas etapas suelen incluir la creación de datos, el almacenamiento, el uso, el intercambio, el archivo y la eliminación.\nEs como el recorrido de un libro: desde que el autor lo escribe, pasando por su publicación, la lectura por parte de la gente, el almacenamiento en una biblioteca y, posiblemente, el desmantelamiento.\nEn el ámbito de los datos, un ejemplo del ciclo de vida de los datos sería la información de productos de una empresa minorista. Comienza con la creación de la información del producto, luego se almacena en una base de datos, se utiliza para las ventas en línea, se comparte con los proveedores, se archiva para el análisis histórico y, finalmente, se elimina cuando el producto ya no está disponible.\nData Engineering Lifecycle El ciclo de ingeniería de datos implica la recopilación, el almacenamiento, el procesamiento, el análisis y el mantenimiento de la infraestructura. Se descubren las fuentes, se define el almacenamiento, se define la ingesta, se transforma y, finalmente, se pone a disposición la información.\nUna empresa de comercio electrónico ingiere datos de múltiples fuentes, los transforma, los integra, realiza análisis y visualiza la información para tomar mejores decisiones. Es un proceso iterativo e implica un seguimiento y una mejora continuos.\nData Sources Se refiere a la fuente o ubicación de la que se recopilan o extraen datos para su uso en análisis, informes o toma de decisiones.\nLas fuentes de datos se pueden comparar con los diferentes ingredientes que se utilizan en la cocina, como frutas, verduras y especias, que se recopilan de varias ubicaciones para crear una receta.\nEn el mundo de los datos, un ejemplo de fuentes de datos es una empresa que recopila información de sistemas dispares, como transacciones de ventas de un sistema de punto de venta, datos de clientes de una plataforma CRM y datos de tráfico web de una herramienta de análisis, para el análisis y la elaboración de informes comerciales.\nData Storage Es un lugar centralizado donde se recopilan y combinan datos de múltiples fuentes. Conlleva conservar los datos en un formato estructurado para acceder a ellos y utilizarlos en el futuro.\nEs como encontrar un lugar para guardar tus libros en una librería para que luego puedas encontrarlos y usarlos cuando los necesites. En el mundo digital, este concepto implica el uso de sistemas o dispositivos para almacenar y recuperar información digital.\nData Ingestion Es el proceso de recopilar, importar y transferir datos de varias fuentes a un sistema informático o de almacenamiento para su posterior procesamiento y análisis.\nEs como recopilar y organizar ingredientes de diferentes proveedores y llevarlos a la cocina de un restaurante para preparar comidas.\nAhora bien, en materia de datos, un ejemplo sería una empresa minorista que recopila datos de ventas de varias tiendas y canales en línea y los incorpora a un almacén de datos centralizado para su análisis y elaboración de informes.\nData Integration Se centra en combinar datos de distintas fuentes en una vista unificada y coherente. Su finalidad es establecer un modelo de datos común.\nDe la misma forma en que se juntan piezas de un rompecabezas de distintos lugares para completar el cuadro, la integración de datos unifica las fuentes. Un ejemplo sería una empresa que fusiona datos de clientes de un CRM, datos de ventas de un sistema ERP y datos de marketing de campañas digitales para crear una vista integral para el análisis y la toma de decisiones comerciales estratégicas.\nData Transformation Es el proceso de convertir datos de un formato, estructura o sistema a otro para que sean utilizables y compatibles con el destino final. Incluye actividades como limpiar, normalizar, agregar, filtrar o enriquecer los datos. Es una etapa crítica en cualquier pipeline de datos para asegurar que la información esté lista para el análisis o almacenamiento.\nImagina que recolectas recetas de cocina de diferentes países: unas están en tazas, otras en gramos, algunas en celsius y otras en fahrenheit. Transformar sería convertir todo a un sistema único (por ejemplo, todo a gramos y celsius) para poder comparar recetas fácilmente.\nEn el mundo real, una empresa de comercio electrónico recibe datos de ventas de múltiples tiendas con formatos diferentes: algunas usan \u0026ldquo;USD\u0026rdquo;, otras \u0026ldquo;$\u0026rdquo;, las fechas varían entre \u0026ldquo;DD/MM/YYYY\u0026rdquo; y \u0026ldquo;MM-DD-YY\u0026rdquo;. El proceso de transformación convierte todo a un formato estándar para que los analistas puedan crear reportes consolidados precisos.\nData Serving Es el proceso de hacer que los datos procesados y transformados sean accesibles y estén disponibles para los usuarios finales o aplicaciones de manera eficiente y en el formato adecuado. Implica proporcionar acceso mediante APIs, dashboards, reportes o consultas directas, asegurando que la información llegue rápidamente a quien la necesita.\nImagina que estás en un restaurante: los chefs preparan la comida en la cocina y, cuando está lista, los meseros la sirven en tu mesa de forma presentable y a la temperatura correcta. En datos, los usuarios son los clientes y los datos procesados son los platillos listos para consumir. Una empresa de logística procesa millones de datos de entregas cada día.\nEl equipo de Data Serving se encarga de que los gerentes de operaciones puedan consultar en tiempo real cuántos paquetes están en tránsito, los equipos de servicio al cliente vean el estatus de envíos específicos, y los ejecutivos accedan a dashboards con métricas clave, todo sin tocar las bases de datos originales directamente.\nStaging Data Es el proceso de almacenar y preparar temporalmente datos para cargarlos en un almacén de datos, lago de datos u otro repositorio de datos.\nEs como preparar y organizar todas las herramientas, equipos y materiales necesarios antes de comenzar un proyecto en el hogar, como pintar una habitación o ensamblar muebles. Implica tener todo listo y organizado para facilitar la ejecución fluida del proyecto.\nEn datos, sería almacenar y estructurar datos sin procesar de varias fuentes en un área de preparación antes de integrarlos en una plataforma unificada de almacenamiento o análisis.\nData Warehouse Es un repositorio centralizado diseñado específicamente para almacenar grandes volúmenes de datos estructurados e históricos provenientes de múltiples fuentes. Está optimizado para consultas analíticas complejas, generación de reportes y toma de decisiones estratégicas. A diferencia de bases de datos transaccionales, su enfoque no es procesar operaciones en tiempo real sino facilitar análisis históricos y tendencias.\nImagina que tienes una biblioteca personal donde guardas libros desordenadamente en diferentes habitaciones. Cuando quieres investigar un tema, pierdes horas buscando. Un data warehouse sería consolidar todos los libros en una biblioteca organizada con un catálogo único donde encuentras todo rápidamente.\nUna cadena de retail como Walmart recibe datos diarios de miles de tiendas (ventas, inventario, devoluciones), sitios web (clicks, carritos), proveedores (entregas, precios) y redes sociales (menciones). El data warehouse centraliza y organiza toda esta información histórica en un formato optimizado donde analistas y ejecutivos pueden generar reportes consolidados comparando ventas de este trimestre vs años anteriores, identificar productos de bajo rendimiento, o analizar patrones de compra por región sin tocar los sistemas operacionales.\nOLAP Online Analytical Processing (OLAP) es una tecnología diseñada para realizar análisis multidimensionales complejos y consultas sobre grandes volúmenes de datos históricos. Está optimizado para lectura, agregaciones rápidas y análisis de tendencias, soportando operaciones como drill-down, slice-and-dice y pivot. Es la base de Business Intelligence y reportes analíticos.\nImagina un cubo Rubik donde cada cara representa una dimensión de análisis: puedes girar y ver datos de ventas por región, luego por producto, luego por mes, todo instantáneamente.\nUna cadena de supermercados usa OLAP para analizar ventas: los ejecutivos pueden ver ventas totales del año, hacer drill-down a un trimestre específico, filtrar por categoría de productos, comparar regiones, y pivotar para ver todo por línea de tiempo o por tienda, todo en segundos sin esperar que se procesen millones de transacciones porque OLAP ya tiene los datos precalculados y organizados para análisis rápidos.\nOLTP Online Transaction Processing (OLTP) es un sistema diseñado para gestionar y procesar transacciones operacionales en tiempo real con alta velocidad y concurrencia. Está optimizado para operaciones de escritura frecuentes, consultas simples y rápidas, garantizando integridad de datos mediante propiedades ACID. Maneja las operaciones diarias del negocio como ventas, reservas o actualizaciones de inventario.\nImagina la caja registradora de una tienda: necesita procesar cada compra instantáneamente, actualizar inventario, registrar pago, y garantizar que todo sea preciso sin errores. Eso es OLTP.\nCuando compras un boleto de avión en línea, el sistema OLTP procesa tu reservación en segundos: verifica disponibilidad de asiento, bloquea ese asiento para que nadie más lo tome, registra tu pago, actualiza inventario, y confirma tu compra, todo garantizando que si dos personas intentan reservar el mismo asiento simultáneamente, solo una lo obtenga. Este tipo de sistema maneja miles de transacciones concurrentes por segundo con precisión absoluta.\nData Mart Es un subconjunto del Data Warehouse de una organización que está diseñado para servir a una línea de negocio o departamento específico.\nEs como una sección especializada en una biblioteca que contiene libros, revistas y recursos enfocados en un tema o asunto específico, satisfaciendo las necesidades de un grupo particular de lectores.\nSi ponemos el tema de datos en contexto, un ejemplo práctico de un Data Mart es un departamento de ventas que tiene su propio Data Mart dentro del Data Warehouse de la empresa, dedicado a almacenar y analizar datos relacionados con las ventas para los requisitos específicos de análisis e informes del departamento.\nData Lake Es un repositorio que puede recopilar una gran cantidad de datos estructurados, semiestructurados y no estructurados que se almacenan hasta que se necesitan para su procesamiento o análisis.\nVas de viaje a una playa y tienes varias fotos de dónde estuviste. En lugar de organizar tus fotos, las envías a tu Data Lake donde estarán disponibles en su estado original. Cuando quieras clasificarlas, puedes elegir qué fotos y organizarlas según tus necesidades.\nData Lakehouse Es una arquitectura moderna de gestión de datos que combina elementos de un Data Lake y un Data Warehouse. Permite almacenar grandes volúmenes de datos estructurados y no estructurados como un lago, pero también soporta consultas y análisis eficientes típicos de un almacén. Unifica flexibilidad y rendimiento en una sola plataforma.\nImagina que tienes una biblioteca donde algunos libros están organizados por categoría (estructurados) y otros están en cajas sin ordenar (no estructurados). Un lakehouse sería como tener ambos en el mismo edificio con un sistema que te permite buscar rápidamente en ambos tipos.\nNetflix maneja datos masivos de usuarios, preferencias, streaming y metadata de contenido. Con un lakehouse, pueden almacenar todo en un solo lugar y realizar análisis complejos para recomendar películas y optimizar la calidad del streaming sin mover constantemente los datos entre diferentes sistemas.\nData Platform Es una infraestructura tecnológica que permite la recopilación, el almacenamiento, la gestión y el análisis de datos de diversas fuentes para respaldar las operaciones comerciales y la toma de decisiones.\nUna plataforma de datos se asemeja a un panel de control central que reúne varias herramientas y sistemas, lo que permite a los usuarios acceder, administrar y analizar los datos de manera eficaz, como un único panel para múltiples funciones.\nUna plataforma de datos agiliza el proceso de recopilación, gestión y almacenamiento de datos, haciéndolos accesibles y utilizables para una variedad de aplicaciones. Proporciona gestión de datos en toda la extensión del entorno, incluidas funciones críticas para el negocio, como la seguridad y la observabilidad.\nSin una plataforma de datos, cada componente suele ser manejado por una herramienta o conjunto de herramientas diferente para hacer que los datos fluyan desde la fuente hasta el usuario final en un entorno complejo.\nData Fabric Es una arquitectura unificada que proporciona acceso, gestión y gobernanza consistente de datos a través de toda la organización mediante una \u0026ldquo;tela\u0026rdquo; o red que conecta diversas fuentes de datos. Permite integrar, transformar y compartir datos sin problemas independientemente de su ubicación, automatizando muchas tareas de gestión de datos mediante inteligencia artificial y metadatos.​\nImagina una red eléctrica de una ciudad: no importa si la electricidad viene de paneles solares, una represa o carbón, todos están conectados a una red única que distribuye energía a cualquier hogar que la necesite de forma transparente.\n*Una empresa multinacional tiene datos en bases de datos locales, aplicaciones en la nube, sistemas legacy y data lakes. Con data fabric, crean una capa inteligente que conecta automáticamente todas estas fuentes, permitiendo que un analista en México consulte datos de servidores en Europa y Asia sin saber siquiera dónde están físicamente, todo con gobernanza centralizada y transformaciones automatizadas.​\nData Mesh Es un enfoque descentralizado de arquitectura de datos que distribuye la propiedad, el acceso y la gobernanza de los datos entre diferentes dominios o unidades de negocio dentro de una organización. En lugar de tener un equipo centralizado que controla todos los datos, cada área es responsable de sus propios datos como productos independientes pero colaborativos.\nImagina una ciudad donde en lugar de tener una sola biblioteca gigante controlada centralmente, cada barrio tiene su propia biblioteca que administra sus propios libros, pero todas comparten un catálogo común y reglas similares de préstamo. Si necesitas un libro de otro barrio, puedes solicitarlo fácilmente.\nEn una empresa grande como Spotify, en lugar de que un solo equipo de datos centralizado gestione toda la información, el equipo de podcasts administra sus datos, el equipo de música los suyos, y el equipo de usuarios los propios, pero todos colaboran usando estándares compartidos para que los datos fluyan entre áreas cuando sea necesario.\nData Sharing Es el proceso de poner los mismos recursos de datos a disposición de múltiples aplicaciones, usuarios u organizaciones. Conlleva tecnologías, prácticas, marcos legales y elementos culturales que facilitan el acceso seguro a los datos para múltiples entidades sin comprometer la integridad de los datos.\nData Sharing mejora la eficiencia dentro de una organización y fomenta la colaboración con proveedores y socios. Permite a las partes interesadas aprender unas de otras y colaborar en prioridades compartidas.\nData Sharing puede ir desde artículos de investigación o publicaciones académicas hasta estadísticas corporativas, datos científicos o revisiones anuales de desempeño.\nData Product Es una aplicación o herramienta de software que utiliza datos para brindar información, servicios o funcionalidades valiosas a los usuarios u otros sistemas.\nEs como una aplicación de un smartphone que utiliza datos de ubicación para ofrecer recomendaciones personalizadas de restaurantes cercanos, lo que ayuda a los usuarios a tomar decisiones informadas sobre dónde cenar.\nUn producto de datos es un dashboard de business intelligence que integra y visualiza datos de ventas, marketing y finanzas para brindar información útil a los tomadores de decisiones dentro de una organización.\nData Quality Abarca dimensiones como la precisión, la integridad, la coherencia, la fiabilidad y la puntualidad. Implica procesos y tecnologías que miden, gestionan y mejoran la salud de los datos. Mantener la calidad de los datos requiere vigilancia en las prácticas de gestión de datos y un seguimiento constante para detectar y corregir problemas.\nPiensa como si estuvieras haciendo un viaje por carretera utilizando un mapa. Si el mapa está actualizado, es preciso y detallado, es probable que el viaje sea tranquilo, pero si está desactualizado, puede perderse o retrasarse. Los datos de alta calidad son como un mapa preciso y actualizado para una empresa, que conduce a mejores decisiones y operaciones más eficientes.\nData Observability Es la capacidad de comprender completamente el estado de salud de los datos en un sistema mediante monitoreo, alertas y análisis de métricas clave como frescura, volumen, esquema, linaje y distribución. Permite detectar, diagnosticar y resolver problemas de calidad de datos proactivamente antes de que afecten decisiones de negocio o análisis.\nImagina que eres médico monitoreando la salud de un paciente: mides signos vitales constantemente (temperatura, presión, ritmo cardíaco) y recibes alertas si algo está mal. Data observability hace lo mismo con tus datos.\nUna plataforma de streaming como Netflix monitorea constantemente sus pipelines de datos: si detectan que las métricas de visualización no se actualizaron en las últimas 2 horas cuando deberían actualizarse cada hora (problema de frescura), o si el volumen de datos recibidos cayó 50% inesperadamente, el sistema alerta automáticamente al equipo de ingeniería mostrando exactamente dónde falló el pipeline para que puedan resolverlo antes de que afecte las recomendaciones a usuarios.\nData Gathering Es el proceso de recopilar, compilar y capturar información de diversas fuentes. La recopilación es esencial para adquirir la materia prima necesaria para el análisis, la interpretación y la toma de decisiones.\nImagina que quieres saber qué sabor de helado prefiere la gente. Haces una encuesta preguntando a tus amigos y vecinos cuál es su favorito. La recopilación de datos es simplemente reunir todas esas respuestas. En el mundo empresarial, una tienda podría realizar encuestas para conocer las preferencias de los clientes sobre un nuevo producto, recopilando respuestas que luego analizará para comprender mejor las necesidades y preferencias de sus clientes.\nData Scalability Es la capacidad de un sistema de datos para crecer y manejar volúmenes crecientes de información, usuarios concurrentes o cargas de trabajo sin degradar significativamente el rendimiento. Incluye escalabilidad vertical (agregar recursos a un servidor) y horizontal (agregar más servidores). Es fundamental para sistemas que anticipan crecimiento continuo de datos.\nImagina una carretera: cuando hay poco tráfico funciona bien, pero cuando crece la ciudad necesitas expandirla. Escalabilidad vertical es hacer los carriles más anchos; horizontal es construir nuevas carreteras paralelas. Instagram comenzó con miles de usuarios compartiendo fotos, hoy tiene miles de millones.\nSu infraestructura de datos es escalable horizontalmente: cuando el volumen de fotos y usuarios crece, automáticamente agregan más servidores distribuidos globalmente que trabajan en paralelo, permitiendo que usuarios en México, Japón y España suban y vean fotos simultáneamente sin ralentizaciones, manejando petabytes de datos sin colapsar.\nData Latency Es el tiempo de retraso entre el momento en que ocurre un evento que genera datos y el momento en que esos datos están disponibles para su consulta o análisis. Puede variar desde milisegundos (baja latencia) hasta horas o días (alta latencia), dependiendo de la arquitectura y requisitos del sistema. Es crítica para aplicaciones en tiempo real.\nImagina que estás viendo un partido de fútbol: verlo en vivo en el estadio es latencia cero, verlo por TV es 5 segundos de latencia, verlo por streaming puede ser 30 segundos, y ver el resumen al día siguiente es alta latencia. Una aplicación de trading financiero requiere latencia ultra baja (milisegundos) porque cada segundo cuenta para decisiones de compra/venta de acciones.\nEn contraste, un reporte mensual de ventas puede tolerar alta latencia (horas). Uber necesita baja latencia en el matching de conductores (segundos), pero puede tener mayor latencia en reportes de tendencias mensuales que los ejecutivos revisan después.\nData Engineer Es el profesional encargado de construir, mantener y optimizar la infraestructura y los sistemas que recopilan, almacenan y procesan grandes cantidades de datos. Diseña y opera pipelines de datos, asegura la calidad de los flujos de información, y garantiza que los datos estén disponibles, confiables y listos para su análisis por otros equipos.\nImagina que eres responsable de construir y mantener las carreteras de una ciudad para que los camiones puedan transportar mercancías de forma eficiente y segura. El ingeniero de datos hace lo mismo pero con información.\nEn una empresa como Amazon o Mercado Libre, un ingeniero de datos construye los sistemas que recopilan millones de transacciones diarias, las procesan para eliminar errores, las transforman a formatos estándares, y las almacenan en diferentes bases de datos donde los analistas y científicos de datos pueden consultarlas. También asegura que estos procesos funcionen las 24 horas sin interrupciones y que los datos lleguen a tiempo para generar reportes y tomar decisiones críticas.\nData Analyst Es el profesional que explora, analiza y encuentra patrones en los datos para obtener conocimiento y responder preguntas de negocio. Utiliza estadísticas, herramientas de visualización y técnicas analíticas para comprender el pasado y el presente. Su objetivo es transformar datos en información útil que ayude a tomar decisiones informadas.\nImagina que eres un detective investigando un caso: examinas pistas, buscas patrones, y armas una historia lógica de lo que sucedió. Un analista de datos hace lo mismo con números y hechos.\nEn una tienda de ropa en línea, un analista de datos examinaría las ventas del último trimestre para identificar qué productos se venden más, en qué días de la semana hay más tráfico, qué regiones compran más, y cuál es el ticket promedio de compra. Con esta información, el equipo de marketing puede diseñar campañas más efectivas y el equipo de inventario puede planificar mejor sus compras.\nData Scientist Es similar al analista de datos, pero la diferencia es que los científicos de datos utilizan técnicas estadísticas sólidas y aprendizaje automático para predecir el futuro. (Los analistas son el pasado y el presente, los científicos son el futuro).\nSi quieres predecir el clima, primero tienes que entender por qué algunas regiones reciben más lluvia que otras, luego recopilar datos sobre temperatura, patrones, etc. Y luego usar herramientas para analizar y predecir cuándo lloverá, o usar herramientas de toma de decisiones para ver si es seguro viajar.\nData Architect Es el profesional responsable de diseñar, estructurar y organizar los activos de datos físicos y lógicos de una organización, así como los recursos de gestión de datos. Define cómo se almacenan, integran, acceden y consumen los datos a través de diferentes sistemas. Es el arquitecto del ecosistema de datos de una empresa.\nImagina que quieres construir una casa: necesitas un plano que muestre dónde irán las habitaciones, la cocina, las puertas, y cómo se conectan entre sí. Un arquitecto de datos hace lo mismo pero con información.\nEn una empresa de seguros, el arquitecto de datos diseñaría cómo los datos de pólizas, clientes, siniestros y pagos se almacenan en diferentes sistemas, cómo se conectan entre sí, qué estándares de seguridad aplicar, y cómo los diferentes equipos pueden acceder eficientemente a la información que necesitan sin duplicar datos ni comprometer la privacidad.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/00-data-terms/","summary":"Un listado de términos en el mundo de los datos que actualizo conforme voy aprendiendo nuevos conceptos.","title":"Data Terms"},{"content":"TL;DR El 90% de data engineers sufren con data modeling según el 2026 State of Data Engineering Survey La causa #1 no es falta de conocimiento, es presión organizacional por moverse rápido Las organizaciones con modelado ad-hoc gastan 38% de su tiempo en firefighting vs 19% con modelos canónicos El sistema te premia por ser rápido hoy y te culpa por la deuda técnica mañana Tienes tres opciones: aceptar la tumba, pelear contra el sistema, o usar datos estratégicamente Intro Tu modelado de datos no falla porque seas mal ingeniero.\nFalla porque hacer las cosas bien en tu organización te está perjudicando. Y eso es mucho más peligroso que no saber modelar.\nCuando el sistema te premia por velocidad y te culpa por la deuda técnica, no importa cuánto sepas. Estás construyendo la tumba que va a enterrar tu carrera.\nEl 2026 State of Data Engineering Survey reveló algo que muchos sospechaban pero nadie decía en voz alta: el 90% de los data engineers están sufriendo con data modeling, y la causa número uno no es falta de conocimiento.\nLa causa número uno es la presión organizacional por moverse rápido.\nEl ciclo de la urgencia El patrón es casi universal. Llega un ticket con algo como \u0026ldquo;Feature XYZ para el dashboard del CEO\u0026rdquo;. El deadline es para ayer. Tu product owner está presionando porque \u0026ldquo;esto es crítico para el negocio\u0026rdquo;.\nTú ya sabes lo que se necesita hacer: normalizar los datos, definir tipos correctamente, documentar el schema, pensar en cómo escala cuando llegue al millón de usuarios.\nPero también sabes que si haces todo eso, no vas a entregar a tiempo.\nAsí que haces lo que hace el 90% de nosotros: apagas la parte del cerebro que piensa en arquitectura correcta y solo haces que funcione. Ad-hoc. Tabla aquí, columna allá. Feature entregado rápido. Jefe feliz.\nSeis meses después: \u0026ldquo;¿Por qué se rompe todo?\u0026rdquo; \u0026ldquo;¿Quién hizo esto?\u0026rdquo;\nY ahí está la clave: el problema no es que hayas decidido hacerlo mal. El problema es que el sistema te premió por hacerlo mal.\nLos incentivos rotos del data engineering moderno Las organizaciones modernas de data engineering tienen incentivos completamente rotos cuando se trata de calidad técnica.\nCuando entregas rápido con modelado ad-hoc, el stakeholder está feliz, el feature está shipped, y tú eres el \u0026ldquo;fast engineer\u0026rdquo;. El sistema te premia.\nSeis meses después, cuando todo está roto, el mismo stakeholder pregunta \u0026ldquo;¿por qué tan lento?\u0026rdquo;, el producto tiene bugs por todos lados, y tú te conviertes del \u0026ldquo;fast engineer\u0026rdquo; al \u0026ldquo;bad engineer\u0026rdquo;. El sistema te culpa.\n¿Ves el patrón?\nEl momento en que empezaste a acumular esa deuda técnica fue cuando el sistema te premió por ser rápido. Pero cuando llega el momento de pagarla, nadie recuerda esa presión original. Solo ven el desastre.\nEl ciclo de muerte del \u0026ldquo;Move Fast\u0026rdquo; Es como usar tarjetas de crédito para pagar otras tarjetas de crédito. Al principio todo funciona. Tienes liquidez. El negocio está feliz. Pero eventualmente, el interés te mata.\nEn datos, el interés se llama firefighting.\nAsí evoluciona típicamente:\nMes 1: Feature A entregado rápido con modelado ad-hoc.\nMes 3: Feature B se agrega. \u0026ldquo;Solo agrégale columnas\u0026rdquo;. Más ad-hoc sobre ad-hoc.\nMes 6: Tienes 15 features interconectados, cero documentación, cero claridad sobre ownership.\nMes 12: Firefighting completo. \u0026ldquo;¿Quién creó esta tabla?\u0026rdquo; \u0026ldquo;¿Por qué este dato es NULL?\u0026rdquo; \u0026ldquo;¿Cuál es la fuente de verdad?\u0026rdquo;\nTumba técnica completa.\nY cuando llegas al mes 12, ¿a quién culpan? ¿Al product owner que exigió velocidad? ¿Al VP que midió KPIs de delivery?\nNo. Culpan a ti. \u0026ldquo;Tus modelos son un desastre.\u0026rdquo; \u0026ldquo;Tus pipelines son lentos.\u0026rdquo; \u0026ldquo;Tú no escalaste bien.\u0026rdquo;\nLo que el survey revela El 2026 State of Data Engineering Survey, con 1,101 data engineers respondiendo, tiene las cifras que confirman este patrón.\nLos pain points de data modeling son claros:\n59.3% — Presión para moverse rápido 50.7% — Falta de ownership claro 39.2% — Difícil de mantener en el tiempo Solo 11.3% dicen que el modelado va bien Pero el dato más revelador es la correlación entre approach de modelado y tiempo en firefighting:\nApproach Tiempo en Firefighting Ad-hoc modeling 38% Canonical/Semantic models 19% Casi la mitad del tiempo perdido. Solo por hacer las cosas bien.\nY aquí está lo más interesante: solo el 5.4% de las organizaciones usan modelos canónicos o semánticos. El 17.4% usan ad-hoc.\nLa pregunta no es \u0026ldquo;¿cuál es mejor?\u0026rdquo;. La pregunta es: ¿por qué el 95% de las organizaciones no están haciendo lo que saben que es mejor?\nRespuesta: Porque el sistema no les permite.\nQué puedes hacer hoy El sistema está roto. Pero tú vives dentro de ese sistema. Tienes tres opciones.\nOpción 1: Aceptar la tumba técnica Si prefieres vivir en constante firefighting, acepta que este es el costo. Pero entiende qué estás eligiendo.\nOpción 2: Pelear contra el sistema Puedes negarte a entregar sin modelado correcto. Puedes documentar y normalizar todo. Vas a ser el ingeniero que \u0026ldquo;no es fast\u0026rdquo;. Tu carrera puede sufrir.\nOpción 3: El enfoque estratégico Esta es la que recomiendo.\nComprueba el survey primero. La próxima vez que te presionen, muéstrales: \u0026ldquo;Si usamos ad-hoc, vamos a perder 38% de nuestro tiempo en firefighting según el survey de 1,101 engineers. ¿Es esto lo que quieres?\u0026rdquo;\nNo es tu opinión. Son datos.\nDefine ownership explícito. Antes de crear cualquier tabla, pregunta: \u0026ldquo;¿Quién es el owner de este modelo? ¿Qué sucede cuando cambia?\u0026rdquo; Si nadie tiene una respuesta, documenta que no hay ownership. Cuando falle, no es tu culpa.\nComienza pequeño con canonical models. No intentes refactorizar todo. Empieza con un área crítica. Define un schema canónico para esa área. Documenta el why. Cuando esa área tenga la mitad de bugs que el resto, los datos hablarán por sí mismos.\nMétricas antes que intuición. Mide cuánto tiempo tu equipo pierde en firefighting. Preséntalo en retros: \u0026ldquo;El mes pasado perdimos 40 horas en debugging de schemas ambiguos.\u0026rdquo;\nNadie puede ignorar números.\nEl insight clave: no estás pidiendo permiso para hacer \u0026ldquo;mejor ingeniería\u0026rdquo;. Estás pidiendo permiso para no desperdiciar el 38% del tiempo de tu equipo.\nTrade-offs: ¿Qué camino tomar según tu contexto? No hay respuesta universal. Depende de dónde está tu organización.\nSi es una startup sin product-market-fit: Usa ad-hoc. La velocidad de aprender es más importante que el modelado perfecto. Pero documenta que es deuda técnica.\nSi es una empresa establecida con product-market-fit: El costo de no modelar bien ya superó el beneficio de la velocidad hace meses. Si no cambias, vas a estar en firefighting permanente.\nPero aquí está la realidad difícil: no todas las organizaciones se van a salvar. Algunas prefieren la tumba técnica porque el costo de cambiar su cultura es demasiado alto.\nSi estás en una de esas, es una conversación de carrera, no de ingeniería.\nOutro Tu modelado de datos no falla por ti. Falló por el sistema que te premia por velocidad y te culpa por deuda técnica.\nEl survey es claro: el 90% de nosotros estamos en la misma situación. No es un problema de skills. Es un problema de incentivos rotos.\nPero ahora tienes algo que yo no tenía cuando empecí: datos para defender tu trabajo. Usa el survey. Mide tu firefighting. Documenta el ownership.\nNo vas a cambiar el sistema de tu empresa en un día. Pero puedes dejar de ser el culpable cuando todo explote.\nFuentes 2026 State of Data Engineering Survey — https://joereis.github.io/practical_data_data_eng_survey/ ","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-data-modeling-crisis-2026/","summary":"El 90% de los data engineers tienen problemas con data modeling. Pero no es falta de skills—es que tu organización te premia por velocidad y te culpa por la deuda técnica que inevitablemente genera.","title":"Data Modeling Crisis: Por qué tu velocidad está construyendo tu tumba técnica"},{"content":"TL;DR ELT hizo fácil construir pipelines pero casi imposible mantenerlos a escala debido a la falta de entornos de desarrollo Los ingenieros de datos carecen de herramientas básicas de desarrollo que los ingenieros de software dan por hecho: staging, CI/CD, pruebas locales y bucles de feedback rápidos La industria optimizó para el problema incorrecto—escalar almacenamiento y cómputo en lugar de escalar prácticas y flujos de trabajo de desarrollo Las soluciones actuales (más observabilidad, orquestación, gobernanza) son todas reactivas y abordan síntomas en lugar de causas raíz La solución real requiere una capa de staging para transformaciones y herramientas de desarrollo local, no más monitoreo Si deseas escuchar en vez de leer, haz click aquí\nIntro Hay algo que hemos normalizado en data engineering que sería completamente inaceptable en software. Si le dijeras a un equipo de backend que tienen que probar cada cambio directamente en producción—con datos reales, costos reales, consecuencias reales—pensarían que estás siendo irresponsable. Sin embargo, en data engineering, no llamamos a esto \u0026ldquo;probar en producción.\u0026rdquo; Lo llamamos ELT.\nEsto no vino de la teoría. Vino de ver el mismo patrón repetirse en docenas de equipos: equipos pequeños y capaces que se mueven rápido al principio—dashboards aquí, pipelines allá, todo parece funcionar—durante unos nueve meses. Entonces algo se rompe. Los dashboards se vuelven lentos. Los cambios pequeños se vuelven aterradores. El warehouse se bloquea por minutos, a veces horas.\nCuando preguntas dónde prueban antes de desplegar, la respuesta es incómoda: \u0026ldquo;Aquí mismo. En producción.\u0026rdquo; No porque quieran, sino porque no hay otra opción real.\nEsto no es un problema de herramientas. Es un problema de modelo mental.\nLo Que ELT Hizo Bien ELT nos da algo poderoso: velocidad inicial. Mover datos rápido, transformar en SQL, aprovechar warehouses masivos como Snowflake y Redshift—eso fue una revolución real. ETL requería ingeniería especializada en Java o Python para cada pipeline. Las bases de datos MPP hicieron SQL performante a escala. Esto cambió la propiedad de ingenieros de backend a equipos de analítica y simplificó la ingesta a operaciones básicas de copia, acelerando el tiempo para insight.\nEl enfoque democratizó la transformación de datos más allá de ingenieros especializados, eliminó el cuello de botella del desarrollador para cambios de esquema, y permitió a los equipos de analítica ser dueños de sus propios pipelines. Ciclos de iteración más rápidos para el desarrollo inicial. Eso es lo que ELT hizo bien.\nEl Costo Oculto Pero ELT también creó algo silencioso: el warehouse se convirtió simultáneamente en entorno de desarrollo y entorno de producción. Sin darnos cuenta, normalizamos un flujo de trabajo donde cada prueba cuesta dinero, cada error tiene consecuencias reales, y cada trabajo bloqueado afecta a otros equipos.\nAl principio, esto no se siente mal. Se siente práctico. Hasta que deja de escalar.\nCuando tienes 10-20 modelos corriendo, todo es manejable. El problema es que el sistema no te avisa cuando deja de escalar. Si no tienes las herramientas o la cultura correspondiente, una vez que llegas a 300 modelos, ya estás atrapado. Ya es muy complicado.\nEl costo no es solo dinero. Es atención y riesgo. El costo real es cognitivo. Empiezas a pensar dos veces antes de tocar algo. No porque faltes de habilidad, sino porque temes romper algo downstream sin darte cuenta. Cada cambio se vuelve muy tenso. Cada decisión pesa más de lo necesario.\nEl Breakdown de Escala He visto este patrón repetirse cuando los equipos pasan de 50 a 500 transformaciones. ¿Qué pasa? Dejas de construir cosas nuevas y solo mantienes lo que hay. El sistema se vuelve frágil. Regresas a lo defensivo. Es común escuchar: \u0026ldquo;Mejor no tocarlo\u0026rdquo; o \u0026ldquo;Corrámoslo en la noche cuando nadie esté ahí.\u0026rdquo;\nCuando muchas personas quieren probar cosas al mismo tiempo, el warehouse se convierte en un cuello de botella humano. Esto no es técnico—es humano.\nEste patrón aparece en la historia. Con el tiempo, emerge una tensión. Siempre eliges entre dos malas opciones: ser rápido y arriesgarte a romper algo, o ir lento y bloquear a todos los demás. No hay buenas opciones. Esto afecta la confianza del equipo en el sistema, incluso en el sistema que ellos mismos crearon.\nLa gente pierde confianza. Empiezan a hacer workarounds. Saben que si no lo tocan, no lo van a romper.\nPor Qué Las Soluciones Reactivas Fallan Por mucho tiempo, la respuesta de la industria ha sido: más observabilidad, más orquestación, más gobernanza. Esto debería ser lo opuesto. Estamos agregando políticas y procesos que no abordan el problema raíz—seguridad, confiabilidad y precisión de los datos.\nTodo esto es reactivo. Detecta el problema después de que ocurre. Los dashboards de observabilidad te dicen qué falló, no que tu modelo de flujo de trabajo es el problema.\nEs como instalar una cámara de seguridad. Te muestra el robo, pero no lo previno. En data engineering, confundimos visibilidad con prevención.\nLa Solución Real La clave es esta: el problema no es ELT en sí. Es ELT sin entornos de staging.\nLa ingeniería de software resolvió esto hace mucho tiempo: dev local, staging, CI/CD, producción. Llámalo como quieras, pero tiene esas etapas. En datos, por alguna razón—no todos los equipos, no todas las empresas, pero muchos que he visto—esas etapas se saltan de ingeniería y desarrollo.\nAprendemos cuando este tipo de sistema se rompe. No deberíamos dejar de aprender porque ya está resuelto. Por alguna razón, no lo incluimos en nuestros flujos de trabajo de datos. Quizás es porque los datos involucran muchos temas humanos, así que los tratamos diferente al software.\nQué Cambia Cuando Separas Desarrollo de Producción Cuando realmente separas desarrollo de producción, el equipo se siente más seguro experimentando, iterando más rápido, aprendiendo sin miedo. La conversación cambia de \u0026ldquo;veamos qué se rompe hoy\u0026rdquo; a \u0026ldquo;probémoslo primero en staging.\u0026rdquo; Eso cambia todo.\nCuando realmente vives esta práctica y ves los beneficios, no hay retorno. Nunca. Y no debería haberlo. Nadie quiere volver a probar en producción.\nEsto es más cultural que técnico. Las herramientas existen. Lo difícil es admitir que la forma en que operamos o el modelo actual no está diseñado para escala. Es doloroso. Entiendo por qué los equipos lo evitan.\nEs una Postura, No una Herramienta El cambio real no es una herramienta. Las herramientas son muchas. Es una postura. Primero, aceptar que los datos también son software. Que las transformaciones merecen el mismo rigor a pesar de tener lógica de negocio y contexto que es diferente de algo determinista o con estado. Los datos tienen memoria, sí. Pero merecen el mismo rigor de ingeniería.\nUn equipo de datos maduro no trata de ir más lento. Trata de dejar de pagar por aprender en producción. Los entornos separados no son burocracia. Son lo que te permite pensar con claridad, escalar, hacer las cosas bien desde el principio.\nToma más tiempo, sí. Pero hacer las cosas bien tiene sus beneficios. Siempre pasa lo mismo. Pero por alguna razón, todos tendemos a querer resultados ya. Lo antes posible. Queremos ver cambios inmediatos. Las cosas buenas toman su tiempo.\nAquí hay un principio: cuando construyes un pipeline y vas a escalar, no puedes probarlo con miedo. Si pruebas con miedo, el sistema está mal diseñado. Probar en producción debería ser simple—simple porque ya hiciste las validaciones previas. También es, de cierta forma, responsable a largo plazo. Si no lo haces bien, se va a romper.\nCómo Vender el Cambio Sin Hablar de Herramientas ¿Cómo vender esta idea sin caer en la trampa de las herramientas? Habla de riesgo y costos invisibles. Es muy difícil, pero sígueme aquí: costos invisibles. Tiempo perdido. No estoy mencionando tecnología. Costos invisibles. Tiempo perdido.\nCuando empiezas a operar con entornos apropiados, te das cuenta de que la duda no aparece hasta el momento en que ya no puedes avanzar más. El enfoque anterior te paraliza porque lo hiciste de esa manera y es muy complicado avanzar. Esto debería redefinir tu forma de pensar sobre el software de datos.\nLa medida de un equipo de datos no es cuántos dashboards tienes. Es qué tan seguro es cambiar el sistema que ya tienes. Esa es la perspectiva diferente que puedes adoptar. Si tienes muchas herramientas, ¿por qué no puedes moverte más rápido? Si tienes muchos dashboards, por qué no eres mejor en lo que haces?\nLa forma en que operas, incluyendo el sistema que necesitas afectar, esa es la diferencia.\nLa Realidad de Escala No es normal probar cambios críticos directamente en producción. Solo lo normalizamos porque al principio funcionaba. Era rápido. Era fácil. Solo descargabas los datos, los cargabas en el warehouse y transformabas ahí. No mencionamos qué podría pasar. No teníamos alternativas claras.\nCuando los sistemas crecen, la falta de entornos empieza a mostrar. No solo se siente que falta algo. Te quita la capacidad de pensar. Tu tiempo, tu energía, tu forma de operar cambia. Estás pensando: \u0026ldquo;Voy a probar con miedo. Miedo de que si hago esto, ¿cuánto costará? ¿Bloqueará el sistema? ¿Afectará a la persona que necesita este reporte para estos stakeholders?\u0026rdquo;\nCada cambio se vuelve muy tenso. Cada decisión pesa más de lo necesario. No debería ser así.\nEl software de datos puede manejar mucho de esto. ELT no está roto. Pero escalar ELT sin staging, sin desarrollo local, sin esos entornos nos fuerza a aprender de la forma más costosa posible. Terminas pagando miles de dólares en costos de warehouse, tiempo de debugging y costo de oportunidad. Y no debería ser así.\nEsto no es una limitación técnica. Hay muchos equipos brillantes haciendo cosas increíbles, pero todo es frágil. Da un paso atrás. Es una decisión de diseño. Ese es el tema primordial.\nCierre Si estás viviendo esta realidad—si estás probando cada cambio en producción, si tienes miedo de tocar los pipelines existentes, si estás pagando miles en costos de debugging—sabe que hay otra forma.\nEntornos de staging reales. Capacidades de desarrollo local. Flujos de trabajo de promoción CI/CD. Estos no son lujos reservados para empresas de software maduras. Son necesidades para cualquier equipo de datos que quiera escalar sin romperse.\nSi tienes un entorno de staging real, o si ya pasaste ese punto frágil y quieres compartir tu experiencia, contáctame. Comparte esta información. Estos tipos de conversaciones son las que realmente mueven esta disciplina adelante. Cuando los equipos planifican de la mejor manera posible, sucede algo increíble otra vez. Algo muy bueno. Algo excelente.\nFuentes Staging Environments for Data Pipelines — DLT Hub Mejores prácticas de la industria de organizaciones que gestionan decenas de miles de pipelines de datos a escala ","permalink":"https://soyomarvaldezg.codeberg.page/posts/a-elt-prod-matando-dataeng/","summary":"ELT revolucionó los pipelines de datos al mover las transformaciones al warehouse, pero creó un defecto crítico: los ingenieros de datos ahora prueban todo en producción sin entornos de desarrollo apropiados, haciendo que el debugging sea costoso y el mantenimiento casi imposible a escala.","title":"ELT a Escala: Por Qué Probar en Producción Está Matando el Data Engineering"},{"content":"TL;DR Un roadmap efectivo de Data Engineering no es una lista aleatoria de herramientas (Python, SQL, Airflow, etc.). Se basa en entender el Ciclo de Vida de los Datos (Fuentes, Ingestión, Almacenamiento, Transformación y Consumo). Las herramientas deben encajar en estas etapas y en los \u0026ldquo;subyacentes\u0026rdquo; (Undercurrents) como Seguridad, DataOps y Arquitectura. Sin este contexto, corres el riesgo de construir soluciones que no sobreviven en producción.\nVideo en YouTube: click aquí\nRoadmap: click aquí\nIntro Aprender Python, SQL y una nube no te convierte automáticamente en un Data Engineer; te convierte en alguien peligroso si no entiendes el ciclo de vida de los datos.\nMuchos se pierden estudiando roadmaps genéricos donde no queda claro dónde entra Git, dónde entra Python o para qué se usa SQL realmente. Si quieres dejar de estudiar cosas sueltas y empezar a pensar como alguien que puede sobrevivir en producción, necesitas entender el mapa completo de los datos.\nLa Analogía del Chef Para entender el rol del ingeniero, usemos una analogía culinaria. El ciclo de vida de un ingrediente va desde que se cultiva hasta que se tira a la basura o alguien se lo come. Tú, como Data Engineer, eres el chef de línea. No te importa cómo se cultivó la zanahoria (fase de creación), pero sí te importan las etapas dentro de la cocina:\nRecepción (Ingestión). Almacenamiento en frío (Storage). Cocción/Preparación (Transformación). Tu control es el flujo desde las fuentes hasta el consumo.\nEl Mapa Mental: Los 3 Pilares y el Ciclo de Vida Antes de elegir herramientas, necesitas tener claro el terreno. Basándonos en el libro Fundamentals of Data Engineering de Joe Reis \u0026amp; Matt Housley, el ciclo se divide en:\nFuentes: Bases de datos, APIs, archivos planos. Ingestión: Cómo conectas y mueves la información. Almacenamiento: Data Lake, Data Warehouse. Transformación: Dar sentido a los datos para el negocio. Consumo: Dashboards, ML features. Los \u0026ldquo;Undercurrents\u0026rdquo; (Subyacentes): Esto es lo que a menudo se ignora en los roadmaps pero es vital para que un pipeline sea robusto: Administración de datos, orquestación, arquitectura, seguridad, Software Engineering y DataOps.\nDeep Dive: ¿Qué aprender en cada etapa? Aquí es donde la mayoría de los juniors se estrellan: intentan aplicar herramientas antes de entender el problema.\n1. Fuentes (Sources) Tecnología: Ninguna herramienta técnica entra aquí todavía. Enfoque: Entendimiento y Gobierno de Datos.\nError Junior: Tratar cualquier fuente como una simple tabla. Preguntas Clave: ¿Quién es el dueño de los datos? ¿Cuál es la tasa de crecimiento (volumetría)? ¿Qué tan confiables son (veracidad)? ¿Cuál es la variedad de los datos? Recursos: Fundamentals of Data Engineering (Joe Reis \u0026amp; Matt Housley), Desbloquea tu carrera en datos (Omar Valdez G). 2. Ingestión Tecnología: Python (scripts, conectores), Git (versionado), Orquestadores (Airflow, Prefect, Dagster), Patrones (CDC, Full Refresh). Enfoque: Decides la latencia, la carga sobre el origen y los patrones de integración.\nError Junior: Elegir herramientas por moda (\u0026ldquo;Vibe Coding\u0026rdquo;) sin evaluar si el patrón es correcto para la carga y la resiliencia del origen. Preguntas Clave: ¿Cuál es la frecuencia mínima necesaria? ¿Qué tan resiliente es el origen? ¿Qué pasa si el esquema cambia? Recursos: Data Engineering Design Patterns (Bartos Konieczny), Data Pipelines Pocket Reference (James Densmore). 3. Almacenamiento (Storage) Tecnología: SQL (tablas, esquemas, particiones), Cloud (AWS, GCP, Azure), Formatos (Parquet, Iceberg), Conceptos (Bronze/Silver/Gold). Enfoque: Defines cómo guardar lo crudo, cómo limpiarlo y cómo dejarlo listo.\nError Junior: Crear una tabla gigante con todo mezclado (el \u0026ldquo;monstruo\u0026rdquo;). No planificar el crecimiento o los permisos por capa. Preguntas Clave: ¿Qué datos van en cada etapa (Bronze/Silver/Gold)? ¿Quién tiene acceso a cada capa? ¿Planeas usar Data Lake o Warehouse? Recursos: Deciphering Data Architectures (James Serra), Fundamentals of Data Engineering (Joe Reis \u0026amp; Matt Housley). 4. Transformación Tecnología: SQL, Python, Spark, dbt (o SQLMesh), Testing, Modelado Dimensional. Enfoque: Conviertes datos brutos en algo que el negocio puede entender.\nError Junior: Hacer transformaciones complejas dentro de los dashboards o escribir queries monstruosas. Ignorar el modelado y las software best practices. Preguntas Clave: ¿De dónde vienen las reglas de negocio? ¿Cuál es el modelo lógico (estrella, copo de nieve)? ¿Cómo versionas tus modelos? Recursos: The Data Warehouse Toolkit (Kimball - enfócate en el 80/20 del libro), Data Engineering Design Patterns (Bartos Konieczny). 5. Consumo (Consumption/Serving) Tecnología: Herramientas BI (Power BI, Looker, Tableau), Observabilidad, SLAs. Enfoque: Se mide si todo lo anterior tuvo sentido. Es donde la validación final ocurre.\nError Junior: Creer que la responsabilidad termina al llenar la tabla. Si el dato no se puede consumir o no confía el usuario, el trabajo anterior fue inútil. Preguntas Clave: ¿Qué consumidores dependen de esto? ¿Qué métricas monitoreas (observabilidad)? ¿Cuáles son los SLAs? Recursos: Desbloquea tu carrera en datos (Omar Valdez G), Data Engineering Design Patterns (Bartos Konieczny). Conclusión Python, SQL y la Nube son necesarias, pero sin el contexto del ciclo de vida de datos, eres un riesgo para la empresa.\nLas herramientas favoritas (Git, Docker, Airflow, dbt) solo tienen sentido cuando sabes en qué parte del ciclo entran y qué problema específico resuelven.\nConsejo Final: Antes de elegir tu próxima herramienta o curso, da dos pasos atrás y pregúntate: ¿En qué parte del ciclo de vida de ingeniería de datos realmente me va a ayudar esto? Empieza pequeño, entiende las fuentes, define el almacenamiento y luego conecta los puntos.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-dataeng-roadmap-nadie-ensena/","summary":"Aprender Python, SQL y Cloud no te convierte en un Data Engineer; te convierte en alguien peligroso si no entiendes el ciclo de vida de los datos. Descubre el roadmap real dividido por etapas, desde la comprensión de fuentes hasta el consumo, pasando por patrones de integración y modelado.","title":"El Roadmap Data Engineering que NADIE te enseña  🚀"},{"content":"TL;DR Elegir el rol equivocado en datos te costará tiempo y dinero. No son escaleras donde uno es más \u0026ldquo;avanzado\u0026rdquo; que otro, sino caminos paralelos: el Data Analyst traduce datos a decisiones de negocio (qué pasó), el Data Engineer construye la infraestructura para que fluyan (cómo llegan los datos) y el Data Scientist crea modelos predictivos (qué pasará). Todos usan Python y SQL, pero con objetivos distintos. Elige basándote en si te gusta comunicar/negocio, programar/sistemas o investigar/matemáticas.\nVideo en Youtube: click aquí\nIntro Si no sabes cuál elegir entre Data Analyst, Data Engineer o Data Scientist, estás destinado a perder meses aprendiendo las habilidades equivocadas. Muchos caen en la trampa de pensar que \u0026ldquo;todos hacen lo mismo\u0026rdquo; o que el Data Scientist es la meta final.\nLa realidad es que, aunque los tres trabajan con datos, ahí termina el parecido. Son roles con objetivos, mentalidades y herramientas muy específicas. Vamos a desglosar las diferencias reales, qué hace cada uno en un día típico y qué roadmap deberías seguir.\nDiferencias Clave y Analogía Para entender la distinción fundamental, usemos una analogía con el agua:\nData Engineer: Es el plomero. Se asegura de que el agua (datos) llegue a todas partes mediante tuberías (pipelines) y sistemas eficientes. Data Analyst: Es quien te dice cuánta agua gastas y cómo ahorrar. Toma los datos, los analiza y genera decisiones de negocio. Data Scientist: Es quien predice cuándo se va a romper una tubería antes de que suceda. Usa modelos y algoritmos para anticipar el futuro. Si lo visualizáramos en un diagrama de Venn a alto nivel:\nAnalyst: Se enfoca en Reportes y Dashboards. Engineer: Se enfoca en Pipelines e Infraestructura. Scientist: Se enfoca en Machine Learning y Algoritmos. La Intersección: Los tres roles, en algún momento, usan Python y SQL. Ese es el común denominador, pero cada uno lo utiliza de forma diferente.\nEl Mito de la Escala vs. Realidad Existe el mito de que necesitas saber \u0026ldquo;un poco de todo\u0026rdquo; o que debes empezar como Analista para llegar a ser Científico. Falso. Son trayectorias paralelas, no una escalera jerárquica.\nHe visto gente gastar 6 meses aprendiendo Machine Learning cuando su trabajo solo requería SQL y Tableau. También he visto a quienes les gusta la infraestructura perder tiempo en bootcamps de análisis de negocio. Elegir mal no solo es una pérdida de dinero en cursos, sino de tiempo valioso que podrías haber invertido en especializarte.\nUn Día en la Vida: ¿Qué hacen realmente? Para que veas la diferencia práctica, así se ve un día típico de trabajo:\nData Analyst (Enfoque: Negocio y Comunicación)\n09:00 AM: Reunión con Marketing para analizar el rendimiento de una campaña. 10:00 AM: Extrae datos usando SQL (Postgres). 12:00 PM: Crea un dashboard en Tableau o Power BI. 03:00 PM: Presenta insights a los stakeholders y responde preguntas de negocio. 05:00 PM: Documenta los hallazgos en Confluence o plataformas similares. Data Engineer (Enfoque: Sistemas y Optimización)\n09:00 AM: Revisa que los pipelines corrieron correctamente y valida los logs. 10:00 AM: Debug de un pipeline: investiga el error y aplica rollback si es necesario. 02:00 PM: Optimiza una query que tarda 3 horas en ejecutarse. 03:00 PM: Diseña una nueva tabla en el Data Warehouse. 05:00 PM: Configura una nueva estación en Airflow. Data Scientist (Enfoque: Matemáticas y Predicción)\n09:00 AM: Evalúa el modelo del mes pasado: revisa métricas, drift y compara contra la línea base (baseline). 10:00 AM: Feature engineering con nuevos datos. 03:00 PM: Entrena un nuevo modelo (ej. XGBoost). Validación: Verifica la precisión del modelo. Final: Presenta los resultados al equipo de producto. Nota: En empresas con baja madurez de datos, estos roles suelen mezclarse, pero en entornos ideales, estas son las funciones diferenciadas.\nRoadmaps y Stacks Tecnológicos ¿Cómo elegir? Aquí tienes una guía general de herramientas y perfiles:\n1. Data Analyst Herramientas: SQL (Postgres), Excel (nunca falla), Tableau o Power BI, Python básico (Pandas). Tiempo de aprendizaje: 4 a 6 meses. Perfil ideal: Te gusta comunicar, entender el negocio y trabajar con personas (stakeholders). 2. Data Engineer Herramientas: SQL Avanzado, Python, Apache Spark, Airflow, DBT (usado por Analytics Engineers), y Cloud (AWS, GCP o Azure). A veces Scala. Tiempo de aprendizaje: 8 a 12 meses. Perfil ideal: Te gusta programar, optimizar sistemas y resolver problemas técnicos complejos. Generalmente es un perfil más introvertido o enfocado en la infraestructura. 3. Data Scientist Herramientas: Python, Scikit-Learn, Jupyter Notebooks, Estadística profunda, Algoritmos de Machine Learning. Tiempo de aprendizaje: Largo (incluye matemáticas avanzadas). Perfil ideal: Te gustan las matemáticas, experimentar, investigar y crear pruebas de concepto. Menos orientado a la producción (a diferencia del Machine Learning Engineer). ¿Cómo elegir tu camino? Antes de decidirte, prueba pequeño:\nAnalyst: Intenta hacer una presentación y escribe unas cuantas queries de SQL. Scientist: Juega experimentando con modelos de predicción (ej. predecir precios de casas). Lo sorprendente es que muchas personas se van con el roadmap completo sin tener claro lo básico. El consejo más valioso que puedo darte es: Agrega bien las bases.\nPython y SQL son los dos pilares fundamentales. He visto perfiles que por dominar bien estos dos, pueden saltar o cambiar de rol más adelante (de Analyst a Engineer o viceversa) con mayor facilidad.\nConclusión Los tres roles tienen curvas de aprendizaje y objetivos diferentes, pero todos empiezan en el mismo lugar: un SQL sólido y un Python básico. Ahora que sabes qué hace cada uno en su día a día y qué tipo de perfil encaja contigo, la decisión depende de qué te apasione más: explicar la historia (Analyst), construir el escenario (Engineer) o predecir el futuro (Scientist).\nNo se trata de elegir el \u0026ldquo;mejor\u0026rdquo; rol según el salario o la jerarquía, sino el que va contigo. Recuerda: prueba rápido, empieza pequeño y construye sobre cimientos sólidos.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-analyst-engineer-scientist-diff/","summary":"¿No sabes si ser Data Analyst, Data Engineer o Data Scientist? Descubre las diferencias reales en sus día a día, el stack tecnológico de cada uno y cómo elegir el camino correcto para no perder meses aprendiendo skills equivocados.","title":"Analyst vs Engineer vs Scientist: Diferencias Reales 🎯"},{"content":"TL;DR El error más silencioso en SQL es tratar NULL como una cadena vacía o como un valor comparable. NULL representa la ausencia de dato. Comparar con = o != devolverá siempre \u0026ldquo;falso\u0026rdquo; (o desconocido), haciendo que tu query no devuelva resultados aunque existan datos. Para filtrar correctamente, debes usar los operadores IS NULL y IS NOT NULL. Ten cuidado también con las funciones de agregación como COUNT y con los JOINS.\nVideo en YouTube: click aquí\nIntro ¿Alguna vez has ejecutado una consulta SQL pensando que devolvería datos, y el resultado ha sido un set vacío, pero sin ningún mensaje de error? Este es el error más común y silencioso en el desarrollo de bases de datos.\nNo va a \u0026ldquo;crashear\u0026rdquo; tu aplicación ni lanzar una excepción, simplemente te devuelve datos incompletos. En este artículo, entenderás la diferencia fundamental entre NULL y una cadena vacía, y aprenderás a escribir queries que realmente traen toda la información que necesitas.\nEl Escenario: Buscando lo \u0026ldquo;Vacío\u0026rdquo; Imagina que tenemos una tabla simple llamada usuarios. Algunos usuarios tienen un segundo apellido y otros no. En la base de datos, aquellos que no tienen segundo apellido no deben guardarse como un espacio en blanco o una cadena vacía, sino como NULL.\nSi intentamos buscar a los usuarios que no tienen segundo apellido (Ana y Carlos), el primer instinto de muchos desarrolladores es buscar donde el apellido es una \u0026ldquo;cadena vacía\u0026rdquo;.\nEl Query Incorrecto:\nSELECT * FROM usuarios WHERE segundo_apellido = \u0026#39;\u0026#39;; Al ejecutar esto, el resultado es 0 filas. ¿Por qué? Si sabemos que Ana y Carlos no tienen segundo apellido, ¿por qué no aparecen?\n¿Qué es realmente NULL? La confusión viene de pensar que NULL es igual a \u0026quot;\u0026quot; (cadena vacía). No lo es.\nNULL no es un valor; es la ausencia de un valor. No es cero, no es un espacio en blanco, es simplemente \u0026ldquo;desconocido\u0026rdquo;. Por lo tanto, la igualdad matemática o lógica no aplica aquí.\nSQL maneja una lógica de tres estados:\nTRUE (Verdadero) FALSE (Falso) UNKNOWN (Desconocido) Cualquier comparación directa con NULL (como = NULL, \u0026lt;\u0026gt; NULL, o incluso NULL = NULL) resulta en UNKNOWN. La cláusula WHERE solo deja pasar las filas donde la condición es TRUE. Si es UNKNOWN, la fila se filtra.\nLa Solución: IS NULL Para preguntarle a SQL por la ausencia de un valor, no usamos comparación, usamos una comprobación de estado.\nEl Query Correcto:\nSELECT * FROM usuarios WHERE segundo_apellido IS NULL; Este comando funciona porque IS NULL explícitamente devuelve TRUE si el valor es nulo.\nLo opuesto también aplica: Si quieres filtrar los que SÍ tienen valor, no uses \u0026lt;\u0026gt; '' (ya que un NULL también pasaría el filtro en algunos contextos o fallaría en otros dependiendo del motor), usa:\nSELECT * FROM usuarios WHERE segundo_apellido IS NOT NULL; Otras Trampas con NULL El problema de NULL no solo afecta a los filtros WHERE. Hay otros dos lugares comunes donde te puede jugar una mala pasada:\n1. Funciones de Agregación (COUNT) Ten mucho cuidado al contar filas.\nCOUNT(*): Cuenta el número total de filas en la tabla. COUNT(columna): Cuenta solo las filas donde esa columna NO es nula. Si haces COUNT(segundo_apellido) en nuestra tabla, te dará 2 (solo los que tienen apellido), en lugar de 4 (el total de usuarios). Si quieres contar usuarios independientemente de si tienen apellido o no, usa COUNT(*).\n2. Joins (Uniones) Al unir tablas, si no manejas los NULLs correctamente en las llaves de unión, puedes perder datos inesperadamente.\nEn un INNER JOIN: Si una columna de unión es NULL en una de las tablas, esa fila no coincidirá con nada (ya que NULL = NULL es falso) y se perderá del resultado. En un LEFT JOIN: Si la tabla derecha tiene NULLs, aparecerán en el resultado, pero debes tener cuidado de no filtrarlos después en tu cláusula WHERE. Conclusión Cambiar la mentalidad sobre NULL es crucial para escribir SQL robusto. Recuerda siempre:\nNULL es la ausencia de valor, no un valor vacío. Nunca uses = o != o \u0026lt;\u0026gt; para comparar con NULL. Usa siempre IS NULL y IS NOT NULL. Ten presente cómo afecta NULL a tus conteos (COUNT) y tus uniones (JOINS). La regla es simple: Siempre que trabajes con columnas que pueden ser nulas, piensa en términos de presencia o ausencia (IS), no de igualdad (=).\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-query-culpa-null/","summary":"NULL no es una cadena vacía, es la ausencia de valor. Aprende por qué tus filtros fallan al usar comparaciones comunes, cómo usar \u003ccode\u003eIS NULL\u003c/code\u003e correctamente y evita errores silenciosos en tus consultas SQL.","title":"Tu query no devuelve nada? Culpa a NULL 🤫"},{"content":"TL;DR El modelado de datos es el plano arquitectónico que determina el éxito o el fracaso de un proyecto. Muchos fallan por crear \u0026ldquo;tablas gigantes\u0026rdquo; o por no considerar la evolución del negocio. Para evitarlo, debes modelar para el acceso (no solo el almacenamiento), preparar el modelo para la evolución, y contextualizar según el caso de uso (Transaccional, BI o Machine Learning). Recuerda siempre guardar el nivel más alto de granularidad posible.\nVideo en Youtube: click aquí\nIntro Te voy a contar algo que aprendí de la manera difícil. El 60% de los proyectos de datos que fallan, no lo hacen por la tecnología elegida ni por el volumen de datos, sino por una decisión que toman al inicio: el modelado.\nEl modelado de datos no es solo dibujar cajitas y flechas; es el plano arquitectónico de todo lo que vas a construir después. Si estás construyendo dashboards, implementando Machine Learning o simplemente almacenando datos, tu éxito depende de esto. Hoy veremos los errores que cuestan millones y un framework práctico para modelar datos que funcionan en el mundo real.\nEl Error de la \u0026ldquo;Tabla Gigante\u0026rdquo;: El Caso E-Learning Imagina una plataforma de e-learning que evaluaste con 500 usuarios. Seis meses después, gracias a una campaña de marketing, crecen a 20,000 usuarios. El sistema se vuelve inútil, lento y caótico, a pesar de haber invertido más de $150,000 en infraestructura.\n¿El culpable? No fue el servidor. Fue el modelado.\nEl error común es crear una única tabla gigante (por ejemplo, cursos_contenido) donde se acumula todo.\nSe agregan campos de usuario (user_id, username) dentro de la tabla de cursos. Con el tiempo, se agregan más columnas y la tabla se llena de valores nulos y desorden. Al volverse inmanejable, alguien decide crear otra tabla de usuarios paralela porque la original es difícil de consultar. Resultado: Analistas y Científicos de Datos no saben cómo hacer joins, los IDs no coinciden y se pierde la integridad. Es como construir una casa hermosa sin cimientos. Todo parece perfecto hasta la primera tormenta. Reconstruir los cimientos con la casa habitada es 10 veces más costoso que hacerlo bien desde el principio.\nLos Tres Pilares para Evitar Desastres En el mundo real, con plazos limitados, hay tres pilares que marcan la diferencia entre un modelo frágil y uno robusto:\n1. Modela para el Acceso, no solo para el Almacenamiento El verdadero valor de los datos está en cómo recuperas y usas la información, no en cómo la guardas.\nEnfoque Novato: Una tabla gigante de \u0026ldquo;Productos\u0026rdquo; con 200 columnas (categorías, precios, inventario, proveedor). Enfoque Experto: Varias tablas más pequeñas e interconectadas, optimizadas para las búsquedas más frecuentes. Mito vs. Realidad:\nMito: \u0026ldquo;Si tengo todo en una tabla es más fácil.\u0026rdquo; Realidad: Las consultas complejas en tablas gigantes se vuelven exponencialmente lentas. Consejo: Antes de diseñar, pregúntate: ¿Cuáles son las 5 o 10 consultas más frecuentes que se harán? Optimiza para esas. 2. La Evolución es Inevitable. Prepárate El negocio cambia, tus datos cambian y tus necesidades también. Tu modelo debe adaptarse sin demolerlo todo.\nReglas de Oro: No asumas que conoces todos los datos futuros. Usa IDs que nunca cambien, aunque todo lo demás en la fila sí lo haga. Rediseñar un modelo después costará muchísimo más que hacerlo bien desde el inicio. 3. Contextualiza según el Caso de Uso No existe un modelo perfecto universal. El mismo conjunto de datos se modela diferente según quién lo consuma:\nCaso Transaccional (OLTP): Múltiples tablas pequeñas normalizadas (3NF). El foco es la consistencia y la integridad de los datos (ej. Clientes, Órdenes, Detalles). Caso de Análisis / Business Intelligence (OLAP): Modelo Estrella (Star Schema). Los hechos (Facts) en el centro (90% del volumen) rodeados de dimensiones (Dimensions) que describen la información. Optimizado para preguntas puntuales de análisis. Caso de Machine Learning: Datos desnormalizados. Aquí sí conviene una tabla ancha (wide table) para evitar joins costosos durante el entrenamiento. Incluye campos precalculados (ej. \u0026ldquo;gasto total por cliente\u0026rdquo;) para facilitarle la vida al científico de datos. Decisiones Estructurales Clave Una vez claros los pilares, hay dos decisiones técnicas fundamentales: cómo conectas los datos y su nivel de detalle.\nRelaciones 1 a 1: Un usuario tiene un perfil. 1 a Muchos: Un cliente hace muchas órdenes (la relación más común). Un error aquí rompe el historial del cliente. Muchos a Muchos: Siempre usa una tabla intermedia y dale atributos útiles a esa relación. Granularidad La granularidad es el nivel de detalle de una fila en tu tabla. Existen tres niveles:\nBaja (Detallada): Transaccional (cada clic de usuario). Media: Agregada para reportes rápidos. Alta: Super agregada (ventas totales por país). La Regla de Oro de la Granularidad: La tendencia siempre es de Baja hacia Alta (agregar). Nunca podrás desagregar. Si guardas solo ventas totales por tienda, luego no podrás analizar la canasta de compra por cliente. Incluso si ocupa más espacio, almacena siempre el nivel más granular posible. El costo de almacenamiento es barato comparado con el costo de perder la oportunidad de análisis por falta de detalle.\nTécnicas de Optimización Para que tu modelo sea rápido y manejable en el tiempo:\n1. Manejo del Tiempo (Temporalidad) Cuando un dato cambia en el mundo real (ej. el precio de un producto), no lo sobrescribas. Usa la técnica de Slowly Changing Dimensions (SCD):\nMarca el registro antiguo como inactivo (asigna fecha fin). Inserta un nuevo registro con la información actualizada y fecha inicio. Esto te permite analizar el histórico y ver qué promociones funcionaron en el pasado. 2. Particionamiento Imagina tener 5 años de ventas en una sola tabla. Si preguntas por las ventas del mes pasado, la base de datos escanea los 5 años. Si particionas la tabla por mes, la base de datos sabe exactamente dónde está ese mes y lee solo esa pequeña porción. Es el turbo para tus consultas.\nFramework Práctico de Modelado ¿Cómo juntamos todo esto? Sigue este proceso de 5 pasos:\nDefine Objetivos de Negocio: ¿Qué preguntas clave responderán los datos? ¿Quiénes son los usuarios? (Transacciones rápidas vs. Análisis complejo vs. ML). Identifica Patrones de Acceso: ¿Habrá más lectura o escritura? ¿Cuáles son las consultas críticas? ¿Cuál es el volumen de datos esperado a 1 o 5 años? Prototipa para Casos Extremos: Piensa qué pasa si los datos se multiplican por 10 o 100. ¿Qué tan fácil es añadir nueva información sin romper el esquema? Valida con Datos Reales: No te fíes solo de datos de prueba sintética. Carga volúmenes realistas y mide los tiempos de tus consultas clave. Diseña para Evolucionar: Documenta por qué tomaste ciertas decisiones. Planifica revisiones periódicas (ej. cada 12 meses) para ver si el modelo sigue alineado con la estrategia. Conclusión La mayoría de los modelos no fallan el día uno, fallan uno o dos años después cuando el negocio ha cambiado. Pensar en la evolución desde el inicio es la clave.\nEl modelado de datos es un arte y un equilibrio entre teoría y necesidades prácticas. Si te quedas con algo de este video, que sea esto: Modela pensando en cómo se van a acceder los datos y cómo van a evolucionar con el tiempo, no solo en cómo los vas a almacenar hoy. Los equipos futuros de BI, Analistas y Machine Learning te lo agradecerán.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-por-que-modelado-falla/","summary":"El 60% de los proyectos de datos fallan no por la tecnología, sino por decisiones de modelado incorrectas al inicio. Descubre los tres pilares del modelado efectivo, la importancia de la granularidad y un framework práctico para asegurar la escalabilidad de tu arquitectura.","title":"Por QUÉ tu MODELADO FALLA (No es lo que Piensas) 🔥"},{"content":"TL;DR La Inteligencia Artificial (IA) es una herramienta poderosa pero no un reemplazo del pensamiento humano experto. El \u0026ldquo;Vibe Coding\u0026rdquo; o el uso ciegos de herramientas de Low-Code y generación de código pueden traer productividad a corto plazo, pero derivan en crisis de mantenimiento, seguridad y escalabilidad a largo plazo. La verdadera ventaja competitiva radica en el conocimiento profundo, la capacidad de hacer las preguntas correctas (prompting inteligente) y una visión sistémica que la IA aún no posee.\nVideo en Youtube: click aquí\nIntro ¿Es la IA capaz de reemplazar totalmente a un programador o a un experto en tu campo? ¿Es todo lo que responde la IA 100% confiable? Hoy exploraremos lo que hay detrás de la inteligencia artificial y por qué necesitamos una visión más integral.\nVamos a desglosar la ilusión del reemplazo, el sesgo en los datos, casos reales de fracaso en \u0026ldquo;Vibe Coding\u0026rdquo;, la importancia del conocimiento profundo y la visión sistémica en el ciclo de vida del software.\nLa Ilusión del Reemplazo Total Imagina que tienes un asistente de IA muy inteligente en tu casa, pero que nunca ha estado físicamente en ella. Si le preguntas dónde está el control remoto, te dirá \u0026ldquo;donde suele estar en la mayoría de las casas\u0026rdquo;, pero no sabrá que tú lo guardas en un cajón específico.\nLa primera respuesta de la IA suele parecer correcta, y muchas veces aceptamos sin cuestionar si falta contexto. Detectar qué funciona y qué realmente necesitas es la diferencia entre una respuesta genérica y el análisis de un experto que entiende el contexto completo.\nLa IA se Alimenta de Nosotros (Sesgos) Es importante entender que existe un sesgo invisible en cada respuesta. La IA técnicamente no tiene opiniones propias; aprende de datos creados por humanos. Como dice la frase: \u0026ldquo;La historia la cuentan los vencedores\u0026rdquo;, y esto aplica a la IA.\nSi buscas \u0026ldquo;programadores exitosos de Google\u0026rdquo;, probablemente verás imágenes de hombres jóvenes con cierto perfil. La IA aprende de esos sesgos. Además, la IA aprende por patrones. Si repites algo falso muchas veces, la IA lo dará por hecho. Este es el principio de cómo se puede manipular la información si no se tiene criterio.\nLa Trampa del Vibe Coding: Casos de Estudio El uso de IA para generar código sin entender (Vibe Coding) tiene riesgos ocultos:\nEl SaaS de Seguros: Un desarrollador usó IA para crear un flujo completo. Funcionó bien al principio, pero no consideró datos sensibles (PII) ni implementó cifrado adecuado. A los 3 meses, una auditoría de seguridad detectó el fallo, resultando en multas masivas por incumplimiento. Lección: La IA te da lo que pides, pero no te advierte sobre lo que no sabes que deberías pedir (seguridad, compliance). Low-Code/No-Code: Se crea un SaaS sin código. Todo parece perfecto hasta que el proveedor sube precios 300% o los clientes piden personalización compleja. Resultado: Vendor lock-in pesadilla, costos ocultos, escalabilidad imposible y seguridad dependiente de terceros. A menudo, hay que reconstruir todo desde cero. Colapso de un \u0026ldquo;AI-Coder\u0026rdquo;: Un sistema funciona perfecto hasta que una API dependiente cambia de un día para otro. El desarrollador no entiende el código, no sabe qué modificar, ni puede implementar nuevas funciones. Los costos de tokens se disparan y el proyecto se abandona. Realidad: La IA te hace el trabajo 10 veces más rápido al principio, pero puede hacerlo 100 veces más lento cuando necesitas mantenerlo. Productividad vs. Tiempo: Fundamentos vs. Vibe Coding Si graficáramos la productividad contra el tiempo, veríamos dos curvas claras:\nVibe Coder: Empieza con productividad alta (todo es generación automática), pero se estanca y cae en picada cuando aparecen bugs complejos, problemas de escalabilidad o cambios en APIs que no controla. Profesional con Fundamentos: Empieza con productividad más baja (entendiendo el contexto, estructurando lógica), pero alcanza una inflexión y crece sostenidamente. Fases del proyecto:\nGeneración de código: Aquí la IA (y el Vibe Coder) gana. Mantenimiento y Evolución: Aquí es donde el profesional con fundamentos domina, porque entiende la arquitectura, la conectividad y puede prever problemas futuros. Tomar el atajo del Vibe Coding es una trampa a largo plazo.\nConocimiento como Ventaja Competitiva Si todo el conocimiento está en Google y la IA, ¿para qué necesitamos expertos? La respuesta: Fórmulas Secretas.\nEl conocimiento superficial es un commodity. El conocimiento profundo no es comparable. Cualquiera puede pedirle código a la IA para analizar datos, pero solo un experto sabe qué preguntas importan para el negocio, qué datos son ruido y cuáles son relevantes. Un experto entiende las implicaciones de los resultados en un contexto específico.\nPrompting Inteligente No se trata solo de pedir, sino de saber cómo. Es como darle instrucciones a un nuevo empleado muy inteligente pero sin experiencia. Cuanto más contexto y detalles le des, mejor será el resultado.\nEsfórzate en hacer el \u0026ldquo;prompt\u0026rdquo; correcto. Define el rol, el objetivo, el contexto y las restricciones.\nVisión Sistémica: Más Allá del Código La Teoría General de Sistemas dicta que no basta analizar un elemento de forma aislada; hay que analizarlo junto con sus relaciones. La IA a menudo ignora principios sistémicos al inicio:\nPropósito claro y definido. Minimización de dependencias. Patrones de diseño. Seguridad defensiva. Pruebas automatizadas. Mantenibilidad a largo plazo. Si le pides a la IA un microservicio, funcionará, pero ¿funcionará bajo carga? ¿Es seguro? ¿Se puede integrar con otros sistemas? Necesitas arquitecturar pensando en el futuro.\nEl Ciclo de Vida del Software y la IA ¿Dónde debe ir la IA y dónde el humano?\nIA Excelente (Implementación): Generación de código boilerplate. Es su fuerte. IA con Supervisión Humana (Pruebas, Implantación, Monitoreo): La IA puede ayudar, pero un humano debe verificar los casos, aprobar el despliegue y vigilar la producción. Experto Humano (Análisis, Diseño, Mantenimiento, Requisitos Futuros): Análisis: Entender el problema y el contexto es puramente humano. Diseño: La arquitectura y estrategia requieren previsión. Mantenimiento: Evoluciones, actualizaciones y manejo de cambios en usuarios/conectividad. Requisitos Futuros: Cambios regulatorios y amenazas de seguridad que la IA no puede prever. Responsabilidad Legal y Ética La IA no puede reemplazar al humano en responsabilidades legales.\nUn documento legal generado por IA no es válido hasta que un humano con licencia lo certifica. Un diagnóstico médico de IA puede tener 95% de precisión, pero si se equivoca, ¿a quién demandan? La ley está hecha para humanos. La responsabilidad siempre recae en las personas u organizaciones.\nConclusión La IA es una herramienta extraordinaria, pero la responsabilidad es humana. El método correcto no es dejar que piense por ti, sino usarla como un colaborador.\nResuelve el problema conceptualmente por ti mismo primero (dibuja, diseña). Usa la IA para acelerar la implementación. Valida críticamente todo. Existe una paradoja: Cuanto más sabes, más le puedes extraer a la IA. No permitas que la IA debilite tu capacidad de pensamiento crítico. En un mundo donde todos usan IA, la diferencia la hará quien la use con sabiduría y conocimiento profundo.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-ia-vibe-coding/","summary":"Explora los límites de la Inteligencia Artificial, los peligros del \u0026ldquo;Vibe Coding\u0026rdquo; sin fundamentos y por qué el conocimiento profundo y la visión sistémica son más críticos que nunca en la era de la automatización.","title":"La Realidad Detrás de la IA: Más Allá del Vibe Coding 💡"},{"content":"TL;DR El \u0026ldquo;Stack Moderno de Datos\u0026rdquo; (MDS) ofrece una gran escalabilidad y adopción gracias a la nube, resolviendo problemas de ingeniería del pasado. Sin embargo, ha creado una \u0026ldquo;trampa\u0026rdquo;: la fragmentación de herramientas genera complejidad para depurar errores, falta de observabilidad y problemas de calidad de datos. Para superarlo, debemos dejar de obsesionarnos con la tecnología y enfocarnos en el mapeo semántico, contratos de datos, entendimiento del negocio y tratar los datos como un producto.\nVideo en Youtube: click aquí\nIntro Antes de la explosión del stack moderno de datos, las herramientas eran escasas y los datos se usaban principalmente para automatización de reportería y análisis específicos. Hoy en día, existe una percepción de que hemos encontrado el \u0026ldquo;stack mágico\u0026rdquo; capaz de resolver todos los problemas.\nNada podría estar más lejos de la realidad. Aunque el stack moderno es poderoso, trae nuevos problemas que no se ven a primera vista y que pueden frenar a las empresas si no se gestionan con una estrategia sólida.\n¿Qué es el Stack de Datos Moderno? Imagina construir un flujo de datos completo, desde la captura de sistemas operacionales, pasando por transformación y almacenamiento en la nube, hasta la visualización o Machine Learning.\nHoy en día, tenemos una herramienta para cada paso:\nAlmacenamiento/Procesamiento: BigQuery, Snowflake. Orquestación: Airflow, Prefect. Streaming: Kafka, Flink. Visualización: Looker, Power BI. Si le sumamos herramientas de observabilidad y catálogos, terminas conectando más de 10 o 15 componentes distintos. El gran logro de este stack es la escalabilidad y la facilidad de adopción, pero esto viene con un costo oculto.\nLa \u0026ldquo;Trampa\u0026rdquo; del Stack Moderno El problema principal es que estas herramientas no siempre fueron diseñadas para trabajar juntas. Tenemos un rompecabezas de diferentes tecnologías y vendedores.\n1. Fragmentación y Complejidad Cada herramienta tiene sus propios metadatos, logs, configuraciones y formas de gestionar errores. Imagina un pipeline con Snowflake, dbt, Airflow y Kafka. Si algo falla, ¿fue culpa de Airflow? ¿De dbt? ¿De las credenciales de la API? ¿De un script colgado?\nRastrear un problema en estos laberintos puede tomar horas o días, a menos que tengas una cultura excelente de monitoreo y alertas, algo que muchos equipos aún no adoptan.\n2. Calidad de Datos El stack moderno por sí solo no soluciona el aspecto cultural ni las buenas prácticas. Suelen faltar pruebas automatizadas, validaciones y verificaciones de consistencia.\nEl caso de \u0026ldquo;Datos Felices\u0026rdquo;: Imagina una empresa ficticia donde cada noche corre un pipeline financiero. Un día, el equipo de TI cambia la codificación de un campo (de entero a decimal) sin avisar. El script de transformación comienza a generar valores nulos y el tablero reporta \u0026ldquo;cero ventas\u0026rdquo;. El pánico se apodera de la empresa hasta que, mucho después, encuentran el origen.\nEsto sucede porque muchas empresas confían en la tecnología y no en un sistema sólido de calidad.\n3. Explosión de Casos de Uso y Deuda Técnica Hemos pasado de un simple tablero para un ejecutivo a cientos de modelos y tableros en pocos años. Esto ha traído:\nDificultad para comprender el contexto. Iniciativas que reutilizan datos con diferentes nombres. Referencias a tablas que ya no se mantienen. Lucha constante por encontrar la \u0026ldquo;fuente de la verdad\u0026rdquo;. \u0026ldquo;Deuda de datos\u0026rdquo; por la creación excesiva de tablas personalizadas. ¿Cómo Superar la Trampa? 4 Ideas Clave El stack moderno resolvió problemas de ingeniería (costo y rendimiento), pero generó problemas en cómo los datos se usan para resolver necesidades de negocio. Aquí hay cuatro enfoques de alto nivel para abordar esto:\n1. Data Warehousing empieza con entender los datos No basta con pegar datos de diferentes sistemas (ventas, facturación, usuarios) en una tabla. Primero hay que entender qué significa cada dato y cómo se relaciona.\nMapeo Semántico: Por ejemplo, client_id en un sistema puede significar lo mismo que person_id en otro. El objetivo es unirlos con sentido. Si entendemos los datos, el Data Warehouse será fácil de entender. 2. Involucrar a los Ingenieros de Software Los ingenieros de software crean los sistemas y los datos, pero a menudo no saben cómo se usarán después. Esto genera cambios que rompen reportes sin previo aviso.\nContratos de Datos: Define reglas claras de calidad, formato y significado. Los ingenieros deben saber cómo se usan sus datos y ser responsables de la calidad que generan sus sistemas. 3. Los Ingenieros de Datos deben entender el Negocio Los ingenieros de datos arman la \u0026ldquo;tubería\u0026rdquo;, pero muchas veces no saben el propósito final.\nContexto: No crees solo una tabla de \u0026ldquo;ventas\u0026rdquo;; entiende si se usa para un reporte financiero, una campaña de marketing o una aplicación. Esto permite conectar los datos de forma lógica y útil. 4. Pensar en los Datos como un Producto Cada tabla, dashboard o modelo debe resolver un problema real de negocio. No debe ser solo un ejercicio técnico.\nAsegúrate de que el producto de datos tenga un cliente claro y un uso útil. Conclusión El stack moderno de datos trae una potencia increíble, pero también trae problemas de calidad y confusión de roles. Es un escenario real en muchas empresas que, en su afán por subirse a la nube, añadieron herramientas sin una estrategia sólida.\nCitando el libro Team Topologies de Matthew Skelton: las organizaciones que entienden cómo fluyen sus equipos y sus datos son las que logran escalar sin romperse.\nEl verdadero stack moderno no es el que tiene más herramientas, es el que logra conectar datos, personas y decisiones con propósito.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-trampa-stack-moderno-datos/","summary":"El Stack Moderno de Datos resolvió problemas de escalabilidad y costo, pero trajo nuevos desafíos silenciosos, que son complejidad operativa, falta de calidad de datos y desconexión entre equipos. Descubre cómo evitar la \u0026ldquo;trampa\u0026rdquo; enfocándote en la estrategia y no solo en las herramientas.","title":"La Trampa del Stack Moderno de Datos: Lo que Nadie te Cuenta"},{"content":"TL;DR La arquitectura de datos ha evolucionado desde sistemas rígidos y costosos (Data Warehouse on-premise) hacia almacenamientos masivos y desordenados (Data Lakes), hasta llegar a soluciones híbridas en la nube. Hoy en día, el Data Lakehouse combina lo mejor de ambos mundos: el almacenamiento barato de un lago con las capacidades de gestión transaccional de un warehouse, apoyándose en metadatos y APIs para mantener el orden.\nVideo en Youtube: click aquí\nIntro ¿Te has preguntado por qué antes los datos cabían en un solo servidor y ahora necesitamos la complejidad de la nube? La respuesta está en la evolución de las necesidades del negocio y el volumen de información.\nAntes de profundizar en la historia, definamos qué es arquitectura de datos: son los planos y planes. La estrategia. Es vital tener un plan de organización, almacenamiento y explotación de la información.\nPara usar una analogía: imagina tu cocina. Si no ordenas tu despensa, pasarás tiempo buscando qué compraste, qué vas a comer, y es probable que la comida se caduque. Con los datos pasa lo mismo. Sin arquitectura, gastas tiempo implementando soluciones que creías correctas pero que terminan siendo inútiles.\nFase 1: Data Warehouse Relacional (On-Premise) En los inicios, el problema principal siempre fue: ¿Cómo acceder a la información correcta? Los Data Warehouses on-premise surgieron para resolver esto, enfocados en Business Intelligence (BI).\nEl primer Data Warehouse fue instalado por Teradata en 1983 para análisis financiero.\nEl flujo de esta arquitectura seguía un patrón clásico de ETL:\nFuentes: Ventas, inventario, CRM. Staging: Un área intermedia para transformar los datos. Data Warehouse: El repositorio final con los datos estructurados. El problema: Era una arquitectura rígida. Si necesitabas más poder de almacenamiento o cómputo, implicaba meses de inversión y cambios en la infraestructura física. Cambiar el modelado de datos era casi como reconstruir la casa desde cero.\nFase 2: Data Lake Con la llegada del Big Data alrededor de 2010 (con Hadoop, MapReduce y Spark), el objetivo cambió radicalmente: almacenar todo en raw (crudo) a bajo costo.\nEl flujo del Data Lake era más simple:\nFuentes: Archivos planos, videos, audio, logs. Data Lake: Un repositorio central donde se tiraba todo \u0026ldquo;tal cual\u0026rdquo;. El Data Lake se vendió como la solución a todos los problemas del Warehouse relacional. Sin embargo, surgió un nuevo problema: consultar los datos no era fácil.\nEl \u0026ldquo;Data Swamp\u0026rdquo; (Pantano de Datos): A menudo, un Científico de Datos se encontraba con que los datos estaban ahí, pero no había metadatos ni catálogos. Nadie sabía qué estaba guardado ni cómo encontrarlo. La mentalidad de \u0026ldquo;como es barato, guardemos todo\u0026rdquo; sin estrategia llevó a un caos de gestión. Se almacenaba la información, pero no se evaluaba cómo administrarla.\nFase 3: La Nube y el Modern Data Warehouse Con la popularización de la nube, cambió la forma de pensar: ya no hace falta comprar servidores, solo pagas por lo que usas. Esto permitió manejar la Velocidad (streaming, tiempo real) y el Volumen de datos que empresas como Netflix generan (millones de eventos por clic).\nAquí surge el concepto del Modern Data Warehouse. Se dio cuenta de que los Data Lakes fallaron en reemplazar totalmente al Data Warehouse relacional, pero ofrecían un excelente lugar de aterrizaje (landing zone).\nLa solución fue combinar lo mejor de los dos mundos:\nFuentes: Diversos orígenes de datos. Ingesta -\u0026gt; Data Lake: Se guarda la información cruda. Transformación -\u0026gt; Data Warehouse: Se mueven los datos necesarios a una estructura relacional para análisis. Visualización: Herramientas de BI. Esta arquitectura permitía tener almacenamiento barato en el lago y rendimiento estructurado en el warehouse.\nFase 4: Data Lakehouse Alrededor de 2020, la evolución dio un paso más con el Data Lakehouse. El objetivo era eliminar la necesidad de tener un Data Warehouse relacional separado y utilizar un solo repositorio.\n¿Qué cambió para que el Data Lake no fuera un caos como antes? La aparición de una capa de software de almacenamiento transaccional que se ejecuta sobre el Data Lake existente. Esta capa hace que el lago funcione como una base de datos tradicional (propiedades ACID), pero manteniendo la flexibilidad de guardar cualquier tipo de dato.\nDiagrama de un Data Lakehouse:\nFuentes: Varias fuentes de datos. Ingesta -\u0026gt; Repositorio: Todo cae en un solo lugar. Capa de Software: Aquí está la magia, la capa transaccional sobre el lago. Modelado: Se preparan los datos. Visualización: Consumo final. Componentes Transversales Clave Para que un Data Lakehouse funcione correctamente, se necesitan dos componentes fundamentales que atraviesan todo el flujo:\nMetadatos: Es la información descriptiva (definiciones, linaje, catálogos).\nIngesta: Describe el origen y estructura. Transformación: Rastrea qué se está haciendo. Visualización: Permite a los usuarios finales saber con qué están tratando. APIs: Facilitan la exposición y consumo de datos. Durante la transformación, se pueden exponer APIs para acceder a datos limpios directamente, permitiendo una integración más fluida con otras aplicaciones.\nMención Especial: Data Mesh Es importante mencionar el Data Mesh, aunque no es una tecnología per se, sino un cambio de mentalidad organizacional. No todas las empresas están listas para implementarlo; depende de su nivel de madurez. Es un tema profundo que abordaremos en otro video, pero debes saber que evaluar si es necesario es parte del rol del arquitecto.\nConclusión Las arquitecturas de datos siempre han evolucionado para resolver problemas. Sin embargo, cada mejora trae nuevos desafíos.\nComo menciona el libro The Innovator\u0026rsquo;s Dilemma, la clave está en responder a los retos con soluciones que nos impulsen a evolucionar en lugar de quedarnos con lo que ya conocemos. En el mundo de los datos, la única constante es el cambio. No se trata de alcanzar una meta final, sino de seguir innovando y aprendiendo paso a paso.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-como-nacio-arq-moderna/","summary":"Un recorrido histórico desde los Data Warehouses relacionales on-premise hasta los Data Lakes y el moderno Data Lakehouse. Descubre cómo la nube y el Big Data cambiaron las reglas del juego.","title":"Cómo Nació la Arquitectura de Datos Moderna"},{"content":"TL;DR La diferencia principal radica en el orden de las operaciones: ETL (Extract, Transform, Load) transforma los datos antes de cargarlos, ideal para sistemas on-premise costosos donde el espacio es limitado. Por otro lado, ELT (Extract, Load, Transform) carga los datos crudos primero y los transforma dentro del Data Warehouse, aprovechando el almacenamiento barato y el poder de cómputo de la nube, lo que lo convierte en el estándar actual por su flexibilidad y aislamiento de la fuente.\nVideo en Youtube: click aquí\nIntro En el mundo de la ingeniería de datos, dos acrónimos fundamentales son ETL y ELT. Aunque parecen simples variaciones en el orden de las letras, representan dos filosofías distintas sobre cómo mover, procesar y almacenar la información.\nEntender cuándo y por qué usar cada uno es vital para diseñar arquitecturas eficientes. ¿Vale la pena transformar los datos antes de guardarlos, o es mejor guardar todo \u0026ldquo;tal cual\u0026rdquo; y procesarlo después? La respuesta depende mucho de la infraestructura y las necesidades del negocio.\n¿Qué es un ETL? ETL significa Extract, Transform, Load (Extraer, Transformar, Cargar). Este proceso se divide en tres etapas claras:\nExtract (Extracción): Consiste en tomar toda la información de las fuentes definidas (bases de datos, APIs, CSVs) e ingerirla hacia un punto intermedio. Transform (Transformación): Aquí es donde se da sentido a los datos. Se realiza la limpieza, validación y aplicación de reglas de negocio. Es la etapa más pesada lógicamente. Load (Carga): Una vez que los datos están limpios y estructurados, se cargan en el repositorio final para su consumo. ¿Por qué nació el ETL? Para entender el ETL, hay que mirar al pasado. Los sistemas de Data Warehouse tradicionales (on-premise) eran extremadamente costosos. Comprar servidores, instalar la infraestructura y configurar todo para una simple prueba de concepto podía tomar meses.\nDebido a este alto costo, el almacenamiento y el procesamiento eran recursos limitados y valiosos. No se podía dar el lujo de almacenar \u0026ldquo;basura\u0026rdquo; o datos sin procesar. Por ello, se tenía que ser muy preciso:\nSe extraía solo la información necesaria. Se transformaba un subconjunto de datos cuidadosamente seleccionado. Se cargaba solo lo que ya servía para el análisis. El flujo del ETL Si visualizáramos este proceso, veríamos lo siguiente:\nFuentes: Bases de datos, APIs, archivos CSV. Extracción: Los datos se mueven de las fuentes. Staging (Área de preparación): Aquí llega la información cruda y es donde ocurre la Transformación. Se limpia y estructura antes de tocar el sistema final. Data Warehouse: Finalmente, se cargan los datos ya procesados listos para ser consultados. ¿Qué es un ELT? ELT significa Extract, Load, Transform (Extraer, Cargar, Transformar). Como puedes notar, las últimas dos letras intercambian su orden.\nEl cambio de paradigma se dio gracias a la aparición de los Data Warehouses en la nube. Proveedores como Snowflake, Google BigQuery o Amazon Redshift hicieron que la infraestructura fuera accesible con solo unos clics.\n¿Por qué usar ELT? Con la nube, el costo del almacenamiento bajó drásticamente. Ya no era necesario ser tan \u0026ldquo;tacaño\u0026rdquo; con el espacio. Se descubrió que no era obligatorio transformar los datos antes de cargarlos. El flujo se simplificó:\nSe extraen los datos. Se cargan tal cual (crudos) en la nube (como si los pasaran a través de una pared). Se transforman dentro del propio Data Warehouse. Ventajas principales:\nAislamiento: Si la lógica de la fuente original cambia, tienes los datos crudos a salvo en la nube y puedes re-procesarlos sin volver a pedirlos a la fuente. Costo: Aunque el almacenamiento puede aumentar, se elimina la complejidad de planificar transformaciones complejas antes de siquiera saber si los datos serán útiles. Poder de cómputo: La nube permite separar el almacenamiento del cómputo. Puedes transformar datos usando motores potentes dentro de la misma instancia sin afectar la carga. El flujo del ELT En un diagrama de ELT, la estructura varía ligeramente respecto al ETL:\nFuentes: Igual que antes (BD, APIs, CSV). Extracción: Se toman los datos. Load (Carga): Los datos caen directamente en el repositorio final en estado crudo. No hay un área de staging externo obligatorio para la transformación previa. Transformación: Este componente actúa dentro del Data Warehouse. Utiliza el poder de cómputo de la nube para limpiar, estructurar y modelar los datos que ya están ahí. ¿Cuándo usar cada uno? Hoy en día, la mayoría de las arquitecturas modernas tienden a usar ELT porque la tecnología lo permite y resulta mucho más práctico. Al eliminar la barrera de la transformación previa, los equipos de datos pueden experimentar más rápido.\nUsa ELT si: Estás trabajando en la nube, quieres flexibilidad para cambiar tus modelos de datos sin volver a extraer desde cero, y necesitas iterar rápido. Usa ETL si: Tienes restricciones de legacy, necesitas cargar datos en un sistema on-premise con recursos limitados, o hay requisitos de seguridad estrictos que prohíben almacenar datos crudos en el repositorio final. Conclusión La evolución de ETL a ELT refleja la evolución de la tecnología: pasamos de un mundo donde el hardware era caro y escaso, a uno donde el almacenamiento es abundante y el cómputo es elástico.\nEntender esta diferencia no es solo teórico; define cómo diseñamos tus pipelines, qué herramientas elegimos y cuánta agilidad tendremos para responder a las necesidades del negocio. En la era de la nube, ELT se ha convertido en el patrón predominante por su capacidad para manejar el caos de los datos crudos y convertirlo en valor de manera escalable.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-etl-elt-diferencia/","summary":"Descubre las diferencias clave entre los procesos ETL y ELT, su historia, por qué la nube cambió el paradigma de los datos y cuál es el enfoque moderno para la arquitectura de datos.","title":"ETL y ELT: ¿Cuándo y Por qué usar cada uno?"},{"content":"TL;DR Un Arquitecto de Datos diseña la estructura de almacenamiento, organización y utilización de datos para garantizar la calidad y flexibilidad de los mismos. Se enfoca en la estrategia y tácticas, trabajando en estrecha colaboración con ingenieros de datos para implementar la arquitectura. Comprender el ciclo de vida de la ingeniería de datos y los desafíos comunes es clave para agregar el valor empresarial necesario.\nVideo en Youtube: click aquí\nIntro Hoy en día, es esencial que los datos puedan ser accedidos y reutilizados no solo por profesionales, sino también por usuarios comunes, como aquellos que utilizan redes sociales y tratan de descargar su propia información.\nTareas como crear, guardar, ingerir, transformar, procesar y visualizar datos requieren tiempo y esfuerzo.\nAdemás, mantener la seguridad, ejecutar la gestión, realizar operaciones, detallar la orquestación, preservar buenas prácticas de ingeniería de software y definir la estrategia de arquitectura de datos son aspectos críticos del ecosistema de datos.\nDe todos estos puntos, quiero centrarme en la arquitectura de datos. Existen varios roles relacionados con los datos en el mercado laboral que a veces pueden resultar abrumadores o difíciles de distinguir entre sí.\nSi tienes experiencia trabajando con datos, es posible que hayas notado que a veces un Analista de Datos realiza tareas que típicamente son realizadas por un Ingeniero de Datos, o viceversa.\nDe manera similar, un Científico de Datos puede estar enfocado únicamente en consultas SQL y paneles para una empresa. Esta variación en los roles a menudo depende de la madurez de los datos de la empresa, organización o proyecto.\n¿Qué es un Arquitecto de Datos? Si buscas en línea, en libros o preguntas a alguien con experiencia en datos, puedes encontrar diferentes definiciones de lo que es un arquitecto de datos.\nSegún el libro Deciphering Data Architectures de James Serra:\nSon quienes diseñan la estructura de alto nivel de la arquitectura de datos (MDW, Data Fabric o Data Lakehouse) y deciden qué tecnologías y políticas de gobernanza de datos debe utilizar el proyecto.\nSegún TOGAF:\nSon responsables de describir la estructura e interacción de los principales tipos y fuentes de datos, activos de datos lógicos, activos de datos físicos y recursos de gestión de datos de la empresa.\nSegún DAMA DMBOK:\nIdentifican las necesidades de datos de la empresa (independientemente de la estructura) y diseñan y mantienen planes maestros para guiar la integración de datos, controlar los activos de datos y alinear las inversiones en datos con la estrategia empresarial.\nSegún el libro Fundamentals of Data Engineering de Joe Ries \u0026amp; Matt Housley:\nFuncionan como un nivel de abstracción respecto a los ingenieros de datos. Los arquitectos de datos diseñan el modelo para la gestión organizacional de los datos, mapeando procesos y la arquitectura general de datos y sistemas. También sirven como un puente entre los aspectos técnicos y no técnicos de una organización.\nTambién tienen otra definición:\nSon aquellos que diseñan sistemas para apoyar las cambiantes necesidades de datos de una empresa, logradas a través de decisiones flexibles y reversibles alcanzadas mediante una cuidadosa evaluación de compensaciones. Ahora, ¿qué definición se debe elegir? Resumiendo todas estas definiciones, se podría encapsular de la siguiente manera:\nDiseñan la estructura general de cómo se almacenan, organizan y utilizan los datos. Deciden qué tecnologías se utilizarán para gestionar los datos. Crean reglas y políticas para garantizar que los datos sean de alta calidad y confiables. Aseguran que los sistemas de datos sean flexibles y puedan adaptarse a las cambiantes necesidades de la empresa. Funcionan como diseñadores, desarrollando los sistemas necesarios para todo el ciclo de vida de los datos, de modo que las empresas puedan maximizar y potenciar el valor de sus datos.\nUn arquitecto de datos analiza los pros y los contras, diseña con agilidad y agrega valor al negocio.\n¿Qué NO es un Arquitecto de Datos? Cualquier cosa relacionada tanto con la estrategia como con las tácticas puede considerarse parte de la Arquitectura de Datos.\nLa estrategia implica las preguntas qué, por qué y cuándo, mientras que las táctica involucra la pregunta cómo.\nSupongamos que alguien de tu empresa se acerca a ti y expresa la necesidad de integrar información de diversas fuentes para poder utilizar los datos.\nComo arquitecto de datos, debes comenzar investigando con qué exactamente están tratando, entendiendo por qué quieren esta integración y utilización de datos, y determinando cuándo necesitan este tipo de solución.\nEstas no son las únicas preguntas que un arquitecto de datos formula, pero el punto que quiero enfatizar es que no debes simplemente decir: \u0026ldquo;Tenemos las herramientas X, Y y Z para extraer y analizar datos,\u0026rdquo; ya que esto puede tener consecuencias negativas en el diseño de la solución.\nAdemás de la estrategia y las tácticas, los arquitectos de datos deben considerar tres aspectos principales al desarrollar una nueva arquitectura de datos:\nCompletitud Precisión Consistencia A menudo, los interesados pueden no tener una comprensión clara de lo que están tratando, por lo que es esencial estar presente al definir esos requisitos funcionales.\nEn mi opinión, es un arte; a veces, los interesados pueden saber solo que necesitan integrar y utilizar datos, lo cual puede ser un buen punto de partida.\n¿Pero estas tareas suelen ser realizadas por un Ingeniero de Datos, o no? Es cierto que un ingeniero de datos es capaz de manejar todas estas tareas, pero como se mencionó anteriormente, los arquitectos de datos operan a un nivel más alto de abstracción.\nAdemás, aunque no soy un experto en construcción, entiendo que un ingeniero civil podría cumplir con las funciones de un arquitecto. Entonces, ¿por qué existen los arquitectos?\nPorque los arquitectos se enfocan en la estrategia y las tácticas, mientras que los ingenieros dan vida a los diseños.\nUn ingeniero de datos tiene la tarea de crear, probar y mantener la arquitectura de datos. Escribe scripts para extraer, cargar y transformar datos de diversas fuentes para crear una solución de datos, trabajando en estrecha colaboración con un arquitecto de datos para implementar la arquitectura planificada.\nSi bien un ingeniero puede realizar trabajos de arquitectura, es importante definir sus limitaciones, objetivos, tareas y alcance. Esto es crucial porque es posible que hayas encontrado situaciones en tu lugar de trabajo donde un ingeniero asume más responsabilidades de las necesarias.\nAhora, de todos estos roles, ¿has observado alguna posición donde las tareas se hayan combinado?\nData Analyst Data Scientist Business Intelligence Analyst Data Engineer Database Administrator Data Architect Data Steward Product Owner No es raro que los roles se mezclen, pero es esencial recordar que un rol relacionado con los datos puede abarcar múltiples responsabilidades.\nSu Rol en el ciclo de vida de Ingenieria de Datos Entender el ciclo de vida de la ingeniería de datos es importante debido a su impacto en cada etapa de un proyecto, lo que en última instancia entrega valor empresarial a los interesados.\nGeneración Almacenamiento Ingestión Transformación Visualización o Entrega Los datos tienen valor en cada fase de este ciclo, y los datos que no son consumidos o consultados pueden representar un riesgo para cualquier negocio.\nMuchas empresas, en su búsqueda de proyectos ambiciosos en la era del big data, han recopilado cantidades masivas de datos que, en última instancia, no se utilizaron.\nLos proyectos deben ser intencionales a lo largo de todo el ciclo de vida, tanto en ingeniería como en datos.\nUn ingeniero de datos es responsable de extraer información de manera oportuna, siguiendo los protocolos adecuados de seguridad e integración, y cualquier otra tarea necesaria.\n¿Pero el trabajo de un Ingeniero de Datos termina aquí? Eso es lo que quiero que entiendas y a lo que me refiero: un arquitecto de datos debe evaluar, diseñar, organizar y ver el valor en las fases del proyecto. Un ingeniero de datos podría realizar todas estas tareas, pero no es su trabajo principal.\nPor ejemplo, imaginemos que vas a un hospital y te encuentras con un médico. Probablemente sepas con certeza que el médico va a:\nExaminar tu condición Hacer un diagnóstico Prescribir medicación Y seguramente no va a:\nLimpiar el hospital Fabricar la medicación Gestionar la administración del hospital ¿Pero qué pasa con los ingenieros de datos? ¿Las expectativas son poco claras? Lo que ocurre es que ellos pueden:\nDiseñar el modelo de datos de un Data Warehouse Gestionar bases de datos de aplicaciones Crear un pipeline de datos para Machine Learning Administrar toda la infraestructura de big data e instalación de software Analizar big data para transformar datos en bruto en información significativa Como mencioné anteriormente, si las empresas fueran más maduras en términos de datos, entonces habría límites mejor definidos.\nAl final del día, también depende de cómo las herramientas en lo que se conoce como \u0026ldquo;red de datos moderna\u0026rdquo; aumenten con la creciente complejidad de los datos.\n¿Qué es lo que debería de hacer un Ingeniero de Datos? Creo que deberían tener un amplio entendimiento de todo el ciclo de vida de los datos, distinguiendo entre habilidades esenciales, beneficiosas u opcionales.\nSin embargo, lo que se considera esencial en una empresa puede verse como opcional en otra. En última instancia, depende de las operaciones específicas y las necesidades del negocio y sus clientes.\nDesafíos Comunes de Datos Si la madurez de los datos es baja, puedes encontrar:\nSilos de datos Infraestructura inadecuada Resistencia cultural Vulnerabilidades de seguridad Por otro lado, si la madurez de los datos es alta, puedes enfrentar:\nProblemas de gobernanza y gestión de datos Innovación con tecnologías emergentes Desarrollo y mantenimiento de análisis avanzados En ambos escenarios, puede haber una variedad de desafíos, pero es importante reconocer que muchos datos no se están utilizando de manera efectiva. Esto podría deberse a un mal diseño de la arquitectura de datos, gobernanza o gestión de datos inadecuadas, o a una mala calidad de los datos desde su creación.\nOutro Un Arquitecto de Datos desempeña un papel crucial en la configuración del paisaje de datos de una organización. Son responsables de crear arquitecturas de datos robustas que aseguren la accesibilidad, confiabilidad y seguridad de los datos.\nAbordando tanto aspectos estratégicos como tácticos, los Arquitectos de Datos cierran la brecha entre los requisitos funcionales y los requisitos técnicos.\nSu capacidad para evaluar compensaciones y desarrollar sistemas adaptables es esencial para satisfacer las necesidades de datos.\nPor último, los Arquitectos de Datos empoderan a las organizaciones para utilizar eficazmente sus recursos de datos, impulsando el valor empresarial y la innovación.\n","permalink":"https://soyomarvaldezg.codeberg.page/posts/v-data-architect/","summary":"Enterate el por qué un Arquitecto de Datos puede tener un gran impacto y cuál es la diferencia entre otros roles en el mundo de los datos.","title":"¿Por qué ser un Arquitecto de Datos?"},{"content":"El término Big Data surgió hace años y desde entonces muchos consideran que los datos son el \u0026ldquo;nuevo petróleo\u0026rdquo;. Pero en la realidad, aprovechar plenamente este recurso es complicado: abundan los retos en gestión, calidad, integridad y privacidad.\nLos datos terminan siendo preocupación secundaria en vez de un activo crítico.\n\u0026ldquo;What You See Is All There Is\u0026rdquo; – Daniel Kahneman, Thinking Fast and Slow\nEsta frase resume un peligro común: tomar decisiones importantes solo con la información que tenemos a la vista, sin examinar qué falta o podría estar mal.\nPor eso, los datos no son museos de dashboards ni monstruos que nos generen desconfianza, sino una fuente valiosa cuando se tratan con rigor y conciencia.\n¿Qué encontrarás aquí? Artículos prácticos y análisis sobre calidad, arquitectura, seguridad y mejores prácticas del manejo de datos en la vida real. Reflexiones, ejemplos y consejos que abordan problemas cotidianos del mundo de datos: gestión, visualización, acceso, privacidad y toma de decisiones. ¿Quién soy y por qué hago esto? Soy Omar Valdez, he trabajado desde la trinchera armando reportes y pipelines hasta definir arquitecturas y liderar proyectos de datos a escala.\nHe visto de cerca la importancia (y los desafíos) de tratar a los datos como capital estratégico, no solo como \u0026ldquo;lo que soporta la operación\u0026rdquo;. Estoy convencido de que una comunidad informada y consciente puede potenciar el valor de los datos, reducir riesgos y tomar decisiones más inteligentes.\nMi compromiso contigo Promover mejores prácticas para extraer valor real, cuidando siempre la integridad y confidencialidad de los datos Compartir contenido útil, claro y sin teoría innecesaria, siempre enfocado en la aplicación práctica Hacer visible el lado humano, ético y estratégico de los datos ","permalink":"https://soyomarvaldezg.codeberg.page/whoami/","summary":"\u003cp\u003eEl término Big Data surgió hace años y desde entonces muchos consideran que los datos son el \u0026ldquo;nuevo petróleo\u0026rdquo;. Pero en la realidad, aprovechar plenamente este recurso es complicado: abundan los retos en gestión, calidad, integridad y privacidad.\u003c/p\u003e\n\u003cp\u003eLos datos terminan siendo preocupación secundaria en vez de un activo crítico.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u0026ldquo;What You See Is All There Is\u0026rdquo;\n– Daniel Kahneman, Thinking Fast and Slow\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eEsta frase resume un peligro común: tomar decisiones importantes solo con la información que tenemos a la vista, sin examinar qué falta o podría estar mal.\u003c/p\u003e","title":"\u003e_ whoami"},{"content":"La razón principal por la que estoy haciendo esto es porque esperaba poder saber, durante el proceso de personalizar mi interfaz de usuario, cómo hacerlo lo más atractivo y eficiente posible.\nComo lo comentó Linus Torvalds:\n\u0026ldquo;Cualquier programa solo es tan bueno como sea útil. En el verdadero open source, tienes el derecho a controlar tu propio destino.\u0026rdquo;\nNOTA: Generalmente se actualiza de forma eventual, por lo que NO puede estar al día esta información.\nLo Básico Para mi sistema operativo, uso MacOs Para mi window manager, uso Aerospace. Para mi terminal, uso Ghostty. Para mi shell, uso Zsh. Aplicaciones Para mi launcher, uso Raycast Para mi editor, uso NeoVim Para mi file manager, uso Yazi Para mi terminal multiplexer, uso Tmux Theme Para mi theme, generalmente uso Tokyonight Storm Para mi terminal font, uso Iosevka Nerd Font Para mi shell prompt, uso oh-my-posh Si deseas ver más de mis dotfiles, haz click aquí\n","permalink":"https://soyomarvaldezg.codeberg.page/dotfiles/","summary":"\u003cp\u003eLa razón principal por la que estoy haciendo esto es porque esperaba poder saber, durante el proceso de personalizar mi interfaz de usuario, cómo hacerlo lo más atractivo y eficiente posible.\u003c/p\u003e\n\u003cp\u003eComo lo comentó Linus Torvalds:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u0026ldquo;Cualquier programa solo es tan bueno como sea útil. En el verdadero open source, tienes el derecho a controlar tu propio destino.\u0026rdquo;\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cem\u003eNOTA: Generalmente se actualiza de forma eventual, por lo que NO puede estar al día esta información.\u003c/em\u003e\u003c/p\u003e","title":"dotfiles"}]