Hola Habr! Se ha escrito mucho sobre el tema de la arquitectura del almacén de datos, pero aún no se ha reunido tan sucintamente como en un artículo que me topé accidentalmente.
Te invito a que te familiarices con este artículo en mi traducción. ¡Comentarios y adiciones son bienvenidos!
(Fuente de la imagen)Introduccion
Entonces, la arquitectura de los almacenes de datos está cambiando. En este artículo, compararemos los almacenes de datos empresariales tradicionales y las soluciones en la nube con un costo inicial más bajo, escalabilidad mejorada y rendimiento.
Un almacén de datos es un sistema en el que se recopilan datos de varias fuentes dentro de una empresa y estos datos se utilizan para respaldar las decisiones de gestión.
Las empresas se están mudando cada vez más a almacenes de datos basados en la nube en lugar de los sistemas locales tradicionales. Los almacenamientos de datos en la nube tienen varias diferencias con respecto a los almacenamientos tradicionales:
- No es necesario comprar equipo físico;
- Los almacenes de datos en la nube son más rápidos y económicos de configurar y escalar;
- Los almacenes de datos en la nube generalmente pueden realizar consultas analíticas complejas mucho más rápido porque utilizan un procesamiento paralelo masivo.
Arquitectura tradicional del almacén de datos
Los siguientes conceptos destacan algunas de las ideas y principios de diseño establecidos utilizados para crear almacenes de datos tradicionales.
Arquitectura de tres niveles
Muy a menudo, la arquitectura tradicional del almacén de datos tiene una estructura de tres niveles que consta de los siguientes niveles:
- Nivel inferior : este nivel contiene el servidor de base de datos utilizado para recuperar datos de muchas fuentes diferentes, por ejemplo, de bases de datos transaccionales utilizadas para aplicaciones front-end.
- Nivel medio : el nivel medio contiene un servidor OLAP que transforma los datos en una estructura que es más adecuada para análisis y consultas complejas. Un servidor OLAP puede funcionar de dos maneras: ya sea como un sistema avanzado de administración de bases de datos relacionales que asigna operaciones de datos multidimensionales a operaciones OLAP relacionales estándar, o utilizando un modelo OLAP multidimensional que implementa directamente datos y operaciones multidimensionales.
- Nivel superior : el nivel superior es el nivel del cliente. Este nivel contiene las herramientas utilizadas para el análisis de datos de alto nivel, informes y análisis de datos.
Kimball vs. Inmon
Dos pioneros de los almacenes de datos: Bill Inmon y Ralph Kimball, ofrecen diferentes enfoques de diseño.
El enfoque de
Ralph Kimball se basa en la importancia de los data marts, que son almacenes de datos que pertenecen a negocios específicos. Un almacén de datos es simplemente una
combinación de varios mercados de datos que facilitan la presentación de informes y el análisis. El proyecto de almacén de datos basado en Kimball utiliza un enfoque ascendente.
El enfoque de Bill Inmon se basa en el hecho de que el almacén de datos es un almacenamiento centralizado de todos los datos corporativos. Con este enfoque, la organización primero crea un
modelo de almacén de datos
normalizado . Luego, se crean marts de datos dimensionales basados en el modelo de almacén. Esto se conoce como un enfoque de almacenamiento de datos de arriba hacia abajo.
Modelos de almacén de datos
En la arquitectura tradicional, existen tres modelos generales de depósitos de datos: almacenamiento virtual, presentación de datos y depósito de datos corporativos:
- Un almacén de datos virtual es un conjunto de bases de datos separadas que se pueden compartir para que el usuario pueda acceder efectivamente a todos los datos como si estuvieran almacenados en un almacén de datos;
- Se utiliza un modelo de presentación de datos para informar y analizar líneas comerciales específicas. En este modelo de almacenamiento, los datos agregados de una serie de sistemas de origen relacionados con un área comercial específica, como ventas o finanzas;
- El modelo de almacén de datos corporativos implica almacenar datos agregados que abarcan toda la organización. Este modelo considera el almacén de datos como el corazón de un sistema de información empresarial con datos integrados de todas las unidades de negocios.
Star vs. Copo de nieve
Los esquemas de estrellas y copos de nieve son dos formas de estructurar su almacén de datos.
Un esquema en
estrella tiene un almacén de datos centralizado, que se almacena en una tabla de hechos. El gráfico divide la tabla de hechos en una serie de tablas de dimensiones desnormalizadas. La tabla de hechos contiene los datos agregados que se utilizarán para los informes, y la tabla de dimensiones describe los datos almacenados.
Los proyectos desnormalizados son menos complejos porque los datos están agrupados. La tabla de hechos usa solo un enlace para adjuntar a cada tabla de dimensiones. El diseño en forma de estrella más simple simplifica enormemente la escritura de consultas complejas.
Un patrón de
copo de nieve es diferente porque usa datos normalizados. La normalización significa una organización de datos eficiente para que todas las dependencias de datos estén definidas y cada tabla contenga un mínimo de redundancia. Por lo tanto, las tablas de medición individuales se bifurcan en tablas de medición separadas.
El esquema de
copo de nieve usa menos espacio en disco y mantiene mejor la integridad de los datos. La principal desventaja es la complejidad de las consultas requeridas para acceder a los datos: cada consulta debe pasar por varias uniones de tabla para obtener los datos correspondientes.
ETL vs. ELT
ETL y ELT son dos formas diferentes de cargar datos en el almacenamiento.
Los ETL (Extraer, Transformar, Cargar) primero recuperan datos de un grupo de fuentes de datos. Los datos se almacenan en una base de datos provisional provisional. Luego, se realizan operaciones de conversión para estructurar y transformar los datos en una forma adecuada para el sistema de almacenamiento de datos de destino. Luego, los datos estructurados se cargan en el almacenamiento y están listos para el análisis.
En el caso de
ELT (Extraer, Cargar, Transformar), los datos se cargan inmediatamente después de la extracción de los grupos de datos de origen. No existe una base de datos intermedia, lo que significa que los datos se cargan inmediatamente en un único repositorio centralizado.
Los datos se convierten en un sistema de depósito de datos para su uso con herramientas de análisis e inteligencia empresarial.
Madurez organizacional
La estructura del almacén de datos de la organización también depende de su situación y necesidades actuales.
La estructura básica permite a los usuarios finales de almacenamiento acceder directamente a los datos de resumen de los sistemas de origen, crear informes y analizar estos datos. Esta estructura es útil para casos donde las fuentes de datos provienen de los mismos tipos de sistemas de bases de datos.
El almacenamiento con un área intermedia es el siguiente paso lógico en una organización con orígenes de datos heterogéneos con muchos tipos y formatos de datos diferentes. El área de preparación convierte los datos en un formato estructurado genérico que es más fácil de solicitar utilizando herramientas de análisis e informes.
Una variación de la estructura intermedia es la adición de marts de datos al almacén de datos. Los mercados de datos almacenan datos resumidos en un campo específico de actividad, lo que hace que estos datos sean fácilmente accesibles para formas específicas de análisis.
Por ejemplo, agregar datos marts puede permitir que un analista financiero realice más fácilmente consultas detalladas sobre datos de ventas y prediga el comportamiento del cliente. Los marts de datos facilitan el análisis al adaptar los datos específicamente para satisfacer las necesidades del usuario final.
Nuevas arquitecturas de Data Warehouse
En los últimos años, los almacenes de datos se están moviendo a la nube. Los nuevos almacenes de datos en la nube no se adhieren a la arquitectura tradicional y cada uno de ellos ofrece su propia arquitectura única.
Esta sección describe brevemente las arquitecturas utilizadas por los dos almacenamientos en la nube más populares: Amazon Redshift y Google BigQuery.
Desplazamiento al rojo amazónico
Amazon Redshift es una vista basada en la nube de un almacén de datos tradicional.
Redshift requiere que los recursos informáticos se preparen y configuren como clústeres que contienen una colección de uno o más nodos. Cada nodo tiene su propio procesador, memoria y RAM. Leader Node compila las solicitudes y las pasa a los nodos de proceso que ejecutan las solicitudes.
En cada nodo, los datos se almacenan en bloques llamados
cortes . Redshift utiliza el almacenamiento de columnas, es decir, cada bloque de datos contiene valores de una columna en varias filas, y no de una fila con valores de varias columnas.
Redshift utiliza la arquitectura MPP (procesamiento masivo en paralelo), que divide grandes conjuntos de datos en fragmentos que se asignan a sectores en cada nodo. Las solicitudes son más rápidas porque los nodos de proceso procesan las solicitudes en cada segmento al mismo tiempo. El nodo Nodo líder combina los resultados y los devuelve a la aplicación cliente.
Las aplicaciones de cliente, como BI y herramientas analíticas, pueden conectarse directamente a Redshift utilizando los controladores de código abierto PostgreSQL JDBC y ODBC. De esta forma, los analistas pueden realizar sus tareas directamente en los datos de Redshift.
Redshift solo puede cargar datos estructurados. Puede cargar datos en Redshift utilizando sistemas preintegrados, incluidos Amazon S3 y DynamoDB, transfiriendo datos desde cualquier host local con una conexión SSH, o integrando otras fuentes de datos utilizando la API de Redshift.
Google bigquery
La arquitectura de BigQuery no requiere un servidor, lo que significa que Google controla dinámicamente la asignación de recursos informáticos. Por lo tanto, todas las decisiones de gestión de recursos están ocultas para el usuario.
BigQuery permite a los clientes descargar datos de Google Cloud Storage y otras fuentes de datos legibles. Una alternativa es la transmisión de datos, que permite a los desarrolladores agregar datos al almacén de datos en tiempo real, línea por línea, cuando estén disponibles.
BigQuery utiliza un motor de consulta llamado Dremel, que puede escanear miles de millones de filas de datos en solo unos segundos. Dremel utiliza consultas masivamente paralelas para escanear datos en el sistema de gestión de archivos base Colossus. Colossus distribuye archivos en trozos de 64 megabytes entre una variedad de recursos informáticos llamados nodos, que se agrupan en grupos.
Dremel utiliza una estructura de datos de columna similar a Redshift. La arquitectura de árbol envía solicitudes a miles de máquinas en segundos.
Se utilizan comandos SQL simples para realizar consultas de datos.
Panoplia
Panoply ofrece una gestión integral de datos como servicio. Su arquitectura única de optimización automática utiliza el aprendizaje automático y el procesamiento del lenguaje natural (PNL) para modelar y agilizar la transferencia de datos desde el origen al análisis, reduciendo el tiempo de datos a valores lo más cercano posible a cero.
Panoply Intelligent Data Infrastructure incluye las siguientes características:
- Análisis de consultas y datos: determinando la mejor configuración para cada caso de uso, ajustándola con el tiempo y creando índices, ordenando claves, claves de disco, tipos de datos, evacuación y partición.
- Identifica consultas que no siguen las mejores prácticas, por ejemplo, aquellas que incluyen bucles anidados o conversiones implícitas, y las reescribe en una consulta equivalente que requiere una fracción del tiempo de ejecución o de los recursos.
- Optimice la configuración del servidor a lo largo del tiempo basándose en patrones de consulta y aprendiendo qué configuración del servidor funciona mejor. La plataforma cambia sin problemas los tipos de servidor y mide el rendimiento general.
Más allá del almacenamiento en la nube
El almacenamiento de datos basado en la nube es una gran mejora con respecto a los enfoques de arquitectura tradicional. Sin embargo, los usuarios aún encuentran una serie de problemas al configurarlos:
- Cargar datos en almacenes de datos basados en la nube no es trivial, y las canalizaciones de datos a gran escala requieren configuración, pruebas y soporte para el proceso ETL. Esta parte del proceso generalmente es realizada por herramientas de terceros;
- Las actualizaciones, inserciones y eliminaciones pueden ser complejas y deben realizarse con cuidado para evitar la degradación del rendimiento de la consulta;
- Los datos semiestructurados son difíciles de manejar: deben normalizarse en un formato de base de datos relacional, que requiere la automatización de grandes flujos de datos;
- Las estructuras anidadas generalmente no son compatibles con los almacenes de datos en la nube. Debe convertir las tablas anidadas a formatos que comprenda el almacén de datos;
- Optimización de clúster . Hay varias opciones para configurar un clúster Redshift para ejecutar sus cargas de trabajo. Diferentes cargas de trabajo, conjuntos de datos o incluso diferentes tipos de consultas pueden requerir diferentes configuraciones. Para lograr un rendimiento óptimo, es necesario revisar constantemente y, si es necesario, configurar adicionalmente la configuración;
- Optimización de consultas : las consultas de los usuarios pueden no seguir las mejores prácticas y, por lo tanto, tardarán mucho más en completarse. Puede trabajar con usuarios o aplicaciones cliente automatizadas para optimizar las consultas para que el almacén de datos pueda funcionar como se espera
- Copia de seguridad y recuperación : aunque los proveedores de almacenamiento de datos ofrecen muchas opciones para hacer una copia de seguridad de sus datos, su configuración no es trivial y requieren supervisión y atención.
Enlace al texto original: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud