¿Cuáles son las diferencias entre una base de datos, data mart, data warehouse, un lago de datos y un cubo?

Poniendo todo en términos laicos:

La base de datos es un sistema de gestión para sus datos y cualquier cosa relacionada con esos datos. Es como una biblioteca gigante de archivos de Excel. Cada archivo de Excel es una tabla en una base de datos. Los datos se almacenan en el archivo de Excel (la base de datos realmente almacena datos en un archivo). Tiene una biblioteca de archivos de Excel, toda esa biblioteca se llama una base de datos.

También hay secuencias, índices, disparadores, almacenamiento de procesos y funciones, etc., pero están ahí para ayudarlo a acceder a los datos más rápido o ayudarlo a mover / manipular datos.

De todos estos elementos, la base de datos es la base en la que se basa todo lo demás.

Data Warehouse está construido sobre una base de datos.

Imagina que tienes una gran biblioteca de libros, esa es tu base de datos. Usted pregunta “¿cuántas recetas de pollo hay en esta biblioteca?” Bueno, debe buscar debajo de la sección de cocina, la sección de procedimientos, la sección de viajes para cocinar en sabores locales, la sección de salud para una cocina saludable, etc. etc.

En un almacén de datos, si desea ver recetas, alguien creará un libro para usted llamado todas las recetas, con pollo, carne de res y cerdo bien etiquetados; tendrían que tomar todas las recetas de todos los libros y ponerlas en un libro para usted.

Data Warehouse son datos que tiene en otras bases de datos pero organizados específicamente para las preguntas que desea hacer.

En contraste, las “otras bases de datos” son bases de datos operacionales organizadas específicamente para que usted pueda administrar su negocio / sitio web de manera rápida y eficiente.

Data Mart es parte de un Data Warehouse. Para escribir ese libro en todas las recetas de todos los demás libros, necesitaría mucha investigación; necesita ver si estas dos recetas son iguales (si es así, solo ponga una de ellas allí), necesita mirar recetas incompletas (¡alguien arrancó una página de este libro!) y sacarlas, usted necesitará traducir recetas de otros idiomas al idioma que desean sus lectores (no creía que solo las personas de habla inglesa cocinaban pollo, ¿verdad?)

Para resolver todos esos detalles, tendrá hojas de trabajo intermitentes, desea escribir meta libros (donde enumera todos los libros que tienen recetas, números de página sobre dónde están esas recetas en el libro; ya sabes, un libro sobre otros libros) . Estos libros también están en su Data Warehouse, pero a sus lectores no les importan, quieren las “TODAS las recetas para todas las cosas de todo el mundo conocido”, o “todas las posibles consecuencias de todas las acciones tomadas por todas las personas en todo hora”. Estos libros finalizados son lo que llamamos Data Mart.

Sus lectores hojearán este libro de recetas multidimensional, pueden buscar por carne, o región, o religión, o tipos de curso, o nivel de picante, o lo que sea, porque lo organizamos de todas las formas posibles. Si quieren encontrar el “plato principal para el pollo que tiene picante de 3 o menos, independientemente de las regiones del mundo”, pueden hacer una lista, hacer un recuento de cuántos o resumir cuánto pollo y especias se necesitan. cocinar cada una de esas recetas.

Esto es lo que un Data Mart puede hacer por usted. Lo llamamos rebanar y cortar en cubitos, que no está relacionado con las recetas o la cocina …

Data Cube es muy similar a un Data Mart. Si Data Mart es una colección de estos libros finalizados, un Data Cube es un libro.

Otros argumentarán que es diferente a una tabla de hechos (los libros finalizados en nuestro ejemplo) en el Data Mart, pero no pueden proporcionar ningún argumento sólido sobre los beneficios de diferenciarlos. Básicamente solo discuten por el argumento y tratan de sonar bien.

Data Cube puede ser denso (en realidad, una de las únicas diferencias entre Data Cube y Data Mart). Imagine una hoja de Excel, al cruzar, tiene género como etiquetado como masculino, femenino, desconocido. Bajando tienes rango de salario, 0 – 50k, 50k – 100k, 100k +. Ahora tiene una matriz 3 × 3 con celdas vacías. En esas celdas vas a poner los nombres de las personas que pertenecen allí. Obtienes Bob en Hombre, 50k – 100k, Josy en Mujer, 100k +. El resto está vacío.

