Subdirección de las Tecnologías de la 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 parquets.

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 en minúsculas, incluso cuando el activo se corresponde con una base, esquema o tabla de datos.
• 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.

Inicialmente, se indica a cuál de las tres capas que se muestran a continuación pertenece la colección.

• raw.  Se refiera a la capa raw.
• cur.  Abreviatura de la capa curación.
• con.  Abreviatura de la capa consumo.
• ori.  Se refiere a la capa origen.

Es importante destacar que, para las capas de origen y raw, la herramienta Stratio no permite modificar los nombres de las tablas y columnas que se leen de forma automática de las fuentes orígenes. En este sentido, como los orígenes de datos se encuentran en Oracle, los nombres de sus tablas y columnas aparecerán en mayúsculas y con los nombres originales de las mismas.

Después de indicar la capa a la que pertenece 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.

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

Por ejemplo: cur_historia_salud

Para los casos de uso de analítica avanzada, se crean diferentes tipos de tabla en la capa de curado. Cada una de ellas presenta una finalidad específica y un sufijo al final de su nombre para identificarlo. Por este motivo, las colecciones que se generen para los casos de uso de analítica avanzada presentarán los siguientes sufijos.

• par. Se refiere a aquellas tablas parciales, así como uniones de tablas, que sirven para desarrollar los casos de uso.
• ent. Se refiere a aquellas tablas que sirven de entrenamiento para los diferentes modelos de analítica.
• trf . Se refiere a tablas de transformación, aquellas que son finales del caso de uso pero que todavía no se encuentran preparadas para su explotación en la capa de consumo.

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.

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.

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.

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.

Las 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.

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.

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 “neg” que apuntan a /consumo o a _postgres (versión más consistente y generada en HDFS por procesos ETLs de Stratio), o en su defecto a /curado_sas (segunda versión más consistente). Normalmente, la colección a consumir y usar es la colección “neg”, 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 que no hacen alusión alguna a los datos ni al nombre de la tabla.

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.