Dirección General de Sistemas de Información y Comunicaciones

Área de Gobernanza y Calidad

Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Resumen de normativas

A continuación se recoge en una tabla un resumen de las normativas del presente documento:

Esta tabla es un documento vivo, es decir, se irá actualizando conforme se vayan añadiendo o modificando las normativas.

Introducción

Todos los proyectos desarrollados para la STIC deben construirse y desarrollarse en base a los requisitos técnicos y tecnológicos que la infraestructura del SAS soporta. En caso contrario deberá especificarse de forma clara y concisa durante la reunión de lanzamiento del proyecto. A continuación se detalla el conjunto de requisitos a contemplar por parte de los proveedores.

Criterios de subida a producción

En esta sección se recogen los requisitos mínimos necesarios y los pasos a seguir para asegurar su cumplimiento a la hora de pasar del entorno preproductivo al de producción. En concreto, este documento abarca todos aquellos elementos que se pueden dar de alta en la herramienta de Big Data Stratio. Mediante el cumplimiento de esta normativa, se consigue disponer de un entorno productivo estandarizado, de fácil entendimiento y dispuesto en todo momento a ser explotado, cumpliendo los estándares mínimos en materia de calidad establecidos.

Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.

Normativa para el paso a producción

Para que un conjunto de activos sea cargado en un entorno de producción, deberá cumplir con una serie de requisitos en función del activo que se desee promocionar. Estos requisitos quedan recogidos en el documento específico para ello, el cual deberá ser cumplimentado por el solicitante y validado por el responsable acordado durante el proceso definido para la promoción entre entornos.

A continuación, se listan a modo resumen los diferentes requisitos que han de tenerse en cuenta para verificar que el activo cumple con todas las condiciones establecidas para su promoción. En función del activo que se desee promocionar, determinados requisitos serán de carácter obligatorio.

• N-01. Se cumple con la estructura del activo establecida por la organización.

• N-02. Se ha definido el propietario del dato.

• N-03. Se ha definido el administrador del dato.

• N-04. El nombre cumple con la normativa establecida por la organización.

• N-05. El campo de descripción del activo se encuentra completo.

• N-06. Los permisos de acceso y consumo han sido definidos y validados.

• N-07. Contiene los metadatos mínimos asociados.

• N-08. El formato de los metadatos asociados es el correcto.

• N-09. La sensibilidad de la información ha sido definida y validada.

• N-10. Las reglas de calidad han sido aprobadas por el responsable correspondiente.

• N-11. Se ha definido y validado el umbral necesario para las diferentes reglas de calidad.

• N-12. Los resultados de los perfilados de datos son tratados correctamente

• N-13. La frecuencia de ejecución de las reglas de calidad ha sido definida y validada por el responsable correspondiente.

• N-14. La tipología de relaciones utilizada está dentro de las establecidas por la organización.

• N-15. La tipología de activos de negocio utilizados se recoge en las acordadas por la organización.

• N-16. Los términos de negocio han sido definidos y validados por el responsable acordado.

• N-17. El linaje de los datos ha sido identificado y definido por el responsable correspondiente.
• N-18. Se cumple con los aspectos de la normativa definidos para los ficheros parquet.
• N-19. Se usa la herramienta de Airflow según las directrices recogidas en la normativa.
• N-20. Se cumple con la normativa definida sobre el uso de la herramienta de Postgres.
• N-21. Se parametrizan correctamente las variables correspondientes en las llamadas externas de los flujos de Rocket.
• N-22. Las buenas prácticas definidas para los desarrollos de Rocket se están llevando a cabo.

Normativa para el control de versiones

En este apartado se exponen las normas de obligado cumplimiento para el cambio de versiones del entorno productivo.

• Si durante el proceso de definición e implantación de una nueva versión de asset se requiere dar de alta otro activo además del antiguo, este debe implementarse en producción de forma paralela y coordinada con el anterior. De esta forma, coexisten los dos activos durante el tiempo sea necesario, siempre dentro de los tiempos máximos establecidos de forma previa y cumpliendo con la normativa de nombres establecida en secciones siguientes.
• Mientras que para el nuevo activo no se haya realizado el seguimiento necesario para asegurar la correcta definición del mismo, se puede usar el activo anterior para consultar y obtener la información de este en caso de necesidad.

Normativa para definición de linaje

Este concepto se refiere al registro y seguimiento detallado de la procedencia y los cambios que experimentan los datos a lo largo de su ciclo de vida. Es fundamental para garantizar la transparencia, conocer la trazabilidad y evaluar la confiabilidad de los datos en una organización. En este contexto, es imperativo la añadidura de unos metadatos, tanto a Business Views como a Technicals Views que recojan la información relacionada con el linaje. Concretamente, estos metadatos han sido creados como atributos personalizados en la herramienta (Governance) y cumpliendo la normativa de nomenclatura expuesta en siguientes apartados.

Para recoger el linaje de los datos, se necesitan dos atributos personalizados descritos a continuación, que deberán completarse para todos los datos que se suban a producción:

• Atributo atr_origen. Este atributo indica de dónde procede una Business View o una Technical View. Este atributo ha de asignarse desde el asset destino (Technical View, Business View) hacia el asset origen (asset del data dictionary), y dado que su objetivo crea un vínculo entre assets, es una atributo personalizado de tipo relación.
• Atributo atr_transformacion. Este atributo da información acerca de las posibles transformaciones que sufran las Business Views o Technical Views. Puesto que ha de ser un atributo de libre escritura para poder reflejar cada casuística de transformación que pueda darse, es creado como atributo de tipo string.

A través de estos metadatos, se construye un cuadro de mando en Discovery que refleja el linaje de Technicals y Business Views:

Circuito de subida a producción

A continuación, se muestra el flujograma del circuito de subida a producción de una nueva Mejora en el entorno Big Data Stratio.

En este proceso se identifican tres tipos de roles en los cuales pueden existir diferentes grupos:

• Expertos de Gobierno. Este rol se compone exclusivamente por profesionales de la OTBI, encargados de validar las mejoras y ejecutar las promociones.
• Usuario solicitante. Este rol es quien inicia el circuito y puede formar parte de la OTBI, STAGI, un proveedor interno o externo e incluso por instituciones externas como pueden ser Hospitales y Universidades.
• Desarrolladores. Hace referencia a aquellos profesionales encargados de ejecutar las acciones técnicas pertinentes, pueden ser los proveedores externos o internos.

Actualmente, se ha identificado que una PL debe contener la siguiente información relacionada con el asset a promocionar:

1. Herramienta de Stratio (Rocket, Discovery, Governance o GoSec) al que pertenece.
2. Tipo de asset.
3. Nombre del asset.
4. Urgencia de la promoción.
5. Motivo de la urgencia.
6. Otros elementos relacionados con dicho asset que se quiera promocionar. Por ejemplo relaciones entre colecciones.
7. URL del asset a promocionar.
8. Checklist de requisitos para el paso a producción.

Toda esta información debe ser la que presenta el asset en el entorno de preproducción. Para su validación respecto a la normativa, se deberán usar los Cuadros de Mando de promociones y el Borrador PID.

Para la creación de una PL, se debe considerar el flujo normal de creación de PLs, por lo que se debe tener presente que este paso abarca la creación de una mejora (por parte del Usuario solicitante), la creación de la versión (por parte de la OTBI) y la creación de la SVE (por parte de los Desarrolladores). Una vez creado todo lo anterior, se procederá a la creación de la PL.

Además, hay que tener en cuenta que para nombrar los workflows en Rocket para la promoción de los assets correspondientes, se debe usar letras minúsculas y espacios, incluyendo el tipo de promoción y el número de la PL correspondiente. Ejemplo: bigusu19 promocion devpre.

Requisitos mínimos de metadatos

En esta sección se establecen los metadatos mínimos y recomendados que deben ir asociados a cada tipo de asset dentro de la plataforma Big Data para que estos se promocionen desde el entorno de preproducción al de producción. Se entiende por assets a todos aquellos elementos que pueden ser creados dentro de la plataforma Big Data. En el caso del SAS la solución es Stratio, por lo que la definición de estos metadatos se realiza en función de los elementos que se pueden crear en los diferentes módulos que la componen. Es por ello que esta sección se subdivide en los tres módulos principales de Stratio, estableciendo para ellos un conjunto de metadatos comunes a todos los tipos de assets del módulo así como los específicos de cada uno de ellos.

Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.

Governance

Metadatos comunes

A continuación, se presenta una tabla con los metadatos que son comunes a todos los assets que se encuentran en la herramienta de Governance. Algunos de ellos se encuentran establecidos en el activo de forma automática por la herramienta. En aquellos casos en los que el metadato no se grabe de automáticamente por la herramienta, se deben establecer mediante la creación de los atributos adicionales que sean necesarios.

Los assets que se generan automáticamente en la herramienta a partir de las bases de datos orígenes (Data Dictionary) son muy numerosos y, por tanto,  no es necesario generar los metadatos de descripción, estado, obsoleto. No obstante, para todos aquellos activos que se vayan generando con el uso de la herramienta sí deben presentar de forma obligatoria en el entorno de producción los metadatos marcados con dicha etiqueta.

Metadatos específicos

En este apartado, se especifican los metadatos que son únicos de cada tipo de activo presentes en la herramienta. Es decir, cada asset debe presentar tanto los metadatos comunes como los definidos en este apartado que se encuentren categorizados como obligatorios.

Colecciones

A continuación, se muestra una tabla con los metadatos exclusivo del asset de colecciones.

Metadatos de los procesos de ingesta.

Además, existe un conjunto de metadatos asociados a los procesos de ingestas.

Todos los metadatos de este tipo comienzan con los caracteres "dlc". 

Technical Views

En la siguiente tabla se presenta el listado de los metadatos únicos que deben presentar las vistas técnicas de una colección determinada.

Dentro de las Technical Views, a nivel de trabla existen unos atributos que son propios de la base de datos origen en la que se encuentran almacenados dichos datos y también otros metadatos que facilitan la parametrización y el trabajo con los procesos de ingesta. Para facilitar la lectura de dichos metadatos, se dividen en las dos tablas siguientes.

Metadatos relacionados con la base de datos

Todos los metadatos de este tipo comienzan con los caracteres "bdl".

Metadatos relacionados con los procesos de ingesta

Todos los metadatos de este tipo comienzan con los caracteres "dlc".

Metadatos de las columnas de las Technical Views

Para las columnas que conforman las tablas dentro de la vista técnica, existen una serie de metadatos que son exclusivos de ellos. En la siguiente tabla, se muestran dichos metadatos.

Business View

A continuación, se presenta una tabla con los metadatos específicos para las vistas de negocio que componen una colección determinada.

Reglas de calidad

En la siguiente tabla se muestran los metadatos específicos de las reglas de calidad tanto genéricas como específicas.

(*) El metadato carácter se creará o no a todas las reglas de calidad ya definidas en la herramienta en función al volumen de estas y el coste de recursos de dichas definiciones. Cualquier regla de calidad nueva que se cree deberá contener este metadato.

Ontologías

A continuación, se muestran los metadatos que son exclusivos de los elementos que componen una ontología.

Communities

A continuación, se muestran en una tabla los metadatos específicos de los assets de las comunidades que componen el glosario de negocio.

Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, en el caso de las comunidades este metadato no es intrínseco en la herramienta y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.

Domains    

En la siguiente tabla se muestran los metadatos específicos de los assets de los dominios que componen un dominio concreto dentro del glosario de negocio que se encuentra en la plataforma de Stratio.

Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, al igual que en el caso de las comunidades, este metadato no es intrínseco en la herramienta para los dominios y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.

Business terms/rules

En este apartado se agrupan en una tabla los metadatos específicos tanto de los términos como de las reglas de negocio que componen un dominio determinado.

Rocket

Esta sección recoge la normativa aplicable para la gestión del módulo de Rocket de la herramienta Stratio, y al igual que en Governance, se distinguen dos grandes bloques para los metadatos. Por un lado, aquellos metadatos comunes a cualquier tipo de asset y, por otro lado, los metadatos específicos para cada uno de ellos.

Cabe destacar que, en Rocket, no se cuenta con la posibilidad de añadir metadatado adicional, al contrario que en Governance. 

Metadatos Comunes

Existe un conjunto de metadatos que se repiten a lo largo de todos los assets de la herramienta. Estos se generan automáticamente al crear el asset en cuestión, no obstante, el metadato “descripción” se debe rellenar manualmente de forma obligatoria.

Además, dentro del metadato de descripción, se deberán añadir los datos mostrados en la siguiente tabla. Estos se indicarán con el nombre mostrado en la tabla seguido de “: “, separándose entre sí con el carácter “; “.

Es decir, una descripción genérica tendrá la siguiente apariencia:

<<"Descripcion: Primera etapa del proceso de carga de usuario"; "Creacion: 01/10/2023"; "Responsable: Juan Antonio González Pérez">>.

Nombramiento de assets

En esta sección se establecen las normas que deben seguirse para nombrar los assets que se creen dentro de la plataforma Big Data. Estas normas están enfocadas a los assets que componen la solución Stratio implantada en el SAS, encontrándose divididos en función del módulo al que pertenecen.

A su vez, se definen un conjunto de buenas prácticas para que sirvan como guía para cualquier usuario que quiera cualquier elemento de forma general. 

Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.

Buenas prácticas

A continuación, se expone un listado de las buenas prácticas generales que deben seguirse para el nombramiento de cualquier asset que se desee dar de alta en la plataforma Big Data.

• La longitud de los nombres no debe superar el tamaño máximo que permite la herramienta, pero siempre con un límite máximo de 30 caracteres.
• Los nombres han de ser claros y descriptivos, de forma que se entienda el contexto del activo con facilidad y, al mismo tiempo, sean lo más cortos posibles.
• Solo se deben emplear caracteres alfanuméricos y barra baja, evitando así el uso de otro tipo de carácter especial.
• Escribir todos los caracteres alfanuméricos del nombre del asset en minúsculas.
• Los caracteres alfanuméricos han de escribirse en español siempre que sea posible y sin usar la letra “ñ”, escribiendo en su lugar “ny”.
  Por ejemplo: año_nacimiento  → anyo_nacimiento

• Usar barra baja ( _ ) para separar identificadores dentro del nombre.
• Cuando la fecha del asset se deba incluir en el propio nombre, debe aparecer al principio y seguir el formato de fecha recomendada por Oracle sin separaciones: YYYYMMDD y YYYYMMDD-24HHMMSS en el caso de ser necesario las horas, minutos, y segundos.
  Por ejemplo: 20220518-140847

• En caso de necesitar un control de las versiones y revisiones del asset, este debe incluirse al final del nombre, separado por una barra baja. El formato tendrá la estructura XXrYY, donde XX e YY son dos números de dos dígitos que indican la versión y revisión del asset respectivamente. La letra r hace referencia a la release de la normativa. Se entiende por revisión cuando se realiza una pequeña modificación en el activo en cuestión sin que los procesos en los que está involucrado se vean muy afectados. Al contrario, un cambio de versión tiene lugar cuando la modificación del activo es más profunda, rompiéndose el modelo o definición de este y afectando en mayor medida a los procesos que lo rodean.
  Por ejemplo, nombre_asset_02r01

• El nombre de los assets obsoletos y/o que se encuentren en desuso pero que se requieren conservar debe comenzar con los caracteres "_OLD_". Estos assets solo se deben encontrar en entornos de pruebas o desarrollo, nunca en el productivo.
• El nombre del asset debe ser autocontenido y autodescriptivo, es decir, su comprensión no debe depender del contexto de la herramienta.
• En caso de necesitar añadir una secuencia numérica, se debe intentar estimar cuál va a ser la cantidad total de elementos que van a ser nombrados. Por ejemplo, si el máximo es 999, entonces, la secuencia numérica empezaría por 001, 002, 003…
• Se debe evitar, en todo momento, incluir información sensible en el nombre de los activos.
• Para aquellos assets que dispongan de carácter técnico o de negocio, se deberá de indicar en el nombre esta misma característica, tal y como se establece en el presente documento.
• Cuando el asset se está implementando en un entorno de desarrollo, debe contener el prefijo “dev”. Este prefijo se elimina de forma automática en la plataforma cuando se pasa a un entorno preproductivo y productivo.

Como añadido a todas estas buenas prácticas, es recomendable disponer de una tabla con todas las abreviaturas que se van a usar en los diferentes assets. En dicha tabla, se deben considerar, también, todos los ámbitos y subámbitos de información a los que pertenezcan los diferentes conjuntos de datos. De esta forma, se consigue que todos los usuarios miembros de la organización puedan acceder con facilidad a un determinado asset, comprendiendo sin dificultades el contexto de este. 

Estructura general de nombres

De forma general, se establece que el nombre de un asset contiene una serie de elementos comunes, los cuales se listan a continuación y en el orden en el que aparecen dentro del nombre.

• • Prefijo _OLD_ que indica que el asset se encuentra obsoleto.
  • Prefijo dev para indicar que el asset está definido en un entorno de desarrollo. Es obligatorio cuando se encuentra en el entorno de desarrollo, pero no debe ponerse para entornos preproductivos y productivos.
  • Fecha de creación del activo.
  • Abreviatura que indicará a qué elemento de la herramienta Stratio pertenece el activo concreto. Este valor aparece indicado en los apartados para cada asset en concreto.
  • Tipo de elemento específico que pueden presentar los diferentes assets de forma independiente. Esta parte del nombre es obligatoria en aquellos activos que presenten distinción de tipos.
  • Descripción que dota de contexto al nombre del activo.
  • Numeración correspondiente al activo en caso de ser necesaria.
  • Versionado del documento, compuesto por un conjunto de dígitos que indican el versionado y la revisión del asset respectivamente.

A continuación, se presenta el orden de los elementos comunes que pueden aparecer en el nombre de un asset.

Donde ZZ es una secuencia numérica ilustrativa de dos dígitos.

Es posible que para un asset en concreto sea necesario añadir una descripción extra a la estructura general aquí presentada. Cada una de estas particularidades se detallan en los apartados de los assets concretos en los que aparecen. Un ejemplo de esto es el carácter técnico o de negocio que presenta una regla de calidad.

Governance

Reglas de calidad

Toda regla de calidad empezará con los caracteres “rc” (regla calidad). El siguiente término indica el carácter técnico o de negocio de la propia regla de calidad, por lo tanto, debe presentar uno de los dos valores siguientes:

• t.  Se refiere a una regla de calidad técnica.
• n.  Se refiere a una regla de calidad de negocio.

Los siguientes elementos que lo componen constituirán la descripción del contexto de la regla de calidad. Esta descripción cambia en función de la información a la que se le aplica la regla de calidad. A continuación, se indica el tipo de regla de calidad, la cual puede tomar cinco valores diferentes, que se listan a continuación.

• com.  Se refiere a las reglas de calidad de completitud.
• act.  Aquellas reglas de calidad que miden la actualidad de los datos.
• con.  Se refiere a aquellas reglas relacionadas con la consistencia de los datos.
• pre.  Esta abreviatura se refiere a aquellas reglas de calidad que calculan la precisión de la información.
• uni.  Aquellas reglas de calidad encargadas de medir la unicidad en un determinado conjunto de datos.
• for. Indica que la regla de calidad comprueba el formato de los datos a los que se aplica.

Seguidamente, se indica si la regla de calidad es planificada o proactiva.

• pr. Indica que la regla de calidad es de tipo proactivo.
• pl. Se refiere a que la regla de calidad es de tipo planificado.

Además, se indica qué se hace con los datos que no cumplen la regla de calidad. Existen tres valores distintos.

• pt. Indica que la regla de calidad no realiza ninguna acción sobre los datos (pass through).
• mf. Establece que la regla de calidad mueve los datos erróneos a otra tabla (move to failed).
• au. Se refiere a que la regla de calidad audita los datos erróneos (audit QR).

Finalmente, se indicará una breve descripción que contextualice el tipo de dato al que se está aplicando dicha regla.

Entonces, un ejemplo de regla de calidad técnica presentará la siguiente estructura:

rc_[t/n]_[com/act/con/pre/uni/for]_[pr/pl]_[pt/mf/au][Descripción breve]

Por ejemplo: rc_n_uni_pr_mf_dni_paciente

Technical Views

Para nombrar las diferentes Technical Views, es necesario tener en cuenta las diferentes tablas que la van a constituir y, a partir de las mismas, constituir un nombre que permita conocer sin ambigüedades toda la información que comprende el asset.

Siempre que la cantidad total de tablas no sea muy elevada, se recomienda indicar en el nombre del asset las abreviaturas de las tablas que lo componen. Cuando, en caso contrario, el número de tablas es muy elevado, el nombre debe ser capaz de describir el ámbito de información que contiene la Technical View.

Para este asset en concreto, no es necesario indicar un prefijo que indique el tipo de activo que constituye. Esto es debido a las siguientes dos razones.

• El nombre que recibe la Techincal View se establece de forma automática, por lo que correspondería un cambio manual de todas las instancias que se creen de este activo.
• En una misma colección las Technical Views y las Bussiness Vews están virtualizadas bases de datos diferentes, por lo que no es necesaria su discriminación ya que se encuentran sintácticamente diferenciadas. En el caso de las Business Views, la sintaxis es “nombre_coleccion”.

Por lo tanto, el nombre debe seguir las buenas prácticas descritas en el tercer apartado del presente documento.

[Descripción Technical View]

Por ejemplo: diagnost_domici_usuario

Business Views

Los nombres de las Business Views dependen tanto del conjunto de datos técnicos como del significado funcional concreto que se le dé a los mismos. Por lo tanto, el nombre debe contener la información necesaria para conocer los dos elementos que componen el asset.

El nombre de estos activos debe contener una descripción que indique los datos técnicos y el significado funcional que componen el activo. Esta descripción ha de ser sencilla y significativa, de manera que cualquier usuario de negocio sea capaz de entender el contexto de los datos técnicos que componen la Business View pertinente.

Para este asset en concreto, no es necesario indicar un prefijo que indique el tipo de activo que constituye. Esto es debido a las siguientes dos razones.

• El nombre que recibe la Bussiness View se establece de forma automática, por lo que correspondería un cambio manual de todas las instancias que se creen de este activo.
• En una misma colección las Technical Views y las Business Vews están virtualizadas bases de datos diferentes, por lo que no es necesaria su discriminación ya que se encuentran sintácticamente diferenciadas. En el caso de las Business Views, la sintaxis es “semantic_nombre_coleccion”.

Por lo tanto, el nombre debe seguir las buenas prácticas descritas en el tercer apartado del presente documento.

[Descripción Business View]

Por ejemplo: multicontagio_covid

Colecciones

Las colecciones son combinaciones de Business y Technical Views, por lo tanto, en su nombre se debe establecer la información necesaria para poder identificar qué activos lo componen.

Los nombres de las colecciones incorporan prefijos para identificar la capa a la que pertenecen.

Los posibles prefijos de las colecciones son:

• ori. Capa origen (tablas en Oracle)
• raw. Capa de tablas en crudo, ingestadas en HDFS.
• cur. Capa de tablas curadas tras haber pasado por raw.
• con. Capa de tablas finales más consistentes generadas (o que se vayan a generar en un futuro) en Stratio por procesos ETLs. En concreto, se incluyen todas las tablas migradas de las instancias de Oracle DPBILOAD y DPBISAS.
• ope. Versiones más consistentes de las tablas cuya información proviene de orígenes externos que no son DPBILOAD ni DPBISAS, y no son generadas desde cero en Stratio por procesos ETL.
• con_bps. Colecciones personalizadas definidas por la STAGI. Contienen tanto tablas de la capa “con_” como  “ope_”. Estas colecciones no deben ser usadas por los procesos de carga desarrollados por las factorías.

Después de indicar el prefijo que más se ajusta a la colección, se establece una descripción que sea capaz de contextualizar las Technical y Business Views que componen la propia colección. A continuación, se puede observar cuál es la estructura de nombramiento de este asset.

[ori/raw/cur/con/ope/con_bps]_[Descripción Colección]

Por ejemplo: cur_historia_salud

Justificación de los diferentes prefijos de colecciones

• ori_

Son aquellas colecciones que apuntan directamente a los orígenes en Oracle.

• raw_ y cur_

Las colecciones “raw_” y “cur_” contienen tablas que pasan por los procesos de ingestas y curados, respectivamente. Hay tablas que pasan por raw_ y luego se quedan en cur_. Por otro lado, también existen curaciones en Postgres que no pasan por cur_, sino que van directamente desde raw_ a Postgres.

• ope_, con_, y con_bps_

Las colecciones “ope_” (operacional) y las colecciones “con_” apuntan ambas a  las versiones más consistentes de las tablas:

• Las de “ope_ “ son versiones más consistentes de tablas que vienen de Oracle u otro origen externo, es decir, que no son generadas en Stratio. Por ende, las tablas de las colecciones “ope_” pueden apuntar directamente al origen, al curado o a la capa raw, en el último caso, serán tablas cuya ingesta sea de tipo total y sus datos no requieran de un postprocesado de curación.

Nota: En la ilustración anterior, la tabla_y y la colección “ope_” apuntan al origen porque es su versión más consistente, sin embargo, la “cur_tabla_x” se ha ingestado y curado, por tanto, su versión más consistente está en la capa de curado de HDFS. Por su parte, la tabla_z apunta a Postgres, porque tras haberse ingestado y curado, se ha almacenado ahí por sus características. Además, la “cur_tabla_x” y la “tabla_z” pertenece al mismo conjunto de datos que la “tabla_y”, dentro de la “bbdd_ejemplo”.

• Las “con_” son colecciones que guardan las versiones más consistentes de una tabla. Estas colecciones se crean a petición de cliente, y su particularidad es que apuntan a tablas generadas por ETLs en Stratio, con lo cual, apuntan a tablas de consumo o de Postgres que forman parte de un mismo conjunto vertical de datos.

• No obstante, puede ocurrir que la STAGI necesite definir una misma colección para acceder tanto a datos de un operacional (“ope”) como a tablas generadas por Stratio (“con_”). De modo que para diferenciar los verticales completos de datos “con” de las colecciones personalizadas creadas bajo petición de la STAGI, se usa el prefijo “con_bps_”. En dichas colecciones habrá tanto tablas generadas por procesos ETLs como tablas externas de operacionales, es decir, una mezcla de “con_” y “ope_”.

Constantes

Las constantes son unos elementos que, una vez definidos, se pueden usar en cualquier punto de la plataforma, por lo tanto, su nombre será específico del uso que se le quiera dar.

El nombre debe comenzar siempre por el prefijo “cons”, el cual indica que corresponde a una constante de la herramienta. La descripción del nombre debe ser suficientemente clara como para que cualquier usuario pueda entender el significado de esta. Al mismo tiempo, debe procurarse utilizar abreviaturas, siempre que sean entendibles, para reducir la longitud del nombre.

Cabe destacar que existen ciertas constantes que son intrínsecas de la herramienta y que, por tanto, no son modificables. Este tipo de activo conserva su nombre original, por lo que esta normativa no aplicaría en dichos casos.

A continuación, se muestra la estructura de nombramiento que debe presentar este activo.

cons_[Descripción Constante]

Por ejemplo: cons_edad_min_vacu_cov

Atributos adicionales

La herramienta Stratio permite añadir atributos personalizados a los elementos que componen su Data Catalog, estos son, las fuentes de datos, las colecciones y las Technical y Business Views.

Estos atributos dependen en gran medida de las necesidades del usuario que las defina y de los activos a los que complementa. Por lo tanto, los elementos que aparezcan en su nombre son muy variados.

Como regla general, se debe establecer un prefijo “atr” para indicar que ese atributo ha sido añadido de forma manual por un usuario concreto. Además, como en el resto de assets, el nombre ha de seguir las buenas prácticas establecidas en el tercer apartado del presente documento.

La estructura que presenta este activo es la que se muestra a continuación.

atr_[Atributo Adicional]

Por ejemplo: atr_cantidad_traumato

Cabe destacar que existen ciertos atributos adicionales que son intrínsecos de la herramienta y que, por tanto, no son modificables. Este tipo de activo conserva su nombre original, por lo que esta normativa no aplicaría en dichos casos. A continuación, se muestra un listado de las abreviaturas que puede presentar.

• bdl.  Se usan para los atributos relacionados con la virtualización de los datos.
• dlc.  Son atributos relativos a la ingesta automática de los datos.
• ontology.  Atributos relacionados al asset de las ontologías.
• related to. Relación nativa definida en la plataforma de Governance.

Activos de negocio

Existen ciertos activos que no están relacionados con otros elementos de la plataforma ni tampoco se puede acceder que no sea el propio menú de la herramienta. Por este motivo, no es necesario aplicar las normas expuestas en el presente documento. No obstante, se recomienda que todos los nombres que se establezcan no sean excesivamente largos y siempre se deben acortar lo máximo posible al mismo tiempo que se conserva su significado.

A continuación, se muestra un listado de estos activos que son exclusivamente de negocio.

• Communities. Estos activos son las primeras entidades de mayor jerarquía que se definen en el apartado de la herramienta Stratio exclusivo para glosarios de negocio.
• Domains. Para cada comunidad creada, se pueden crear elementos que agrupen diferentes dominios de información, llamados Domains.
• Business Rules. Son objetos correspondientes a reglas de negocio que se definen para un dominio concreto.
• Business Terms. Estos activos son términos de negocio que se definen para un dominio específico.
• Process. Este tipo de activo sirve para definir diferentes procesos dentro de cada uno de los dominios previamente creados en la herramienta de forma particular.

Dentro de este orden jerárquico, es necesario que cada uno de los elementos definidos sean coherentes con la estructura establecida. Por lo tanto, se debe prestar especial atención a la estructura del glosario para que la información sea fácilmente localizable.

Ontologías

Las ontologías deben ser nombradas de tal manera que cualquier usuario con perfil de negocio sea capaz de comprender con facilidad y sin ambigüedad las clases y relaciones establecidas en la ontología.

Al igual que ocurre para el conjunto de activos de negocio anterior, no es necesario establecer en el nombre de las ontologías ningún prefijo concreto. Sin embargo, el nombre debe describir de forma breve y concisa, de forma que sea fácilmente legible para cualquier usuario de negocio. Al final del nombre debe indicarse la versión de la ontología, aunque, contrario a lo que se indica en el apartado de buenas prácticas, no se debe indicar la revisión de la versión. Esto ocurre porque la ontología evoluciona como una única entidad a la que no se le puede cambiar el nombre. Solamente se debe crear otra ontología con una nueva versión cuando se cambie profundamente la estructura de esta.

A continuación, se establece la estructura que debe tener una ontología.

 [Descripcion Ontología]_XX

Por ejemplo: sas_03

Rocket  

El módulo de Rocket se divide en diferentes elementos que presentan una posición o estructura determinada en la herramienta. Estos son:

• Proyectos. Es el elemento principal en el cual se definen el resto de assets. Constituye el mayor nivel de detalle de gestión de acceso dentro del módulo.
• Directorios. Al igual que en cualquier sistema operativo, dentro de un proyecto se pueden generar diferentes estructuras de directorios diferentes en los cuales se crean los workflows dentro de Rocket.
• Assets. Estos elementos son los que se usan para construir procesos de manipulación del dato. 

Proyectos

Actualmente, los proyectos se encuentran definidos de forma previa. Estos proyectos han sido definidos en función de la capa de datos a la que pueden acceder y de los diferentes contratos que acceden a la plataforma Big Data. A continuación, se muestra una tabla con los diferentes proyectos definidos.

Directorios

Los directorios dentro de cada proyecto deben seguir las buenas prácticas establecidas en esta normativa. En concreto, se debe poner especial foco en los siguientes aspectos:

• Todas las palabras deben ir en minúsculas. Esto se establece para facilitar el uso del buscador de la herramienta Big Data Stratio, el cual diferencia entre mayúsculas y minúsculas.
• No se deben poner signos de puntación en los nombres de los directorios.
• Aunque la separación entre palabras se definen en las buenas prácticas con el uso de  "_", Stratio Rocket no soporta este carácter en los nombres de los directorios. Por este motivo, se restringe al uso del guion, "-".

La estructuración de cada proyecto se debe dividir en función de los equipos y trabajos típicos que desarrollen en ese espacio, estando siempre enfocado en la optimización de la accesibilidad y entendimiento por parte de nuevos usuarios que carezcan del conocimiento experto.

Assets

Los trabajos de manipulación de datos se definen a través de los assets, que pueden ser de diferentes tipos.   

• AutoMLPipeline
• Batch
• Hybrid
• MLProyect
• Notebook
• Streaming

Por norma general, el nombre debe componerse de unas palabras descriptivas seguidos de su orden de ejecución y la versión del workflow. Estos dos últimos elementos se incorporan por los siguientes motivos.

• Dentro de una misma ruta de directorios de un proyecto de Rocket se pueden definir varios workflows que dependan unos de otros. Por lo tanto, para facilitar el entendimiento general de un proceso, se debe poner en cada workflow el orden de ejecución, mediante "OEXX".
• Es importante notar que, al contrario que en el resto de assets en los que el versionado es opcional, en el caso de los workflows es obligatorio ya que el trabajo de versionados es típico de los diferentes desarrollos llevados a cabo por los equipos del SAS. El valor de este versionado debe ser el último funcional del asset en cuestión y no de una versión desfasada.
• Por último, como excepción a la norma general, no es necesario indicar el tipo de asset ya que viene indicado en la interfaz de la plataforma y en sus metadatos.

A continuación, se establece la estructura que debe tener un asset de Rocket.

 [Nombre workflow]_OEXX_YYrZZ

Normativa de documentación

Dentro de la metodología de trabajo establecida en el Marco de Trabajo de Governance, se encuentran diferentes procesos en los que es de obligado cumplimiento la elaboración de documentación que permita llevar un control de la información almacenada. Se distinguen dos normativas, siendo estas las referentes a documentación de nuevas fuentes de datos y de reglas de calidad

Nuevas fuentes de datos

Siempre que una nueva fuente de datos sea incorporada a la plataforma, los usuarios deben registrar dicha incorporación, así como posibles actualizaciones en fuentes de datos ya existentes. Para ello, en caso de una nueva fuente de datos o actualización de una existente, es necesario recoger determinada información específica referente a la misma que será registrada en el espacio destinado a ello, el cual debe mantenerse actualizado constantemente. La información que se debe recoger es la siguiente:

Reglas de calidad 

En lo que respecta a la definición de nuevas reglas de calidad, se debe llevar a cabo la documentación de las mismas, con el objetivo de realizar una buena gestión y mantenimiento de estas, contando así con un espacio que aúne toda la información relevante de las distintas reglas de calidad definidas y que permita, por tanto, evitar duplicidades, identificar nuevas necesidades, realizar seguimientos, etc.

La información que debe recogerse de cada una de las reglas identificadas es la siguiente:

Durante la definición de las distintas reglas de calidad dentro de la herramienta, es necesario establecer un umbral mínimo a partir del cual la regla de calidad reportará un error. Ante esto, existe la necesidad de identificar un umbral por defecto para las diferentes reglas creadas, siendo este el 90%. En determinados casos, será posible solicitar la modificación de dicho umbral mediante el proceso pertinente.

Normativa de gestión de assets 

A lo largo de la metodología definida en el Marco de Trabajo de Governance, se identifican una serie de normas que han de cumplirse para la gestión de los diferentes assets que presenta la herramienta. A continuación, se detallan dichas normas en función del asset al que afectan.

Gestión de relaciones

A lo largo del proceso de identificación y creación de relaciones entre los diferentes activos de la herramienta, es necesario regirse por una serie de normativas que garanticen la correcta gestión y mantenimiento de estas. Estas normativas giran en torno a dos aspectos fundamentales que se detallan a continuación.

Relaciones entre activos

En primer lugar, es necesario conocer entre que activos es necesario realizar el proceso de definición de relaciones, así como el sentido de estas. Esto es, no definir relaciones que sean generadas de forma automática y respetar aquellas que se hayan establecido por la organización como obligatorias.

A continuación, se detalla entre qué tipo de activos es posible la definición de relaciones.

Tipos de relaciones

Por otro lado, se deben seguir una serie de directrices acerca de la tipología de relaciones que se han de crear. Esto es, en función de los activos que se quieran relacionar, así como el objetivo de cada una de estas relaciones, la tipología de estas estará determinada según se establece en la siguiente tabla.

Normativa de Airflow

Definición y usos

La plataforma Apache Airflow permite la creación, la planificación y el seguimiento de flujos de trabajo a través de la programación informática. Es una solución de código abierto que se utiliza para la arquitectura y la orquestación de circuitos de datos y para el lanzamiento de tareas. Concretamente, en el proyecto de Gobernanza de datos del SAS, se utiliza principalmente para lanzar procesos en un orden concreto y con una periodicidad concreta.

Los casos de uso más comunes son la automatización de ingestas de datos, acciones de mantenimiento periódicas y tareas de administración. Para ello, Airflow permite planificar trabajos como un CRON y también ejecutarlos bajo demanda.

Los procesos o tareas se agrupan en DAGs (gráfico acíclico dirigido) a los cuales se les da una frecuencia o periodicidad de ejecución customizada. El orden en el que se ejecuta cada proceso dentro del DAG puede ser cualquiera que defina el usuario, o también pueden ejecutarse todos a la vez, aunque normalmente se organizan teniendo en cuenta las dependencias y los flujos de datos.

La plataforma también da información acerca de cuándo ha sido la última ejecución de cada proceso y cuál es el estado de esa ejecución, es decir, si el proceso terminó con éxito, si hubo algún fallo, si está corriendo, si fue detenido, etc.

Implicación con Rocket, Python y Git

Los procesos agrupados en DAGs se conforman de cualquier acción que se pueda ejecutar en Python, desde limpiezas o ingestas hasta llamadas a APIs. En el contexto del del proyecto de la OTBI del SAS, lo más habitual es que sean llamadas a flujos de Rocket con parámetros definidos por el usuario. Es por ello por lo que Airflow se relaciona estrechamente con el módulo de Rocket de Stratio.

Tanto los DAGs de Airflow como su periodicidad y el resto de los parámetros se programan a través de Python. Estos scripts de Python se suben a Git, de tal forma que Airflow lee constantemente los scripts de Python almacenados en Git.

Git es una plataforma de gestión de repositorios de código fuente y de colaboración entre desarrolladores. Git permite a los equipos de desarrollo almacenar, administrar, revisar y colaborar en proyectos usando el sistema de control de versiones de la propia plataforma.

DAGs

Las siglas DAG se corresponden con Gráfico Acíclico Dirigido ya que representan el circuito de tareas teniendo en cuenta las dependencias y los flujos. También especifica el orden y la frecuencia de ejecuciones o reintentos.

No obstante, teniendo en cuenta el uso que hace de ellos la OTBI en el paradigma del SAS, se podría definir un DAG como una agrupación de workflows de Rocket.

En el desarrollo de los DAGs, las invocaciones a los flujos se deben hacer usando el nombre de las ETLs y no el identificador de cada una. Por defecto ha de llamarse a la última versión del flujo.

Nomenclatura de DAGs

Dentro del contexto del proyecto del SAS, no es necesario definir el orden de ejecución de los DAGs, ya que el orden de las tareas que contiene el DAG va incluido dentro del script. Además, el orden de tareas puede verse en la pestaña “Graph” de Airflow, dónde también puede observarse la dependencia y el paralelismo de las tareas.

Airflow también permite crear grupos de tareas y establecer dependencias entre dichos grupos, de modo que se podría programar que al finalizar una tarea se ejecute un grupo de tareas en paralelo, y que al finalizar todas ellas, se lance otra tarea de manera secuencial.

En la imagen anterior, se observa como tenemos un grupo de tareas llamado “curation_analysis”, que contiene 3 tareas. Una de esas subtareas, es otro grupo que contiene a su vez 5 tareas (“exec_curation_analysis”). Siempre y cuando sea posible, han de organizarse las tareas en grupos y subgrupos, siguiendo el ejemplo anterior, con el fin de facilitar la comprensión del DAG.

No es necesario incluir en la nomenclatura un control de versiones, ya que esto se realiza automáticamente gracias al sistema de control de versiones de Git.

No obstante, sí que es necesario establecer las normas que deben seguirse para nombrar los DAGs que se creen dentro de la herramienta de Git:

• La longitud de los nombres no debe superar el tamaño máximo que permite la herramienta, pero siempre con un límite máximo de 40 caracteres.
• Los nombres han de ser claros y descriptivos, de forma que se entienda el contexto del DAG con facilidad y, al mismo tiempo, sean lo más cortos posibles.
• Solo se deben emplear caracteres alfanuméricos y barra baja, evitando así el uso de otro tipo de carácter especial.
• Escribir todos los caracteres alfanuméricos del nombre en minúsculas.
• Los caracteres alfanuméricos han de escribirse en español siempre que sea posible y sin usar la letra “ñ”, escribiendo en su lugar “ny”.
• Usar barra baja (_) para separar identificadores dentro del nombre.
• El nombre de los DAGs obsoletos y/o que se encuentren en desuso pero que se requieren conservar debe comenzar con los caracteres "_OLD_". Estos DAGs solo se deben encontrar en branchs de pruebas o desarrollo, nunca en el productivo.
• El nombre del DAG debe ser autocontenido y autodescriptivo, es decir, su comprensión no debe depender del contexto de la herramienta.
• Se debe evitar, en todo momento, incluir información sensible en el nombre de los DAGs.

Etiquetas de DAGs

A cada DAG se le puede poner una o varias etiquetas dentro del script de Python. Esta etiqueta aparecerá en Airflow debajo del nombre del DAG, obteniendo así la posibilidad de filtrar los DAGs en Airflow, una opción muy ventajosa a la hora de buscar un DAG en concreto entre cientos de ellos.

Para mantener una buena organización y facilitar la búsqueda de DAGs, se le ha de poner a cada uno de ellos una etiqueta que haga referencia al proyecto al que pertenecen. Por ejemplo, si hay un proyecto de Rocket llamado “ana_omop” que contiene los workflows a los que llaman los procesos o tareas que conforman un DAG, ese DAG ha de llevar la etiqueta “ana_omop”. Hay casos en los que un DAG puede llamar a workflows de diferentes proyectos de Rocket, en dicho caso, el DAG debe tener las etiquetas de ambos proyectos. Otra nomenclatura a seguir sería tener en cuenta el propósito del proyecto. Por ejemplo, en un desarrollo de usuarios, se debería etiquetar a esos DAGs con la etiqueta “usuarios”, de forma adicional a la etiqueta de proyecto.

En la medida de lo posible, es obligatorio que las etiquetas coincidan con los nombres de las carpetas donde están alojados los DAGs.

Documentación de DAGs

Respecto a la información de los DAGs, se debe documentar cada DAG y cada grupo de tareas (módulo) que lo compone a nivel genérico.

Para añadir descripción a un DAG, se pone un parámetro doc_md (descripción de tipo markdown) en las líneas de configuración del DAG, seguido de la descripción genérica que se desee poner y una breve descripción de la funcionalidad de los módulos que lo componen. La siguiente imagen muestra un ejemplo en el código.

El resultado de añadir esas descripciones en el código de configuración del DAG se reflejaría de la siguiente forma en la interfaz visual de Airflow:

Para añadir descripciones a las tareas, la operativa es exactamente la misma, con la diferencia de que ha de ponerse el parámetro y la descripción en las líneas de configuración de la tarea en cuestión. Por ejemplo:

El resultado de añadir ese parámetro de descripción a una tarea en concreto se refleja en la interfaz gráfica de Airflow cuando se navega a una tarea específica, al entrar en el apartado de "More Details", viéndose de la siguiente forma:

Estructura de carpetas en Git

Tanto la carpeta “dags” como la carpeta “librerías” son desarrollos de la UTE los cuáles no deben modificarse en ningún caso. Para los desarrollos de la OTBI se crean dos carpetas nuevas cuya jerarquía ha de llevarse a cabo tal y como se dicta en los siguientes puntos.

Carpetas DAGs

En el repositorio Git hay una carpeta llamada “dags” en la que la UTE ha creado una subcarpeta por cada DAG con sus respectivos scripts de inicio y script de tareas. Esta carpeta no se puede modificar, ni tampoco sus contenidos, ya que afectaría a los casos de usos ya entregados.

Para organizar los DAGs que se van desarrollando por parte de la OTBI se ha creado una carpeta llamada “dags_sas” en la que se deberán recoger dichos desarrollos. Esta separación es necesaria porque la OTBI trabaja sus desarrollos en tres branchs distintos (dev, pre y master) y la hora de promocionar una carpeta de un branch a otro los cambios se pierden. Ello implica que si se promociona alguna subcarpeta de “dags” (desarrollos de la UTE) se estarían modificando casos de uso ya entregados, algo que está prohibido. Por este motivo se deben separan los desarrollos de la UTE de los desarrollos de la OTBI.

Dentro de la carpeta de “dags_sas” (desarrollos de la OTBI), la organización debe consistir en agrupar los DAGs por proyectos de Rocket. Además, es una organización lógica, ya que los procesos o tareas de Airflow son, en su mayoría, llamadas a workflows de Rocket y éstos se organizan en proyectos.

Carpetas librerías

Los DAGs de la UTE (recogidos en la carpeta “dags”) frecuentemente invocan a ciertas funciones que se almacenan en una carpeta llamada “librería”. De nuevo, para no afectar a los desarrollos ya entregados por parte de la UTE, la carpeta “librerías” no se puede modificar ni tampoco sus contenidos.

Dada la premisa anterior, la OTBI ha creado una carpeta llamada “librería_sas” para recopilar ahí las funciones a las que se invocará en los scripts de sus DAGs. Del mismo modo que en la carpeta “dags_sas”, la carpeta “librería_sas” se debe organizar por proyectos de Rocket.

Parámetros

Se deben definir parámetros para los DAGs, respetando que, si un DAG se compone de diferentes grupos de tareas (módulos), los parámetros se definirán para cada grupo.

Estos parámetros se definen en el código haciendo uso de la función params y dentro de esa función se le asigna el nombre de la sección con la palabra reservada section, de forma que los parámetros que tengan el mismo nombre de sección se aglutinan en un mismo grupo.

Existen parámetros genéricos o globales que se usan en varias ETLs. Esos parámetros forman parte del grupo Variables Globales que contienen variables compartidas para todos los grupos de tareas de los DAGs.

Además, a cada parámetro se le debe añadir una descripción de lo que hace a nivel práctico, para ello se añade en el código el parámetro description.

Normativa de ficheros parquet

Como punto de partida, es conveniente mencionar que en el área de Gobernanza del SAS hay varios tipos de orígenes a los cuáles pueden apuntar las colecciones de datos. Uno de ellos serían las bases de datos relacionales de Oracle, donde el SAS almacena todos sus datos, y por tanto, es la fuente primera de la organización. Por otro lado, se tiene el sistema de almacenamiento de Stratio, donde se generan tablas mediante sus respectivos desarrollos, el cual tiene dos tipos de almacenamiento: HDFS (sistema distribuido de Big Data) y Postgres.

Parquets

Parquet es un formato de archivo de almacenamiento de datos columnar y abierto que se utiliza para almacenar datos en HDFS. Una misma tabla almacenada en HDFS consta de varios archivos parquets. En los desarrollos se determina el número de parquets que se quieren generar. Se ha de tener en cuenta, en la medida de lo posible, que un mismo parquet no debe pesar, como regla general, más de 1 GB, y nunca menos de 250 MB.

Particionado

Suele ser necesario particionar los ficheros parquets, es decir, separar las filas de una tabla dependiendo del valor de una de sus columnas. Habitualmente, se particionan las tablas por alguna columna tipo fecha.

Por ejemplo, particionando la tabla por una columna de año, se crea un archivo parquet para cada valor distinto de la columna año de una tabla y se crea una subcarpeta para cada parquet. También puede particionarse un mismo año en meses o agrupaciones de meses, en ese caso, pueden existir varios parquets dentro de una misma subcarpeta.

Cuando la tabla es muy grande, se intentan crear particiones para que cada directorio tenga 1 o 2 parquets de 1GB. Del mismo modo, es importante que los parquets generados tengan un tamaño mínimo de 250 MB para no infrautilizar los recursos de la herramienta.

En base a la experiencia, se considera que, aproximadamente, 1 GB en parquet son 10 millones de filas. No obstante, dependiendo del número de columnas, esto podría variar, por ejemplo, una tabla con que contenga más columnas que otra, pesará más. También hay que tener en cuenta los tipos de datos, por ejemplo, una tabla con columnas de tipo BLOB pesará más que otra con columnas de tipo INTEGER.

Considerando la premisa anterior, se intenta particionar la tabla por una columna de tal forma que los parquets resultantes sean de 10 millones de filas. Normalmente, se suele hacer una disgregación de la columna fecha, esto supone que haya una columna para el año y otra para el mes y de esta forma el particionado sea más flexible y versátil.

La columna de partición puede ser cualquiera siempre y cuando no contenga nulos y sea equidistante, es decir, que tenga aproximadamente el mismo número de registros para cada uno de sus distintos valores.

Por otra parte, al realizar consultas sobre la tabla, habría que hacer una consulta conocida como “consulta a nivel de columna”, por ejemplo: SELECT * FROM TABLA1 WHERE ANYO=2020. De esta manera, se optimiza el rendimiento de la memoria ya que la consulta lleva implícito el directorio que se debe consultar, porque la tabla está particionada por año.

En determinadas ocasiones, se sabe de antemano la columna por la cual se va a consultar la tabla, por ejemplo, si el usuario funcional manifiesta que suele consultar y filtrar en la tabla por la columna “COD_PROVINCIA”, habría que particionar por esa columna, siempre y cuando sea una columna técnicamente adecuada para hacer la partición. Para elegir dicha columna de partición, también habrá que tener en cuenta la usada en las consultas de los procesos ETLs de carga.

Ingestas

Las ingestas se refieren al movimiento de los datos desde Oracle a HDFS de las tablas que se desean migrar.

Existen casos concretos en los que la ingesta no es necesaria, ya que, como se apuntaba anteriormente, en Stratio se pueden crear colecciones que apunten a orígenes de Oracle. Se ingestarán aquellas tablas masivas sobre las que tengamos beneficios de almacenarlas en HDFS, o aquellas tablas que vayan a ser generadas por los procesos de Stratio en un futuro. Estas tablas deben ser ingestadas en HDFS para poder cargar las filas que existían previamente en Oracle, dentro de Stratio. Es decir, se empieza a generar la tabla X a partir de un día, pero se necesitará hacer una carga inicial con todo lo que existía previamente en Oracle antes de ese día en concreto. Por otro lado, las tablas de orígenes externos que no vayan a ser generadas en los procesos de Stratio y actúen sólo a modo de escritura que tengan menos de 1 millón de filas, se virtualizarán directamente hacia el origen dentro de las colecciones de tipo "ope_".

Es en el proceso de curación donde se pueden incorporan nuevas columnas, por tanto, deben ingestarse y curarse aquellas tablas en las que se necesite agregar nuevas columnas.

Ingestas completas e incrementales

Existen varios tipos de ingestas: completas e incrementales.

En una ingesta completa se carga por primera vez o se reescribe completamente la tabla como un nuevo conjunto de datos, el proceso implica cargar todos los datos desde cero.

Por su parte, en una ingesta incremental, solo se cargan y actualizan los datos que han cambiado (nuevos o modificados) desde la última carga.

En el contexto del área de Gobernanza del SAS existe otro tipo de ingesta especial que es la ingesta incremental por particiones, un híbrido entre ingesta total e ingesta incremental. Consiste en hacer ingestas truncando las particiones modificadas. Además, a través de este método se actualizarían en Stratio aquellas filas que son borradas en Oracle.

Este tipo de ingesta sólo se podrá realizar cuando la tabla está particionada en Oracle, y cuando se sabe que los procesos de carga en Oracle van truncando/escribiendo por particiones la tabla en cuestión.

Por ejemplo, si se sabe que han cambiado tres filas, en una ingesta incremental, se ingestarían esas tres filas. Sin embargo, si la tabla en cuestión en Oracle estuviese particionada por la columna COD_ANYO, y esas 3 filas modificadas pertenecen a la partición COD_ANYO = 2023, la ingesta incremental por particiones lo que haría sería ingestar y sobreescribir en Stratio todos los registros con COD_ANYO = 2023. Es decir, se cargaría por completo (borrando previamente) todo el año del 2023.

Curación

Las tablas que se generan en Stratio, a través de los procesos de curación o las ETLs de carga, conforman los inputs de la curación, una vez han sido ingestados. Los casos en los que dichos datos se suelen almacenar, una vez curados, en HDFS son los siguientes:

• Tablas medianas/grandes/masivas: Cuando la tabla que va a servir de input es mediana/grande/masiva, es conveniente pasarla a HDFS (siempre que se pueda tener una buena política de partición según lo expuesto anteriormente) para que la lectura y el flujo sean más eficientes. Se considera que, como mínimo, para que tenga sentido usar HDFS, una tabla ha de tener aproximadamente 5 millones de filas, o que pese en formato parquet 250 MB. Si la tabla comienza a aumentar en volumetría, habría que considerar particionar para que cada partición pese aproximadamente 1 GB o como mínimo 250 MB.
• Tablas con modificación de estructura: Son las tablas a las que se le quiera aplicar una estructura diferente, por ejemplo, tablas que en Stratio haya que añadirle columnas. Esto es porque las tablas de Oracle no se pueden modificar en origen.

En el resto de casos, normalmente cuando el tamaño de las tablas es pequeño, dichas tablas se almacenan en Postgres, siempre que se decidan ingestar/curar. Existe el caso de otras tablas pequeñas que se decide no ingestar ni curar. Para ellas, simplemente se apuntará a Oracle desde las colecciones.

Existe una casuística en la cual la tabla, una vez curada, debe almacenarse en Postgres y no en HDFS, aunque sea masiva. Es el caso en el que la tabla vaya a ser consultada por filas en vez de por columnas, es decir, que se vaya a buscar registros bastante concretos, tratándose de filas exactas, por ejemplo: SELECT * FROM TABLA1 WHERE DNI=01234567A.

Pueden existir tablas candidatas a estar en HDFS que se usen como inputs, pero no se generen, esas tablas se ingestan y se curan pero no se llevan a consumo ni a Postgres. En consecuencia, las colecciones que usen esa tabla apuntarán al curado o al origen, ya que es su versión más consistente, esto se hace para evitar horas de desarrollo.

Por otra parte, habrá tablas que se utilicen como inputs, pero no se ingesten ni se curen, es el caso de tablas que no sean candidatas a estar en HDFS y, por tanto, se apuntará directamente al origen.

Curados completos e incrementales

Existen varios tipos de curaciones: competas e incrementales.

El curado completo implica revisar y limpiar todo el conjunto de datos para corregir errores, inconsistencias, y asegurar la calidad de los datos.

Los curados incrementales se enfocan solo en los datos nuevos o modificados desde la última curación, limpiando y corrigiendo estos cambios.

En el contexto del área de Gobernanza del SAS existe otro tipo de curación especial, que es la curación delta. Este tipo de curación sólo procesa los últimos datos ingestados usando la columna "TS_RAW" (fecha de carga en la capa raw). Se usa en casos muy extremos donde la curación completa implicaría mucho tiempo de carga (más de 12 horas).

Dado que en las ingestas incrementales pueden existir filas duplicadas (un mismo registro puede modificarse varias veces en procesos de curaciones), este tipo de curación obtiene la versión más reciente de cada registro a partir de las claves primarias indicadas por parámetros.

Tras la carga y el curado, se realiza una operación UPSERT (Update/Insert) de las nuevas filas (ya sin duplicados) sobre la capa de curado y usando las mismas claves primarias anteriores.

Este tipo de curación es eficiente, pues no procesa la tabla entera, pero su uso debe ser comedido, ya que exige mantener un control diario de que la ejecución sea correcta al existir el riesgo de que se pierdan datos.

La curación delta se usa en los siguientes casos:

• La ingesta incremental es acumulativa.
• Existe la posibilidad de que existan registros duplicados en la ingesta.
• No existe la posibilidad de que se produzcan eliminaciones de datos de manera sistemática en la capa de ingesta (eliminaciones no manuales).
• La tabla es masiva y su procesamiento es extremadamente costoso o es necesario que su curación se realice de forma rápida.

Colecciones

En cuanto a colecciones, existen colecciones “raw” que apuntan a la capa de ingestas, colecciones “cur” que apuntan exclusivamente a /curado_sas, colecciones “ope” que apuntan a la versiones más consistentes de las tablas, colecciones "con" creadas bajo petición expresa y que apuntan a la versiones más consistentes de las tablas generadas por ETLs en Stratio, es decir, apuntan a consumo o a Postgres. Y por último, existen colecciones "con_bps" que apuntan a versiones más consistentes de tablas generadas en Stratio y tablas externas operacionales. Normalmente, la colección a consumir y usar es la colección “ope”, "con" y "con_bps" donde están las versiones más consistentes.

Capas

Las diferentes capas definidas por las que transitan los datos son las siguientes:

• Las tablas ingestadas que van a HDFS se incluyen en una carpeta llamada “dev/raw” o “dev/raw_incremental” del entorno DEV, o “raw” o “raw_incremental” de los entornos PRE o PRO, dependiendo de si la ingesta de dicha tabla es incremental o no.
• La curación es una limpieza de los datos que vienen brutos, y, una vez realizada, se pasan las tablas curadas a una carpeta llamada “curado_sas” o “curado_sas_incremental”, dependiendo de si el curado es incremental o no.
• Una vez ingestados y curados los datos pasan a la capa de consumo, cuya carpeta en HDFS es llamada “consumo” o “consumo_incremental”, dependiendo de si la carga es incremental o no.

Todas las carpetas “…_incremental” serán incluidas en el backup del HDFS. En estas carpetas se incluyen las tablas cuya generación es costosa y no es fácil de cargar de forma completa de una sola vez.

La capa de consumo puede estar en Postgres o en HDFS en función de su volumen. Como mínimo, para que sea rentable tener la tabla almacenada en HDFS, el peso de cada parquet asociado a la tabla ha de ser superior a 250 MB.

Hay que tener en cuenta que el espacio que ocupan las tablas en Oracle no es el mismo que en HDFS, por lo tanto, hasta que la tabla no esté ingestada, no se podrá saber su peso exacto. Por experiencia, se conoce que 250 MB son aproximadamente 2,5 millones de filas. La OTBI, por defecto, pasa a Postgres tablas con menos de 5 millones de filas, y, si tiene más, se almacena en HDFS.

Nomenclatura en Stratio

Los nombres de los archivos parquets se generan automáticamente en Stratio, resultando una serie de caracteres alfanuméricos en minúsculas que no hacen alusión alguna a los datos ni al nombre de la tabla (para facilitar la comprensión, los ejemplos que aparecen en la normativa sí poseen nombres ilustrativos).

Este nombre es algo que no se puede modificar, y, por tanto, hay que tenerlo en cuenta en la posible integración de parquets externos, dado que si la nomenclatura del parquet no es la correcta, el virtualizador y la disponibilización de los datos no funcionará correctamente.   

Normativa Postgres

Postgres

 Postgres es un sistema de gestión de base de datos relacional, de código abierto y compatible con SQL.

Dado que en el contexto del proyecto se está llevando a cabo una migración de datos desde Oracle, este tipo de base de datos es adecuado por ofrecer la posibilidad de crear esquemas de datos de la misma forma que en el origen. Esta es una premisa relevante, ya que los datos deben ser migrados físicamente con la misma estructura que tenían en el origen (Oracle).

Tanto las particiones de la tabla, como sus índices y sus claves primarias, deben ser idénticos en Oracle y en Postgres.

Casuísticas de migración a Postgres

Existen dos causas principales que justifican la migración de los datos a Postgres:

• Tablas pequeñas: Menos de 5 millones de registros.
• Tablas con acceso por filas: Casos en los que se quiera consultar una tabla a partir de un registro único, por ejemplo, un DNI. En este caso, se le añade un índice a la columna del DNI, de modo que al hacer una consulta ésta sea más eficiente.

Las tablas que no cumplan estas casuísticas anteriores serán migradas a HDF.

Capas

Existen 4 instancias (capas) de Postgres, ordenadas de menor a mayor consistencia son: test, dev, pre y pro.

Las tablas se crean por primera vez en test, dónde además se realizan todo tipo de pruebas. Test es la única capa dónde se tienen permisos de creación de tablas, en el resto de capas no se crea nada, sino que se promociona lo que haya en capas anteriores.

Una vez las tablas estén creadas en la capa de test de Postgres, se extrae (a partir de cualquier herramienta de gestión de base de datos) el script SQL que crea todas las tablas con la estructura que se les ha dado. Este script puede ser ejecutado en cualquier otra instancia de Postgres para crear todas las tablas de una colección ya migrada a Postgres, con el mismo esquema que tenía en Oracle.

Una vez que se tiene ese script, se debe poner una petición CGES a los gestores de sistema para que ellos, que sí poseen permisos de escritura en el resto de capas, ejecuten esos script en las capas de dev, pre y pro. No obstante, se está trabajando para que esta ejecución la realice Liquidbase de forma automática con Jenkins.

Este es el proceso para tener las tablas creadas en las 3 capas de Postgres. Es importante señalar que las tablas han de ser consistentes en las 4 instancias, es decir, si se hace un cambio en la capa test, este cambio debe propagarse al resto de capas.

Nomenclatura

Los objetos de Postgres tales como tablas, columnas, restricciones, etc. son case-sensitive, ello significa que existe diferencia entre mayúsculas y minúsculas. De modo que, para consultar tablas cuyo nombre esté escrito en mayúsculas, se debe poner, en la consulta SQL, el nombre de la tabla y de las columnas entre comillas, por ejemplo:

En contrapartida, si el nombre de la tabla que se quiere consultar está escrito en mayúsculas pero no se le ponen las comillas en el script SQL, el resultado dará error y dirá que esa tabla no existe, por ejemplo, al consultar así, se obtendrá el siguiente resultado de error:

Como se puede apreciar en la imagen anterior, a pesar de haber escrito el nombre de la tabla en mayúsculas en la consulta, el mensaje de error que muestra el sistema escribe el nombre de la tabla en minúsculas, dado que, por defecto, el sistema trabaja con minúsculas. Es decir, CREATE TABLE X se traduce a create table x, y se crea la tabla en minúsculas.

En definitiva, cuando se desee consultar una tabla cuyo nombre sea en mayúsculas, se debe poner el nombre de la tabla entre comillas. Esta premisa es muy importante y se ha de tener en cuenta, dado que todos los nombres de las tablas, sus columnas y sus esquemas están escritos en mayúsculas.

Por otro lado, existe una normativa de nomenclatura para los elementos de Postgres la cuál se detalla en la siguiente tabla.

Parametrización obligatoria Rocket

Parámetros

En los workflows de Rocket frecuentemente se usan pasos que en los que se realizan escrituras a sitios externos como SFTP o Postgres. Para hacer esas escrituras a SFTP es necesario indicar una IP, un puerto y un Vault secret (pseudónimo que llama a una contraseña que está almacenada en otro sistema). Para hacer escrituras a Postgres, únicamente es necesario indicar una URL.

Los ejemplos que se muestran a continuación obedecen a una parametrización para escrituras a SFTP. Para escrituras a Postgres, los pasos serían los mismos, pero sólo habría que indicar la URL.

Establecimiento de parámetros en proyectos

Tanto la IP, como el puerto, y también el Vault secret no deben escribirse manualmente en cada workflow, dado que ello supondría que, ante un cambio en cualquiera de ellos, hubiese que modificar todos los workflows que hagan escritura en SFTP.

Para evitar esta problemática, se debe introducir la IP, el puerto y el Vault secret como parámetros previamente definidos en cada proyecto de Rocket. De esta forma, si se producen cambios, sólo hay que modificar el parámetro del proyecto.

Las siguientes capturas muestran un ejemplo de cómo establecer parámetros de SFTP dentro de un proyecto.

Uso de parámetros en workflows

Para poder usar un grupo de parámetros en concreto dentro de un workflow de Rocket, hay que acceder a la configuración del flujo y activarlo. Las siguientes capturas muestran un ejemplo de cómo hacerlo.

Estructura de carpetas y archivos en SFTP

La estructura del SFTP debe seguir la siguiente directriz: la carpeta raíz debe contener una carpeta para cada entorno, es decir, una carpeta "dev", otra llamada "pre" y otra "pro". Luego, dentro de cada carpeta se debe tener una carpeta para cada proyecto de Rocket, donde se suban los desarrollos de cada proyecto.

Normativa de desarrollos en Rocket

Introducción

Esta normativa ha sido elaborada con el fin de establecer unas pautas generales que permitan que los desarrollos de Rocket sean los más correctos, efectivos y eficientes posible. Además, al llevar a cabo este compendio de premisas, se facilita y potencia la productividad mediante el trabajo en equipo. Los desarrollos que obedezcan estas buenas prácticas serán más resistentes y/o fáciles de enmendar ante posibles cambios de cualquier tipo en el futuro.

Índice

Buenas prácticas

1.Ajustes Debug y Auto-Debug

Lo primero que se debe hacer al crear flujos de Rocket es ir a la configuración del flujo.

Y una vez ahí, ir a los ajustes del Debug para marcar la opción “Do not use cached debug data”.

También en los ajustes de Auto-Debug se debe desmarcar la opción de “Enable Autodebug for this workflow” y marcar “Do not use cached debug data”, de forma que quede como en la siguiente imagen.

Esto se hace para que el Debug no se guarde en caché, lo que supondría que al aplicar un cambio en una entrada, por ejemplo, ese cambio no se refleje en el workflow a causa de haberse quedado una ejecución de Debug en caché. Por otro lado, al desactivar el auto-debug, se evita la ejecución de un Debug cada vez que se guarde el workflow, ganando eficiencia a la hora de desarrollarlos.

2. Parametrización

Se han de parametrizar siempre los desarrollos, en la medida de lo posible. Los parámetros deben definirse en los ajustes de los workflows, y con un valor por defecto si éste fuese conveniente.

3. Parámetros obligatorios

Hay ciertos parámetros que son estrictamente obligatorios, éstos son:

• Las conexiones JDBC de Postgres.
• IP, puerto y Vault secret de los SFTP.

Estos parámetros se definen a nivel de proyecto para que estén disponibles para todos los workflows de un mismo proyecto.

Una vez los parámetros se han definido a nivel de proyecto, deben importarse en el workflow para disponibilizarlos y poder usarlos. Esto se hace en los ajustes del workflow, concretamente en la opción de “Parameters group”.

Una vez se realiza esta configuración, se podrá invocar al parámetro en cualquier entrada o salida de Postgres, en el caso del ejemplo que se ilustra.

Se ha puesto el ejemplo de la parametrización de Postgres, sin embargo, para la parametrización de SFTP se seguirían los mismos pasos.

4. Relaciones entre workflows

En el caso de que se disponga de ETLs que estén relacionadas de alguna forma, la relación ha de configurarse mediante sus workflows desde el apartado “Relations”.

Una vez que se escoja el asset relacionado y se pulse en “Link”, la relación se reflejará de la siguiente forma.

5. Subconjunto de datos de Input

En cuanto a los inputs, existen dos opciones de seleccionar los datos que requieran.

La primera opción es colocar un input de tipo Parquet, por ejemplo, y, posteriormente, filtrar las filas y columnas que se deseen con sus respectivos nodos.

La segunda opción, es usar un nodo SQL en el que se construya una consulta para seleccionar solo las columnas y las filas que se necesiten.

Esta segunda opción es más eficiente por varias razones:

• Usando la consulta SQL no se accede al dato físico, sino a la colección.
• La columna sobre la que se aplica la cláusula WHERE es preferiblemente la columna de partición de la tabla a consultar, de esta forma, sólo se accederá a la subcarpeta de esa partición.
• Sólo se cargan en memoria las columnas seleccionadas en la consulta, lo que incrementa el rendimiento del proceso.

6. Nodo Persist en bifurcaciones

En las bifurcaciones de caminos, se debe añadir un nodo de “Persist” intermedio, puesto que, gracias al almacenamiento en memoria que brinda el “Persist”, se evita el cálculo de la consulta SQL dos veces.

Esto también se aplica a bifurcaciones de caminos tras un paso de tipo Filter (camino positivo y negativo):

El nivel de almacenamiento del “Persist” es modificable, pero se recomienda que se use “MEMORY_ONLY” siempre que se pueda, para trabajar solo en memoria.

7. Broadcastjoins entre tablas de distinto tamaño

En los JOINS entre una tabla muy pequeña (menos de 150 mil filas) y una tabla grande, se debe usar el tipo de JOIN llamado “broadcast”.  La operación BROADCASTJOIN se aplica sobre la tabla pequeña. De esta forma, la comunicación entre los ejecutores del JOIN será mucho más eficiente. La tabla pequeña se copia entera dentro de cada ejecutor, y eso provoca que cada uno de ellos no necesite realizar operaciones de shuffle para realizar el JOIN.

Al ejecutar flujos donde haya este tipo de JOINS, es importante ejecutarlo con unos recursos en los que cada ejecutor tenga la memoria suficiente para albergar la copia de la tabla completa.

8. Preferencia de uso de nodos de transformación

El sistema tiene sus nodos por defecto con distintas funciones para satisfacer un amplio espectro de casuísticas de transformación, por lo tanto, estos nodos deben ser siempre la primera opción.

Sin embargo, se pueden encontrar ocasiones en las que los nodos no satisfagan las necesidades del desarrollo, en ese caso se podrá recurrir a los nodos SQL. Para crear o reemplazar columnas en el Dataframe, se recomienda hacer uso del paso “AddColumns”. Es preferible el paso anterior “AddColumns” al de “SelectColumns”, puesto que en el primer caso se calculan exactamente las columnas que se necesitan, y con el segundo se necesitan retornar todas las columnas del Dataframe. No obstante, “SelectColumns” puede ser interesante incorporarlo en ciertos puntos clave del flujo (como al final), para que se sepa con facilidad las columnas que se están retornando a partir de dicho punto. Además, este paso permite realizar transformaciones , renombrados  y eliminaciones de columnas en un solo paso. Si el uso de este paso facilita enormemente la labor del desarrollador, estaría justificado su uso.

Si los pasos anteriores no satisfacen las casuísticas requeridas, se podría tomar la opción del paso  “Trigger”, el cuál es completamente moldeable al ser un editor de código SparkSQL (se pueden realizar operaciones de GROUP BY o consultas más complejas). El nodo “Trigger” puede también resultar ventajoso puesto que puede aglutinar varios pasos de cada uno de los nodos individuales que trae por defecto el sistema.

Si las dos opciones anteriores no son lo suficientemente potentes o configurables para la transformación que se desea realizar, se puede usar el nodo de transformación PySpark. No obstante, estos nodos solo pueden usarse bajo el consentimiento previo de la OTBI, dado que suponen un cambio de contexto que puede perjudicar el rendimiento y la efectividad del flujo.

9. Funcionalidad Create group

En desarrollos muy grandes, por ejemplo uno que contenga 40 nodos en un mismo flujo, puede que muchos de ellos tengan un objetivo común. En ese caso, lo que se debe hacer es seleccionar ese conjunto de nodos y utilizar la función “Create group”.

De esta forma, todos estos nodos quedarán agrupados visualmente en uno solo. Ese grupo, una vez creado, se puede renombrar para asignarle un nombre representativo de lo que realmente están haciendo ese conjunto de nodos.

10. Uso de descripciones de nodos

En nodos que realicen acciones muy complejas, se debe añadir una descripción indicando qué hacen. De forma que, al pulsar sobre el botón de información, aparezca de la siguiente forma.

11. Uso de comentarios de nodos

La posibilidad de añadir comentarios a los nodos sólo debe utilizarse para hacer anotaciones que sirvan como información para los distintos participantes del equipo de desarrollo, no para describir el funcionamiento del flujo. Eso deberá realizarse mediante los campos de descripciones.

12. Uso y recomendación del nodo Bypass

En los nodos de tipo “Output” se especifica la tecnología y la ruta de almacenamiento para la tabla generada por el workflow.

No obstante, la configuración de escritura se establece en el nodo “Writer” del paso anterior, donde se asigna el nombre a la tabla.

Un problema común es que, al realizar modificaciones menores en el workflow, incluso sin ejecutarlo, la configuración del Writer en el nodo de transformación se pierde.

Para mitigar este problema, se ha de insertar un nodo “Bypass” justo antes del nodo de “Output”. En este nodo “Bypass”, se define la configuración del Writer. El nodo “Bypass” no tiene ninguna funcionalidad específica y no requiere ajustes, por lo que no es necesario que se modifique nunca. Esta estrategia garantiza la integridad de la configuración de escritura, evitando su eliminación accidental.

13. Restricciones para cargar incrementales

Las tablas que requieran una carga incremental de tipo Upsert deben ser tablas Delta o estar almacenadas en Postgres, así se suprime el riesgo de perder datos.

En HDFS no existen las operaciones de Update/Upsert, por lo que si se usan tablas de tipo Parquet para simular este comportamiento, se deberían cargar las filas existentes al inicio del flujo, procesarlas con las nuevas, quedarse con la fila más consistente por cada clave primaria y finalmente hacer un overwrite de toda la tabla. El overwrite en HDFS elimina los archivos de la tabla y los crea de nuevo, por lo que si el proceso falla en mitad de la operación, se perderán todos los datos de la tabla.  Es por ello que para operaciones incrementales en HDFS se deben usar los outputs de tipo Delta. Las tablas Delta guardan un historial de versiones de sus parquets y nunca eliminan los archivos antiguos hasta que no se ejecuten los comandos de VACUUM, lo que provoca que ante fallos de escritura, no se pierdan los datos.

En Postgres no hay ningún tipo de limitación con las cargas incrementales, ya que al ser una base de datos relacional, no se guardan los cambios hasta que las transacciones no finalicen.

14. Requisitos tablas Deltas

Para que no se generen parquets diminutos en las tablas Delta tras operaciones Upsert, se deben cumplir los siguientes requisitos:

• Las tablas Delta deben estar particionadas.
• La primera vez que se escriba en una tabla Delta debe usarse el modo Overwrite, indicando en el Writer el número de parquets a generar dentro de cada partición.

• Para hacer escrituras en tablas Deltas debe añadirse, en todas y cada una de las escrituras que se vayan a realizar (incluyendo la primera vez que se carga la tabla), un parámetro determinados en Spark a nivel de workflow:
  • databricks.delta.merge.repartitionBeforeWrite.enabled (con Configuration value igual a ‘true’)

Este parámetro fuerza al sistema a que se generen en cada escritura, tantos archivos parquets dentro de cada partición como se hubieran definido la primera vez que se creó la tabla en modo Overwrite. Si la tabla se creó inicialmente con 2 parquets por partición, las operaciones de Upsert generarán exactamente 2 parquets por cada partición.

Si no se siguen exactamente estos requisitos, las operaciones de Upsert generarán diversos parquets de escaso tamaño (decenas de ellos), perjudicando en el rendimiento de consulta de la tabla. Para más información consultar la página oficial de Delta Lake: https://docs.delta.io/2.0.2/delta-update.html

15. Eliminación de versiones obsoletas de tablas Deltas

Como se ha dicho anteriormente, al hacer sobreescrituras en tablas Deltas, no se elimina la tabla preexistente, sino que se crea una nueva versión. En las consultas SparkSQL se accede únicamente a la última versión de la tabla. No obstante, para ahorrar espacio en el sistema, es recomendable eliminar la antepenúltima versión, de forma que quede la versión que se acaba de crear y también la inmediatamente anterior a esta. Por ejemplo, si se tiene versión 0, versión 1 y se crea una versión 2, se elimina sólo la versión 0.

Para eliminar la antepenúltima versión, y por supuesto también las anteriores a esta penúltima versión, se debe ejecutar un flujo como el siguiente.

En dicho flujo, el Trigger es un SQL sencillo, como el que aparece en la siguiente imagen.

El número de horas que se debe establecer debe ser ligeramente superior al número de horas que han pasado desde que se generó la penúltima tabla.

Si se elimina la versión inmediatamente anterior y existe algún usuario consultando dicha versión de la tabla en ese momento, se le caerá el proceso. Para evitar este problema se elimina la versión penúltima.

16. Csv en formato UTF-8

Para importar un archivo csv en Stratio, el desarrollador debe asegurarse de que el csv tiene el formato UTF-8, de lo contrario, el archivo no será correctamente leído (aparecerán caracteres extraños).

17. Versiones de workflow

En Rocket se manejan o se crean diferentes versiones de un mismo workflow cuando se hacen pequeños cambios en el desarrollo. En los casos en los que los cambios sean de más envergadura o más sustanciales, lo que se debe hacer es reflejar el cambio de versión modificando el nombre del workflow e incorporando la versión pertinente.

En el caso de que haya distintas versiones, la última versión del workflow siempre debe ser la más consistente, pero además, en los ajustes del workflow es recomendable añadir unas etiquetas de versión indicando descriptivamente que tiene de particular cada versión.

18. Subconjunto acotado de datos para Debug

En los desarrollos en los que se requiera simulación de datos para hacer comprobaciones básicas en un subconjunto acotado de datos, se debe ir a la configuración del nodo de input y, en el apartado de Debug, seleccionar la opción de “SQL query” para “Mock data type”. Lo que produce esto es que al ejecutar el Debug del workflow, éste se hará trabajando sólo con los datos que hayan sido seleccionados aquí.

Esto lo que permite es ejecutar el Debug de una forma más rápida, ya que se han seleccionado para tal cometido un subconjunto de datos determinado.

Hay otra opción para seleccionar datos más concretos, esta es “Paste and input” poniendo en el “Data type” el valor JSON. No obstante, la salvedad de JSON es que sólo reconoce datos de tipo numérico y de tipo texto, por lo que si hay alguna columna tipo fecha no será reconocida como tal, para sortear este obstáculo, se debe poner un paso intermedio que transforme el tipo de columna.

19. Pruebas de ejecución reales

Aunque el modo Debug es correcto para hacer pruebas de ejecución preliminares, se debe tener en cuenta que la prueba real es ejecutar el flujo completo con la totalidad de los datos.

20. Almacenamiento de nodos como plantillas

Las funciones en ODI son funciones definidas en el sistema que todos los procesos y flujos deberían poder invocar en sus transformaciones, es decir, es como tener una función en Oracle para invocarla cuando al desarrollador le interese. Por ello, en un contexto de migración tecnológica a Stratio, deberían convertirse en funciones que se parametrizan y se encuentran ya almacenadas en el sistema. Para hacerlo, se pulsa click derecho sobre el nodo en cuestión y se selecciona la opción “Save as template”.

Una vez guardada, se almacenará como plantilla a nivel de proyecto. Las plantillas del proyecto se categorizan según sean nodos de  tipo Inputs, “Transformación” o “Output”. En el caso que se ha puesto como ejemplo, el nodo es de transformación.

De esta forma, la plantilla que se acaba de crear ya está disponible para añadirla como nodo en cualquier workflow a través del siguiente menú.

Un detalle relevante de las plantillas a tener en cuenta es que no se pueden modificar al invocarlas en un workflow, solo tienen permisos de lectura. 

21. Tablas temporales

Las tablas temporales son tablas que se generan en un proceso en concreto y que, posteriormente, van a ser utilizadas en varios procesos diferentes. Por este motivo, estas tablas se deben almacenar en una ruta de /rocket/projects/…

En caso de que la tabla vaya a consultarse por muchos otros procesos, se debería incluir en una colección de tipo “con_” terminando con el sufijo “_etl”. De esta forma, al cambiar en un futuro la ruta de la tabla, solo habrá que volver a virtualizarla y todos los procesos que lean de la misma, no requerirán modificaciones.

22. Descripción de flujos

La descripción de cada flujo debe ser lo más completa posible, persiguiendo el objetivo de que al ser leída por cualquier otro desarrollador que no sea el creador del flujo, éste pueda saber esclarecidamente las acciones que el workflow realiza.