Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
La base de datos en la que se basa la colección existe
Se ha definido el propietario del dato
Se ha definido el responsable del dato
Los permisos de acceso y consumo han sido definidos y validados
El nombre cumple con la normativa establecida por la organización
Contiene los metadatos mínimos asociados
El formato de los metadatos asociados cumple la normativa
El campo de descripción del activo se encuentra completo
Se ha comprobado que las colecciones utilizadas para el desarrollo existen en los entornos productivos
El formato de los metadatos asociados sigue la normativa
El campo de descripción se encuentra completo
La sensibilidad de la información ha sido definida y validada
Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
El nombre cumple con la normativa establecida por la organización
Contiene los metadatos mínimos asociados
El formato de los metadatos asociados sigue la normativa
El campo de descripción del activo se encuentra completo
Las reglas de calidad han sido aprobadas por el responsable correspondiente
Se ha definido y validado el umbral necesario para las diferentes reglas de calidad
Los resultados de los perfilados de datos son tratados correctamente
La frecuencia de ejecución de las reglas de calidad ha sido definida y validada por el responsable correspondiente
La tipología de relaciones utilizada está dentro de las establecidas por la organización
La relación entre assets que se desea realizar está entre las recogidas por la organización
Se cumple con la estructura del activo (Colecciones/Reglas de calidad) establecida por la organización
Se ha definido el propietario del dato
Se ha definido el administrador del dato
Los permisos de acceso y consumo han sido definidos y validados
El nombre cumple con la normativa establecida por la organización
Contiene los metadatos mínimos asociados
El formato de los metadatos asociados es el correcto
El campo de descripción del activo se encuentra completo
La tipología de activos de negocio utilizados se recogen en las acordadas por la organización
Contiene los metadatos relacionados con la definición del linaje (transformación y origen)
Las tipologías de relaciones establecidas para la definición de linaje cumplen con la normativa constituida
Los nombres de los assets cumplen con la normativa establecida por la organización
Se ha evitado el uso de cajas PySpark y PySparkUDF
Se ha definido el responsable del desarrollo
Se ha definido el responsable del proceso de carga
Contiene los metadatos mínimos asociados
El formato de los metadatos asociados es el correcto
Se han definido las relaciones con otros assets
Los assets de los que depende existen y funcionan correctamente
La fuentes de datos de las que se hacen uso están correctamente definidas
Se siguen las buenas prácticas impuestas para la correcta gestión de proyectos y el correcto desarrollo de workflows
Los nombres de los DAGs cumplen con la normativa establecida por la organización
Se han añadido en el script de python etiquetas que hacen referencia a los proyectos o desarrollos a los que pertenece el DAG
Se ha almacenado el DAG en la carpeta "dags_sas" de Git, dentro de la subcarpeta correspondiente a su proyecto
Se han almacenado las funciones a las que invoca el DAG en la carpeta "librería_sas" de Git, dentro de la subcarpeta correspondiente a su proyecto
Se respetan las directrices recogidas en la normativa sobre la forma de hacer las llamadas a los flujos
Se han añadido descripciones a los DAGs, a los grupos de tareas y a cada tarea en concreto
Se han añadido parámetros a los DAGs y a sus tareas, y descripciones de esos parámetros
Los tamaños de los archivos parquets cumplen con el tamaño establecido en la normativa
La columna de partición no contiene nulos y es equidistante
La columna de partición elegida es técnicamente correcta
Se han ingestado y curado aquellas tablas que requerían añadir alguna columna
La tabla se ha almacenado donde corresponde según su cantidad de registros
Las tablas ingestadas y/o curadas se han ubicado en la capa que corresponde según establece la normativa
Las carpetas "…incremental" se han incluido en el backup de HDFS
Las particiones, índices y claves primarias son idénticos en Postgres y en Oracle
Las tablas almacenadas en Postgres tienen menos de 5 millones de registros
Las tablas son consistentes en todas las instancias
Los nombres de las tablas, campos, secuencias, índices, constantes y esquemas siguen las pautas establecidas en la normativa
Manual de Instalación/Desinstalación
Instalación
Procesos de promoción
Governance - Colecciones
Implementar la promoción a través de Jenkins, dentro del proyecto Governance, mediante la opción Build with Parameters, estableciendo los parámetros necesarios.
Governance - Resto asset
Desde el entorno de origen ir a Opciones → Export y seleccionar el asset que se desea promocionar, estableciendo la configuración a exportar.
Al exportarlo se descargará un archivo .zip que se debe importar en el entorno de destino. Dicha acción se realiza desde Opciones -> Import.
Rocket
Acceder a la opción Promote version dentro de la interfaz de edición del asset que se desea promocionar.
Determinar los parámetros necesarios para la promoción: asset, version, dependencias y settings.
Seleccionar promote para llevar a cabo la promoción.
Actualización de un asset existente.
En el caso en el que se requiera la actualización de un asset ya existente para posteriormente ser promocionado, los pasos a seguir serían los siguientes:
Actualización de asset en Governance
Modificación del asset en el entorno de desarrollo con las actualizaciones pertinentes.
Actualización del atributo atr_version con la versión correspondiente.
Borrado del antiguo asset en el entorno de destino. Este borrado es necesario ya que si el asset a promocionar existe en el entorno destino, el proceso de promoción no contempla la sobreescritura de los Custom Attributes, por lo que estos serán duplicados.
Promoción del asset actualizado a través de los pasos anteriormente citados en (1) o (2).
Actualización de assets de Rocket
Creación de una nueva versión del asset a través de la opción Save → Save as new version.
Promoción de la nueva versión del asset a través de los pasos anteriormente citados en (3).
Desinstalación
En el caso de necesitar volver a una versión anterior tras la realización de una promoción, los pasos a seguir serían los que se detallan a continuación.
Restaurar versión anterior - Governance
A través de Git y dentro del proyecto Governance, se encuentran los diferentes assets existentes en cada uno de los entornos, así como el histórico de cambios.
Se debe acceder al entorno deseado y restaurar la versión que se requiera.
Restaurar versión anterior - Rocket
Acceder al menú Admin Proyect - Backups y restaurar la versión a la que se requiera volver.