[[TOC]]

---

La definición de área de landing es que sea un conteiner o storage account (inmutable) con la cual se puede subir los datos como fueron generados en el sistema origen. Sin embargo, consideramos los datos que llegan a el área de landing podrán tener errores por la generación en su fuente, duplicidad o datos en columnas que violar reglas de dominio de datos, por ejemplo un precio aparecer con valor negativo, o un campo que sea una fecha presentando fechas en el futuro.

• Área de land representa un punto de entrada de datos.
• Los datos no deberán modificarse a lo largo del tiempo.
• Los datos deberán de ser estables o no sufrir ningún proceso de purgado mientras la política de gobierno de datos considera que estos siguen aportando valor al negocio.
• La organización deberá de definir la política para el momento de purgado de datos a luz de la posibilidad de aportar valor a los datos y requerimientos de compliance.
• Distintos repositorios/carpetas dentro de el área de land podrán tener reglas distintas para la gestión y mantenimiento (access tier hot/cold o reglas para purgado)
• Por defecto el landing es un repositorio con access tier cold (por volumen y costo), los datos capturados podrán ser originales, en este sentido estos podrán ser comprimidos o no.

• Captura de Event Hubs
• Datos originales desde otras fuentes de datos
• Datos historicos

• Los datos en el landing deberán de estar organizados en carpetas por tipo de documento cargado.

• No importando la fuente, en todos los escenarios, los datos crudos deberán de llegar a el área de landing, además deben de no sufrir ningún cambio, validación o otra intervención en los mismos

• Considerar formatos de archivos soportados para lectura en Azure Databricks:

  • Planos (.csv)
  • Captura de eventos de event hub, AVRO
  • JSON
  • parquet

• Los procesos de carga de datos pueden ser por

  • Batch, usando:
    • Azure Data Factory
    • AzCopy
  • Continuados usando streaming

El área de landing es un storage account, con el cual los datos estarán organizados en distintos containers de acuerdo con la utilización:

• Datos de Common Data Model (Integración con Dynamics): CDM
• Datos crudos de integración de los distintos sistemas: Land
• Captura de eventos de Event Hubs: Capture

Específicamente, el container de land deberá de ser organizado en una estructura de carpetas, planificada para facilitar el proceso de otorgar permisos y la organización de los datos.

/Land/{Area}/{sistema}{Entidad}/{Partición}

Onde {Partición} considera el modelo de particionamiento elegido para una determinada entidad, por ejemplo, si los datos son generados en archivos diarios, la jerarquía de particionamiento podría ser:

Ejemplo: /Land/{Area}/{sistema}{Entidad}/{Año}/{Mes}/{Día}

La definición de una jerarquía de archivos a modo de particionamiento es importante por dos razones, por organización del datalake/Land y por rendimiento. En Azure Data Lake Storage gen2 la estructura de los datos, como la jerarquía en el particionamiento tiene influencia en el rendimiento.

---

El area trusted tiene los datos con la misma granularidad de los datos en landing, pero especificamente para los archivos JSON, los distintos niveles fueron explotados en entidades en trusted. Cada archivo JSON resultante de los procesos en middleware debera de resultar en varias tablas en el area trusted.

• Datos con la misma granularidad de landing.
• Datos validados, por dominio de datos, nulos o no, rango de datos valido, o contenido.
• En los ambientes de Desarollo o QA, las informaciones personales deberan de ser enmascaradas por razones de privacidad y compliance con HIPAA, por ejemplo.
• Los procesos de carga de datos deberán de resultar en tablas delta en el data lake las entidades que correspondan a Trusted.

• Datos cargados a partir de los archivos originales (a partir de land)
• Específicamente, los datos que llegan desde las fuentes, podrán representar distintas entidades de negocio adentro. Entonces, el proceso de captura de datos a trusted efectivamente toma los datos los explota a múltiples tablas en trusted.
• Las tablas en trusted serán Tablas Delta, por control de concurrencia, características de gestión granular de datos (DELETE, UPDATE, MERGE) además de otros recursos como permitir consultas a datos anteriores a actualizaciones.
• Se supone que los datos que llegan desde el área de landing, llegan con un nivel de integridad en el origen. Datos que durante su procesamiento son inválidos o insuficientes para cargar a trusted, serán rechazados y para análisis serán enviados para una carpeta "bad" disponible en cada carpeta de las entidades en trusted.
• los datos cargados en las tablas serán ubicados en la carpeta tabla/data

