huemulsolutions / huemul-bigdatagovernance Goto Github PK

Para el SortBy utiliza el primer campo definido como PK que no sea la clave de partición (en caso de tablas transaccionales)

1. Agregar campo isWarning para determinar si DQ tuvo warnings (a nivel grupal y detallado)
2. codificar external_code con las reglas de calidad internas aplicadas.

Recuperar apertura de largo dinámico incluido en versión 1.4.1 que no fue incluido en 2.0

El log de DQ no guarda todos los casos con error

Expected behavior
Registrar en el Log de DQ los casos con error.

Cuando se aplica DataQuality con warnings, el resultado de cada fila/campo se pierde (no se guarda en ninguna parte).

La idea de esta nueva funcionalidad es crear un campo en las tablas maestras y transaccionales, que permita agregar los warnings de dataquality, el campo se llamaría MDM_DataQualityResult y guardaría la información de la siguiente forma: [[NombreCampo]]=ReglaDQ;[[Nombrecampo2]]=OtraReglaDQ;[[NombreTabla]]=ReglaDQTabla

Si el campo está poblado, es porque alguna regla no se cumplió.

Las reglas solo se pueden guardar a nivel de filas, a nivel agrupado no tiene sentido, ya que todas las filas tendrían esa regla repetida

Implementar DataQuality relacionado a otras tablas, pueden ser las mismas validaciones sobre las FK que ya están creadas, o sobre otras tablas.

Upload code beta 0.8

Al invocar método executeOnlyInsert, dar la opción de registrar este insert en el modelo de DQ con la opción de Warning. Lo anterior para los casos de insertar datos que no estén en los maestros, pero que tengan se ser insertados por el proceso TX para garantizar la integridad referencia.

Es necesario mejorar el rendimiento de la ejecución de DQ, por tanto cuando termina el proceso de generar el DF final, se debe dar la opción de dejar en cache.

Se debe agregar parámetro de cache en métodos executeOnlyInsert, ExecuteFull, executeOnlyUpdate, executeSelectiveUpdate

Si no se especifica o se envía null, no aplica cache.

El desarrollador que utilice esta opción, debe conocer las limitantes de memoria

Agregar un atributo en las columnas que permita asociar un id externo de conceptos de negocio (dimensiones, ontología u otro similar).

Pueden haber tablas que ya existen en el ambiente, o datos que fueron cargados sin aplicar el 100% del DQ, para estos casos se debe ejecutar un DataQuality a nivel de stock.

Se debe evaluar si el resultado de este DQ se debe guardar en la misma estructura de PostreSQL, o generar una nueva tabla para almacenar exclusivamente este resultado.

En vez de sobreescribir directamente el parquet al guardar una tabla, se puede crear una versión _new del parquet nuevo, luego borrar la anterior y luego cambiar el nombe de _new a la oficial. de esta forma se maximiza el tiempo de uso de este archivo, se evita que otros procesos que lo necesitan fallen.

Evaluar.

Actualmente el método open de DataLake devuelve un objeto RDD. Esta nueva funcionalidad agrega un método que abre el archivo devolviendo un objeto DataSet.

Se debe crear un nuevo método similar a OpenFile.

Al terminar el proceso, se muestra la fecha de término, sin embargo el tiempo transcurrido no se muestra.

También es necesario cambiar el orden del mensaje, primero se debe mostrar el nombre del proceso, luego el id y finalmente el tiempo transcurrido.

agregar ejemplos cuando falla DQ. los ejemplos se pueden poner solo para dataquality de tipo row

Actualmente cuando se guarda el detalle de registros que falla una prueba de DQ solo lo hace cuando la validación es a nivel detallada, para el caso de PK y FK no guarda nada.

Se requiere guardar este detalle, ya sea en una estructura del modelo de control nueva o en alguna ya existente

Agregar una nueva opción a las reglas de DQ, que permita identificar qué hacer con los registros fallidos en DQ. Actualmente hay dos posibles comportamientos: Error (el proceso falla completamente) y warning (el proceso no falla). En ambos casos se registra en el modelo de control, y al fallar la regla de DQ se registran los casos fallidos en la tabla de detalle.

