Cuando tienes escamas Sber. Uso de Ab Initio con Hive y GreenPlum

Hace algún tiempo nos enfrentamos a la cuestión de elegir una herramienta ETL para trabajar con Big Data. La solución Informatica BDM utilizada anteriormente no nos convenía debido a su funcionalidad limitada. Su uso se ha reducido a un marco para lanzar comandos de envío de chispas. No había muchos análogos en el mercado que, en principio, fueran capaces de trabajar con el volumen de datos con el que tratamos todos los días. Al final elegimos Ab Initio. Durante las demostraciones piloto, el producto mostró una velocidad de procesamiento de datos muy alta. Casi no hay información sobre Ab Initio en ruso, así que decidimos hablar sobre nuestra experiencia en Habré.

Ab Initio tiene muchas transformaciones clásicas e inusuales, cuyo código se puede ampliar utilizando su propio lenguaje PDL. Para una pequeña empresa, una herramienta tan poderosa probablemente resulte excesiva y la mayoría de sus capacidades pueden resultar costosas y no utilizarse. Pero si su escala se acerca a la de Sberov, entonces Ab Initio puede resultarle interesante.

Ayuda a una empresa a acumular conocimiento a nivel mundial y desarrollar un ecosistema, y ​​a un desarrollador a mejorar sus habilidades en ETL, mejorar su conocimiento en el shell, brinda la oportunidad de dominar el lenguaje PDL, brinda una imagen visual de los procesos de carga y simplifica el desarrollo. debido a la abundancia de componentes funcionales.

En esta publicación hablaré sobre las capacidades de Ab Initio y brindaré características comparativas de su trabajo con Hive y GreenPlum.

• Descripción del framework MDW y trabajo en su personalización para GreenPlum
• Comparación de rendimiento de Ab Initio entre Hive y GreenPlum
• Trabajando Ab Initio con GreenPlum en modo de tiempo casi real

La funcionalidad de este producto es muy amplia y requiere mucho tiempo para estudiarla. Sin embargo, con las habilidades laborales adecuadas y la configuración de rendimiento adecuada, los resultados del procesamiento de datos son muy impresionantes. Usar Ab Initio para un desarrollador puede proporcionar una experiencia interesante. Esta es una nueva visión del desarrollo ETL, un híbrido entre un entorno visual y desarrollo de descargas en un lenguaje similar a un script.

Las empresas están desarrollando sus ecosistemas y esta herramienta resulta más útil que nunca. Con Ab Initio, puede acumular conocimientos sobre su negocio actual y utilizarlos para ampliar negocios antiguos y abrir nuevos. Las alternativas a Ab Initio incluyen entornos de desarrollo visual Informatica BDM y entornos de desarrollo no visuales Apache Spark.

Descripción de Ab Initio

Ab Initio, al igual que otras herramientas ETL, es una colección de productos.

Ab Initio GDE (Graphical Development Environment) es un entorno para el desarrollador en el que configura transformaciones de datos y las conecta con flujos de datos en forma de flechas. En este caso, dicho conjunto de transformaciones se llama gráfico:

Las conexiones de entrada y salida de los componentes funcionales son puertos y contienen campos calculados dentro de las transformaciones. Varios gráficos conectados por flujos en forma de flechas en el orden de su ejecución se denominan plan.

Hay varios cientos de componentes funcionales, lo cual es mucho. Muchos de ellos están altamente especializados. Las capacidades de las transformaciones clásicas en Ab Initio son más amplias que en otras herramientas ETL. Por ejemplo, Join tiene múltiples salidas. Además del resultado de conectar conjuntos de datos, puede obtener registros de salida de conjuntos de datos de entrada cuyas claves no se pudieron conectar. También puede obtener rechazos, errores y un registro de la operación de transformación, que puede leerse en la misma columna que un archivo de texto y procesarse con otras transformaciones:

O, por ejemplo, puede materializar un receptor de datos en forma de tabla y leer los datos en la misma columna.

