Preguntas y respuestas con Barry Devlin sobre canalizaciones de datos automatizadas

Las canalizaciones de datos automatizadas son una pieza crucial del rompecabezas del almacenamiento de datos. Permiten a las empresas modernas mantener datos precisos y de alta calidad que impulsan sus iniciativas de BI y análisis. Recientemente lanzamos Astera DW Builder, un robusto constructor de almacenes de datos que acelera radicalmente la construcción, la orquestación y la gestión de las canalizaciones de datos para permitir decisiones más rápidas basadas en datos.

Astera Las canalizaciones de datos autorreguladas de DW Builder le permiten llenar sin problemas su almacén de datos con datos entre empresas. Con las funcionalidades ETL y ELT automatizadas del producto, puede cubrir el viaje de los datos desde la fuente hasta la información con un esfuerzo manual mínimo.

Recientemente, tuvimos la oportunidad de conversar con Barry Devlin, una de las principales autoridades en todo lo relacionado con el almacenamiento de datos, desde las mejores prácticas de inteligencia empresarial hasta los macrodatos y más. Estas son algunas de las ideas que Barry proporcionó sobre las consideraciones clave para la canalización de datos en la EDW moderna.

Los almacenes de datos modernos procesan grandes volúmenes de datos. Cuando se trata de crear canalizaciones de datos que puedan entregar activamente estas grandes cantidades de datos, ¿existen mejores prácticas que recomendaría?

Bueno, antes de hablar sobre las mejores prácticas, me gustaría hacer una mejor práctica por adelantado que es definir y desarrollar algunas de las frases que usaremos aquí. [Eso es] porque hay muchos significados diferentes de palabras y frases clave en el mercado en este momento.

Entonces, primero, canalizaciones de datos, muchas personas usan esta frase para referirse a un camino integrado completo desde los datos de origen hasta las herramientas utilizadas por el empresario. Veo que su uso del término se centra menos en el camino de la sopa completa a las nueces, sino más bien en la posibilidad de una canalización más corta entre, digamos, diferentes componentes como una instancia de SAP y un flujo de clics en un sitio web a un almacén de datos empresarial. Creo que este es un enfoque mejor y el que tiene más probabilidades de éxito.  

En segundo lugar, está la cuestión de qué queremos decir cuando decimos almacén de datos. Porque hay muchos enfoques contrastantes. Entonces, en la mayoría de los casos, cuando digo almacén de datos, me refiero a una estructura de dos capas que consta de un almacén de datos empresarial, un EDW y un tercer formulario normal, o más probablemente en la actualidad, un modelo de bóveda de datos, que alimenta múltiples mercados de datos, muchos de los cuales pueden ser de naturaleza dimensional. Y esto no excluye otras estructuras, la mayoría de las cuales son una simplificación de este enfoque de dos capas.

Finalmente, usaré la frase "preparación de datos o información" para cubrir todos los tipos de procesamiento como ETL, ELT, transmisión, automatización de almacenamiento de datos e incluso virtualización de datos porque todos estos últimos términos son instancias específicas de preparación de datos e información o enfoques técnicos al mismo.

Entonces, habiendo dicho eso desde el principio, permítanme hablar sobre las mejores prácticas sobre las que me han preguntado y me limitaré a tres, pero hay muchas más.

Primero, diría herramientas y automatización integrales y fáciles de usar, y eso es bastante obvio. La preparación de datos [preparación] es la parte más cara de un almacén de datos. Por lo tanto, la creación de equipos de programadores para construir múltiples soluciones a medida inconsistentes y que no se pueden mantener es, o debería ser, cosa del pasado. Ese es el punto uno.

La mejor práctica dos es: acertar en la fase de diseño involucrando a la empresa de manera cercana y continua en el proceso. Esto significa iterativo, enfoques ágiles de desarrollo [es decir] menos en la entrega de aplicaciones comerciales, pero más en la entrega de partes útiles del alcance de la información del almacén de datos.

Y en tercer lugar, diría que gestión de cambios y mantenimiento. Estas son características clave que a menudo se pasan por alto. Por lo tanto, concéntrese en garantizar que las actualizaciones y el mantenimiento se consideren temprano y establezca un proceso que esté estrechamente relacionado con el diseño y la construcción iniciales.

Entonces, volviendo a mi primer punto, las herramientas y la automatización juegan un papel central para que esto suceda. Entonces, hay tres mejores prácticas que creo que son realmente importantes en esta área.

Desarrolle e implemente almacenes de datos de gran volumen

¡Pruébalo ahora!

ETL ha sido sinónimo de almacenamiento de datos desde el inicio de la tecnología. ¿Cómo ha evolucionado este proceso en la era de los llamados big data que tenemos ahora? ¿Qué tipo de innovaciones está viendo que pueden reducir el costo y la complejidad del ETL tradicional?

Creo que siempre tenemos que aprender de la historia. La preparación de datos, en mi opinión, ha evolucionado a trompicones y comienza con frecuentes pasos hacia atrás. Por ejemplo, los lagos de datos iniciales recientes y el almacén de datos basado en la nube a menudo se completaban a través de scripts y soluciones programáticas similares en Hadoop. Eso ha sido una gran decepción para mí.

Es bueno ver ahora un nuevo enfoque en las herramientas automatizadas. La tendencia a largo plazo ha sido, en general, desde soluciones hechas a mano y a medida hasta el uso de ETL y, más recientemente, herramientas ELT. Esto se ha complementado con un cambio de la entrega de datos por lotes a una variedad de enfoques de entrega incremental a medida que aumentan los volúmenes de datos y la empresa demanda información cada vez más oportuna.

En los viejos tiempos, ETL era todo de sistemas operativos a menudo anticuados en diseño con muchos códigos arcanos. Comprender las complejidades, así como las reglas comerciales profundas que estaban obsoletas pero que aún estaban en el sistema, era un requisito clave para un programador ETL.

Y luego estaba la demanda absoluta de limitar el impacto en los sistemas operativos, [en términos de] tanto su diseño como su rendimiento. Los ingenieros de ETL tenían que ser expertos en las misteriosas estructuras y el contenido de estos sistemas fuente heredados.

La buena noticia ahora es que los sistemas operativos a menudo están mejor diseñados, son más modernos y, a veces, están basados ​​en la nube. Por lo tanto, hay menos necesidad de lidiar con sistemas arcanos y más enfoque en el diseño innovador y los sistemas de destino. Por supuesto, reduce los costos y la complejidad de la preparación de datos.

Sin embargo, las fuentes de datos externas como Internet de las cosas (IoT) generan nuevas necesidades tanto en términos de puntualidad de los datos como de los tipos de análisis involucrados. Por lo tanto, desde el punto de vista técnico, también debemos considerar los enfoques de transmisión frente a carga por lotes o replicación.

Las fuentes menos arcaicas también permiten un cambio de transformaciones personalizadas y codificadas a mano a un enfoque más basado en modelos o metadatos para la preparación de la información, que es realmente el núcleo de la automatización del almacén de datos.

Mencionaste un par de veces que ELT es un enfoque más nuevo que se ha afianzado. ¿Cómo ve eso en relación con ETL? ¿Son estos enfoques complementarios o hay un tipo de cosas que están sucediendo aquí?

Creo que hay muchas preguntas en torno a eso, pero, primero, me gustaría decir algo que creo que ETL fue una elección de terminología realmente desafortunada en los primeros días. Extraer, transformar y cargar, porque centra la atención en la secuencia de acciones en lugar del proceso general, por lo que prefiero usar el término preparación de datos o información.

El orden o la ubicación de los pasos es menos importante para mí que cómo los realizamos. Con suerte, de alguna manera impulsada por metadatos. Por lo tanto, vale la pena señalar también que la transformación es el paso más complejo e importante del proceso y comprender dónde ocurre resulta ser una consideración clave del diseño.

Entonces, dicho eso y volviendo a tu pregunta. ELT (extraer, cargar y transformar) simplemente significa que la transformación se produce en el entorno de destino utilizando la potencia informática [de los] enfoques, como una base de datos relacional que se encuentra allí. ¿Es bueno eso? Sí. Principalmente.

La transformación en el sistema fuente, tal vez eso debería haberse llamado transformar, extraer y cargar [TEL], siempre se realiza hasta cierto punto, pero históricamente se mantuvo en el mínimo absoluto para reducir el impacto del sistema fuente. La transformación en un sistema intermedio, ETL, era entonces una opción obvia, minimizando los impactos tanto en los sistemas de origen como en los de destino.

Sin embargo, los sistemas de destino, especialmente en la nube, tienen pocas o ninguna restricción de rendimiento y el DBMS relacional de destino tiene buenas capacidades de transformación, por lo que ELT tiene mucho sentido, y sí, creo que son complementarios y, en particular, un enfoque que combina ETL y ELT parece para mí, ser el más flexible y poderoso, especialmente si hay algo de inteligencia y automatización al elegir cuándo y en qué circunstancias la función se envía desde el servidor ETL [es decir,] donde se define por primera vez y se ejecuta en el sistema de destino. ¡Así que, absolutamente! No es cuestión de elegir entre los dos. Creo que ambos pueden coexistir, y creo que ese es un enfoque realmente bueno.

¿Cómo se asegura de que los datos correctos se introduzcan en su almacén de datos que se combinen y se transformen de manera óptima para adaptarse a los requisitos de informes y análisis? ¿Cuáles son algunos consejos que le daría a las organizaciones que buscan garantizar la calidad de los datos en su almacén de datos empresarial?

Oh, son grandes preguntas. Me refiero a que la calidad es fundamental para todas las formas de toma de decisiones basadas en datos o, diría, información más adecuada. Entonces, lo primero para mí es siempre un trabajo de modelado de datos o información completo y de calidad. Sé que algunas personas levantarán las manos y dirán: “Oh, demasiado lento [y] demasiado caro. Hagamos el esquema al leer ”Pero, sinceramente, no creo que haya otra forma de obtener datos altamente consistentes en su almacén que no sea el modelado por adelantado.

Entonces, eso es realmente importante, y creo que este modelado puede y debe hacerse en etapas, un enfoque por etapas ágil. Ese es un gran tema y probablemente para otro día. Sé que muchas organizaciones se han decidido por un enfoque de almacenamiento de datos totalmente dimensional y que puede ser ideal para empresas de tamaño medio.

Pero para las empresas más grandes, generalmente es preferible un almacenamiento consistente de datos centrales conciliados y EDW para crear y mantener datos e información de calidad óptima. Y finalmente, más allá del modelado, emplear un equipo de modelado bueno y flexible es probablemente el siguiente aspecto más importante de la implementación de un entorno de preparación de datos de primera clase.

Especialmente, en las organizaciones medianas, sugeriría que un enfoque de automatización del almacén de datos es probablemente mejor tanto en términos de calidad como de costo porque, por lo general, eso incluye el paso de modelado en el proceso de avanzar.

[Diga] que esta arquitectura que tiene está construida. Tiene varias canalizaciones de datos que provienen de una variedad de sistemas de origen. Usted mencionó sistemas operativos, obviamente, tal vez flujos de IoT, [entonces] hay muchas posibilidades cuando se habla de la empresa moderna. Tiene diferentes latencias de datos trabajando aquí e interdependencias en muchos casos. Orquestar todo esto es obviamente una pregunta difícil. ¿Cuáles diría que son los elementos esenciales para corregir esa parte de la ecuación?

Bueno, primero, me gustaría decir que siempre hemos estado lidiando con múltiples canalizaciones de datos provenientes de varios sistemas de origen con diferentes latencias e interdependencias de datos, como ha mencionado, ciertamente, en grandes empresas con las que he tratado.

Creo que el aspecto más importante hoy, y lo ha mencionado, es que estamos buscando ingerir y analizar grandes cantidades de datos sin procesar y, a menudo, son datos sucios, y se desconoce qué tan sucios están, de la web e Internet de cosas. Y esos datos tienen características muy diferentes de los datos del sistema operativo, que yo llamo datos mediados por procesos, o PMD para abreviar, que eran las principales fuentes de datos hasta, digamos, hace 10 años.

