Bluetab

an IBM Company

Bluetab

Data Governance: trend or need?

by

Data Governance: trend or need?

Alvar Noe Arellanos

Business & IT Strategy Professional

En los últimos años la implementación de un gobierno de datos corporativo dentro de las diferentes organizaciones, independientemente de la industria a la que pertenezca. En cada una de estas implementaciones surge una pregunta recurrente “El Gobierno de Datos es una necesidad o una tendencia”. Realmente no es una pregunta fácil de contestar ya que deben considerarse varios aspectos para poder contestarla.

Con la llegada de la pandemia, las organizaciones tuvieron que evolucionar de manera acelerada a un esquema digital en el cual los datos, las personas, la escalabilidad de tecnología y la evolución de procesos, juegan un rol esencial para la evolución y trascendencia de las empresas

Si los datos se posicionan como un pilar esencial dentro de la evolución de las organizaciones, tiene sentido que el control y aprovechamiento total de estos requiera la necesidad de un gobierno de datos.

El Gobierno de Datos, según el marco metodológico DAMA®, es definido de la siguiente forma:

"El ejercicio de autoridad compartida, control y toma de decisiones (planificación, seguimiento y aplicación) a través de la gestión de los activos de datos"

Hasta este momento hemos identificado que el Gobierno de Datos es necesario para la evolución de una organización, aun no determinamos en que aspectos se estaría se centraría. Estos aspectos los listamos a continuación:

Organización

Colaboradores que interactúan en la gestión y administración de los activos de datos de la empresa relacionados con el Gobierno de Datos.

Procesos

Las tareas y actividades que conforman los procesos de gestión del Gobierno de Datos

Políticas y Estándares

Las políticas, estándares y lineamientos que permitan gestionar, controlar y estandarizar el Gobierno de Datos.

Tecnología

Tecnología, arquitectura, herramientas que se utilizan para la administración de la información relacionada con el Gobierno de Datos

Si bien estos pilares del Gobierno de Datos permitirán que los datos soporten la evolución digital de la organización, es importante aclarar que para que esto funcione es necesario mantener un modelo alineado a la estrategia de negocio, que sea sustentable y flexible, permitiendo identificar y ajustar de forma activa nuevas fuentes de información, SLAs, entre otros requerimientos que soporten los objetivos de negocio.

Con la implementación de un Gobierno de Datos dentro de las organizaciones se podrán obtener beneficios asociados directamente a las áreas de negocio, por ejemplo:

La obtención de estos beneficios permitirá que la evolución de las organizaciones frente a los retos globales y de las industrias, sea posible.

Dicho lo anterior se pude inferir que el gobierno de datos configura la gestión general de la disponibilidad, usabilidad, integridad y seguridad de los datos usados en una organización, permitiendo a las organizaciones eliminar una administración ineficiente de la información que afectaría a las organizaciones. Especialmente si miramos desde la perspectiva financiera y consideramos que el flujo de datos ha aumentado de forma exponencial en los últimos años a raíz del desarrollo de nuevas tecnologías y del crecimiento del mercado.

Tener una buena gestión de datos significa tomar las mejores decisiones para el negocio, lo que resulta en el aumento de la productividad y de la eficiencia operacional y, consecuentemente, en un incremento en los ingresos empresariales.

Una vez identificada la importancia y los beneficios que el gobierno de datos puede presentar podemos llegar a la conclusión que la implementación de un Gobierno de Datos dentro de una empresa que esta evolucionando a una cultura digital y data driven, es necesaria y no solo una tendencia a implementar según la industria a la cual la organización pertenece.

Alvar Noe Arellanos

Business & IT Strategy Professional

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Snowflake Advanced Storage Guide

by

Guía avanzada sobre almacenamiento en Snowflake

Roberto García Parra

Technical Delivery Manager

Introducción a Snowflake

Snowflake es una plataforma avanzada de datos que se consume en modalidad SaaS 100% en cloud. El principal factor diferenciador de Snowflake es que proporciona capacidades avanzadas para todas las necesidades de datos de las compañías (Almacenamiento, procesamiento, explotación y soluciones de analítica avanzada) de una manera más flexible y sencilla que las soluciones de Datawarehouse tradicionales. 

El motor de queries y procesamiento de Snowflake está basado 100% en SQL para facilitar el acceso a la mayoría de los profesionales de datos, aunque Snowflake está haciendo esfuerzos por ampliar las posibilidades de desarrollo (Por ejemplo, recientemente ha sacado Snowpark, una API que permite a los desarrolladores que estén habituados a trabajar con Spark tanto en Scala cómo en Java y recientemente en Python, a poder migrar sus códigos de forma sencilla a Snowflake). Además, dispone de conectores nativos con una serie de partners que abarca todas las fases de la ingeniería de datos, cómo por ejemplo partners de integración de datos tan importantes cómo Matillion, Informatica, DBT o DataStage; de Business Intelligence cómo Domo, Cognos o Looker; o de Machine Learning cómo Alteryx, Dataiku o AWS Sagemaker.

La otra ventaja diferenciadora de Snowflake es que tiene unas capacidades de optimización que no requieren apenas de mantenimiento y cubren un abanico muy amplio de casos de uso, entre las que se podrían destacar la clusterización automática, el cacheo y el search optimization service, elementos en los que ahondaremos en detalle en futuros artículos, ya que en éste nos vamos a centrar sobre todo en las capacidades de almacenamiento.

Principales características diferenciadoras de Snowflake:

  • Pone al alcance de los usuarios funcionalidades avanzadas que se gestionan de forma sencilla, abstrayendo a los usuarios de lo que se maneja por debajo.
  • Multi-cloud: Se puede desplegar en cualquiera de los tres clouds más importantes (Amazon, Azure y Google) e incluso permite implementar una estrategia multi-cloud dónde la mayoría de la administración y operación corre por cuenta de Snowflake.
  • No hay que mantener ni hardware ni software. Todo gestionado por Snowflake y sin pérdida de servicio.
  • Gestión sencilla de las unidades de procesamiento (Llamadas Virtual Warehouses). Es muy sencillo subir o bajar la talla del procesamiento (a golpe de click o una sencilla sentencia SQL), y los cluster se pueden configurar para que se bajen automáticamente tras un tiempo de inactividad, y vuelvan a levantarse de forma rápida cuándo entre una nueva petición (en menos de un segundo la mayor de las veces). Dado que una de las variables que marcan el coste es el tiempo de actividad de un warehouse, esto permite eficientar los costes, sin tener que preocuparnos de estar bajando-levantando instancias en función del uso de la plataforma.

La arquitectura de Snowflake está basada en tres principales capas:

  1. La capa de almacenamiento, que es en la que nos centraremos en este artículo. Esta capa basada en microparticiones es la base de algunas de las funcionalidades más disruptivas de Snowflake cómo por ejemplo el Zero-copy cloning o el Time-to-Travel, que veremos también en futuros artículos.
  2. Capa de procesamiento.
  3. Cloud Services, que es la capa con la que se interactúa con Snowflake y es el cerebro que gestiona y coordina el resto de capas y componentes.

Objetivo del artículo

Vamos a entender en profundidad cómo funciona Snowflake en la capa de almacenamiento. A grandes líneas, veremos:

  • Cómo se almacenan, distribuyen y comprimen los datos.
  • La importancia de los metadatos a la hora de escanear de forma eficiente el almacenamiento cuándo se hace tanto una consulta, cómo una operación DML de inserción, actualización o borrado.
  • Cómo es este proceso de búsqueda en los datos, para reducir al máximo el número de bytes a escanear (y por tanto, la reducción en los tiempos de consulta).

Esto será la base para entender varias de las funcionalidades diferenciales que ofrece Snowflake:

  • A nivel rendimiento: Clustering, caching, search optimization service y query acceleration service (Recientemente liberada). Estos servicios-funcionalidades ayudan a optimizar diferentes casos de uso dónde lo proporcionado por el almacenamiento no sea suficiente para obtener el rendimiento deseado.
  • Data Sharing, sin necesidad de replicar los datos físicamente.
  • Resiliencia: Zero-copy cloning, Time Travel y Fail Safe.

Introducción al almacenamiento

El almacenamiento en Snowflake se basa en la generación de ficheros comprimidos con un tamaño máximo aproximado de 16MB y que se almacenan en un repositorio orientado a objetos tipo el S3 de AWS. Estos ficheros son inmutables, y cualquier operación de inserción-borrado-actualización siempre se hace generando un nuevo fichero de datos y actualizando los metadatos para saber cuáles son los ficheros que están activos en cada momento, además de otros metadatos que veremos más adelante en profundidad para eficientar la cantidad de bytes escaneados a la hora de ejecutar una query.

Objetivos del almacenamiento Snowflake

La forma en la que almacena los datos Snowflake está enfocada a dos objetivos principales:

  • Optimizar el rendimiento de las consultas, con una combinación de organización automática de los datos, almacenamiento columnar y el mantenimiento de una metadata.
  • Posibilitar varias de las características diferenciales que tiene Snowflake frente a otros Datawarehouse tradicionales, cómo por ejemplo:
    • Zero-copy cloning.
    • Time Travel.
    • Data Sharing sin necesidad de replicar el dato físicamente.

Principales características del almacenamiento en Snowflake

Compresión columnar: Snowflake analiza y comprime automáticamente los datos durante la carga de la tabla, agrupándolos por columnas. En función del tipo de datos de cada una de las columnas, selecciona el esquema de compresión más óptimo para cada una de ellas: Cada columna puede tener su propio esquema de compresión y aumentar-reducir de forma independiente. Gracias a esta eficiencia en la compresión, se obtiene una mejora significativa en los rendimientos al reducir la cantidad de datos a escanear, además de un ahorro en costes de almacenamiento, ya que Snowflake factura por la cantidad almacenada ya comprimida.

Microparticiones: Son unidades de almacenamiento contiguo en las que Snowflake va almacenando los datos en el orden de la ingesta. A diferencia de otros motores de bases de datos, en Snowflake no es necesario declarar una forma de particionar los datos por una o más columnas, sino que él ya lo hace de manera automática de la siguiente forma: Por un lado, va insertando los datos según le llegan en bloques de almacenamiento que oscilan entre los 50 y los 500MB antes de compresión (16MB aprox comprimidos). Cuándo se llena un bloque, pasa al siguiente, y así sucesivamente hasta que todos los datos son insertados. Snowflake también encripta tanto en tránsito cómo en destino todos los datos.

Cada una de estas particiones son inmutables: en el caso en el que haya una actualización en alguna de las microparticiones, lo que se hace es crear una nueva versión de la misma, y se mantienen las versiones antiguas por el tiempo parametrizado en el time travel (propiedad DATA_RETENTION_TIME_IN_DAYS en la tabla Snowflake). La inmutabilidad permite cosas cómo por ejemplo poder acceder a versiones de los datos en diferentes momentos del tiempo o hacer clonados de tablas sin tener que replicar los datos.

Metadatos en las microparticiones Snowflake

Para cada micropartición, Snowflake genera una metadata con la siguiente información:

A nivel columna

  • El rango de valores para cada una de las columnas de la micropartición.
  • Valores mínimo y máximo.
  • Conteo de valores diferentes.
  • Conteo de nulos.

A nivel tabla

  • Tamaño de tabla (en bytes).
  • Referencias de archivos y extensiones de tabla.
  • Conteo de filas.
  • Otras propiedades adicionales usadas tanto para la optimización cómo para el procesamiento de las queries.

Principales características del microparticionamiento de Snowflake

  • Automático y transparente para el usuario: A diferencia de otros sistemas tradicionales, no hay que declarar previamente un campo de partición, ni hacer un mantenimiento posterior.
  • Asegura la eficiencia en el podado tanto en las consultas, cómo en las operaciones DML.
  • Todas las particiones tienen un tamaño similar: En otros sistemas, el tamaño de las particiones depende del campo elegido, y puede haber un claro desbalance de particiones en función del número de ocurrencias que tenga cada valor del campo particionado (Hot partition Keys). El trade-off para tener estos tamaños similares es que pueden solaparse valores: Un determinado valor de columna (por ejemplo una fecha) puede estar en más de una micropartición. Cuánto mayor es el solapamiento en las particiones de un valor, menor será el podado, ya que habrá que recorrer más particiones para filtrar los valores correctos en una búsqueda.
  • Según Snowflake, este método de particionado automático sería suficiente para tablas con tamaños de hasta 1TB sin tener que plantearse otras opciones cómo por ejemplo el clusterizado.
  • En campos secuenciales cómo fechas o numéricos es dónde más vemos que se puede obtener un beneficio en esta forma de particionar, ya que si la inserción de los datos está ordenada por dichos campos, el podado (pruning) será altamente eficiente, y en consecuencia la cantidad de datos a escanear y la rapidez en la resolución de las queries.
  • El almacenamiento columnar permite que Snowflake solamente escanee aquellas columnas incluídas en la consulta. De ahí que sea importante incluir solamente las columnas que realmente necesitemos y evitar queries del tipo SELECT * si no es necesario consultar todas las columnas.

