Migración de aplicaciones de datos a Azure Databricks

En este artículo se proporciona una introducción a la migración de aplicaciones de datos existentes a Azure Databricks. Azure Databricks proporciona un enfoque unificado que le permite trabajar con datos de muchos sistemas de origen en una sola plataforma.

Para obtener información general sobre las funcionalidades de la plataforma, consulte ¿Qué es Azure Databricks?.

Para obtener información sobre la migración entre versiones de Databricks Runtime, consulte la guía de migración de Databricks Runtime.

Migración de trabajos de ETL a Azure Databricks

Puede migrar trabajos de Apache Spark que se usan para extraer, transformar y cargar datos de implementaciones locales o nativas de la nube a Azure Databricks con unos pocos pasos. Consulte Adaptación del código de Apache Spark para Azure Databricks.

Azure Databricks amplía la funcionalidad de Spark SQL con integraciones de código abierto preconfiguradas, integraciones de asociados y ofertas de productos empresariales. Si las cargas de trabajo de ETL se escriben en SQL o Hive, puede migrar a Azure Databricks con una refactorización mínima. Más información sobre las ofertas de Azure Databricks SQL:

Para obtener instrucciones específicas sobre cómo migrar desde varios sistemas de origen a Azure Databricks, consulte Migración de canalizaciones de ETL a Azure Databricks.

Reemplazo del almacenamiento de datos de empresa por una instancia del lago de datos

Azure Databricks proporciona un valor y un rendimiento óptimos cuando las cargas de trabajo se alinean en torno a los datos almacenados en el lakehouse. Muchas pilas de datos de empresa incluyen un lago de datos y un almacenamiento de datos de empresa, y las organizaciones crean flujos de trabajo ETL complejos para intentar mantener sincronizados estos sistemas y datos. El lago de datos permite usar los mismos datos (almacenados en el lago de datos) en consultas y sistemas que normalmente dependen de un almacenamiento de datos independiente. Para más información sobre el almacén de lago, consulte ¿Qué es un almacén de lago de datos? Para más información sobre el almacenamiento de datos en Databricks, consulte ¿Qué es el almacenamiento de datos en Azure Databricks?.

La migración desde un almacenamiento de datos de empresa a un lago de datos generalmente implica reducir la complejidad de la arquitectura y los flujos de trabajo de datos, pero hay algunas advertencias y procedimientos recomendados que se deben tener en cuenta al completar este trabajo. Consulte Migración del almacenamiento al almacén de lago de Databricks.

Unificar las cargas de trabajo de ML, ciencia de datos y análisis

Dado que lakehouse proporciona acceso optimizado a los archivos de datos basados en la nube a través de consultas de tabla o rutas de acceso de archivos, puede realizar ML, ciencia de datos y análisis en una sola copia de los datos. Azure Databricks facilita el traslado de cargas de trabajo tanto de herramientas de orígenes abiertos como propietarias, y mantiene versiones actualizadas de muchas de las bibliotecas de orígenes abiertos usadas por analistas y científicos de datos.

Las cargas de trabajo de Pandas en cuadernos de Jupyter se pueden sincronizar y ejecutar mediante carpetas de Git de Databricks. Azure Databricks proporciona compatibilidad nativa con Pandas en todas las versiones de Databricks Runtime y configura muchas bibliotecas populares de aprendizaje automático y aprendizaje profundo en Databricks Runtime para Machine Learning. Si sincroniza sus cargas de trabajo locales usando Git y archivos de área de trabajo en carpetas de Git, puede usar las mismas rutas relativas para los datos y las bibliotecas personalizadas presentes en su entorno local.

Nota:

De forma predeterminada, Azure Databricks mantiene extensiones .ipynb para cuadernos de Jupyter sincronizados con carpetas de Git de Databricks, pero convierte automáticamente cuadernos de Jupyter en cuadernos de Databricks cuando se importa con la interfaz de usuario. Los cuadernos de Databricks se guardan con una extensión .py y, por tanto, pueden vivir en paralelo con cuadernos de Jupyter en un repositorio de Git.