Sesión de preguntas y respuestas con Paul Kellett sobre canalizaciones de datos automatizadas

By |2022-08-04T13:42:49+00:0016th noviembre, 2021|

Las canalizaciones de datos automatizadas sirven como columna vertebral de un ecosistema totalmente basado en datos. Permiten a las empresas extraer datos de fuentes dispares, aplicar transformaciones y llevar a cabo el proceso de integración de manera eficiente, confiable y rápida. Más empresas están optando por la automatización del almacén de datos para mejorar el análisis de datos y competir de manera más estratégica.

Recientemente lanzamos Astera DW Builder, una plataforma de automatización de almacenamiento de datos de un extremo a otro que proporciona un entorno iterativo sin código para diseñar, desarrollar e implementar canalizaciones de datos a velocidades sin precedentes.

Para educar a las empresas modernas sobre el flujo de datos autorregulado, organizamos un seminario web en vivo titulado: Prepare su almacén de datos para el futuro con canalizaciones de datos autorregulables en noviembre 2nd, donde tuvimos la increíble oportunidad de conversar con Paul Kellett. Tiene más de 25 años de experiencia trabajando en proyectos de inteligencia empresarial a nivel empresarial para organizaciones.

En nuestra sesión de preguntas y respuestas, obtuvimos información valiosa sobre la creación de canalizaciones de datos automatizadas y de alta calidad, procesos de almacenamiento de datos modernos, almacenamiento de datos en la nube y más.

Afnan: Los almacenes de datos modernos procesan grandes volúmenes de datos. ¿Recomendaría alguna de las mejores prácticas que las personas deberían utilizar para crear canalizaciones de datos que puedan entregar de manera efectiva estas grandes cantidades de datos a su almacén de datos?

Pablo: Sí, pero también agregaría que no se trata solo de los volúmenes de datos. Es la variedad de fuentes, la variedad de formatos de las fuentes y el hecho de que, si se encuentra particularmente en cualquier entorno corporativo, con frecuencia accede a decenas de sistemas: están en un estado de cambio constante. Por lo tanto, el tipo de datos que obtiene generalmente cambiará.

Esos sistemas no se detienen: las empresas innovan y cambian, por lo que aquí se enfrentan varios problemas. Necesita obtenerlo de manera confiable; necesita [procesar datos] de una manera sólida [con] la menor cantidad posible de intervenciones. Históricamente, las personas podían crear una serie completa de extractos a partir de sus sistemas de origen, estarían haciendo soluciones de tipo punto a punto en las que podría tener varios mecanismos diferentes para recibir los datos. Yo diría, intente tener [un] mecanismo estándar constante [y] tendrá un solo tipo de práctica.

Luego, debe implementar herramientas que sean adecuadas para estas cosas. Por lo tanto, evite tanto como sea posible las soluciones artesanales o de punto a punto. Lo que vemos en muchos almacenes de datos históricos es que hay una serie de soluciones hechas a mano a medida para obtener los datos del Sistema 'A' y uno diferente del 'Sistema B'. Básicamente, terminan con problemas de calidad y solidez, y también terminan con problemas de mantenimiento, y tienden a adaptarse con bastante lentitud a los cambios.

Entonces, es un triple golpe en términos de hacer eso. Desea utilizar cosas que estén haciendo el trabajo pesado por usted. No querrás repetir cosas estándar como el manejo de errores. Necesita que sea simple, fácil, robusto, consistente y estándar. Mi último punto sobre esa pregunta sería intentar, si es posible, extraer los datos de los sistemas de origen en lugar de que se los proporcione como un extracto.

Afnan: Las canalizaciones de datos y ETL son básicamente un concepto que ha sido sinónimo de almacenamiento de datos desde el inicio de la tecnología. Entonces, ¿cómo crees que ELT y la canalización de datos han evolucionado en la era del big data? ¿Qué tipo de innovaciones cree que podrían reducir tanto el costo como la complejidad del ETL tradicional?

Pablo: Muchos de los costos históricamente han venido probablemente de dos áreas principales: una ha sido una gran cantidad de soluciones de tipo artesanal, que son bastante caras y bastante limitadas. Además, y no estoy llegando a las herramientas ELT aquí, pero han sido grandes [y] caras. Requieren recursos especializados y una infraestructura, hardware, servidor y plataformas dedicados propios, y [requieren] recursos [que] son ​​difíciles de conseguir.