Entendiendo la organización de datos en Snowflake

Partiendo de los siguientes datos de ejemplo:

Ordenados por fecha. Al insertarlos en Snowflake, para ilustrar este ejemplo se supone que se generan dos microparticiones, que se van llenando en el orden en el que entran los datos:

Si por ejemplo, hacemos la siguiente query:

Select Fecha, sum(importe)

From ventas

Where fecha = ‘01/01/2022’

Snowflake recorrería los siguientes datos:

  • Primero se podan las microparticiones que no estén en el rango. En este caso, cómo estamos buscando el 1 de Enero, ignorará la segunda micropartición.
  • Dentro de la primera micropartición, dado que en la query solamente se están seleccionando las columnas fecha e importe de venta, no recorre la parte de los datos del cliente. Esto es posible gracias al almacenamiento columnar.

Si se buscan las ventas de un cliente específico:

Select sum(importe)

From ventas

Where cliente = ‘C2’

En este ejemplo, recorre las dos microparticiones, ya que C2 está dentro del rango de valores de ambas, aunque realmente C2 no está en la micropartición 1. Esto es lo que se comentaba en el apartado anterior de la posible dependencia que puede haber en la búsqueda de rangos en cada micropartición de cómo están distribuidos los datos.

DML’s en Snowflake

Para ver cómo funcionan las principales operaciones de DML en Snowflake, hemos reproducido el siguiente experimento: Creamos una nueva tabla, partiendo de una tabla origen que tiene las ventas de varios días de 60 call centers, seleccionando solamente los Call Center 1 y 20. Lo que haremos será operaciones atómicas de inserción, actualización y borrado para ver cómo se gestionan tanto los datos cómo los metadatos.

  • Inserción: Para comprobar cómo funciona la inserción insertamos dos nuevos registros con Call Center que no existen: El 10 y el 11.
    Los ficheros que componen las microparticiones son inmutables, por lo que Snowflake en la inserción puede ejecutar dos posibles acciones:
    • Crear un nuevo fichero con los registros existentes más el nuevo, y archivar el antiguo.
    • Crear una nueva partición para ese dato.
  • Actualización: Las acciones que realiza Snowflake para ejecutar una actualización son:
    • Identificar las microparticiones afectadas por la actualización.
    • Generar nuevos ficheros de micropartición que incluyan las modificaciones.
    • Archivar las versiones anteriores de los ficheros durante el tiempo marcado por el DATA_RETENTION_TIME_IN_DAYS.

Para verificar esto, partiendo del ejemplo anterior hemos lanzado una consulta que actualice los call center 10 y 11 a 15 por ejemplo. Comprobamos que efectivamente Snowflake solamente recorre esa partición, y genera un nuevo fichero con los nuevos valores, archivando el anterior:

Si se actualiza alguno de los otros dos call center, el número de particiones recorridas sería mayor, lo cuál implica que el coste de las operaciones DML también se ve afectado por la manera en que estén organizados los datos.

  • Borrado: Snowflake procede de manera similar a la actualización:
    • Identifica las microparticiones afectadas por el borrado.
    • Genera nuevos ficheros de micropartición dónde no aparezcan los registros eliminados.
    • Archiva las versiones anteriores de los ficheros durante el tiempo marcado por el DATA_RETENTION_TIME_IN_DAYS.

La importancia de entender cómo gestiona Snowflake estas operaciones es por las implicaciones que tiene a nivel rendimiento y almacenamiento. Sobre todo en el segundo caso, hay que tener en cuenta que si tenemos un alto número de días de retención en tablas (DATA_RETENTION_TIME_IN_DAYS) que se modifican frecuentemente, estaremos archivando muchas versiones de los datos que pueden incrementar considerablemente nuestro almacenamiento.

La principal ventaja es que Snowflake se encarga de todo este complejo mantenimiento siendo la gestión del almacenamiento transparente para el usuario.

En estos casos, para eficientar el almacenamiento es fundamental conocer los tres tipos principales de tablas que pone a nuestra disposición Snowflake, así cómo el concepto de Fail-Safe y Time-Travel:

Time-Travel: Periodo que, en función de la edición de Snowflake, (hasta un día en Standard y hasta 90 días en tablas permanentes a partir de edición Enterprise) permite almacenar todas las versiones por las que pasa una tabla, y habilita funcionalidades cómo poder restaurar datos en cualquier punto dentro de ese periodo, o hacer queries sobre un estado específico de los datos.

Fail-Safe: período de siete días durante el cuál se almacena cada versión de los datos en la que ha expirado su DATA_RETENTION_TIME_IN_DAYS y que permite la restauración de los mismos durante ese periodo pero solamente a través del soporte de Snowflake (Los usuarios no tienen acceso directo al Fail-Safe). Este periodo no es configurable y solamente está disponible en las tablas permanentes, cómo veremos a continuación.

Con estos dos conceptos claros, pasamos a describir los tres tipos principales de tablas en Snowflake:

  • Temporales: Solamente persisten durante la sesión, y no tienen Fail-Safe. Se puede definir Time-Travel de cero o 1 día.
  • Transitorias: A diferencia de las temporales, sí pueden persistir más allá de la sesión, pero solo permiten tener Time-Travel de hasta un día y tampoco incorporan Fail-Safe.
  • Permanentes: Igual que las transitorias, persisten más allá de una única sesión, pero permiten extender el Time-Travel hasta 90 días (siempre y cuándo se esté trabajando en una edición Enterprise o superior) e incorporan de caja el Fail-Safe (No configurable ni removible).

Por la naturaleza de cada una de las tablas, vemos que por ejemplo debemos tener en cuenta que si nuestra tabla se puede ver afectada por continuas operaciones DML de actualización-inserción, en el caso que tengamos una tabla permanente con un alto número de días de Time-Travel, nuestros costes de almacenamiento pueden verse incrementados.

La recomendación general para optimizar el almacenamiento es que se utilicen tablas temporales para tablas que simplemente utilicemos cómo tablas intermedias o staging, las transitorias para tablas permanentes que puedan ser fácilmente reproducibles desde fuera, y las permanentes para tablas críticas que tengan que estar siempre disponibles y que el coste de reprocesamiento en caso de desastre sería elevado.

Aspectos a tener en cuenta respecto al almacenamiento

  • Consultas por columnas no ordenadas en la inserción: Esta forma de particionar proporcional implica que haya solapes de valores en las diferentes microparticiones. En columnas de baja cardinalidad (por ejemplo con 2-3 valores diferentes) si los datos no están ordenados por esa columna y hacemos un filtro exclusivamente por dicha columna, hay que controlar el nivel de podado de microparticiones, porque puede pasar que esos 2-3 valores se encuentren en todas las particiones y que Snowflake no pueda podar ninguna. En estos casos, se recomienda para solucionarlo bien añadir al filtro un campo tipo fecha o numérico por el que estén ordenados los datos, o plantear la posibilidad de añadir una cluster key por dicho campo, que es uno de los servicios de optimización con los que cuenta Snowflake. Otra opción sería crear una vista tanto standard cómo materializada que ordene por ese campo.

    Ejemplo dónde queda evidenciado esto, es, lanzamos una consulta sobre una gran tabla de unos 14.000 millones de filas, cuyos datos están ordenados por fecha y cliente. En esta tabla, queremos consultar los diferentes tipos de envío que se han hecho. Si lanzamos la consulta sin filtro:

Primero vemos que se escanean las 49.448 microparticiones, lo cuál es lógico ya que no hemos incluído filtro alguno. Por otro lado, se escanean 13,58GB de los 770GB que tiene la tabla. Esto se debe a que en la query hemos incluído una única columna, y ya que Snowflake cómo hemos comentado almacena los datos de forma columnar y comprimida, solamente accede a los datos de la columna que consultamos.

Si aplicamos un filtro sobre la columna Call Center, que es un numérico que toma valores entre 1 y 60, y es un campo por el que no se ha ordenado en la inserción de los datos, y buscamos por ejemplo el call center número 20:

select distinct cr_ship_mode_sk from “SNOWFLAKE_SAMPLE_DATA”.”TPCDS_SF100TCL”.”CATALOG_RETURNS” where cr_call_center_sk = 20 

Vemos que efectivamente, apenas se han podado valores: De las 49,448 microparticiones, 49.447 tenían en su rango de call center el 20, con lo cuál ha habido que recorrerlas igualmente.

Sin embargo, si incluímos en el filtro uno de los campos de clusterizado, por ejemplo el código de cliente:

Vemos que sólo se ha recorrido un 10% aprox de las microparticiones, y el tiempo de query ha bajado de 1 minuto 45 segundos a 12 segundos. 

Con esto se puede concluir que el principal factor de rendimiento en las consultas es el número de bytes que tenga que escanear Snowflake el cuál viene principalmente determinado por el número de particiones a escanear, y la cantidad de datos de cada columna, y que si solamente incluimos en el filtro columnas por las que no estén ordenados los datos o no estén incluídos en la cluster key, en tablas de gran tamaño el rendimiento puede verse afectado. Es recomendable incluir en los filtros al menos uno de los campos de ordenación o de las cluster key para que las queries sean eficientes, o de no poder ser así, Snowflake nos proporciona otras alternativas para mejorar el rendimiento cómo las vistas materializadas, el cacheo o el search optimization service.

  • Búsqueda por rangos en las microparticiones: A la hora de podar microparticiones, Snowflake busca en la metadata si el valor buscado está en el rango de valores mínimo-máximo de la columna filtrada en la micropartición. Esto genera una dependencia a la hora de podar valores en base a cómo estén distribuidos dichos rangos en las microparticiones, lo cuál puede afectar a la cantidad de microparticiones podadas cuándo buscamos por columnas por las que no estén ordenados o clusterizados los datos: Por ejemplo, nos podemos encontrar casos dónde busquemos un valor que no existe, pero que por estar dentro del rango de valores en la metadata, obligue a Snowflake a recorrer igualmente todas las microparticiones.

En estos casos, Snowflake dice que en tablas con tamaños por debajo de 1TB la organización automática de datos debe ser suficiente para obtener buen rendimiento en las consultas.

Pruebas con Snowflake para entender cómo funciona el microparticionado y los metadatos asociados a las microparticiones

La tabla que se ha utilizado para estas pruebas contiene 100 millones de registros y seis columnas, dónde los datos se han distribuido en 49 particiones ocupando un total de 708MB (unos 14,5MB de media por micropartición). Los datos están ordenados por un campo de fecha.

Comentar que para estas pruebas, se ha utilizado la herramienta de Profiling de Snowflake, que está disponible desde el historial de queries. Hemos encontrado esta herramienta muy completa e intuitiva, y permite de un solo vistazo encontrar dónde se están generando los cuellos de botella en las queries, todo el plan de ejecución por el que pasa una query, así cómo las filas que salen de cada paso (lo cuál nos permite por ejemplo detectar cosas habituales de mal rendimiento cómo joins explosivos) y las microparticiones que se van podando en cada estado. Gracias a esta herramienta, hemos podido entender qué es lo que pasaba exactamente en cada una de las situaciones que hemos querido investigar y entender la gestión de Snowflake del almacenamiento.

Esta herramienta de profiling está disponible en el menú History de la UI, pinchando en la query que queramos analizar.

El objetivo de estas pruebas es entender la forma en la que Snowflake selecciona las microparticiones a recorrer y cómo de importante es la forma en la que se insertan los datos para mejorar el rendimiento en nuestras consultas, así cómo las columnas por las que se filtre.

En la tabla existe una columna, Call Center, dónde hay diferentes valores entre el 1 y el 60 pero con saltos (no están todos los posibles valores). Si hacemos una búsqueda por un call center específico de los que están:

Apreciamos que sea cuál sea el Call Center que incluyamos en el filtro siempre se recorren todas las microparticiones. La explicación es que Snowflake para determinar las microparticiones a recorrer, mira en la metadata de la columna Call Center si el valor buscado está dentro del rango, y en este caso, dónde los datos están ordenados por fecha, siempre se cumple que el valor está dentro del rango, por lo que tiene que recorrer todas las microparticiones.

