Estándares y Lineamientos
Cloud en Azure Desarrollo
Documento de estándares técnicos para nomenclatura, construcción de componentes, notebooks, pipelines y buenas prácticas de datos sobre Azure.
| Campo | Valor |
|---|---|
| Versión | 2.0 |
| Autor | Diego Eduardo Martin Avila Sanchez |
| Fecha creación | 05-02-2025 |
| Fecha y hora de impresión | 05-02-2025 |
| Responsable del documento | Diego Eduardo M. Avila Sanchez – diego.avila@alpura.com |
| Título del Documento | Estándares y Lineamientos – Infraestructura Azure |
| Última Versión | Versión 2.0 |
| Nombre del archivo (.docx) | ALP_IM_Estandares y Lineamientos_Infra v1 – Data_Factory |
| Fecha de creación | 05-02-2025 |
| Última modificación | 05-02-2025 |
Control de versiones del documento
| Fecha | Versión | Descripción | Autor |
|---|---|---|---|
| 05/02/25 | 1.0 | Generación del documento | Diego Eduardo M. Avila Sanchez |
| 12/02/25 | 2.0 | Actualización del documento | Luis Angel Trujillo Mendoza |
Tabla de contenido
- Introducción
- Propósito
- Alcance
- Descripción de la Arquitectura
- Componentes en Data Factory
- Nomenclatura
- Componentes en Databricks
- Construcción de Notebooks en las Capas Silver
- Databricks Unity Catalog
- Estándares Capa Gold
- Mejores Prácticas y Recomendaciones
Introducción
Este documento establece una convención estandarizada para la creación de nombres de recursos dentro de la plataforma Microsoft Azure. Una nomenclatura adecuada facilita la administración, automatización y comprensión de los recursos desplegados en la nube, especialmente en entornos empresariales donde existen múltiples suscripciones, proyectos y ambientes.
Propósito
El presente documento tiene como objetivo plasmar la definición de los Estándares y Lineamientos de desarrollo de los diferentes componentes dentro de la plataforma de Azure de acuerdo con la arquitectura definida por Microsoft siguiendo las mejores prácticas.
Alcance
En este documento describe y concentra los estándares y lineamientos de desarrollo establecidos por Microsoft siguiendo las mejores prácticas para los diferentes componentes que conforman una solución a una iniciativa dentro de la plataforma Azure.
El documento comprende las siguientes secciones:
- Introducción: Describe el ámbito de acción del documento.
- Arquitectura: Describe los componentes principales dentro de la infraestructura de Azure.
- Nomenclatura: Describe los lineamientos de nombrado para la construcción de componentes dentro de Databricks y Data Factory.
- Estándares Capa Bronze: Describe los estándares y lineamientos dentro de la capa bronze.
- Estándares Capa Silver: Describe los estándares y lineamientos dentro de la capa silver.
- Estándares Capa Gold: Describe los estándares y lineamientos dentro de la capa gold.
- Estándares Capa Curated: Describe los estándares y lineamientos dentro de la capa curated.
- Mejores Prácticas y recomendaciones: Se definen algunas recomendaciones a seguir durante la construcción de los notebooks y pipelines.
Descripción de la Arquitectura
La arquitectura propuesta para Alpura en Azure contempla una infraestructura híbrida y segura que integra múltiples fuentes de datos, servicios de procesamiento, almacenamiento y consumo, así como componentes de seguridad y administración.
Toda esta infraestructura será desplegada respetando las convenciones de nombres descritas en este documento, asegurando claridad operativa, trazabilidad y escalabilidad del entorno en Azure.
| Componente | Descripción |
|---|---|
| Fuentes de datos | Se integran datos desde múltiples orígenes como ERP (Tirara), bases de datos en GCP, almacenamiento histórico en IBM, archivos planos (Excel, CSV, TXT), sistemas Oracle y fuentes externas como Nielsen y Digins. |
| Red privada y seguridad | Todo el tráfico hacia Azure está protegido a través de una red privada, Firewalls, y conexiones VPN seguras, con autenticación mediante Active Directory. |
| Procesamiento y Orquestación | Se utilizará Azure Databricks para el procesamiento de datos mediante clústeres escalables y notebooks organizados por ambiente (Bronze, Silver, Gold). Las tareas serán orquestadas mediante workflows que podrán integrarse con servicios como Azure Data Factory. |
| Almacenamiento | Los datos serán almacenados en una arquitectura de capas (Bronze, Silver, Gold, Cifrado) sobre Azure Data Lake o cuentas de almacenamiento. |
| Recursos de Consumo | Se utilizará DBT para transformación de datos y generación de modelos. Las salidas serán consumidas en Power BI a través de workspaces definidos. |
| Automatización y DevOps | Se cuenta con agentes dedicados para tareas de automatización, integración continua y despliegue (CI/CD) conectados a repositorios de Azure DevOps. |
| Notificaciones y Monitoreo | Se establecerán procesos para el envío de notificaciones por correo y alertamiento, integrados con pipelines específicos. |
Capas de datos
| Capa | Objetivo |
|---|---|
| Bronze | Almacena la información cruda e ingestada mediante un snapshot en archivos con formato parquet para cada ejecución. |
| Silver | Almacena la información cruda e ingestada en tablas con formato delta de forma completa o incremental. |
| Gold/Consuption(Opcional) | Almacena información precisa con un enfoque corporativo Global en un modelo de datos definido. |
| Curated | Almacena información con la aplicación de reglas de negocio integrando dominios de datos en un modelo de información no relacional. |
También considerar el procesamiento de carga el cual depositara y aplicara reglas de negocio a la información de la capa curated en un modelo de datos final dentro de la capa de Consumption, este modelado no necesariamente aplica para todos los negocios, algunas capas pueden diferir si se crean o no, de acuerdo con la necesidad y la solución establecida.
Componentes en Data Factory
Los Componentes de Data Factory se Distribuyen en 2 Partes los cuales son:
- Recursos: Aquellos Objetos que se necesitan para las embeber las actividades y orquestar procesamientos.
- Actividades: Componentes u Objetos dentro de los Recursos, que se utilizan para generar o aplicar ciertos filtros con unas o más actividades.
Recursos
- Carpeta Principal:
- parent: Inicial el Clúster o la Escalabilidad o ayuda de ejecuciones paralelas.
- child: Llamada de actividades de ejecución o mantenimiento de paralelismo.
- infant: Utilidades de la operación, Manejo de Errores.
Recursos de Data Factory
| Nombre | Sintaxis | Prefijo | Ejemplo |
|---|---|---|---|
| Pipline | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | PL | PL_TRN_TransformacionFecha |
| Template Gallery | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | TG | TG_TRN_TransformacionFecha |
| Dataset | <Prefijo>_<TipoComponente>_<AcciónPrincipal> | DS | DS_SQL_Transforma_Datos |
| Data Flow | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | DF | DF_TRN_CargaVentas |
| Flowlet | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | FT | FT_TRN_Productos |
| Power Query | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | PQ | PQ_CRG_Ventas |
| Copy Data tool | <Prefijo>_<TipoAccion>_<AcciónPrincipal> | PL | PL_CRG_Productos |
Describe si es una ejecución (EXEC), extracción (EXT), Transformación (TRN) o Carga (CRG).
Actividades
| Nombre | Sintaxis | Ejemplo |
|---|---|---|
| Copy Data | <AcciónPrincipal> | CargaDatos |
| Data Flow | <AcciónPrincipal> | Transforma_Datos |
| Azure Data Explorer | <AcciónPrincipal> | Visualiza_Datos |
| Azure Function | <AcciónPrincipal> | DataTransformation |
| Custom | <AcciónPrincipal> | Csm_DataTransformation |
| Notebook | <AcciónPrincipal> | Product |
| Jar | <AcciónPrincipal> | DataProduct |
| Python | <AcciónPrincipal> | Product |
| U-SQL | <AcciónPrincipal> | LoadData |
| Append Variable | <AcciónPrincipal> | Timestamp |
| Delete | <AcciónPrincipal> | Timestamp |
| Execute Pipeline | <AcciónPrincipal> | Timestamp |
| Execute SSIS package | <AcciónPrincipal> | Esis_Timestamp |
| Fail | <AcciónPrincipal> | DatosVentas |
| Get Metadata | <AcciónPrincipal> | Dataset |
| Lookup | <AcciónPrincipal> | Marca |
| Stored Procedure | <AcciónPrincipal> | DataVentas |
| Script | <AcciónPrincipal> | Ventas |
| Set Variable | <AcciónPrincipal> | Parametros |
| Validation | <AcciónPrincipal> | Datos |
| Web | <AcciónPrincipal> | Web_Reporte |
| WebHook | <AcciónPrincipal> | |
| Wait | <AcciónPrincipal> | Carga |
| Hive | <AcciónPrincipal> | Carga |
| MapReduce | <AcciónPrincipal> | Caracteres |
| Pig | <AcciónPrincipal> | Datos |
| Spark | <AcciónPrincipal> | Extraccion |
| Streaming | <AcciónPrincipal> | Datos |
| Filter | <AcciónPrincipal> | Registros |
| ForEach | <AcciónPrincipal> | Datos |
| If Condition | <AcciónPrincipal> | Tablas |
| Switch | <AcciónPrincipal> | Datos |
| Until | <AcciónPrincipal> | Roadmap |
| Machine Learning Batch Execution | <AcciónPrincipal> | VentasFuturas |
| Machine Learning Update Resource | <AcciónPrincipal> | VentasFuturas |
| Machine Learning Execute Pipline | <AcciónPrincipal> | VentasFuturas |
| Power Query | <AcciónPrincipal> | Tiempo |
El desarrollo de los Pipelines Implementados, deben considerarse los más optimizados posibles y los menos procesos generados, ya que los costos de los recursos de servidores son por contenido de Pipelines y por ejecución, esto lo determinara la solución implementada para cada cliente.
Las siguientes nomenclaturas aplican para los desarrollos de componentes de las capas gold, curated y consumption.
Nomenclatura
Durante el desarrollo de procesos o componentes se deben de tomar en cuenta los siguientes lineamientos y estándares para el nombrado y definición de los diferentes componentes desarrollados para una solución.
Esquemas de bases de datos
Para las capas Bronze y Silver es importante señalar que tiene una dependencia importante de la configuración de la metadata y se debe respetar mantener el mismo nombre de las conexiones en los tres ambientes (DEV, QA y PROD) para evitar un ajuste de código al hacer los pases entre los diferentes ambientes.
<Capa>_<Descripción>
Ejemplo:
gold_conpt_
silver_conpt
curated_conpt
Donde:
-
Capa: Es el nombre de la capa donde se lleva a cabo el procesamiento, donde los valores posibles son:
- silver
- gold
- curated
-
Descripción: Nombre que describe de manera general la información almacenada en el esquema en idioma inglés. Se prohíben caracteres especiales, solo está permitido el guion bajo “_” para separación de palabras.
Tablas
Para la definición del nombre de las tablas se deberán considerar la siguiente nomenclatura:
<Tipo>_<Descripción>
Ejemplo:
Dim_item
Fact_sales
cat_universal_store
Donde:
-
Tipo: Es el enfoque de procesamiento que se le da la información:
- Dim: Procesamiento de dimensión
- Dim_hist: Procesamiento de dimensión histórica
- Fact: Procesamiento fact
- Fact_hist: Procesamiento fact histórico
- Cat: Procesamiento de un catalogo
-
Descripción: Es el nombre alusivo a la dimensión o fact que se está construyendo en idioma inglés. Se prohíben caracteres especiales, solo está permitido el guion bajo “_” para separación de palabras.
Campos
Para la definición de los nombres de los campos se deberá de considerar la siguiente nomenclatura:
- Los nombres de los campos deberán estar descritos en lenguaje inglés o español según sea el requerimiento.
- Se prohíben los caracteres especiales, solo está permitido el guion bajo “_” para la separación palabras.
Definición de Tipos de Dato
| Capa | Tipo de dato | Descripción |
|---|---|---|
| gold y curated | String | Representa valores de cadena de caracteres. |
| gold y curated | Integer | Representa números enteros con signo de 4 bytes. |
| gold y curated | Double | Representa números de punto flotante de precisión doble de 8 bytes. |
| gold y curated | Date | Representa valores que comprenden valores de los campos año, mes y día, sin zona horaria. |
| gold y curated | Timestamp | Representa valores que comprenden valores de los campos año, mes, día, hora, minuto y segundo, con la zona horaria local de la sesión. |
| consumption | nvarchar | Tipos de datos de caracteres que son de tamaño variable, estos tipos de datos almacenan el rango completo de datos de caracteres Unicode. |
| consumption | varchar | Tipos de datos de caracteres que son de tamaño variable, cuando se usa una intercalación habilitada para UTF-8. |
| consumption | datetime2 | Define una fecha que se combina con una hora del día que se basa en un reloj de 24 horas. |
| consumption | Integer | Representa números enteros con signo de 4 bytes. |
| consumption | Decimal | Representa números con una precisión máxima especificada y una escala fija, la cual siempre está definida por una precisión de 26,6. |
Creación de índices y constraint
Para la creación de índices en una base de datos así como tambien la definición de la integridad referencial hacia el modelo de datos se deben tener en cuenta las siguientes consideraciones:
- Índices con prefijo
IDX_(IDX_Client_name). - Claves primarias con
PK_(PK_Client_Id). - Claves foráneas con
FK_(FK_Sales_Client).
Componentes en Databricks
Notebooks (Preparación de Datos y Procesamiento)
Estos notebooks están orientados a las capas Bronze, Silver, Gold, Se deberá construir un notebook por cada tabla generada, si surgiera la necesidad, se podría genera dos o más tablas dentro del notebook, siempre y cuando este justificado y los notebooks deberán de nombrarse con la siguiente nomenclatura:
NB_<Capa>_<Tipo>_<Clave de Negocio>_<Descripción>_<indicador>
Ejemplo:
NB_Gold_Fact_rs_tables
NB_Gold_Dim_cs_customer
NB_Gold_Fact_Sales_h
cur_Fact_Sales_i
Donde:
| Elemento | Descripción | Valores / Ejemplos |
|---|---|---|
| Capa | El nombre de la capa no deberá permitir abreviaturas; En esta capa se realiza el procesamiento. | bronze, silver, gold |
| Tipo | Es el enfoque de procesamiento que se le da la información. | Dim, Dim_hist, Fact, Fact_hist, Cat_Master |
| Clave de Negocio | Es una clave que identifica a los notebooks de data ops dentro de una solución de analítica. | cs, rs, mba, so |
| Descripción | Es el nombre alusivo a la dimensión o fact que se está construyendo en idioma inglés. | Se prohíben caracteres especiales, solo está permitido el guion bajo “_”. |
| Indicador | Opción para identificar si el notebook tiene procesamiento histórico o diario incremental. | i = carga incremental, h = carga histórica |
Estructura y Nomenclatura para Carpetas de Notebooks en Databricks
Para garantizar un orden adecuado de los artefactos (notebooks, scripts y configuraciones) dentro de Databricks Workspace, se adopta la siguiente estructura de carpetas estándar, basada en el modelo de capas y áreas de trabajo.
Directorio raíz:
- Shared
| Carpeta | Propósito | Nomenclatura Sugerida |
|---|---|---|
| 00_Working | Espacio temporal o de trabajo colaborativo para pruebas, experimentación y notebooks en desarrollo. | 00_Working |
| 01_Bronze | Carpeta que contiene los notebooks relacionados con la carga, ingestión y almacenamiento de datos crudos. | 01_Bronze |
| 02_Silver | Carpeta para notebooks de transformación, limpieza y homologación de datos (capa Silver). | 02_Silver |
| 03_Gold | Carpeta destinada a notebooks para modelado, generación de vistas, métricas y explotación de datos (capa Gold). | 03_Gold |
| PoC | Carpeta para pruebas de concepto y pilotos. | PoC |
Ejemplo:
Shared/
├── PoC
├── 00_Working
├── 01_Bronze
├── 02_Silver
└── 03_Gold
- Las carpetas 01_Bronze, 02_Silver y 03_Gold deberán alinearse con la estructura de capas Delta Lake.
- La carpeta 00_Working es un entorno de trabajo no productivo.
- PoC se reservan para desarrollos o experimentos sin impacto en la operación.
- Cada notebook debe reflejar en su nombre la capa y objetivo que cumple.
Nomenclatura para notebooks:
nbk_{nombre_logico}_{layer}_{ambiente}
Ejemplo:
nbk_clientes_ingestion_bronze_dev
Donde:
- nbk = Notebook.
- nombre_logico = Descripción breve de su función.
- layer = bronze, silver, gold, working, poc, innovation.
- ambiente = dev, qa, stage, prod.
Construcción de Notebooks en las Capas Silver
La capa curated es donde los eventos crudos ingestados son transformados (limpiados y refinados) en conjuntos de datos o dominios de datos definidos por negocio para poder ser consumidos directamente por los procesos de carga a la capa de Consumption y/o Global. El objetivo es uniformar la forma en que se almacenan los archivos en términos de codificación, formato, tipos de datos y contenido (es decir, cadenas). También llamada capa conformada.
A continuación, se adjuntan algunos ejemplos de un notebook de la capa curated para una tabla transaccional, dimensión o notebook de MLOps:
Los modelos de datos construidos y definidos dentro de esta capa deben de cumplir los siguientes lineamientos:
- Los modelos no podrán ser relacionales ya que dentro de este tipo de tablas en formato delta no permite la creación de llaves foráneas o llaves primarias.
- La relación entre estas tablas deberá mantenerse de forma lógica mediante la identificación de claves de negocio.
- Los modelos dentro de esta capa permiten almacenar historia si es que así lo requieren siempre y cuando se particionen estas tablas por una fecha.
- Evitar duplicar la misma información en dos tablas diferentes.
- El procesamiento de la información de esta capa solo podrá consumir información de la capa silver, gold y curated.
- Se debe crear un modelo de datos para cada solución, proyecto o dominios de información.
- Las tablas transaccionales dentro de esta capa deberán de estar particionadas mediante el campo de fecha correspondiente.
- El procesamiento incremental de las tablas transaccionales de esta capa deberá estar operando por la partición definida, es decir, solo se reemplazarán los valores que existan dependiendo del valor de la partición.
- La incrementabilidad de la información en las tablas que no son transaccionales deberán de operar mediante un campo llave, sin embargo, cuando es un volumen muy bajo de información se tiene que procesar de forma completa la tabla.
Para poder iniciar con la construcción de un notebook de procesamiento dentro de la capa es necesario tener presentes las siguientes consideraciones:
Es factor clave alinearse a los estándares de la Organización si esta tuviera alguno. De lo contrario seguir los estándares mencionados en este Documento.
Databricks Unity Catalog
Estructura y Nomenclatura para Creación de Tablas en Unity Catalog
Unity Catalog es la capa de gestión y gobernanza de datos que nos permite tener un mejor control sobre los objetos de datos. Para la correcta configuración del mismo debe aprovisionarse el Workspace de Databricks correspondiente con su respectivo catálogo de datos y los esquemas definidos, para este proyecto se comparte el espacio de trabajo con nombre que se definirá y el catálogo asignado es el cat_esquema de trabajo_DV para el entorno de desarrollo.
Las tablas gestionadas en Unity Catalog deberán seguir una estructura y nomenclatura que garantice claridad, trazabilidad y alineación con las capas definidas (Bronze, Silver, Gold y Control).
Reglas Generales
- Toda tabla debe estar dentro de un esquema correspondiente a su capa.
- Las tablas deberán diferenciar entre:
- Tablas de hechos (facts)
- Tablas dimensionales (dim)
- Tablas de control (tbl)
- Vistas (vw)
- Se recomienda la utilización de Delta Lake (delta tables) para todas las tablas.
Estructura Base
cat_master_{empresa}.{schema}.{tabla}
Ejemplo:
cat_master_alpura.sch_bronze_layer.dim_client
Convenciones por tipo
| Tipo de Objeto | Prefijo | Descripción |
|---|---|---|
| Tablas Dimensionales | dim_ | Contienen catálogos o dimensiones relevantes para análisis. |
| Tablas de Hechos | fact | Contienen transacciones, métricas o eventos de negocio. |
| Tablas de Control | tbl_ | Utilizadas para configuración, logs, metadatos y procesos de control. |
| Vistas | vw_ | Vistas creadas sobre cualquier capa para facilitar el consumo de datos o exponer modelos derivados. |
Ejemplos según capas
| Capa | Esquema | Ejemplos |
|---|---|---|
| Bronze Layer | sch_bronze_layer | dim_client, dim_product, dim_tiempo |
| Silver Layer | sch_silver_layer | tbl_cat_client, tbl_cat_product, factsales |
| Gold Layer | sch_gold_layer | factsales, vw_factsales, dim_date |
| Control Layer | sch_cntrl_dv | tbl_config_source, tbl_log_processing, tbl_email_notifications |
Recomendaciones
- Las columnas deben incluir siempre campos de trazabilidad como: source, batch_id, fecha_ingestion.
- Usar siempre managed tables dentro de Unity Catalog para aprovechar auditoría, lineage y control de versiones.
- Las tablas de Control deben ser gestionadas exclusivamente por los equipos de operación y monitoreo.
- Aplicar grants específicos y controlados para cada esquema y tipo de usuario.
Política de Versiona miento de Tablas
- Todo cambio estructural (nuevas columnas, eliminación, renombramiento) debe documentarse.
- Se debe mantener un historial de cambios en un repositorio de cambios asociado al catálogo o en el esquema sch_cntrl_dv.
- Opcionalmente utilizar Delta Lake time travel para consultar versiones históricas.
- Mantener convenciones en las columnas para distinguir campos de control: _version, _fecha_actualizacion, _usuario_modificacion.
Sugerencia de permisos mínimos
| Capa | Rol | Permisos |
|---|---|---|
| Bronze | Data Engineers | SELECT, INSERT, UPDATE |
| Silver | Data Engineers / Data Scientists | SELECT, INSERT, UPDATE |
| Gold | Data Scientists / BI | SELECT |
| Control | Operación | SELECT, INSERT, UPDATE, DELETE |
Cabecero del notebook
El cabecero del notebook este hecho con el siguiente código en Mark Down.
Al ejecutar el código obtenemos el siguiente resultado.
En la siguiente tabla se define cada uno de los rubros que debe contener el cabecero:
| Rubro | Descripción |
|---|---|
| Título del notebook | Nombre o título del notebook |
| Descripción del notebook | Colocar a grandes rasgos el objetivo general del notebook |
| Tablas Fuente | Listado de tablas que consume el notebook para su procesamiento |
| Tablas Destino | Listado de tablas que genera el notebook como resultado de su procesamiento |
| Historial de Versiones | Cada que exista una modificación del notebook después de su versión inicial es necesario documentarlo en esta parte |
Creación de Widgets
Los widgets están configurados para recibir los parámetros del (framework (Azure Data Factory o Azure databricks) los cuales pueden fungir como el Orquestador para la ejecución de los diferentes procesos, estos widgets se definen y crean de acuerdo con la necesidad que requiera los Notebooks, un ejemplo de estos se muestra a continuación:
- Con el siguiente código (spark sql) se crean los siguientes widgets los cuales son necesarios para el procesamiento de los notebooks.
- Con el siguiente código (scala) se obtienen los valores de los widgets en variables definidas para ser utilizados durante el procesamiento del notebook.
En la siguiente tabla se definen algunos Widgte base principales (los nombres de estos pueden cambiar de acuerdo con la necesidad del proyecto), especificando su funcionalidad u objetivo de cada uno de ellos Ejemplo:
| Widget | Descripción |
|---|---|
| loadType | Este valor se obtiene del campo LOAD_TYPE de la tabla dbo.OBJ_METADATA donde los valores posibles son “F” e “I”. F = Carga Full. I = Carga Incremental. |
| StartDate | Este parámetro es utilizado para definir la fecha Inicio de carga de información, fuente y procesamiento Ejemplo: 20220101 |
| EndDate | Este parámetro es utilizado para definir la fecha Fin de carga de información, fuente y procesamiento Ejemplo: 20220131 |
| mnt_path | Este valor se obtiene durante el procesamiento del notebook dentro del framework y se refiere al punto de montaje que tiene databricks con el storage account, este punto de montaje cambia dependiendo el ambiente. Ejemplo: Desarrollo: mnt/dev/data. UAT o QA: mnt/uat/data. Producción: mnt/prd/data |
Lógica de Procesamiento del notebook
Para poder implementar una lógica de procesamiento de información dentro de un notebook se deben tomar en cuenta las siguientes consideraciones respetando los lineamientos y estándares de la Organización (Cliente) si esta lléguese a tener, de lo contrario implementar la Lógica establecida por Axity basada en las mejores Prácticas.
Leguaje para desarrollo: El leguaje de implementación para este tipo de notebooks no está limitado a la codificación de los diferentes lenguajes, esta podrías ser Código:
- Spark SQL
- Scala
- Python
- Etc.
- Persistencia de datos: Para poder persistir o escribir los datos solo podrá realizarse al punto de montaje definido para el storage account según el ambiente donde se esté ejecutando. El lenguaje puede ser alguno de los antes mencionados un ejemplo que se anexa, es con código SCALA.
- Creación de tablas: Para Crear las Tablas se requiere que se haya persistido los datos sobre el punto de montaje definido, es necesario crear una tabla externa dentro del clúster para que esta información pueda ser consumida por otros procesos, un ejemplo que se anexa a continuación en con Codigo Spark SQL.
Eliminación de Widgets
Al término de la lógica de procesamiento es necesario eliminar los widgets creados al inicio del procesamiento del notebook. Para la aplicación de esta eliminación de widgets debe ser realizada mediante lenguaje SPARK SQL como se muestra en la siguiente imagen.
Finalización del Notebook
Una vez finalizada la ejecución del notebook es necesario ejecutar la siguiente sentencia de código para terminar de forma correcta y generar un mensaje el cual finalizo el Notebook exitosamente.
Estándares Capa Gold
Esta es la capa donde los procesos se encargan de combinar los resultados de los diferentes procesamientos de información para tener una vista unificada de los resultados en modelos de datos relacionales (modelos estrella, copo de nieve, semánticos, etc). Estos modelos están enfocados para que sean consumidos por herramientas de negocios como Power BI o Analysis Services para los análisis de las diferentes áreas de negocio de la organización.
Construcción de Notebooks de Gold
Los siguientes lineamientos deberán de ser considerados para la construcción de los notebooks de procesamiento:
- Como resultado del procesamiento de los notebooks de la capa de gold solo deberá almacenar información en la capa gold (Azure Synapse Analytics, Snowflake Data Cloud, Azure Sql Database) o en la capa curated del datalake.
- Para el procesamiento hacia la capa de gold solo podrá utilizar como entrada tablas de la capa curated.
- Los tipos de datos deben estar estandarizados de acuerdo con el manejador de base de datos donde se pretende cargar la información.
- De acuerdo con el volumen de información manejada durante el procesamiento de información y por cada tabla se deberá considerar implementar la lógica de incrementabilidad correspondiente, ya sea si se implementa un esquema de carga completa o un esquema de carga tipo delta.
Carga de datos
Para la carga de información hacia la capa de consumo, se tiene que tomar en cuenta primero la tecnología a la que se pretende cargar la información, ya que dependiendo de eso es la lógica para utilizar como se explica en los siguientes Ejemplos:
- Azure Synapse Analytics
- Azure Sql Database
- Snowflake Data Cloud
Mejores Prácticas y Recomendaciones
Generales
Spark y SQL
El ajuste de Spark Performance es un proceso para mejorar el rendimiento de las aplicaciones Spark y PySpark ajustando, optimizando los recursos del sistema (núcleos de CPU y memoria), realizando algunas configuraciones siguiendo algunas pautas y mejores prácticas del marco.
El rendimiento de la aplicación Spark se puede mejorar de varias maneras.
- Usar DataFrame/Dataset sobre RDD: Para los trabajos de Spark, es preferible usar Dataset/DataFrame en lugar de RDD, ya que Dataset y DataFrame incluyen varios módulos de optimización para mejorar el rendimiento de las cargas de trabajo de Spark. En el uso de PySpark, DataFrame sobre RDD como conjuntos de datos no son compatibles con las aplicaciones de PySpark.
- Use coalesce() en vez de repartition(): Cuando desee reducir la cantidad de particiones, es preferible usar coalesce(), ya que es una versión optimizada o mejorada de la función repartition() en la que el movimiento de los datos entre las particiones es menor mediante coalesce, que idealmente funciona mejor cuando se trata de conjuntos de datos más grandes. Nota: Utilice repartition() cuando desee aumentar el número de particiones.
- Usa mapPartitions() en vez de map(): Spark map() y mapPartitions() la transformación aplica la función en cada elemento/registro/fila del DataFrame/Dataset y devuelve el nuevo DataFrame/Dataset. mapPartitions () sobre map () proporciona una mejora del rendimiento cuando tiene inicializaciones complicadas, como clases de inicialización, conexiones de bases de datos, etc. Spark mapPartitions() proporciona una función para realizar inicializaciones pesadas (por ejemplo, conexión de base de datos) una vez para cada partición en lugar de hacerlo en cada fila de DataFrame. Esto ayuda al rendimiento de los trabajos de Spark cuando se trata de una inicialización pesada en conjuntos de datos más grandes.
- Evite las UDF (funciones definidas por el usuario): Intente evitar las UDF de Spark/PySpark a toda costa y utilícelas cuando las funciones integradas de Spark existentes no estén disponibles para su uso. Los UDF son una caja negra para Spark, por lo tanto, no puede aplicar la optimización y perderá toda la optimización que hace Spark en Dataframe/Dataset. Cuando sea posible, debe usar las funciones integradas de Spark SQL, ya que estas funciones brindan optimización.
- Datos persistentes y de almacenamiento en caché en la memoria: La persistencia/almacenamiento en caché de Spark es una de las mejores técnicas para mejorar el rendimiento de las cargas de trabajo de Spark. Spark Cache y Persist son técnicas de optimización en DataFrame/Dataset para aplicaciones Spark iterativas e interactivas para mejorar el rendimiento de los trabajos.
- Reduzca las costosas operaciones Shuffle: La replicación Shuffle es un mecanismo que utiliza Spark para redistribuir los datos entre diferentes ejecutores e incluso entre máquinas. Spark shuffling dispara cuando realizamos ciertas operaciones de transformación como gropByKey(), reducebyKey(), join() en RDD y DataFrame.
- Deshabilitar el registro DEBUG & INFO: Esta es una de las formas sencillas de mejorar el rendimiento de Spark Jobs y se puede evitar fácilmente siguiendo buenos principios de codificación.
Las cargas de trabajo de Spark están cada vez más atascadas por el uso de la CPU y la memoria en lugar de la E/S y la red, pero siempre es una buena práctica evitar las operaciones de E/S.
Referencias
- https://databricks.com/blog/2016/07/14/a-tale-of-three-apache-spark-apis-rdds-dataframes-and-datasets.html
- https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html
Data Ops
- Lenguaje de Codificación: Regularmente el lenguaje para desarrollar este tipo de notebooks es SPARK SQL y SCALA, sin embargo, hay operaciones y funciones que se requieren realizar y que no están soportados en estos lenguajes anteriores. Para esto es necesario implementar funcionalidad con leguaje PYTHON siempre y cuando se pueda justificar su utilización en la construcción de la lógica de estos procesos de Data Ops.
- Resultados de Consultas: Durante el desarrollo de los notebooks en estos procesos se suelen realizar consultas que arrojan un resultado visible para validar los datos. Al finalizar la primer versión o ajuste del notebook es necesario eliminar todas esas consultas de validación ya que generan procesamiento E/S innecesario.
ML Ops
- Implementación de Funciones: La función debe ser colocada y documentada una en cada celda, evitar colocar dos o mas funciones dentro de una celda. Esto nos permite generar un mejor mantenimiento sin afectar toda la lógica de procesamiento del notebook.
- Lenguaje de Codificación: El lenguaje de codificación para estos notebooks es PYTHON, sin embargo, se pueden utilizar los módulos de este lenguaje para optimizar ciertas operaciones dentro del notebook como, por ejemplo; PYSPARK, PANDAS, KOALAS, etc, que son derivados del mismo lenguaje.
- Reutilización de Funciones: Para un mejor desarrollo y aprovechamiento de los recursos del clúster es necesario reutilizar funciones dentro de otras funciones con la finalidad de modularizar el procesamiento de la información.
- Evitar Operaciones de Control: Las siguientes operaciones se deben de evitar utilizar en conjuntos de datos demasiado grandes; for, while, do while, que son utilizadas para realizar iteraciones dentro de los datos, para esto es mejor la utilización de funciones recursivas.
- Utilización de Secretos: Se requiere que para los datos sensibles como, contraseñas, conexiones, usuarios, certificados o llaves de acceso, utilicemos el banco de secretos que ofrece Databricks con el manejo de variables dentro del cluster de spark.