Proceso de ingesta con análisis a escala de la nube en Azure
Azure proporciona varios servicios para ingerir y liberar datos en plataformas nativas y de terceros. Se pueden usar diferentes servicios, en función del volumen, la velocidad, la variedad y la dirección. Algunos de estos servicios son:
- Azure Data Factory es un servicio creado para todas las necesidades de aplicación de datos (alineados por el origen) y niveles de aptitud. Escriba su propio código o construya, extraiga, cargue y transforme procesos dentro del entorno visual intuitivo y sin código. Con más de 90 conectores integrados de forma nativa y sin mantenimiento, integre visualmente los orígenes de datos sin costo adicional. Los ingenieros pueden usar puntos de conexión privados y vincular servicios para conectarse de forma segura a los recursos de la plataforma como servicio (PaaS) de Azure sin usar los puntos de conexión públicos del recurso de PaaS. Los ingenieros pueden usar entornos de ejecución de integración para ampliar las canalizaciones a entornos de terceros, como orígenes de datos locales y otras nubes.
Algunos de estos conectores admiten el uso como origen (lectura) o como receptor (escritura). Los servicios nativos de Azure, Oracle, SAP y otros se pueden usar como origen o receptor, pero no todos los conectores lo admiten. En estos casos, puede usar conectores genéricos como la conectividad abierta de bases de datos (ODBC), el sistema de archivos o los conectores del protocolo de transferencia de archivos (SFTP) SSH.
Azure Databricks es un servicio de análisis rápido, sencillo y de colaboración basado en Apache Spark. Para una canalización de macrodatos, puede ingerir los datos (estructurados o sin formato) en Azure mediante Azure Data Factory en lotes o transmitidos casi en tiempo real con Apache Kafka, Azure Event Hubs o IoT Hub. Estos datos llegan a un lago de datos para un almacenamiento persistente a largo plazo en Azure Data Lake Storage. Azure Databricks puede leer datos de varios orígenes de datos como parte del flujo de trabajo.
Microsoft Power Platform proporciona conectores a cientos de servicios que pueden ser controlados por eventos, programación o inserción. Microsoft Power Automate puede actuar sobre eventos y desencadenar flujos de trabajo optimizados para registros únicos o volúmenes de datos pequeños.
Las herramientas nativas y de terceros de su propiedad proporcionan funcionalidades de nicho para integrarse con sistemas especializados y replicación casi en tiempo real.
- Azure Data Share permite a las organizaciones compartir datos de forma segura con varios clientes y asociados externos. Una vez que cree una cuenta de recurso compartido de datos y agregue productos de datos, se puede invitar a los clientes y asociados al recurso compartido de datos. Los proveedores de datos siempre tienen el control de los datos que han compartido. Azure Data Share simplifica la administración y supervisión de los datos que se comparten, cuándo ser comparten y quién los comparte.
Importante
Cada zona de aterrizaje tiene un grupo de recursos de ingesta de metadatos que existe para las empresas que cuentan con un motor de ingesta de datos independiente. Si no tiene este motor de marco, el único recurso recomendado es implementar un área de trabajo de análisis de Azure Databricks, que las integraciones de datos usarían para ejecutar una ingesta compleja. Consulte el motor de ingesta independiente de datos para ver posibles patrones de automatización.
Consideraciones de ingesta de Azure Data Factory
Si tiene un motor de ingesta independiente de datos, debe implementar una única instancia de Data Factory para cada zona de aterrizaje de datos del grupo de recursos de ingesta y procesamiento. El área de trabajo de Data Factory debe bloquearse a los usuarios y solo las entidades de servicio y las identidades administradas tendrán acceso a la implementación. Las operaciones de la zona de aterrizaje de datos deben tener acceso de lectura para permitir la depuración de canalizaciones.
La aplicación de datos puede tener su propia Data Factory para el movimiento de datos. Tener una instancia de Data Factory en cada grupo de recursos de aplicación de datos admite una experiencia de integración continua (CI) e implementación continua (CD) completa, ya que solo permite implementar canalizaciones desde Azure DevOps o GitHub.
Todas las áreas de trabajo de Data Factory usarán principalmente la característica de red virtual administrada (VNet) en Data Factory o entorno de ejecución de integración autohospedado para su zona de aterrizaje de datos dentro de la zona de aterrizaje de administración de datos. Se recomienda a los ingenieros que usen la característica de VNet administrada para conectarse de forma segura al recurso PaaS de Azure.
Sin embargo, es posible crear más entornos de ejecución de integración para ingerir desde nubes locales, nubes de terceros y orígenes de datos de software como servicio (SaaS) de terceros.
Consideraciones de ingesta de Azure Databricks
Esta guía se detalla sobre la información de:
Protección del acceso a Azure Data Lake Storage Gen2 desde Azure Databricks
Uso de Azure Databricks en el análisis a escala de la nube en Azure
Para el desarrollo, las operaciones de integración deben tener sus propios entornos de Azure Databricks antes de comprobar el código que se implementará en el área de trabajo de Azure Databricks única durante las pruebas y la producción.
Data Factory en el grupo de recursos de aplicación de datos (alineados por el origen) debe proporcionar el marco para llamar a trabajos de Azure Databricks.
Las entidades de servicio pueden ayudar a montar lagos de datos en esta área de trabajo. Para más información, consulte Patrón 1: acceso a través de la entidad de servicio.
Los equipos de aplicaciones de datos pueden implementar trabajos cortos y automatizados en Azure Databricks y esperar que sus clústeres se inicien rápidamente, ejecuten el trabajo y finalicen. Se recomienda configurar grupos de Azure Databricks para reducir el tiempo que tardan los clústeres en poner en marcha los trabajos.
Se recomienda que las organizaciones usen Azure DevOps para implementar un marco de implementación para nuevas canalizaciones. El marco se usará para crear las carpetas del conjunto de datos, asignar listas de control de acceso y crear una tabla con o sin aplicación de controles de acceso a la tabla de Databricks.
Ingesta de secuencias
Es posible que las organizaciones necesiten admitir escenarios en los que los editores generan flujos de eventos de alta velocidad. Para este patrón, se recomienda una cola de mensajes, por ejemplo, Event Hubs o IoT Hub, para ingerir estas secuencias.
Event Hubs e IoT Hub son servicios de procesamiento de eventos escalables que pueden ingerir y procesar grandes volúmenes de eventos y datos con baja latencia y alta confiabilidad. Event Hubs está diseñado como un servicio de streaming de macrodatos e ingesta de eventos. IoT Hub es un servicio administrado que actúa como centro de mensajes para comunicaciones bidireccionales entre la aplicación de IoT y los dispositivos que administra. Desde ahí, los datos se pueden exportar a un lago de datos a intervalos regulares (por lotes) y procesarse con Azure Databricks casi en tiempo real a través de Apache Spark Streaming, Azure Data Explorer, Stream Analytics o Time Series Insights.
La última zona de aterrizaje de Event Hubs o Apache Kafka dentro de la zona de aterrizaje específica del caso de uso debe enviar sus datos agregados a la capa sin procesar del lago de datos en una de las zonas de aterrizaje de datos y a Event Hubs en relación con el grupo de recursos de aplicación de datos (alineados por el origen) de la zona de aterrizaje de datos.
Supervisión de la ingesta
La supervisión de canalizaciones de Azure Data Factory lista para usar se puede utilizar para supervisar y solucionar problemas de las excepciones de las canalizaciones de Data Factory. Reduce el esfuerzo de desarrollar una solución personalizada de supervisión e informes.
La supervisión integrada es uno de los principales motivos para usar Azure Data Factory como herramienta de orquestación principal y Azure Policy puede ayudar a automatizar esta configuración.
Asignación de orígenes de datos a servicios
La guía de esta sección asigna los servicios de ingesta y procesamiento a orígenes que normalmente deben ingerirse o liberarse desde Azure.
Servicios de ingesta:
| ID | Mechanism | Nota |
|---|---|---|
| A | Data Factory | Conectores integrados y genéricos (ODBC, SFTP y REST) |
| B | Azure Databricks | Código personalizado (JDBC, JAR, etc.) |
| C | Aplicaciones de terceros | WANdisco, Qlik y Oracle GoldenGate |
| D | Otros | Por ejemplo, funcionalidades nativas |
| E | Microsoft Power Platform y Azure Logic Apps | Conectores de Microsoft Power Automate |
Asignación de orígenes de datos a servicios:
| Proveedor | Tipo | Hospedada | Categoría | Notas | Ingesta de carga completa | Ingesta de carga incremental | Ingesta en tiempo real | Salida de carga completa | Salida de carga incremental | Salida en tiempo real |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | Tabular | IaaS | Base de datos | GoldenGate a Azure Data Lake Storage | A, B | A, B | C | A, B | A, B | C |
| Microsoft SQL Server | Tabular | IaaS | Base de datos | Transformación horizontal de SAP y Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| MySQL | Tabular | IaaS | Base de datos | Transformación horizontal de SAP y Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| SAP BW/4HANA | Tabular | IaaS | Base de datos | Transformación horizontal de SAP y Qlik | A, B, C, D | A, B, C, D | C | - | - | - |
| SAP HANA | Tabular | IaaS | Base de datos | Transformación horizontal de SAP y Qlik | A, B, C, D | A, B, C, D | C | A, B | A, B | - |
| Apache Impala | Tabular | IaaS | Base de datos | - | A, B | A, B | - | B | B | - |
| Microsoft SharePoint | List | SaaS | Almacén de registros | - | A, E | A, E | E | A, E | A, E | E |
| REST | REST | Varios | REST | XML, JSON, CSV | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E |
| Microsoft Outlook | Correo electrónico | SaaS | REST | XML, JSON, CSV | E | E | E | E | E | E |
En función del destino, Azure Database Migration Service puede replicar desde bases de datos locales y de terceros, como Microsoft SQL Server, PostgreSQL, MySQL u Oracle, a un almacén de datos basado en Azure.