En el ejemplo:

• temp: Para archivos o datos intermedios, o incrementales a modo de durante el procesamiento aislar de los datos completos
• util: Para uso de archivos de configuración para los procesos, archivos de schema, parámetros o metadatos.
• bad: Para los datos rechazados, la propuesta es tener los datos rechazados para debug de los procesos, estos datos son temporales
• data: Para los datos efectivamente cargados, la carpeta data de cada tabla, será la ubicación definida para las tablas delta.

---

El area Refined se dedica a especialización de casos de uso con datos ya validados en el área de trusted. Sin embargo, datos en refined pueden pasar por procesos más complejos de transformación y agregación de datos. El area de refined, sigue la misma taxonomía que tenemos en trusted, pero prodrá crear nuevas entidades/tablas en los dominios.

• Tablas delta con datos refinados, agregados y validados para consumo en reportes
• Datos en refined deberán de ser consistentes con las reglas de negocio, aun que sea necesario validar contra otras tablas, hacer joins.
• Datos en refined podrán manejar datos históricos, los procesos de transformación podrán tener una característica incremental dependiendo del volumen y de las reglas de negocio aplicables
• Tablas refined podrán usar como insumo otras tablas en refined. Importante es tener una buena coordinación de los procesos para tener estos datos lo mas actualizados posibles
• El detalle sobre los metadatos deberán de estar documentados en el catalogo de metadatos - Azure Data Catalog

• Datos en refined deberán de ser tablas delta por defecto;
• Datos sumarizados a partir de datos capturados desde trusted o desde otra tabla en refined
• Los procesos de captura y transformación de datos en las tablas refined podrán hacer validaciones con otras tablas delta en trusted o tablas delta en refined.
• En refined, los distintos bancos de datos en databricks podrán armar esquemas en estrella usando tablas de dimensión a partir de datos en trusted y tablas hecho creadas a partir de los datos en trusted o a partir de otras tablas en refined.
• En refined, la duplicidad de datos que tenemos en trusted podrá ser retirada por el uso de los últimos datos, a partir de la fecha hora de actualización de los datos, o por algún proceso que haga un "distinct" en los datos.
• Por un tema de costo de procesamiento, si necesario de forma recurrente la toma de los últimos datos actualizados o el uso de disctinct crear una tabla delta en refined con estos datos (sin duplicidad) para rehusar en otros procesos.

• Usar lenguaje SQL para generar vistas y datos con cálculos simples. Para cálculos complejos, usar Python en procesamientos complejos.
• Cada vista o tabla temporal, al final del notebook deben ser eliminadas para no consumir memoria que no se utilizará más.

---

Área empleada por equipo de Data Science para volcar la información de modelos de manera temporal teniendo oportunidad de experimentar con los datos y generar data necesaria tanto para consumir como para evaluar modelos de ciencias de datos.

Es un área dedicado a uso por procesos de ciencia de datos, pero con la exportación de los datos necesarios a creación de modelos, que tengan sido capturados a partir del data lake en el formato solicitado por el científico de datos. El uso permite la experimentación, creación de datos intermedios, filtrado y agregación de datos sin la preocupación de impactar datos en producción.

• Creación de muestras de datos de el entorno de desarrollo/producción para generación de modelos
• Desarrollo de notebooks de Data Wrangling en notebooks Databricks usando lenguajes de ciencia de datos, tales como Python o R.
• Desarrollo de notebooks de entrenamiento de modelos;
• Desarrollo de notebooks para validación de métricas de modelos
• Exportación de modelos serializados como archivos .pkl o .onnx usando MLLeap
• Gestión de modelos entrenados usando MLFlow en Databricks

• Selección de una muestra de los datos. Spark SQL: Tablesample
• Separación de carpetas para los experimentos
• Uso de archivos en formato parquet. Por rendimiento en los scripts. No utilizar archivos csv.
• Definir política de administración para borrar los archivos en sandbox sin utilización.

• Spark Structured Streaming documentation
• Tablas Delta
• Enmascaramiento de datos usando codigo en spark - ejemplo
• Table Access Control
• Privilege data access
• Privicera