En un cubo, puede tener esos espacios vacíos como marcadores de posición; en un centro comercial, ni siquiera creas esos marcadores de posición. En un cubo, tiene 9 filas (3 × 3), con muchas de ellas vacías aparte de sus valores de dimensión. En un centro comercial, tienes dos registros, siendo Bob y Josy.

La gente argumenta que el que tiene un marcador de posición es más rápido de leer, ignore a esas personas.

Data Lake es cuando su Data Warehouse se inunda de manera que todo lo que ve es agua. Ok, es broma.

¿Recuerdas que dije que Data Mart son los libros finalizados mientras que Data Warehouse tiene algunos meta libros, libros temporales que escribiste solo para organizar tus pensamientos? Esos libros, junto con las copias originales de esos libros de viajes, libros de instrucciones, libros de recetas en idiomas extranjeros es su Data Lake.

Data Lake es un volcado de todas esas copias originales (tenga en cuenta que no son originales, sino copias exactas), además de meta libros, etc. No le ayuda a organizarse más. Puede que a los lectores no les guste la forma en que organizas tu libro de recetas finalizado, o tal vez él / ella pueda hacerlo más rápido para que no quieran esperarte, o tal vez no confíen en que tu libro sea preciso (tu traducción es mal, cometes errores de ortografía, confundes pollo con carne de res !!! Las gallinas tienen alas … ¡hola!?!), por la razón que sea, no quieren que TÚ hagas el trabajo duro, quieren hacerlo sí mismos.

Tendrán que crear también sus propios meta libros, sus libros intermitentes; y tienen que marcar en los originales para hacer notas y cosas (ya sabes, ¡MATERIAL!), así que haces COPIAS originales (¡ajá! ¡Es por eso que te digo que notes las COPIAS antes, ¿ves? ¡¡Tengo un punto !! !!). Marcan las copias tanto como les gusta, crean tantos meta libros y libros temporales como deseen. Simplemente les das un lugar para hacer eso, ese lugar se llama Data Lake.

Data Swamp es un Data Lake completamente seco y moribundo. No estoy bromeando. Imagina lo que sucede cuando todos tus lectores hacen el trabajo ellos mismos, pero quieren ver el mismo libro de recetas finalizado, letra por letra. Cada uno tiene que hacer su propio trabajo en Data Lake, gastando el tiempo y los recursos una y otra vez solo para obtener el mismo resultado. ¿Por qué? ¿Por qué no lo haces TU una vez y les das copias de tu libro? Bueno, eso tendría más sentido, por lo que todos regresan a Data Mart donde TÚ escribes el libro una vez y esta vez, te esperan porque tienen malas traducciones, también son lentas, pero han estado en el lago y fueron a través de ese dolor para que sepan tener paciencia.

Como nadie está utilizando el Lago de datos, nadie está gastando dinero para mantenerlo limpio; lentamente se pudre, se seca y tiene cosas raras que crecen en él. La próxima vez que lo mires, se convierte en un pantano.

En realidad, Data Lake tiene sus propósitos. Si lo está utilizando en los lugares correctos en el momento adecuado, sigue siendo un lago prístino.

Bienvenido al mundo de los datos… .stuff.

Base de datos = Recopilación estructurada de datos. Puede ser cualquier cosa, desde una lista de nombres en un archivo de texto, hasta una base de datos relacional. Comúnmente se confunde con el sistema de administración de la base de datos (por ejemplo: MySQL es un sistema de administración de bases de datos relacionales, pero si almacena datos en él, esos datos son una base de datos. La gente dice incorrectamente ‘Uso MySQL como mi base de datos’)

Almacén de datos = recopilación estructurada [idealmente] de todos los datos de la organización

Data mart = subconjunto del almacén de datos estructurado para permitir un fácil acceso del usuario. Puede ser un subconjunto de los datos accesibles, organizados por departamento / dominio, como datos relevantes de ventas o datos logísticos. A menudo contiene agregaciones [parciales].

Data lake = Existe cierto debate, pero generalmente se acepta como una recopilación no estructurada de todos los datos de la empresa. Similar a un almacén de datos, pero debido a la parte no estructurada, acepta más datos / integraciones nuevas.

Cubo de datos = estructura de datos con 3 o más dimensiones que generalmente se usan para generar informes En pocas palabras, puede ser una lista de user_id, order_id, item_id en forma de tabla. Es solo un nombre elegante para referirse a una porción de datos en la que puede profundizar, o cortar y cortar.