Hay transformaciones originales. Por ejemplo, la transformación Scan tiene una funcionalidad similar a las funciones analíticas. Hay transformaciones con nombres que se explican por sí mismos: Crear datos, Leer Excel, Normalizar, Ordenar dentro de grupos, Ejecutar programa, Ejecutar SQL, Unir con base de datos, etc. Los gráficos pueden usar parámetros de tiempo de ejecución, incluida la posibilidad de pasar parámetros desde o hacia el sistema operativo. Los archivos con un conjunto de parámetros listo para usar pasados ​​​​al gráfico se denominan conjuntos de parámetros (psets).

Como era de esperar, Ab Initio GDE tiene su propio repositorio llamado EME (Enterprise Meta Environment). Los desarrolladores tienen la oportunidad de trabajar con versiones locales de código y registrar sus desarrollos en el repositorio central.

Es posible, durante la ejecución o después de ejecutar el gráfico, hacer clic en cualquier flujo que conecte la transformación y observar los datos que pasaron entre estas transformaciones:

También es posible hacer clic en cualquier secuencia y ver los detalles de seguimiento: en cuántos paralelos funcionó la transformación, cuántas líneas y bytes se cargaron en cuál de los paralelos:

Es posible dividir la ejecución del gráfico en fases y marcar que algunas transformaciones deben realizarse primero (en la fase cero), las siguientes en la primera fase, las siguientes en la segunda fase, etc.

Para cada transformación, puede elegir el llamado diseño (donde se ejecutará): sin paralelos o en hilos paralelos, cuyo número se puede especificar. Al mismo tiempo, los archivos temporales que crea Ab Initio cuando se ejecutan las transformaciones se pueden colocar tanto en el sistema de archivos del servidor como en HDFS.

En cada transformación, basándose en la plantilla predeterminada, puedes crear tu propio script en PDL, que es un poco como un shell.

Con PDL, puede ampliar la funcionalidad de las transformaciones y, en particular, puede generar dinámicamente (en tiempo de ejecución) fragmentos de código arbitrarios dependiendo de los parámetros de tiempo de ejecución.

Ab Initio también tiene una integración bien desarrollada con el sistema operativo a través del shell. Específicamente, Sberbank utiliza Linux KSH. Puede intercambiar variables con el shell y utilizarlas como parámetros del gráfico. Puede llamar a la ejecución de gráficos de Ab Initio desde el shell y administrar Ab Initio.

Además de Ab Initio GDE, la entrega incluye muchos otros productos. Existe su propio sistema de cooperación que pretende ser llamado sistema operativo. Existe un Control>Centro donde puedes programar y monitorear los flujos de descarga. Existen productos para realizar desarrollo a un nivel más primitivo que el que permite Ab Initio GDE.

Descripción del framework MDW y trabajo en su personalización para GreenPlum

Junto con sus productos, el proveedor suministra el producto MDW (Metadata Driven Warehouse), que es un configurador de gráficos diseñado para ayudar con las tareas típicas de llenar almacenes de datos o bóvedas de datos.

Contiene analizadores de metadatos personalizados (específicos del proyecto) y generadores de código listos para usar.

Como entrada, MDW recibe un modelo de datos, un archivo de configuración para configurar una conexión a una base de datos (Oracle, Teradata o Hive) y algunas otras configuraciones. La parte específica del proyecto, por ejemplo, implementa el modelo en una base de datos. La parte lista para usar del producto genera gráficos y archivos de configuración cargando datos en tablas modelo. En este caso, se crean gráficos (y psets) para varios modos de inicialización y trabajo incremental en la actualización de entidades.

En los casos de Hive y RDBMS, se generan diferentes gráficos para la inicialización y las actualizaciones incrementales de datos.

En el caso de Hive, los datos delta entrantes se conectan a través de Ab Initio Join con los datos que estaban en la tabla antes de la actualización. Los cargadores de datos en MDW (tanto en Hive como en RDBMS) no solo insertan nuevos datos del delta, sino que también cierran los períodos de relevancia de los datos cuyas claves primarias recibieron el delta. Además, debe reescribir la parte sin cambios de los datos. Pero esto debe hacerse porque Hive no tiene operaciones de eliminación o actualización.

En el caso de los RDBMS, los gráficos para la actualización incremental de datos parecen más óptimos, porque los RDBMS tienen capacidades de actualización reales.

El delta recibido se carga en una tabla intermedia de la base de datos. Después de esto, el delta se conecta a los datos que estaban en la tabla antes de la actualización. Y esto se hace usando SQL mediante una consulta SQL generada. A continuación, utilizando los comandos SQL eliminar+insertar, se insertan nuevos datos del delta en la tabla de destino y se cierran los períodos de relevancia de los datos cuyas claves primarias recibieron el delta.
No es necesario reescribir los datos sin cambios.

Entonces llegamos a la conclusión de que en el caso de Hive, MDW tiene que reescribir toda la tabla porque Hive no tiene una función de actualización. Y nada mejor que reescribir por completo los datos cuando se ha inventado la actualización. En el caso del RDBMS, por el contrario, los creadores del producto consideraron necesario confiar la conexión y actualización de las tablas al uso de SQL.

Para un proyecto en Sberbank, creamos una implementación nueva y reutilizable de un cargador de base de datos para GreenPlum. Esto se hizo en base a la versión que genera MDW para Teradata. Fue Teradata, y no Oracle, el que estuvo más cerca y mejor para esto, porque... También es un sistema MPP. Los métodos de trabajo, así como la sintaxis, de Teradata y GreenPlum resultaron ser similares.

A continuación se muestran ejemplos de diferencias críticas para MDW entre diferentes RDBMS. En GreenPlum, a diferencia de Teradata, al crear tablas es necesario escribir una cláusula

distributed by

Teradata escribe:

delete <table> all

, y en GreenPlum escriben

delete from <table>

En Oracle, con fines de optimización escriben

delete from t where rowid in (<соединение t с дельтой>)

, y Teradata y GreenPlum escriben

delete from t where exists (select * from delta where delta.pk=t.pk)

También observamos que para que Ab Initio funcionara con GreenPlum, era necesario instalar el cliente GreenPlum en todos los nodos del clúster de Ab Initio. Esto se debe a que nos conectamos a GreenPlum simultáneamente desde todos los nodos de nuestro clúster. Y para que la lectura de GreenPlum fuera paralela y cada subproceso paralelo de Ab Initio leyera su propia porción de datos de GreenPlum, tuvimos que colocar una construcción entendida por Ab Initio en la sección "dónde" de las consultas SQL.

where ABLOCAL()

y determine el valor de esta construcción especificando la lectura del parámetro de la base de datos de transformación

ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))»

, que se compila en algo como

mod(sk,10)=3

, es decir. tienes que decirle a GreenPlum un filtro explícito para cada partición. Para otras bases de datos (Teradata, Oracle), Ab Initio puede realizar esta paralelización automáticamente.

Comparación de rendimiento de Ab Initio entre Hive y GreenPlum

Sberbank realizó un experimento para comparar el rendimiento de los gráficos generados por MDW en relación con Hive y GreenPlum. Como parte del experimento, en el caso de Hive había 5 nodos en el mismo clúster que Ab Initio, y en el caso de GreenPlum había 4 nodos en un clúster separado. Aquellos. Hive tenía cierta ventaja de hardware sobre GreenPlum.

Consideramos dos pares de gráficos que realizan la misma tarea de actualizar datos en Hive y GreenPlum. Al mismo tiempo se lanzaron los gráficos generados por el configurador MDW:

• carga inicial + carga incremental de datos generados aleatoriamente en una tabla de Hive
• carga inicial + carga incremental de datos generados aleatoriamente en la misma tabla GreenPlum

En ambos casos (Hive y GreenPlum) ejecutaron cargas en 10 subprocesos paralelos en el mismo clúster de Ab Initio. Ab Initio guardó datos intermedios para los cálculos en HDFS (en términos de Ab Initio, se utilizó el diseño MFS usando HDFS). Una línea de datos generados aleatoriamente ocupaba 200 bytes en ambos casos.

El resultado fue así:

Colmena:

Carga inicial en Hive

Filas insertadas
6 000 000
60 000 000
600 000 000

Duración de la inicialización
descargas en segundos
41
203
1 601

Carga incremental en Hive

Número de filas disponibles en
tabla de objetivos al comienzo del experimento
6 000 000
60 000 000
600 000 000

Número de líneas delta aplicadas a
mesa objetivo durante el experimento
6 000 000
6 000 000
6 000 000

Duración del incremental
descargas en segundos
88
299
2 541

Ciruela verde:

Carga inicial en GreenPlum

Filas insertadas
6 000 000
60 000 000
600 000 000

Duración de la inicialización
descargas en segundos
72
360
3 631

Carga incremental en GreenPlum

Número de filas disponibles en
tabla de objetivos al comienzo del experimento
6 000 000
60 000 000
600 000 000

Número de líneas delta aplicadas a
mesa objetivo durante el experimento
6 000 000
6 000 000
6 000 000

Duración del incremental
descargas en segundos
159
199
321

Vemos que la velocidad de carga inicial tanto en Hive como en GreenPlum depende linealmente de la cantidad de datos y, por razones de mejor hardware, es ligeramente más rápida para Hive que para GreenPlum.

La carga incremental en Hive también depende linealmente del volumen de datos cargados previamente disponibles en la tabla de destino y avanza con bastante lentitud a medida que crece el volumen. Esto se debe a la necesidad de reescribir completamente la tabla de destino. Esto significa que aplicar pequeños cambios a tablas enormes no es un buen caso de uso para Hive.

La carga incremental en GreenPlum depende débilmente del volumen de datos cargados previamente disponibles en la tabla de destino y avanza con bastante rapidez. Esto sucedió gracias a SQL Joins y la arquitectura GreenPlum, que permite la operación de eliminación.

Entonces, GreenPlum agrega el delta usando el método eliminar+insertar, pero Hive no tiene operaciones de eliminación o actualización, por lo que toda la matriz de datos se vio obligada a reescribirse por completo durante una actualización incremental. La comparación de las celdas resaltadas en negrita es muy reveladora, ya que corresponde a la opción más común para utilizar descargas que consumen muchos recursos. Vemos que GreenPlum venció a Hive en esta prueba por 8 veces.

Trabajando Ab Initio con GreenPlum en modo de tiempo casi real

En este experimento, probaremos la capacidad de Ab Initio para actualizar la tabla GreenPlum con fragmentos de datos generados aleatoriamente casi en tiempo real. Consideremos la tabla GreenPlum dev42_1_db_usl.TESTING_SUBJ_org_finval, con la que trabajaremos.

Usaremos tres gráficas Ab Initio para trabajar con él:

1) Graph Create_test_data.mp: crea archivos de datos en HDFS con 10 de filas en 6 subprocesos paralelos. Los datos son aleatorios, su estructura está organizada para su inserción en nuestra tabla.

2) Gráfico mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset: gráfico generado por MDW al inicializar la inserción de datos en nuestra tabla en 10 subprocesos paralelos (se utilizan los datos de prueba generados por el gráfico (1))

3) Gráfico mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset: un gráfico generado por MDW para la actualización incremental de nuestra tabla en 10 subprocesos paralelos utilizando una parte de los datos recién recibidos (delta) generados por el gráfico (1).

Ejecutemos el siguiente script en modo NRT:

• generar 6 de líneas de prueba
• realizar una carga inicial insertar 6 de filas de prueba en una tabla vacía
• repetir la descarga incremental 5 veces
  • generar 6 de líneas de prueba
  • realice una inserción incremental de 6 de filas de prueba en la tabla (en este caso, el tiempo de vencimiento de valid_to_ts se establece en los datos antiguos y se insertan datos más recientes con la misma clave principal)

Este escenario emula el modo de funcionamiento real de un determinado sistema empresarial: una porción bastante grande de datos nuevos aparece en tiempo real y se vierte inmediatamente en GreenPlum.