Entonces, lo que estamos viendo ahora es un movimiento para facilitar ese tipo de procesos. Entonces, en lugar de tener que calcular lo que va a obtener, van y hacen un mapa para usted automáticamente. Es mucho más hacer clic y apuntar de lo que históricamente ha sido el caso. Entonces, estamos viendo que esencialmente está reduciendo la necesidad, y [permite] mucha más codificación y mover eso.

Afnan: Un requisito importante que vemos surgir con frecuencia es que más organizaciones quieran construir canalizaciones ELT ahora en lugar de las canalizaciones ETL tradicionales. Entonces, ¿qué opinas sobre ese enfoque? ¿Crees que podría funcionar para todas las organizaciones? ¿O hay ciertas cosas que las organizaciones deben tener en cuenta antes de optar por ELT en lugar de ETL?

Pablo: Entonces, en primer lugar, nunca hay una solución que funcione para todo. Hay casos en los que ETL es bastante adecuado; de hecho, preferido. Pero lo que estamos viendo es que el punto de partida preferido hoy en día probablemente sería ELT. El software y las arquitecturas de la base de datos han mejorado sustancialmente. Una de las necesidades del ELT histórico ha sido la incapacidad de la base de datos para procesar los grandes volúmenes de transformaciones requeridas en las escalas de tiempo. Pueden realizar una gran cantidad de casos de uso.

Personalmente me moví hacia ELT. No recuerdo la última vez que hice ELT; habría sido hace al menos diez años. Su principal impulso sería el componente de bienestar. Ha simplificado su solución. Tienes una plataforma menos en la que fallar y poner [así como] un conjunto menos de plataformas de prueba por las que pasar. Entonces, ha disminuido su complejidad.

También tiene un costo, ya que no tiene esas plataformas para hacerlo, por lo que las cosas que impulsaban la necesidad de eso esencialmente han disminuido. Si estuviera buscando hoy en un entorno Greenfields, asumiría que mi punto de partida sería ELT y luego me alejaría de eso si sintiera que lo necesito debido a algunas circunstancias especiales.

Afnan: ¿Cómo puede asegurarse de tener los datos correctos en su almacén de datos? y que se está combinando, consolidando [y] transformando de manera que se adapte a sus requisitos de análisis e informes?

Pablo: Entonces, en primer lugar, realmente no se pueden garantizar datos correctos. La razón de esto es que usted depende de los datos que le brindan los sistemas de origen y, como atestiguará cualquier persona que haya trabajado en el área, a menudo le brindarán datos incorrectos o datos inconsistentes o los datos tienen problemas cuando se presentan de una manera diferente - [ it] proporciona la posición incorrecta.

Pero lo que puede hacer es intentar dar la mejor imagen posible de los datos de la mejor manera posible. No debería estar preparándose diciendo que daremos datos perfectos porque no suceden. Afortunadamente, no es tan importante porque generalmente se habla de análisis y se trata de comprender el volumen de datos, por lo que no es necesariamente un problema si lo administra correctamente.

Si desea obtener los mejores datos posibles, habría un par de tácticas que le recomendaría, una de ellas sería recopilar en exceso. Si tomamos el ejemplo, digamos, transacciones de ventas, se le pedirá que proporcione informes de ventas o análisis de ventas y alguien averiguará que necesita los campos A, B y C de estas dos tablas y luego [campos] fuera de este y este y esto y obtendrá los datos necesarios para resolver el problema.

En general, mi consejo es que si necesita información de ventas, obtenga toda la transacción de ventas [y] todos los datos asociados. Además, tómelo de la manera más no transformada posible. No corra el riesgo de que, en esencia, una transformación o alguna derivación de los datos introduzca sus propios errores de traducción. Llévelo a su almacén de datos y hágalo allí.

También estaría buscando crear algunos bucles de retroalimentación, para tener formas de hacer comprobaciones de alto nivel. Digamos que tengo los datos que espero obtener, y que por lo general se utilizan informes confiables o datos de los sistemas de origen y luego los comparo con algo similar en lo que obtiene a medida que avanza.