Entonces, dada esa diferencia en la calidad de los datos, diría que intentar enviar todos estos nuevos datos al mismo almacén de datos que su PMD es un error. Necesita múltiples pilares de procesamiento de datos. Expliqué todo eso en mi libro "Falta de inteligencia empresarial”, Así que si quieres bucear más profundo allí, hazlo. Algunos de estos pilares serán almacenes de datos tradicionales, otros serán más como lagos de datos, pero todos, por supuesto, serán alimentados con canalizaciones de datos como definí anteriormente en la entrevista.

Por lo tanto, la clave para que todo eso funcione bien, por supuesto, es garantizar que los datos en estos pilares estén bien interconectados, relacionados y reconciliados, a diferencia de lo que vimos en los silos de datos tradicionales y lo que usted llama orquestación a través de los canales de datos es un componente clave para que esto suceda.

Ahora, esto nos lleva de vuelta al modelado, pero también a los metadatos, porque un elemento esencial en la orquestación de todas estas canalizaciones son los metadatos. Ahora prefiero llamarlo información de configuración de contexto, o CSI, porque esta palabra 'meta' se está abusando un poco en estos días, incluso Facebook la ha adoptado.

Por lo tanto, este tipo de información de configuración de contexto es lo que se contiene y se menciona en la Arquitectura de estructura de datos de Gartner y es realmente esta idea de mantenerse activo y activamente mantenido y mantenido internamente consistente y alineado con los cambios de negocios a menudo Gartner sugiere que necesita usar IA [artificial inteligencia] para hacer eso.

Entonces, involucrar esta idea de metadatos activos es realmente importante. Mi opinión es que en realidad estamos bastante lejos de esto hoy, pero realmente tenemos que enfocarnos en eso porque creo que realmente hará que todo este sistema funcione o se derrumbará.

Hablando del almacén de datos real y dónde está construido. Obviamente, la nube parece ser el lugar al que todos llevan sus sistemas de BI hoy en día. ¿Cuáles son algunas de las consideraciones que los equipos de datos empresariales deben tener en cuenta al crear una canalización de datos para estas plataformas?

Sí, me refiero a que todo el mundo habla de la nube. En términos de arquitectura, mi opinión es que la nube es simplemente [que es] otro grupo de almacenamiento, aunque enorme y altamente distribuido, y si sus herramientas de preparación de datos son compatibles con las fuentes y los objetivos de la nube, entonces está listo para comenzar, ¿verdad? Bueno, yo diría que no del todo.

Es la naturaleza distribuida de [la] nube lo que primero y siempre debe tener en cuenta. La gestión de datos era mucho más sencilla, siempre digo, cuando todos sus datos estaban en un solo mainframe. Pero las copias de datos son la pesadilla de la gobernanza de datos y cuanto más lugares y más separadas estén estas copias, más difícil se vuelve el desafío. Por lo tanto, la nube permite y, hasta cierto punto, promueve la duplicación de datos, algunos de ellos [son] en gran parte invisibles.

Por lo tanto, mi primer consejo en términos de nube es reforzar sus equipos de gestión y gobierno de datos porque realmente serán necesarios. La segunda consideración es lo que se llama gravedad de datos. ¿Dónde se originan los datos?

Si proviene de las instalaciones, habrá costos para llevarlo a la nube. [Y] si proviene de la nube, generalmente es más efectivo mantenerlo allí.

Por supuesto, la mayoría de las empresas hoy en día tienen datos de ambas fuentes, por lo que no existe una única respuesta correcta sobre dónde almacenar y procesar sus datos. Pero está claro que hay presión para llevarlo a la nube, a menudo por motivos económicos. Pero aquí está el robo: lo principal aquí es vigilar los costos relativos del procesamiento de almacenamiento y el transporte de datos, y creo que es el último el que puede atraparlo, especialmente cuando hablamos de preparación de datos y canalizaciones de datos. .