Lo que busca esta nueva funcionalidad, es agregar un nuevo tipo llamado "EXCLUDE", que permita excluir los registros fallidos a una tabla de "cuarentena", en este caso el proceso no se cae, pero registra los casos fallidos en el modelo de control de calidad, asociados al proceso que falló.

Una vez que se hayan resuelto los problemas,

Para esto se debe hacer lo siguiente:

1. modificar enumeración, para agregar el tipo "EXCLUDE"
2. Incluir nuevo path en global Settings, donde se puedan guardar estos registros por cada proceso
3. agregar parámetro en cada método "set" de DQ, de modo tal que permita identificar el tipo de acción (actualmente solo error), a Error, warning y exclude
4. Agregar un método en la tabla, llamado "ExecuteRetry", donde reciba el Id del proceso que falló. Esta función debe juntar el DF malo con el DF bueno, y volver a aplicar todas las reglas de calidad, en caso de ser erroneo, volverá a generar una nueva tabla de cuarentena, en el caso de ser correcto, el proceso anterior quedará "cerrado".

Adicionalmente, se debe modificar el modelo de control, para agregar un nuevo campo en la tabla "control_tablesuse", que permita identificar si la tabla tuvo registros excluidos o no.

Se requiere una forma de determinar rápidamente si el 100% del plan de pruebas se ejecutó en forma correcta o no

Actualmente huemul despliega un ejemplo de los datos de un archivo de texto, se debe agregar un parametro para determinar si el desarrollador desesa o no mostrar ese resumen de datos.

Mejorar SP en Postgre para buscar Id de Tablas al agregar campos.

Agregar las siguientes funciones públicas:

1. getDQResult: retornar los campos de la tabla DQ filtrados por processExec_Id, devolver en un DF
2. getErrors: retornar los campos de la tabla errores filtrados por processExec_Id, devolver en un DF
3. Implementar funciones en huemulBigDataGovernance (clase principal), que replique el getPath y getDataBase, sin la necesidad de enviar el parámetro de conexión de huemul.

Se requiere incluir el id del resumen de data quality en el detalle de filas que no cumplen con el criterio de data quality

Incluir validaciones al inicializar HuemulDataGovernance, de tal forma de validar si todos los métodos requeridos en globalSettings están con valores.

Cambiar nombre de archivos temporales a id autogenerado, y eso guardarlo en un arreglo con las querys usadas.

Agregar una tabla a modelo PostgreSQL para que se puedan visualizar, con link en ejecución de procesos y steps

En ocasiones algunos campos pueden tener un salto de línea incluido en el texto, esto hace que la lectura del fichero interprete erróneamente como una nueva línea.

La idea de esta nueva funcionalidad es forzar la lectura de las N columnas, independiente que existan saltos de línea en un campo en particular.

La lectura de interfaces RAW con posición fija requiere considerar que el último campo puede venir con largo variable.

Ejemplo
campo1Campo2Campo3
Campo4CAmpo5Campo66

En este ejemplo, el último campo puede tener un largo dinámico, por tanto la lectura por posición fija no funciona, debido a que la primera fila tiene un largo menor que la segunda.

La solución implica enviar un -1 al campo en cuestión, eso significa que el largo del último campo será igual al largo desde la posición inicial especificada en la configuración, hasta el largo de la fila.

Dar vuelta mensaje cuando inicia proceso en control, poner primer nombre, después id

Actualmente solo está la descripción del plan de pruebas, se debe agregar un identificador de usuario, de esta forma el usuario puede tomar el resultado y cruzar con su sistema local de control de DQ/QA. Esto implica una modificación en el modelo de datos del modelo de control.

Se requiere la creación de nuevas funciones para apoyar la ambientación del plan de pruebas:

1. Función para saber si existe una tabla creada: esto permite saber si la tabla existe o no
2. Función para crear la estructura vacía de la tabla: en caso que la tabla no exista, se puede crear la tabla

Actualmente no hay un parámetro para indicar el número de particiones para almacenar los datos en cada tabla.

Se deben agregar parámetros en la definición de la tabla para indicar nuevas particiones (para usar con coalesce o repartition).

Esta mejora es importante para administrar de mejor forma las tablas con tamaño menor al bloque definido en HDFS

Cuando intenta agregar un registro al modelo de control no puede, el error es porque el usuario no tiene acceso a escribir, pero eso se pudo ver en modoDebug, cuando estaba en modo normal el programa se cae con nullException y no hay mayor detalle del error.

El bug no es crítico

Dado que los catálogos maestros son imprescindibles para la gestión de la organización, es importante mantener N cantidad de copias de seguridad. Estas copias pueden ser restituidas en caso de procesamiento erroneo.

Actualmente se guarda la última versión en la carpeta temporal, lo ideal sería tener una carpeta de backup configurada en GlobalSettings, o en su defecto generar un archivo de backup en la misma ruta donde está el archivo vigente (evaluar qué es mejor), y además agregar un campo en la tabla control_tables que indique el N° de copias de seguridad, y crear una tabla en PostgreSQL que administre estas versiones, así se puede ir eliminando las versiones más antiguas.

Agregar una tabla que indica el nombre del proceso, y los valores de parámetros que están bloqueados para ejecutar.

Supongamos que el cierre de mes ya fue realizado, para prevenir que esto se vuelva a ejecutar, se pueden ingresar los datos a esta tabla, y el proceso (usando el mismo modelo de control) puede evitar que se vuelva a ejecutar.

No tendría ningún tipo de �modificación a nivel de codificación del lado del usuario, solo se deben ingresar los datos en la tabla del modelo de control (postgreSQL).

Enviar los mensajes de consola usando los métodos de Logs.

Al almacenar la información en HDFS no se está especificando el nivel de compresión (se deja el que trae por default).

Se debe agregar esta característica, para que los usuarios la definan.

Si no se especifica, el comportamiento debe ser el mismo que el actual (el default definido por la configuración).

implementar un comando que permita habilitar o deshabilitar el despliegue del plan de ejecución de cada dataframe,

Hacer script para crear las tablas del modelo de control en cualquier motor que soporte jdbc.
Modificar funciones en huemul_control y agregar parámetro para definir en qué motor de datos se �guardará el modelo de control (postgresql, mysql, sql server, etc).
Se debe eliminar el uso de procedimientos almacenados

Está relacioando con tarea de mejorar búsquedas en modelo de control #12

Integrar modelo de control con Atlas, de tal forma que linaje y DQ pueda ser visualizado por Atlas.

Agregar
SandBox_Risk
SandBox_MIS
SandBox_Commercial
SandBox_Finance
SandBox_Op

El campo MDM_StatusReg queda en 2 al insertar un registro, cuando se elimina queda con -1, sin embargo cuando el registro vuelve a existir el campo MDM_StatusReg queda con -1, debe quedar con valor 2

Para reproducir
Seguir los siguientes pasos

1. crear una tabla tipo master
2. insertar un registro en interfaz txt, cargar la tabla con interfaz
3. eliminar el registro de interfaz y cargar en tabla
4. volver a cargar la interfaz del paso 2, el campo MDM_StatusReg está con valor -1

Comportamiento esperado
Se espera que el campo MDM_StatusReg tenga valor 2 después del ejemplo.

Se requiere especificar un Id externo en las reglas de Dataquality.

Hacer ajustes de la versión 2.0 al generador de código

Revisar dependencias de librería en mvn repository y ajustar en pom del proyecto (revisar link: https://mvnrepository.com/artifact/com.huemulsolutions.bigdata/huemul-bigdatagovernance/2.0)

Si el usuario ya tiene una sesión iniciada de spark, huemul la debe permitir usar

Se requiere conectar el modelo de control con Oracle y con SQL server

Implementar trazabilidad a nivel de campos, identificando cada query que se ejecuta dentro de un proceso, y mapeando con los campos de la query anterior

review all clasees in order to improve comments on code.

it's important to know if all settings are ok before start to use HuemulLibrary, for that, the library must have a Test method to:

1. test PostgreSQL connection (for example a select now() and select top 1 from some table)
2. test Hive Conection (for example select now() from hive), the database must be created before?
3. create a tempfile in hdfs path.

In this way, it's important to create a method to enable the system, for instance:

1. create all PostgreSQL tables and functions in the DataBase (must be the database created before?)
2. create hive databases?
3. create HDFS directory?

Guardar todos los cambios de tablas máster y reference.

Revisar la mejor estructura con precaución de administración de archivos pequeños.

Asignación de id a cada regla de calidad, guardar en modelo de control