Probamos a meter un nuevo registro de un Call Center con ID 11 que se sabe no aparece en los datos. Tras la inserción, el número de microparticiones se mantiene en 49, por lo que Snowflake ha debido generar un nuevo archivo que incluye el nuevo registro, y ha archivado la versión anterior de la micropartición.

Hacemos una búsqueda por ese Call Center, que a priori está en una única micropartición, y al revisar el Profile:

Se aprecia que Snowflake ha tenido que escanear las 49 microparticiones aunque se sabe que el valor 11 está en una micropartición específica. Esto confirma que Snowflake busca en base a rangos de valores por columna, y no conoce los valores específicos de una columna que hay en cada micropartición.

Para evidenciar aún más este hecho, insertamos un nuevo registro de Call Center que esté fuera del posible rango de búsqueda: Call Center con ID 61. Tras la inserción, verificamos que el número de particiones se mantiene, pero cuando se hace una búsqueda por ese valor:

Únicamente ha escaneado una micropartición. Esto se debe a que el 61 es un valor que está fuera del rango de la metadata del resto de las microparticiones, con lo cuál, ha podido saber que el Call Center 61 estaba en una única micropartición.

La siguiente comprobación es ver cómo Snowflake ejecuta la búsqueda de un valor de la columna Call Center que no está en los datos, pero sí en los posibles rangos de valores de la columna en las microparticiones. Por ejemplo, tenemos Call Centers 10, 11 y 13, pero no el 12. Si buscamos por el 12:

Cómo era de esperar, recorre todas las microparticiones, ya que el 12 entra en todos los posibles rangos de valores.

Para terminar de confirmar si Snowflake busca exclusivamente por rangos de valores, se crea una nueva tabla únicamente con los Call Center 1, 10 y 11. Esta nueva tabla tiene 8 microparticiones.

Si buscamos por el Call Center 5 (dentro de rango), recorre las 8 microparticiones aunque el Call Center no exista.

Si buscamos por el Call Center 12, directamente la metadata devuelve que ese Call Center no existe, y por tanto, no recorre ninguna micropartición.

Pero ahora, si buscamos por el valor 11, que recordemos fue una nueva inserción que metimos y justo está en el final del rango, en este caso Snowflake sí es capaz de podar el resto de microparticiones dónde no está el valor:

El motivo está en que se sabe que el resto de microparticiones tienen un rango 1-10, con lo cuál, la única que cumple estar en rango 1-11 es dónde verdaderamente está el valor. Sin embargo, en la otra tabla dónde era altamente probable que todas las microparticiones en la columna Call Center estuviesen en rango 1-60, ahí sí que tuvo que recorrerlas todas para saber dónde estaba el Call Center 11.

Conclusión de las pruebas:

Cuándo tengamos bajo rendimiento en consultas, hay dos indicadores principales a revisar en el profiling: Número de particiones escaneadas y cantidad de datos procesados.

Para mejorar la consulta, el objetivo es reducir el número de ambas: Para recorrer menos particiones hay que añadir filtros por campos en base a los cuáles se estén ordenando los datos (generalmente fechas o id’s numéricos) o replantearnos si ese campo es importante a la hora de filtrar, que los datos estén ordenados por dicho campo. Por supuesto, revisar también si las columnas que utilizamos en la consulta se pueden reducir. 

Si esto no es posible, tendríamos que plantearnos otras estrategias de optimización, cómo clusterizar la tabla en base a ese campo, utilización de cachés, ver si el caso de uso se ajusta a la utilización del search optimization service, o la utilización de vistas materializadas que pueden a su vez estar clusterizadas o no. El detalle de estas estrategias queda fuera del alcance de este artículo.

Principales conclusiones del funcionamiento del almacenamiento en Snowflake

  • El orden de inserción de los datos importa. Es recomendable insertar los datos ordenadamente en base a los filtrados más frecuentes que se vayan a hacer en la explotación.
  • Al almacenar de forma columnar los datos, el solamente seleccionar las columnas necesarias para la consulta reduce el número de bytes escaneados y por tanto el tiempo de resolución de consulta. Es recomendable evitar los SELECT * o añadir columnas innecesarias en las queries.
  • Es muy importante de cara al rendimiento seleccionar el tipo de datos más adecuado para cada columna, ya que Snowflake podrá reducir de manera más eficiente el tamaño de los datos, y esto se traduce en menores tiempos de escaneo, y por tanto de respuestas en las queries.
  • Para que las queries tengan un buen rendimiento, es aconsejable incluir un filtro de la columna por la que estén ordenados-clusterizados los datos y revisar en el profile de la query que tenga un buen porcentaje de poda de particiones.
  • En columnas de cardinalidad muy baja (1-10 valores diferentes), si hacemos búsquedas exclusivamente por ellas, y los datos no están ordenados o clusterizados por estas columnas, puede que no se poden particiones en las búsquedas. Con volúmenes de GB, el recorrer todas las particiones incluso con la talla más pequeña no perjudica el rendimiento y Snowflake maneja perfectamente, pero en volúmenes en el rango de centenas de GB, la diferencia entre tener o no la cluster key para buscar un valor en concreto, sí puede afectar en el número de bytes a escanear y por tanto en los tiempos de respuesta, con lo cuál es importante hacer un estudio de tiempos de consulta, para lo cuál Snowflake nos proporciona una potente herramienta de profiling, que a nosotros particularmente nos ha sido de gran utilidad para poder elaborar este artículo.

Entendiendo cómo Snowflake gestiona el almacenamiento a nivel inserción, actualización y borrado de datos y cómo se gestionan estos datos a la hora de realizar consultas, estaríamos en disposición de dar el siguiente paso que es entender todas las funciones avanzadas que proporciona Snowflake a nivel de optimización, compartición y seguridad-resiliencia en los datos. Éste será el objetivo de siguientes artículos.

Referencias

Documentación oficial de Snowflake https://docs.snowflake.com/en/

Navegación

Introducción

Objetivo

Introducción al almacenamiento

Objetivos del almacenamiento

Principales características del almacenamiento

Metadatos en las microparticiones

Principales características del microparticionamiento

Entendiendo la organización de datos

DML’s en Snowflake

Aspectos a tener en cuenta respecto al almacenamiento