Ahora veamos el registro del script:

Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:49
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:49
Inicie mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:49:37
Finalice mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset el 2020 de junio de 06 a las 04:11:50
Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:50
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:51
Inicie mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:51:06
Finalice mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:53:41
Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:53
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:54
Inicie mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:54:04
Finalice mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:56:51
Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:56
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:57
Inicie mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:57:14
Finalice mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 11:59:55
Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:11:59
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:12:00
Inicie mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 12:00:23
Finalice mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 12:03:23
Inicie Create_test_data.input.pset el 2020 de junio de 06 a las 04:12:03
Finalice Create_test_data.input.pset el 2020 de junio de 06 a las 04:12:03
Inicie mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 12:03:49
Finalice mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset en 2020-06-04 12:06:46

Resulta esta imagen:

Gráfico
Hora de inicio
Tiempo de finalización
Longitud Mínima

Crear_test_data.input.pset
04.06.2020 11: 49: 11
04.06.2020 11: 49: 37
00:00:26

mdw_load.day_one.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 49: 37
04.06.2020 11: 50: 42
00:01:05

Crear_test_data.input.pset
04.06.2020 11: 50: 42
04.06.2020 11: 51: 06
00:00:24

mdw_load.regular.actual.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 51: 06
04.06.2020 11: 53: 41
00:02:35

Crear_test_data.input.pset
04.06.2020 11: 53: 41
04.06.2020 11: 54: 04
00:00:23

mdw_load.regular.actual.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 54: 04
04.06.2020 11: 56: 51
00:02:47

Crear_test_data.input.pset
04.06.2020 11: 56: 51
04.06.2020 11: 57: 14
00:00:23

mdw_load.regular.actual.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 57: 14
04.06.2020 11: 59: 55
00:02:41

Crear_test_data.input.pset
04.06.2020 11: 59: 55
04.06.2020 12: 00: 23
00:00:28

mdw_load.regular.actual.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 00: 23
04.06.2020 12: 03: 23
00:03:00

Crear_test_data.input.pset
04.06.2020 12: 03: 23
04.06.2020 12: 03: 49
00:00:26

mdw_load.regular.actual.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 03: 49
04.06.2020 12: 06: 46
00:02:57

Vemos que se procesan 6 de líneas incrementales en 000 minutos, lo cual es bastante rápido.
Los datos de la tabla de destino resultaron distribuirse de la siguiente manera:

select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2;

Puede ver la correspondencia de los datos insertados con las horas en que se lanzaron los gráficos.
Esto significa que puede ejecutar una carga incremental de datos en GreenPlum en Ab Initio con una frecuencia muy alta y observar una alta velocidad al insertar estos datos en GreenPlum. Por supuesto, no será posible iniciarlo una vez por segundo, ya que Ab Initio, como cualquier herramienta ETL, requiere tiempo para “iniciar” cuando se inicia.

Conclusión

Ab Initio se utiliza actualmente en Sberbank para construir una capa de datos semánticos unificados (ESS). Este proyecto implica la construcción de una versión unificada del estado de varias entidades comerciales bancarias. La información proviene de diversas fuentes, cuyas réplicas se preparan en Hadoop. En función de las necesidades del negocio, se prepara un modelo de datos y se describen las transformaciones de datos. Ab Initio carga información en ESN y los datos descargados no sólo son de interés para la empresa en sí, sino que también sirven como fuente para crear mercados de datos. Al mismo tiempo, la funcionalidad del producto permite utilizar varios sistemas como receptor (Hive, Greenplum, Teradata, Oracle), lo que permite preparar fácilmente datos para una empresa en los distintos formatos que requiere.

Las capacidades de Ab Initio son amplias; por ejemplo, el marco MDW incluido permite crear datos históricos técnicos y comerciales listos para usar. Para los desarrolladores, Ab Initio hace posible no reinventar la rueda, sino utilizar muchos componentes funcionales existentes, que son esencialmente bibliotecas necesarias cuando se trabaja con datos.

El autor es un experto en la comunidad profesional de Sberbank SberProfi DWH/BigData. La comunidad profesional SberProfi DWH/BigData es responsable de desarrollar competencias en áreas como el ecosistema Hadoop, Teradata, Oracle DB, GreenPlum, así como las herramientas de BI Qlik, SAP BO, Tableau, etc.

Fuente: habr.com