Es importante comprender qué es lo suficientemente bueno para el negocio. Por ejemplo, históricamente, las transacciones contables tienen que ser perfectas y estar dentro de los centavos, pero si sus transacciones de ventas aumentan un poco, no es el fin del mundo. Entonces, también estaría usando cosas así. [Hay] trucos y técnicas estándar como formateo de datos estándar [y] eliminar el espacio final como una coma. Decide que vas a hacer esto y hacerlo [de manera] estándar.

Afnan: Cuando se habla de recopilar todos estos datos de diferentes fuentes. Trabajará con múltiples canalizaciones de datos, y todas estas canalizaciones obviamente tendrán diferentes latencias e interdependencias de datos. Entonces, ¿cuáles crees que son los elementos esenciales para orquestar básicamente estas canalizaciones?

Pablo: Existen técnicas de modelado probadas bastante estándar en el modelado de dimensiones que se utilizan en el mercado. Kimball [es] un muy buen lugar para comenzar a buscar el tipo de consejos y técnicas de diseño que han brindado. Estos son muy adecuados para construir su almacén de datos de manera que sus datos sean consistentes y presenten un formato común a medida que avanza.

Manejarán cosas como información faltante, por lo que si no tiene XYZ proveniente de una fuente en particular, si no conoce la definición del producto, entonces sabe que tiene técnicas estándar, como iré y crearé un producto de dominio, así que en al menos mi informe de ventas suma el producto. Puede que no conozca la información del producto, pero sabré que tengo información sobre un producto llamado flete. No sé más sobre ese producto, pero eso es todo lo que sé.

La segunda cosa es que debe controlar la forma en que procesa la información del contenido de los datos [metadatos], no cómo se procesan o se accede a los datos. Entonces, son cosas como si el lunes recibes las transacciones del domingo, no asumas que recibes las transacciones del domingo. Elimine todo de las fechas dentro de los datos. Por lo tanto, siempre intente obtener tantas fechas como sea posible de los datos, para que sepa lo que está sucediendo y luego, de esa manera, pueda volver a hacer coincidir las cosas entre sí.

Entonces, obtendrá algunas inconsistencias entre los sistemas, particularmente [cuando tenga] decenas de sistemas entregándose en su almacén de datos, invariablemente uno de ellos estará inactivo en algún momento uno de ellos estará disponible. [y] esto sucederá con frecuencia. Con ese fin, presente lo que falta como parte de su solución, no se limite a presentarlo y deje claro y obvio que no tenemos los datos de inventario del lunes para [digamos] el centro de distribución 27.

Abordarlo como parte de su procesamiento; esos serían mis principales comentarios. Por lo tanto, use los datos para manejarlo; Kimball es el rey, y asegúrese de que la empresa sepa cuándo obtiene cosas que no han aparecido.

Afnan: El almacenamiento de datos en la nube ha ganado mucho impulso, especialmente este año hemos escuchado hablar de ello por todas partes. Entonces, ¿cuáles cree que son algunas de las consideraciones que los equipos de datos empresariales deben tener en cuenta cuando están construyendo canalizaciones de datos específicamente para un almacén de datos en la nube?

Pablo: Bien, entonces voy a asumir que cuando hablemos [de] comprar un servicio en la nube en términos de hospedaje y administración de su infraestructura de almacenamiento de datos. Entonces, desde una perspectiva técnica, no hay una gran diferencia en cuanto a ir a la nube.

[Las] principales diferencias técnicas serían que obviamente estás en Internet, por así decirlo, y es posible que estés moviendo grandes volúmenes de datos, por lo que debes pensar mucho en cómo vas a mover esos datos grandes. volúmenes alrededor. ¿Están sus sistemas de origen y su infraestructura alojada en la nube, desde una perspectiva de red, lo suficientemente cerca entre sí como para poder mover estas cosas? Además, son lo suficientemente robustos entre sus diversos sistemas para que tenga confiabilidad, nuevamente, en los datos.

El otro elemento a tener en cuenta es con frecuencia las soluciones de almacenamiento de datos. Hay elementos tipo tablero, y los elementos tipo tablero a menudo han tenido una rapidez de aptitud reactiva. Deben reaccionar con bastante rapidez a los usuarios en términos de que haga clic aquí y obtenga la siguiente configuración.

La latencia sí importa. Si el tiempo de ping entre sus usuarios y su infraestructura en la nube es bajo, eso puede hacer que sus paneles se vean mal aunque no lo sean. La mayoría de las consideraciones estarían relacionadas con la infraestructura comercial, regulatoria o. Cuando va a la nube, normalmente está eligiendo a un proveedor. Entonces, ahora no depende de la tecnología. Depende de un proveedor para que sus sistemas funcionen.

Se trata más de medir al proveedor y sus habilidades que a la tecnología. Algunos de los posibles problemas regulatorios son que, si miro aquí donde estoy basado, básicamente no se le permite tomar datos de salud como ejemplo fuera del país sin un permiso especial porque son datos personales, y hay reglas sobre lo que hacer con los datos personales.

Del mismo modo, tiene algo de seguridad de datos que debe tener en cuenta, ya que ahora tiene la responsabilidad de cuidar sus datos a un tercero. En realidad, probablemente serán mejores en seguridad de datos que tú porque es parte de su vida, pero aún debes asegurarte de verificar eso. Y, de hecho, diría que esa es probablemente una de las áreas en las que puedes descansar un poco más fácilmente.

Una de las cosas de pasar a la nube es que obtienes mucha más capacidad [en términos de] tu capacidad de adaptación. [Hay varios] casos en los que he estado con clientes y básicamente se ha configurado su almacén de datos. en la arquitectura de 10 años que ha estado crujiendo lentamente, [con] las cargas diarias llegando cada vez más tarde en la mañana. [Entonces], no recibirá sus informes hasta el mediodía, pero la tarea de mudarse ha sido increíblemente difícil.

Han tenido todo tipo de problemas relacionados con el intento de reclutar y poseer recursos capaces de hacer ese tipo de trabajo para que puedas revelar gran parte de ese problema a otra persona. Sin embargo, no lo haga por motivos de costo, porque generalmente costará similar; aunque el modelo de costos puede diferir, está comprando más [y] mejorando. Entonces, esas serían algunas de las consideraciones para pasar a la nube.

Afnan: ¿Dónde crees que encaja la automatización en todo esto? [Usando] la automatización y la orquestación, ¿cómo cree que puede hacer que todo el proceso de creación y mantenimiento de sus canales de datos sea más eficiente?

Pablo: En primer lugar, en la medida de lo posible, evite que las soluciones punto a punto tengan algo que haga el trabajo pesado por usted. Entonces, quieres algo que esté monitoreando por ti. Con frecuencia, estas cargas ocurren en medio de la noche. Desea un tipo estándar de habilidades de tipo automatizado, como poder reiniciar desde un punto en particular en el tiempo, omitir puntos, todo ese tipo de control de trabajo y cosas de tipo de administración de trabajo.

Quieres algo que sea esencialmente fácil de construir. Cuanto más fácil sea ponerlos juntos [el sistema], más datos obtendrá. Cuanto más rápido lo obtenga y [menos] errores tendrá cuando ingrese esos datos, más probable será que lo haga de la [forma] que la empresa quiere que lo haga.

Quiero decir, en un punto lateral, con frecuencia comento que somos nuestro peor enemigo. Si tenemos éxito en una solución de inteligencia empresarial, normalmente lo sabemos porque estamos completamente sobrecargados de demanda. Bien, entonces debes poder tener que hacer estas cosas de la manera más fácil posible para hacer frente a esa demanda.

Históricamente, el costo de mover [y] crear almacenes de datos ha sido del orden del sesenta por ciento, tal vez incluso dos tercios, dependiendo de sus escalas de tiempo en el lado de ELT. Entonces, realmente desea asegurarse de tener algo que haga muchas de las tareas repetibles tanto como sea posible para usted de la manera más simple posible porque es una gran cantidad de lo que puede ser un costo bastante significativo.

Astera DW Builder: plataforma de almacenamiento de datos automatizada

Astera DW Builder es una solución de almacenamiento de datos de un extremo a otro que le permite desarrollar canales de datos automatizados en un entorno sin código. La plataforma unificada viene con una arquitectura basada en metadatos y agiliza sus procesos de diseño e ingeniería para proporcionar información precisa y relevante para facilitar una mejor toma de decisiones.

Las empresas pueden crear canalizaciones de datos autorreguladas aprovechando las capacidades avanzadas de ETL y ELT, como la orquestación de flujo de trabajo incorporada y los componentes de programación de trabajos de Astera Constructor de DW. Trata Astera DW Builder hoy para descubrir cómo puede agregar valor a su organización.