Pruebas con Snowflake

Principales conclusiones

Referencias

Autores

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

Roberto García Parra

Technical Delivery Manager

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Essential features to consider when adopting a cloud paradigm

by

Características esenciales que debemos tener en cuenta al adoptar un paradigma en la nube

Alejandro León

Delivery Manager

El NIST (National Institute of Standards and Technology), habla de las 5 características esenciales para una buena administración e implementación del paradigma en la nube. En este artículo se revisarán estas características en profundidad, ya que son aspectos importantes para tener en cuenta al momento adoptar el cómputo en la nube.

Características esenciales

Existe una variedad de servicios diferentes que se ofrecen bajo la modalidad de cómputo en la nube, y cada uno de los servicios ofrecidos tiene un fin único. Sin embargo, existe una serie de características comunes que define al cómputo en la nube, y que hace posible identificarlo como tal.

Según el NIST, las 5 características esenciales del cómputo en la nube son:

  • Autoservicio bajo demanda
  • Despliegue de infraestructura desde la red
  • Agrupación de recursos
  • Elasticidad
  • Medir un servicio

Para entenderlas mejor, echemos un vistazo al detalle de cada uno de estos puntos.

Autoservicio bajo demanda

En estos casos, cada uno de los usuarios u organizaciones que opta por utilizar alguna de las ofertas de servicios de cómputo en la nube es responsable de la configuración de los recursos y el despliegue de estos.

De esta forma, el usuario final es quien decide que recursos quiere o necesita utilizar y cuál será la capacidad asignada a cada uno de los recursos, y es el mismo usuario quien puede configurar estas opciones desde un centro de administración de dichos recursos.

Despliegue de infraestructura desde la red

Todos los servicios ofrecidos bajo el paradigma de cómputo en la nube deben de ser accesibles a través de internet, de forma que un usuario puede hacer uso de ellos en cualquier momento de acuerdo con sus necesidades, y, muy importante desde cualquier parte del mundo, sin necesidad de tener acceso físico a la infraestructura que brinda soporte.

Agrupación de recursos (Disposición de infraestructura)

Cada proveedor de servicios de cómputo en la nube mantiene un gran número de recursos de hardware disponibles para sus clientes. Cada que uno de ellos realiza una solicitud y el proveedor asigna los recursos mediante un modelo de múltiples tenencias. Esto, en esencia significa que todos sus clientes están haciendo uso de la una infraestructura compartida. Además, todos los recursos disponibles se agrupan por cliente, al cual se le asigna un acceso único para cada uno de ellos. De esta forma, cada cliente solo puede ver sus recursos y no tiene conocimiento de los recursos asignados a otros clientes.

Elasticidad

Sin importar cual sea el proveedor de cómputo en la nube, el usuario cuenta con una flexibilidad en el despliegue de los recursos. Esta flexibilidad es una abstracción del despliegue de la infraestructura física que el proveedor de servicios debe realizar para satisfacer las necesidades del cliente.

La infraestructura que soporta los centros de datos de los proveedores de los servicios generalmente hace uso de técnicas de cómputo distribuido o virtualización, que son transparentes para el usuario final.

De esta forma, el usuario tiene el control sobre los recursos que necesita, por lo que puede realizar peticiones para aumentar o disminuir las cantidades y/o capacidades de los recursos contratados, y el proveedor debe ser el encargado de administrar ese cambio en su infraestructura de forma transparente y sencilla para dar una respuesta rápida y satisfactoria a las solicitudes de sus usuarios.

Maneras de medir el servicio

Los proveedores de servicios de cómputo en la nube establecen controles para poder realizar una medición de los servicios utilizados por los usuarios. Dependiendo del tipo de recurso ofrecido, se acuerda y establece con el usuario un método de medición de uso de este, por lo general es por uso, o por servicio.

Por ejemplo, en un servicio de almacenamiento de datos en la nube el proveedor puede establecer un precio fijo para los archivos almacenados, o por el tiempo de almacenamiento, o por el espacio de almacenamiento utilizando, o una combinación de 3 factores.

 

Conclusiones

El cómputo en la nube representa una evolución con respecto a un modelo de cómputo tradicional, en el cual particulares u organizaciones necesitan adquirir todos los elementos necesarios para construir una infraestructura tecnológica capaz de soportar sus operaciones o nuevos proyectos.

La oferta de servicios de cómputo en la nube hace más sencillo la implementación de sistemas de información, sin la necesidad de contar con espacio físico para la instalación de equipos físicos, y con un potencial ahorro al hacer uso de modelos de cobro como son las suscripciones de pago por uso.

Es importante subrayar que el cómputo en la nube no es un reemplazo directo para la implementación de un centro de datos en una organización, sino que representa una alternativa con un diferente modo de operación y un potencial ahorro en costos. Queda como responsabilidad de las organizaciones realizar un estudio para verificar la factibilidad en la contratación de servicios de cómputo en la nube y el modelo de servicios requerido según sus necesidades.

Alejandro León

Delivery Manager

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Data governance in the Contact Center services sector

by

Gobierno del dato en el sector de los servicios de Contact Center

Bluetab

Nuestro cliente es una compañía multinacional de origen francés, con más de 44 años de experiencia en servicios de Contact Center (Business Process Outsourcing o BPO). Con más de 380 Mil empleados, y trabajando en más de 170 países y 260 lenguas.

El sector de los servicios de Contact Center es un mercado en continua transformación con unas expectativas de crecimiento, según la generalidad de los analistas, por encima del 13-15%. Y que está experimentando dos grandes tendencias: el increíble crecimiento de las plataformas de datos de cliente y la aplicación de la inteligencia artificial en servicios omnicanal de atención al cliente.

En esa coyuntura, nuestro cliente está transformando sus capacidades para asegurar que la explotación de sus datos sea eficiente y pueda ofrecer valores diferenciales a sus clientes. Y, para ello, la definición de políticas y de un modelo de gobierno de datos adaptados a sus necesidades es hoy crítico.

Bluetab tiene una amplia experiencia en proyectos de implantación de políticas y modelos de gobierno de datos, por lo que aplicando las buenas prácticas logró definir para el cliente un plan de 12 semanas de trabajo que aseguró el establecimiento de las bases fundamentales de dichas políticas de gobierno, y la implantación de una herramienta como Truedat, que asegura el soporte de la gestión automatizada de la implantación del modelo de gobierno.

De esta forma, nuestro cliente ha realizado la puesta en marcha de su primer caso de uso end-to-end, lo que le ha permitido, además de mostrar a negocio de forma tangible el valor del proyecto y lograr definir roles y responsabilidades para la gestión de los datos, estar preparado para el despliegue incremental y controlado de otros casos de uso en su ecosistema con sus capacidades y sin depender de terceros si no lo estima adecuado.

Bluetab

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Data Mesh

by

Sí, Data Mesh es realmente transformacional, pero…
¿quién me ayuda a implantarlo?

En las últimas décadas, las compañías han tratado de generar o determinar un lugar que les permita mantener, controlar y acceder a datos analíticos de su empresa y del mercado; esto con el objetivo de mejorar su negocio.

Un ejemplo típico de ello es la utilización datos del comportamiento de los clientes y el uso de sus productos para la obtención de conocimientos claros y prácticos que les permitan administrar más eficientemente el negocio, así como mejorar y crear nuevos productos.

Sin embargo, al tratar de generar estas entradas de información, los profesionales dentro de la industria se enfrentan a varios retos que pueden llegar a crear mucha frustración y caminos cerrados. Tecnologías como el Big Data o los Data Lakes han ido dando soluciones conforme se evolucionaban los modelos.

Desde mayo de 2019 con la publicación de Zhamak Dehghani, estamos viendo una nueva evolución de las prácticas para diseñar arquitecturas de datos que están cambiando estos modelos del mundo del Big Data y del Data Lake.

Hasta ahora las clásicas tres capas de ingesta, procesamiento y publicación resultaban suficientemente eficientes. Pero esa eficiencia basada en la centralización y el gobierno, hoy genera silos de conocimiento, cuellos de botella en las organizaciones complejas, falta de escalabilidad en la agregación de características y en definitiva desconexión entre los originadores de la información y los consumidores.

El enfoque de Data Mesh es más que una metodología, un paradigma para la integración de una arquitectura de datos que descentraliza la propiedad de los dominios de datos, y al mismo tiempo define productos de datos analíticos, en un entorno que equilibra le gestión gobernada y la autonomía de los citados dominios. El paradigma Data Mesh, que hereda conceptos de la filosofía DDD (Data Driven Design), identifica cuatro conceptos como base de su modelo:

  • Los dominios como dueños de los datos, dominios cuya concepción inicial puede aproximarse a los dominios de negocio, y es donde se definen las entidades de datos y las relaciones con otros dominios para su consumo.
  • Los datos como producto, y como tal, pasan a ser susceptibles de proveer niveles de servicio. Pasando la responsabilidad de los mismo de la plataforma al equipo responsable del dominio.
  • La plataforma como autoservicio, automatizada y asegurando la independencia y la autonomía de cada dominio.
  • El gobierno federado, que asegure las decisiones próximas a los dominios pero que a la vez establezca las reglas de mínimos que aseguren la interoperabilidad entre ellos.

Este nuevo modelo supone además un cambio organizacional para asegurar su éxito. Los dominios además de dueños de sus productos de datos deben ser autónomos a la hora de desarrollar nuevos productos tanto para consumo propio como de otros dominios. Y, además, deben asegurar el consumo y el gobierno de los productos de datos. Y para ello deben contar con el conocimiento necesario de las plataformas, de forma que se asegure su autonomía, descargando del equipo de plataforma ciertas responsabilidades de gestión de dichos productos de datos.

Estos cambios a modelos más ágiles, pero a la vez de responsabilidades distribuidas, son fundamentalmente culturales, y requieren contar con equipos maduros capaces de asumir de forma autónoma la nueva distribución de responsabilidades, los nuevos procesos y su gobierno.

Vale, pero ¿por dónde empiezo?

Hoy nuestros clientes se enfrentan aún a un modelo en proceso de maduración en el mercado que genera muchas cuestiones de enfoque inicial.  Pese a que parece claro que ese equilibrio entre gobernabilidad y autonomía puede aportar eficiencias, el modelo metodológico de Data Mesh es aún emergente, y por descontado requiere del soporte de equipos senior técnicos y de negocio con alto nivel de madurez, capaces de tomar decisiones ágiles a lo largo del proceso, que no puede entenderse como puntual, sino de medio o largo plazo.

Bluetab a lo largo de los proyectos en entornos de clientes, ha desarrollado una metodología basada en experiencias de implantación de modelos de gobierno que aseguran un enfoque adecuado de este proceso de transformación. Una metodología muy operativa enfocada, más allá de un trabajo teórico, a la aplicación práctica de los modelos a los diferentes ecosistemas de nuestros clientes.

Esto se lleva a cabo estableciendo primero, casos de uso controlados y relevantes que permitan la visión desde la generación hasta el consumo de la información requerida por negocio, posteriormente, definiendo el plan de despliegue a los demás casos de uso de la organización y, finalmente y en paralelo, actuando sobre los requerimientos del cambio organizacional con comunicación y acciones específicas que habiliten la gestión del cambio.

Esta metodología inicia con el apoyo a la definición del contexto de dominios y la identificación de un primer caso de uso (MVP) que permita la visión end-to-end de los requerimientos a lo largo de los cuatro elementos, los citados dominios, los productos de datos y sus interdependencias, el modelo de autoservicio y las arquitecturas habilitadoras, y los requisitos de un gobierno no limitativo.

Una vez establecido dicho MVP e implantado, se genera el entendimiento global necesario para la definición de un plan de despliegue capaz de escalar a todo el ecosistema con éxito. Un plan que mediante métodos ágiles irá adaptándose a las diferentes particularidades y al propio cambio de requerimientos de negocio en el tiempo.

Pero el valor de nuestra aportación está en que, a lo largo de nuestros proyectos, hemos desarrollado herramientas prácticas de automatización para la implantación práctica de los modelos, aceleradores que Bluetab pone a disposición de sus clientes y que aseguran la optimización de los tiempos en el proceso de despliegue y su posterior evolución, y el apoyo a los clientes para una definición del modelo adecuado a su ecosistema y adaptada a sus requerimientos de negocio. Todo ello soportado por una estrategia de medición del valor aportado mediante datos objetivados KPIs.

En la definición de un ecosistema orientado a dominios es crucial el entendimiento del negocio y de la realidad de los consumos de datos dentro de cada una de las estructuras organizativas. A partir de ahí se puede establecer el debate para una definición de dominios consistente, acordada y de largo plazo.

Una herramienta como nuestra Matriz de Convergencia, donde se cruzan consumos, proyectos, orígenes, etc., permite una evaluación objetiva y profundizar en un mismo entendimiento y nomenclatura común en la organización. A partir de ahí, la definición del primer caso de uso y la priorización en el plan de escalado posterior se realiza de forma consistente.

En la generación de productos de datos, hay varios factores relevantes además del entendimiento y los modelos del consumo seguramente mediante API´s y una estrategia de disponibilización con la definición de mínimos requeribles. Uno de esos factores es la evaluación de la aportación del valor de dichos productos, y otro la estrategia de comunicación y comunicación/disponibilización a los demás dominios.

Para todo ello nuestro asset de gobierno del dato, Truedat, posibilita una solución que cubre desde el metadatado, a la generación de un Marketplace común, asegurando el control de los mínimos de gestión.

En la gestión del gobierno federado y el equilibrio entre el control y la autonomía de los dominios, nuestra Matriz de Madurez es fundamental para la evaluación del nivel de dicha madurez y el establecimiento del programa que cubra el gap de requerimientos. Y una vez establecido el programa, esta misma suite de servicios, Truedat, aporta capacidades adecuadas de calidad o trazabilidad que aseguran la implementación de las reglas que definan los propietarios en los dominios y la gestión técnica del end-to-end del ciclo de vida del dato.

Y finalmente en el desarrollo de una plataforma automatizada y enfocada al autoservicio de los dominios, nuestros modelos de arquitecturas, así como nuestras herramientas de despliegue automático de servicios y nuestros modelos de despliegue de estrategias Devops y MLops, aseguran una implantación optimizada de la estrategia y un time-to-market eficiente en su evolución de requerimientos.

La implantación de una estrategia Data Mesh genera aún muchas dudas sobre cómo abordarla en entornos complejos en el que coexisten diferentes arquitecturas, modelos de datos y requerimientos de consumo. Nuestro enfoque metodológico, más dirigido al desarrollo práctico de la puesta en marcha de cada uno de los pilares de la estrategia, puede asegurarte un despliegue ágil y en unos tiempos asumibles. De esta forma tanto las áreas técnicas como negocio pueden obtener el retorno de valor en los plazos requeridos.    

Síguenos y en próximos artículos entraremos en mayor detalle sobre cómo aterrizar de forma práctica y eficiente en este nuevo paradigma Data Mesh.

Autores

Liliana Palestina

CTO

Alvar Noe Arellanos

Business & IT Strategy Professional

Juan Manuel Sanchez

Data Strategy

Armando Camargo

Data Governance Manager

Jesus Saavedra

BI Manager

José Carranceja

COO

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Some of the capabilities of Matillion ETL on Google Cloud

by

Algunas de las capacidades de Matillion ETL en Google Cloud

Duvan Duque

Data Engineer | Google Cloud Associate Cloud Engineer

Matilion ETL es un producto que nos permite recopilar datos de distintas fuentes y estructurarlos actualmente cuenta con versiones para Snowflake, Delta Lake en Databricks, Amazon Redshift, Azure Synapse, Google BigQuery siendo esta última en la que vamos a profundizar.

En Google cloud se cuenta con 4 opciones para implementar Matillion las cuales son:

Matillion ETL for BigQuery – Cluster:

  • 12 usuarios concurrentes , 36 entornos y autobalanceo zonal para satisfacer la demanda de forma constante

Matillion ETL for BigQuery – Extra Large:

  • 12 usuarios concurrentes y 36 entornos

Matillion ETL for BigQuery – Large:

  • 5 usuarios concurrentes y 15 entornos

Matillion ETL for BigQuery – Medium:

  • 2 usuarios concurrentes y 6 entornos

Matillion ETL for Snowflake:

  • Esta opción está dirigida a Snowflake

El servicio se encuentra ubicado en el Marketplace de Google De ahora en adelante se hablará de la versión médium ya en ese momento las necesidades del proyecto no se necesitaban más recursos.

Cada una de las versiones tiene un costo diferente la versión médium tiene un precio estimado sin descuentos de 1437.05 USD al mes teniendo en cuenta que la instancia se encuentre encendida durante 30 días 24 horas y la facturación mínima es por 1 minuto.

Una vez lanzado el servicio desde Marketplace se creará una instancia en compute engine la cual cuenta con una dirección IP estática mediante la cual se puede acceder al servicio

Una vez dentro se debe establecer estructura de proyectos los cuales pueden contener carpetas para organizar el flujo de trabajo los cuales van a contener dos tipos de Jobs orquestación y transformación. los cuales se pueden crear realizando un clic derecho sobre las carpetas.

Cada de los jobs cuenta con distintos componentes y capacidades para el caso del job de orquestación son los siguientes:


Componentes de carga

Estos componentes son los que extraen información de las diversas fuentes para llevarla a Bigquery entre ellos tuve la oportunidad de usar integraciones con Hubspot, APIs, Cloud storage y Facebook. siendo estos solo una pequeña porción de la lista de integraciones disponibles

Componentes de descarga

Los cuales principalmente tienen como fuente una tabla de Bigquery y la llevan a otro destino como Cloud Storage

Componentes DDL

Los cuales permiten manipular las tablas de Bigquery

Componentes de flujo

Los cuales permiten realizar operaciones con los otros componentes

Componentes de iteración

Los cuales permiten crear ciclos de un componente

Componentes de código

Los cuales permiten ejecutar códigos como Bash, Jython, Python 2 y Python 3

Componentes de transformación

Los cuales permiten ejecutar otros Jobs de orquestación y transformación

los nombrados anteriormente solo son algunos de los que tuve la oportunidad de trabajar ya que eran los requeridos para alcanzar las necesidades del proyecto y cabe mencionar que la herramienta cuenta con más.
Los jobs tienen la capacidad de encadenar y ejecutar distintos componentes.

Es posible encadenar y establecer condiciones en un Job o múltiples para su ejecución dentro de otro Job

se cuenta con la capacidad agendar la ejecución de los Jobs dentro del propio Matillion

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

Duvan Duque

Data Engineer | Google Cloud Associate Cloud Engineer

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2022 Bluetab Solutions Group, SL. All rights reserved.