Algunas definiciones extraídas del Diccionario de datos y análisis :

Base de datos

Si bien se podría argumentar que este término podría aplicarse a sistemas analógicos, como tarjetas de índice en una biblioteca física, generalmente se utiliza para referir software que permite el almacenamiento y la recuperación de números y texto en formato digital. Las bases de datos difieren de los archivos planos en que a menudo contienen estructuras (por ejemplo, tablas, vistas e índices) destinadas a facilitar estas tareas y vienen con herramientas que permiten la gestión y manipulación eficiente de los datos que contienen.

Algunos ejemplos de bases de datos incluyen:

  1. jerárquico
  2. relacional
  3. grafico
  4. de columna
  5. en memoria
  6. repartido
  7. NoSQL.

Algunos de estos atributos se superponen entre sí, es decir, una base de datos podría ser tanto columnar como en memoria, otra podría ser distribuida y NoSQL.

Data Mart

Parte de un Data Warehouse dedicado a un área temática específica, por ejemplo, Finanzas, Ventas, etc.

Almacén de datos

Una base de datos que contiene datos de muchas fuentes dispares en un formato común que permite la comparación de manzanas y naranjas. Un almacén normal es un gran edificio en el que se pueden almacenar muchas cosas, pero que tiene un sistema de indexación que les permite ubicarse y recuperarse fácilmente. Un almacén de datos es esencialmente el mismo concepto. Los Good Data Warehouses tienen un significado comercial “integrado” en ellos. Los Almacenes de datos generalmente siguen un Paradigma multidimensional (relacionado con OLAP) donde los datos se guardan en Tablas de hechos (tablas que cubren números como ingresos o costos) y Dimensiones (elementos por los que queremos ver los hechos, como región, oficina o semana) .

Consulte también: Uso de múltiples herramientas de inteligencia empresarial en una implementación: Parte I y Parte II

Lago de datos

Un repositorio de Big Data en el que las copias de los sistemas de origen se replican periódicamente. El Data Lake es uno de los recursos que los científicos de datos aprovechan para crear información.

Cubo (enfoque multidimensional)

Una base de datos multidimensional es aquella que está estructurada de una manera que soporta más directamente el concepto relacionado de procesamiento analítico en línea (u OLAP). El enfoque multidimensional concentra los datos transaccionales (o, a veces, estos agregados en saldos) en una sola tabla llamada tabla de hechos, que contiene todas las medidas pertinentes para un área de análisis junto con enlaces a dimensiones relevantes (ver a continuación las definiciones de estos términos). La creación de una base de datos multidimensional a partir de datos de origen que se estructura de manera diferente es el campo de las herramientas de extracción, transformación y carga. Una vez que la información construida puede recuperarse muy rápidamente y los usuarios pueden manipular y filtrar los datos de manera flexible de una manera que tenga sentido para ellos. A modo de analogía muy directa, puede llevar bastante tiempo construir todos los datos que entran en una tabla dinámica de Excel, pero luego la tabla dinámica se puede utilizar de varias maneras diferentes.

A continuación se muestra un conjunto seleccionado de definiciones relacionadas con el Enfoque multidimensional:

Dimensión

Elementos por los que desea analizar datos. Así que país, sucursal, producto, etc. Las dimensiones a veces se organizan en jerarquías de modo que Región, País, Región, Ciudad o Año, Mes, Día.

Medida

Cantidades numéricas que desea analizar. Por ejemplo, cuenta como número de pedidos de ventas o número de clientes; valores monetarios como ingresos por ventas o costos; o porcentajes como crecimiento o margen de beneficio.

Tabla de hechos

Para una estructura multidimensional particular, todas las medidas relevantes se reunirán en una tabla central llamada tabla de hechos. La misma tabla de hechos le permitirá buscar cualquier medida o combinación de medidas o le permitirá agregarlas.

Esquema de estrella

Una disposición en la que una tabla de hechos central está rodeada por una serie de tablas de dimensiones que permiten que las medidas en la tabla de hechos sean “cortadas y cortadas en cubitos” por las dimensiones. Por ejemplo, nuevos clientes y valor de los pedidos que han realizado por país y tipo de producto.

Cubo

Las bases de datos multidimensionales a menudo se denominan cubos, particularmente cuando se guardan utilizando tecnología patentada (como Microsoft SQL Server Analysis Services).

Hablaré en detalle sobre las diferencias en el funcionamiento de un lago de datos y el almacén de datos. Adrian ha explicado amablemente las diferencias entre los demás en la respuesta anterior.

Un amplio entendimiento es que un almacén de datos es una plataforma de procesamiento y almacenamiento de datos completamente esquematizada, mientras que un lago de datos es más fluido en su funcionamiento, como su nombre indica. A continuación se detallan los pocos pasos que se realizan de manera diferente en un almacén de datos en comparación con un lago de datos.

Desacoplamiento de metadatos y datos: en un almacén de datos, primero define los metadatos y luego le agrega datos, pero primero en el lago de datos, ingiere datos y luego define los metadatos a su alrededor. De esta manera, puede asignar múltiples etiquetas de metadatos al mismo conjunto de datos.

Escalabilidad: un almacén de datos puede escalar hasta unos pocos bytes de tierra, mientras que en un lago de datos puede almacenar hasta unos pocos petabytes de datos.

Para leer más sobre 1) Desacoplamiento del almacenamiento y procesamiento y 2) Rendimiento de un lago de datos, haga clic aquí.

Me gustaría contribuir con lo que aprendí al comparar lagos de datos con almacenes de datos. Lei Zhang respondió una pregunta relacionada para mí y ayudó mucho con las aplicaciones de la vida real de los lagos de datos. También escuché de algunos vendedores de inteligencia empresarial (Tableau, Qlik y Logi Analytics) y analicé la interpretación de Gartner de esta tendencia. Uno de los vendedores me llevó al artículo de Michael Stonebraker sobre la conservación de datos y las causas de los “pantanos de datos”.

No hay ningún contenido que convierta todo esto en visual, así que me uní a un ilustrador y ¡hice el primero! Aquí está: ¿Qué es Damming Data Lakes?

Al crear esto, descubrí que muchos proveedores no están llamando a lo que están haciendo lagos de datos. Muchos llaman a esto una variación de un “esquema en el almacén de datos leídos”, o un “almacén de datos de enlace tardío”. Esta infografía tiene el propósito de introducir los lagos de datos como un concepto, por lo que no es tan profundo como podría haber ido y yo piense que los vendedores individuales podrían incluso resolver los inconvenientes que enumeré aquí con los recursos y casos de uso correctos.

Me gusta mucho la respuesta de Julia Scavicchio.

Hay algunas cosas que son importantes para mí que me gustaría ampliar.

El nuevo término Data Lakes es muy similar al tradicional Área de almacenamiento persistente (PSA) del mundo del almacén de datos (DWH) con algunas diferencias únicas.

Data Lakes utiliza tecnología que aprovecha los avances recientes que hacen que sea muy rentable almacenar grandes cantidades de datos con alta disponibilidad.

Esto permite el almacenamiento o los datos independientemente de si se entiende o no. Se está poniendo de moda identificar erróneamente datos que no se entienden como no estructurados. Muy pocas empresas tienen datos no estructurados. Casi no existe. Muchas empresas tienen datos que no entienden. El esquema de lectura es un patrón de diseño de acceso. No es un atributo de datos.

En el PSA tradicional solo persistíamos los datos que formaban parte del ciclo de vida de DWH porque en ese momento nos abrumaba mucho más fácilmente una gran cantidad de datos. Eso ya no necesita ser una preocupación. Ahora podemos almacenar múltiples versiones de los mismos datos, así como los mismos datos pero con múltiples perspectivas. Esto se desalentó en un mundo tradicional de DWH donde solo queríamos la perspectiva empresarial.

Lo que muchas empresas aún no se han dado cuenta es que simplemente almacenar datos sin ningún tipo de gobierno puede contaminar un lago de datos realmente rápido y dificultar su uso. Desearía que la palabra lago de datos también implicara un servicio simple y liviano que asegurara que solo hubiera una forma de poner datos en el lago de datos, y cada vez que los datos se pusieron en el lago de datos se recopiló cierta información. Algunos ejemplos pueden ser:

  • Qué es
  • ¿Tiene un esquema conocido?
  • ¿Tiene un formato conocido?
  • MD5 hash
  • Cuándo fue creado
  • Talla
  • Quien lo puso ahi
    • De quien es
    • De dónde vino
    • ¿Cuál es la fecha de vigencia de los datos?
  • ¿Quién puede acceder a estos datos?
    • Lista blanca / negra del grupo de seguridad
    • Calificación de seguridad

    Este tipo de datos debería estar disponible en un sistema de catálogo y ser parte de la gobernanza del lago de datos sin afectar el rendimiento.

    Aunque personas como Inmon nunca lo quisieron de esta manera, la mayoría de los almacenes de datos que se han construido fueron de solo lectura. Esta siempre ha sido mi mayor decepción con la mayoría de los sistemas que implementé. Quería la fábrica de información de la corporación donde un DWH derivaba datos y los retroalimentaba a sistemas que luego enviaban datos al DWH. Espero que el lago de datos finalmente pueda potenciar este tipo de bucle dinámico de retroalimentación.

    Mucha gente probablemente tratará la interpretación de Julia como datos que solo fluyen del Data Lake. Creo que esto continuará las oportunidades perdidas que vimos con el mundo DWH.

    Ya no me gustan las palabras asociadas con ETL o EDI. En cambio, estoy cambiando mi léxico para centrarme en el movimiento y enriquecimiento de datos. Esto puede parecer sutil o tonto para algunos, pero creo que hay una distinción importante que creo que diferencia el nuevo mundo.

    Cuando movemos datos de diferentes sistemas, estamos rastreando su ciclo de vida. Los cambios que hacemos en esos datos son parte de la procedencia de los datos. Si queremos persistir en cómo esos cambios enriquecen los datos, almacenaremos ese conjunto de datos en el lago de datos. Los estados anteriores de los datos permanecen sin cambios. No se transformó a través del movimiento. El nuevo estado puede no ser parte de la perspectiva empresarial y eso está bien. Debido a que catalogamos las diferentes perspectivas, esto no nos causa ansiedad. Quizás más tarde reconciliaremos estas perspectivas y la perspectiva empresarial también evolucionará. Quizás no, y el microcosmos del valor comercial de los datos enriquecidos solo debe ser realizado por ciertos equipos. Ambos estan bien.

    Esto también implica sistemas mucho más poco flexibles que tienen métodos de entrega de CI / CD que nunca disponibles en el mundo tradicional de DWH.

    Por ejemplo, debería ser trivial que un lago de datos construido sobre algo como AWS s3 soporte dinámicamente un clúster Spark EMR para un proyecto de ciencia de datos de dos semanas que lee una cantidad masiva de datos para derivar una pequeña cantidad de datos que se vuelve a escribir en S3 para que lo use un equipo de negocios por solo un cuarto.

    El aprovisionamiento de este hardware y datos puede automatizarse casi de manera autoservicio con solo un pequeño esfuerzo. Deshacerse del hardware cuando se completa es trivial. Este tipo de identificación de autoservicio no era posible en un DWH tradicional.

    • Data Lake vs Data Warehouse

    • Base de datos vs almacén de datos

    También es importante tener en cuenta que los almacenes de datos pueden obtenerse de cero a muchas bases de datos.

    Data Mart Vs Data Warehouse

    Ref Data Warehouse vs Data Mart

    More Interesting

    ¿Cómo es el alcance del big data (analítico) en todo el mundo y también en India en los próximos años?

    ¿Qué pasó con el proyecto 'Estadístico automático', respaldado por Google, etc.?

    ¿Es la astrología la implementación de la ciencia de datos antiguos?

    ¿Cómo comenzar con Apache Spark y dónde buscar un buen entrenamiento?

    ¿Cuáles son los documentos recientes de ieee sobre minería de datos?

    ¿De qué maneras es importante la investigación matemática fundamental en espacios de alta dimensión (por ejemplo, geometría / topología) importante para la ciencia de datos y el aprendizaje automático?

    ¿Cuáles son los principales factores del big data?

    ¿Cuáles son los métodos de selección de funciones disponibles en los paquetes de Python?

    ¿Qué tareas de minería de datos (big data) necesitan precisión de predicción más allá de 0.999999?

    ¿Qué tipo de proyectos paralelos de ciencia de datos se sugieren para un estudiante de pregrado?

    ¿Qué tan útil es Matlab, para Kaggle, en comparación con R y Python?

    ¿Cuáles son algunas revisiones en el curso de ciencias de datos en el aula por EduPristine en Bangalore?

    ¿Vale la pena aprender habilidades de análisis de datos después de tener 5 años de experiencia en la industria de TI?

    ¿Cuál es la mejor manera de lidiar con los datos faltantes cuando se utiliza la regresión polinómica fraccional?

    Si me gradúo en 1-1 1/2 años con un programa de doctorado en economía, ¿cómo me preparo para un trabajo de ciencia de datos?