[[TOC]]

El Azure Datalake Store es una plataforma como servicio de almacenamiento de datos a escala. Efectivamente, ADLS (Azure Datalake Store) Gen2 es una cuenta de almacenamiento con una caracteristica habilitada (hierarchical namespaces). Además permite el uso de controladores (drivers) específicos para apalancar mejor rendimiento y gestión de seguridad.

Azure Data Lake Store Gen2

• Service Principal (s) para los Databricks clusters
• El Service princial debe de estar en los roles de Storage Blob Data Contributor y Storage Blob Data Reader
• Como regla general, pocos usuarios deberán de tener acceso directamente al data lake store. -Específicamente en Databricks, un clúster puede estar habilitado con authentication passthrough, con la cual puede través de código en databricks podrá "impersonar" los permisos del dicho usuário.

{zona}/{dominio}/{subdominio}/{entidad}/temp/

{zona}/{dominio}/{subdominio}/{entidad}/data/{partición}

{zona}/{dominio}/{subdominio}/{entidad}/bad/

{zona}/{dominio}/{subdominio}/{entidad}/util/

Los domínios definidos para las zonas del datalake son los siguentes:

Uso:

Para cada entidad, que será la ubiciación de las tablas delta, será estructurada con las siguentes subcarpetas:

• Carpeta temp, para agregar nuevos datos permitiendo creación de un dataframe solamente con nuevos datos. Debería de ser limpiada al final de cada uno de los procesos de carga.

• Carpeta data, para grabar los datos procesados, el formato por defecto deberá de ser parquet usando compresión snappy.

  • Artículo- What is parquet?
  • Apache Parquet
  • Parquet Columnar Performance

• bad para dataos rechazados

• util para metadatos, archivos de schema o otros usos de configuración

-Para los clusters parte de los pools configurafos, el cluster databricks debera de ser configurado con un service principal.

• SP (Service Principal) para Databricks clusters

• Debe de pertenecer al grupo “Storage Blob Data Contributor” y "Storage Blob Data Reader" en los storages (land, datalake o otro storage que necesite que se conecte a Databricks) que deberá de conectar, mas específicamente al Azure Data Lake store

• Inicialmente, pocos usuarios deberán de tener acceso directamente a la estructura en el Azure Data Lake Store, esto para reducir la posibilidad de intervenir en la estructura de carpetas o archivos que puedan afectar los pipelines de transformación de datos ya creados. -El control de acceso podra ser granularizado través de los bancos de datos y las tablas en databricks

  • Table Access Control - Object Permissions

Gestión

• Azure Portal
• Azure CLI (for automation)

Exploración

• Storage Explorer

Ingesta

• Azure Data Factory
• AzCopy
• Otra herramienta (Terceros, Logic Apps, Azure Function)

La definición de temperatura de datos es importante a modo un ajuste sobre el nivel de servicio para storage aplicado a los datos, de acuerdo con la expectativa de rendimiento. Además, podemos tener un mejor control de costos, utilizando una capa de almacenamiento más barata, o mismo poniendo los datos en una estructura de "archiving" con la cual los datos no estarán disponibles automáticamente, pero bajo demanda cuando necesarios.

Aquí, detallamos algunos parametros que podrán ser utilizados por cliente para armar sus políticas de gestión de ciclo de vida de sus datos.

"Recency"

• Basicamente configurar un parámetro temporal, datos con mas de 5 años sin actualización serán movidos a una capa cold.

Estadístico

• Para la creación de una determinada medida estadística necesitamos de por lo menos 10 años de datos.

Compliance

• Mi organización es obligada a tener determinado dato disponible en linea por 10 años, los demás podrán estar en un storage lento (archive storage) o seren borrados en definitiva.

Cultura de Big Data

• Mis areas de negocio necesitan de altos volumenes de datos, sin embargo los usuarios no sabem manejar tecnologías de Big Data.En este escenario, podemos tener los datos crudos en un storage cold, y los datos sumarizados en un banco de datos a modo estaren mas cercanos de los consumidores.

Frecuencia de uso

• Datos con 10 años o más, son utilizados solamente una vez cada par de años. Entonces podemos poner una regla para mover estos datos a un storage cold.

Naturaleza

• Mis datos a nivel transacional tienen un volumen tan alto que para almacenar y procesarlos es necesario storage en escala y poder de computo en escala desde el primer día. En este caso, podemos tener los archivos en su area land o trusted en una capa cold desde el primer día, y los datos refinados/sumarizados en una capa hot (rapida) o movidos para una base de datos relacional.

Data Lake Storage Scenarios

Uso

• Datos Hot

  • Datos refined en schemas en Azure SQL
  • Modelos (reusables) creados como datasets en Workspaces/Reports en Power BI Premium
    • Definición por caso de uso
    • Reusables en uno o más reportes

• Datos Cold

  • En Azure Data Lake Store (access tier a definir las reglas cuando en hot, cold o archive)
  • Procesamiento por Databricks
  • Resultados a definir el output por caso de uso
    • Delta Tables (en refined)
    • blob de resultados sumarizados
    • tabla en Azure SQL con resultados sumarizados

Capas de Acceso en Data Lake Store

Es posible automatizar el proceso de cambio de Access Tiers en el storage según reglas que cliente definirá. Efectivamente, Azure Dake Store ahora posee una funcionalidad para gestionar el ciclo de vida de datos, movendolos para una capa cold, archive o borrandolos según reglas establecidas.

En este sentido, las siguentes políticas si definieron en el proyecto como punto de partida sobre el tema de ciclo de vida para los datos: