Arquitectura del almacén de datos: tradicional y en la nube

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

Source: https://habr.com/ru/post/441538/


All Articles