Entonces, pasando aquí a la pregunta final y supongo que es la que hemos estado eludiendo y mencionando de diferentes maneras y en algunas respuestas anteriores, pero para obtener una aproximación, ¿dónde crees que encaja la automatización en todo esto? ¿Cómo puede hacer que el proceso de creación y mantenimiento de canalizaciones de datos sea más eficiente?

Sí, creo que tienes razón. Todo apunta ahora a la automatización. Como ya he dicho, me refiero a que soy un gran defensor de la automatización en la preparación de datos e información. Dicho esto, desconfío profundamente de la automatización en otras áreas, particularmente donde se toman decisiones que afectan la vida y creo que debemos tener cuidado con la automatización allí.

Pero volviendo a la preparación de datos, creo que cualquier cosa que reduzca el costo de lo que efectivamente es solo plomería es muy bienvenida. Y la automatización debe aplicarse en todas las etapas del proceso, siempre que sea posible, desde la especificación y el diseño iniciales hasta las operaciones diarias y hasta el mantenimiento continuo y la gestión de cambios.

Ese es un alcance muy amplio y muy amplio de lo que tendríamos que hacer y lo que necesitamos automatizar. Simplemente no hago una advertencia, ya sabes, basado en mis largos años de experiencia y es que la automatización tiende a empujarte hacia funciones de transformación predefinidas, ¡y son geniales! Pero la capacidad de crear transformaciones personalizadas que son exclusivas de su propio entorno suele ser clave para el éxito interno de las herramientas de preparación de datos.

Estas necesidades pueden ser sólo un cinco por ciento o menos que las transformaciones [predefinidas], pero su importancia a menudo se subestima fácilmente porque a menudo son las transformaciones más importantes desde el punto de vista empresarial.

En mi opinión, las herramientas de automatización del almacén de datos deben permitir que estas rutinas de transformación muy específicas se desarrollen e integren en el flujo de trabajo. Dicho esto, la automatización ofrece la oportunidad de reducir o eliminar las partes repetitivas y comunes del proceso de preparación de datos. Y las herramientas de automatización del almacén de datos también aumentan los aspectos humanos del proceso.

Estoy pensando aquí en la definición de requisitos, la creación de consenso, la gestión de cambios, etc. En este sentido, DWA se parece un poco a la inteligencia artificial, ya que contiene aspectos tanto de automatización como de aumento. Entonces, creo que ese es un aspecto particularmente importante de lo que debemos pensar.

Como pensamiento final, siempre he sentido que la automatización del almacén de datos como ETL fue una elección desafortunada de nombre para esta clase de herramientas porque estas herramientas hacen más que automatización, como acabo de decir, y pueden y deben aplicarse a un gran alcance. una gama más amplia de sistemas de gestión y almacenamiento de datos que solo los almacenes de datos.

Todas las partes del nombre tienen sus debilidades. Entonces, ¿cuál debería ser el nombre? Realmente no lo sé a menos que quiera intentar llamarlo la navaja suiza de la gestión de datos y creo que probablemente sea un buen lugar para detenerse.

Automatice sus canalizaciones de datos sin escribir ningún código

Investigar Como

Astera DW Builder: automatice sus canalizaciones de datos

Astera DW Builder es una solución de almacenamiento de datos unificada que le permite crear una arquitectura de canalización de datos basada en metadatos. La plataforma de un extremo a otro ofrece un entorno de código cero para desarrollar su almacén de datos en un nivel lógico y automatizar sus procesos de diseño e ingeniería para obtener información valiosa que satisfaga sus requisitos de inteligencia empresarial.

La solución ágil y automatizada viene con las mejores capacidades ETL y ELT de su clase, incluida la orquestación del flujo de trabajo y los componentes de programación de trabajos incorporados, para crear canalizaciones de datos autorreguladas. Tomar las medidas de precaución detalladas por Colorado Parks and Wildlife (CPW) Astera DW Builder para una prueba de manejo para aprender cómo puede ayudar a entregar datos precisos y confiables a su BI y arquitectura de informes.