Escalado de análisis a escala en la nube en Azure
Una plataforma de datos escalable es fundamental para que la empresa pueda asumir el rápido crecimiento de datos. Se generan grandes cantidades de datos cada segundo en todo el mundo. Se espera que la cantidad de datos disponibles siga aumentando exponencialmente en los próximos años. A medida que aumenta la velocidad de generación de datos, también aumenta la velocidad del movimiento de datos.
Independientemente de la cantidad de datos que tenga, los usuarios exigen respuestas rápidas de las consultas. Quieren esperar minutos, y no horas, para obtener resultados. En este artículo se explica cómo puede escalar la solución de análisis a escala en la nube de Azure para satisfacer las demandas de rapidez de los usuarios.
Introducción
Muchas empresas tienen monolitos de plataforma de datos de gran tamaño. Estos monolitos se crean en torno a una sola cuenta de Azure Data Lake Gen2 y, a veces, un único contenedor de almacenamiento. A menudo se usa una sola suscripción de Azure para todas las tareas relacionadas con la plataforma de datos. El escalado de nivel de suscripción no está presente en la mayoría de las plataformas arquitectónicas, lo que puede dificultar la adopción continua de Azure si los usuarios se ejecutan en cualquiera de las limitaciones de nivel de servicio o suscripción de Azure. Aunque algunas de las restricciones son límites flexibles, alcanzarlas puede tener un efecto negativo significativo en su plataforma de datos.
Al estructurar la plataforma de datos, tenga en cuenta la estructura de la organización. Observe las responsabilidades funcionales y de propiedad de los datos de sus equipos. Si su organización ofrece a los equipos grandes grados de autonomía y propiedad distribuida, una arquitectura de malla de datos es la mejor opción.
Evite situaciones que tengan diferentes equipos responsables de las diversas tareas de una solución: tareas como ingesta, limpieza, agregación y servicio. Depender de varios equipos puede provocar una pérdida drástica de velocidad. Por ejemplo, si los consumidores de datos de la capa de servicio necesitan incorporar nuevos recursos de datos o implementar cambios funcionales para un recurso de datos determinado, deben pasar por un proceso de varias etapas. En este ejemplo, los pasos son:
- El consumidor de datos envía un vale a cada equipo responsable de una fase de la canalización de datos.
- Los equipos deben trabajar juntos sincronizados porque las capas están interconectadas. Los nuevos servicios requieren cambios en la capa de limpieza de datos, lo que provoca cambios en la capa de agregación de datos, lo que a su vez conduce a cambios en la capa de servicio. Los cambios pueden afectar a cada fase de la canalización.
- Es difícil que los equipos vean los posibles efectos de los cambios de procesamiento, ya que no tienen una visión general de todo el ciclo de vida de un extremo a otro. Deben trabajar juntos para diseñar un plan de lanzamiento bien definido que minimice los efectos en los consumidores y canalizaciones existentes. Esta administración de dependencias aumenta la sobrecarga de administración.
- Como regla general, los equipos no son expertos en los recursos de datos que solicita el consumidor. Para comprender las nuevas características del conjunto de datos o los valores de parámetro, deben consultar a un experto.
- Una vez implementados todos los cambios, se notifica al consumidor de datos que el nuevo recurso está listo para usarse.
Cada organización grande tiene miles de consumidores de datos. Un proceso complicado como el que hemos descrito disminuye gravemente la velocidad en las grandes arquitecturas, ya que los equipos centralizados se convierten en un cuello de botella para las unidades de negocio. El resultado es menos innovación y eficacia limitada. Existe la posibilidad de que las unidades de negocio puedan decidir dejar el servicio y crear su propia plataforma de datos en su lugar.
Métodos para el escalado
El análisis de escala en la nube aborda los desafíos de escalado mediante dos conceptos básicos:
- Uso de zonas de aterrizaje de datos para el escalado
- Uso de productos o integraciones de datos para el escalado, con el fin de hacer posible una propiedad de datos distribuida y descentralizada
Puede implementar una sola zona de aterrizaje de datos o varias. Las zonas de aterrizaje de datos permiten detectar y administrar datos mediante la conexión a una zona de aterrizaje de administración de datos. Cada zona de aterrizaje de administración de datos se encuentra dentro de una única suscripción de Azure.
Las suscripciones son unidades de administración, facturación y escala de Azure. Desempeñan un papel fundamental en su plan de adopción de Azure a gran escala.
Escalado con zonas de aterrizaje de datos
Los conceptos centrales del análisis a escala de la nube son la zona de aterrizaje de administración de datos y la zona de aterrizaje de datos. Debe colocar cada una en su propia suscripción de Azure. Separarlas le permite separar claramente las tareas, seguir el principio de privilegios mínimos y abordar parcialmente los problemas de escalado de suscripciones que se mencionaron anteriormente. Una configuración mínima de análisis de escala en la nube incluye una única zona de aterrizaje de datos y una sola zona de aterrizaje de administración de datos.
Sin embargo, una configuración mínima no es suficiente para las implementaciones de plataformas de datos a gran escala. Las empresas crean plataformas a gran escala y realizan inversiones para escalar de forma coherente y eficaz sus esfuerzos de datos y análisis a lo largo del tiempo. Para superar las limitaciones del nivel de suscripción, el análisis a escala de la nube usa suscripciones como unidad de escalado, como se indica en Zonas de aterrizaje de Azure. Esta técnica permite aumentar la superficie de la plataforma de datos agregando más zonas de aterrizaje de datos a la arquitectura. La adopción de esta técnica también soluciona el problema del uso de Azure Data Lake Gen2 para toda la organización, ya que cada zona de aterrizaje de datos incluye tres lagos de datos. Los proyectos y las actividades de varios dominios se pueden distribuir en más de una suscripción de Azure, lo que proporciona una mayor escalabilidad.
Decida cuántas zonas de aterrizaje de datos necesita su organización antes de implementar una arquitectura de análisis a escala de la nube. Tomar la decisión adecuada establece la base para una plataforma de datos eficaz.
El número de zonas de aterrizaje de datos necesario depende de muchos factores, especialmente:
- Alineación organizativa, por ejemplo, cuántas unidades de negocio necesitan su propia zona de aterrizaje de datos.
- Consideraciones acerca de las operaciones, como la forma en que su organización alinea los recursos de la operación y los recursos específicos de una unidad de negocio.
El uso del modelo de zona de aterrizaje de datos adecuado reduce al mínimo los esfuerzos en el futuro para trasladar productos de datos y recursos de datos de una zona de aterrizaje a otra. También ayuda a escalar de forma eficaz y coherente cualquier esfuerzo de macrodatos y análisis en el futuro.
Tenga en cuenta los siguientes factores al decidir el número de zonas de aterrizaje de datos que desea implementar.
| Factor | Descripción |
|---|---|
| Estructura organizativa y propiedad de los datos | Tenga en cuenta cómo se estructura su organización y cómo se poseen los datos en su organización. |
| Región y ubicación | Si implementa en varias regiones, decida qué regiones deben hospedar las zonas de datos. Asegúrese de cumplir todos los requisitos de residencia de datos. |
| Cuotas | Tenga en cuenta que las cuotas de suscripción no son garantías de capacidad y se aplican en cada región. |
| Soberanía de los datos | Debido a las regulaciones de soberanía de datos, estos deben almacenarse en una región específica y seguir directivas específicas de la región. |
| Directivas de Azure | Las zonas de aterrizaje de datos deben cumplir los requisitos de diversas directivas de Azure. |
| Límite de administración | Las suscripciones proporcionan un límite de administración para la gobernanza y el aislamiento que crea una separación clara de los intereses. |
| Redes | Cada zona de aterrizaje tiene una red virtual. Dado que una red virtual reside en una sola región, cada nueva región requiere una nueva zona de aterrizaje. Las redes virtuales deben ser redes virtuales del mismo nivel para permitir la comunicación entre dominios. |
| Límites | Una suscripción tiene límites. Disponer de varias suscripciones puede mitigar los peligros de alcanzar estos límites. |
| Asignación de costos | Considere si los servicios compartidos, como las cuentas de almacenamiento pagadas de forma centralizada, deben dividirse por unidad de negocio o dominio. El uso de una suscripción independiente crea un límite para la asignación de costos. Puede lograr la misma funcionalidad mediante etiquetas. |
| Clasificaciones de datos y datos extremadamente confidenciales | Los mecanismos de seguridad pueden afectar al desarrollo de productos de datos y a la facilidad de uso de una plataforma de datos. Tenga en cuenta las clasificaciones de datos y decida si los conjuntos de datos altamente confidenciales requieren un tratamiento especial, como el acceso Just-in-Time, claves gestionadas por el cliente (CMK), controles de red específicos o más cifrado. |
| Otras implicaciones legales o de seguridad | Tenga en cuenta si hay otros requisitos legales o de seguridad que requieran la separación lógica o física de los datos. |
Si va a implementar una arquitectura de malla de datos, tenga en cuenta los siguientes factores cuando decida cómo distribuir las zonas de aterrizaje de datos y los dominios de datos.
| Factor | Descripción |
|---|---|
| Dominios de datos | Tenga en cuenta los dominios de datos que usa su organización y decida cuál estará en la plataforma de datos. Tenga en cuenta el tamaño de los dominios de datos individuales. Para más información, consulte ¿Qué son los dominios de datos? |
| Latencia | Los dominios que colaboran en grandes cantidades de datos pueden transferir una gran cantidad de datos entre zonas de aterrizaje. Considere la posibilidad de asignar los dominios en la misma zona de aterrizaje o región. Separarlos aumenta la latencia y puede aumentar el coste en dominios entre regiones. |
| Seguridad | Algunas implementaciones o configuraciones de servicio requieren privilegios elevados en una suscripción. Conceder estos privilegios a un usuario de un dominio proporciona implícitamente a ese usuario los mismos privilegios en otros dominios dentro de la misma suscripción. |
Puede encontrar más consideraciones en la guía del marco de adopción de la nube para las suscripciones.
Muchas organizaciones desean un escalado eficaz de su plataforma de datos empresarial. Las unidades de negocio deben poder crear sus propias soluciones de datos y aplicaciones para satisfacer sus requisitos específicos. Proporcionar esta capacidad puede ser un desafío, ya que muchas plataformas de datos existentes no se basan en los conceptos de escalabilidad y propiedad descentralizada. Esta deficiencia se ve claramente en la arquitectura, la estructura del equipo y el modelo de operaciones de estas plataformas de datos.
Las zonas de aterrizaje de datos no crean silos de datos dentro de la organización. La configuración de red recomendada para el análisis a escala de la nube permite el uso compartido de datos seguro e in situ entre zonas de aterrizaje, lo que, a su vez, permite la innovación entre dominios de datos y unidades de negocio. Para más información, consulte la sección acerca de las consideraciones sobre la arquitectura de la red.
Lo mismo ocurre con la capa de identidad. Al usar un solo inquilino de Microsoft Entra, puede conceder a las identidades acceso a recursos de datos en varias zonas de aterrizaje de datos. Para más información sobre el proceso de autorización de usuario e identidad, consulte Administración del acceso a datos.
Nota
Si tiene varias zonas de aterrizaje de datos, cada zona puede conectarse a datos hospedados en otras zonas. Esto permite que los grupos colaboren en toda la empresa.
El análisis a escala de la nube usa una arquitectura común para defender la gobernanza coherente. Su arquitectura define las funcionalidades y directivas de base de referencia. Todas las zonas de aterrizaje de datos se adhieren a las mismas auditorías y controles. Sus equipos pueden crear canalizaciones de datos, ingerir orígenes y crear productos de datos, como informes y paneles. Los equipos también pueden realizar análisis de Spark o SQL según sea necesario. Para aumentar las funcionalidades de la zona de aterrizaje de datos, agregue servicios a la funcionalidad en la directiva. Por ejemplo, un equipo puede agregar un motor de grafos de terceros para dar respuesta a un requisito empresarial.
La analítica a escala de la nube pone un gran énfasis en la catalogación y clasificación central para proteger los datos y permitir que varios grupos descubran productos de datos.
Precaución
Se desaconseja consultar los datos entre regiones. En su lugar, asegúrese de que los datos están cerca del proceso que los usa al tiempo que se respetan los límites regionales.
La arquitectura de análisis a escala en la nube y el concepto de zonas de aterrizaje de datos permiten a su organización aumentar fácilmente el tamaño de la plataforma de datos a lo largo del tiempo. Puede agregar más zonas de aterrizaje de datos en un enfoque por fases. Los clientes no necesitan tener varias zonas de aterrizaje al principio. Al adoptar esta arquitectura, priorice algunas zonas de aterrizaje de datos y los productos de datos que deben contener. Una priorización adecuada ayuda a garantizar el éxito de la implementación del análisis a escala en la nube.
Escalado con productos de datos o integraciones de datos
Dentro de cada zona de aterrizaje, su organización puede escalar mediante aplicaciones de datos. Las aplicaciones de datos son unidades o componentes de la arquitectura de datos que encapsulan la funcionalidad para posibilitar que otras aplicaciones de datos usen productos de datos optimizados para lectura. En Azure, las aplicaciones de datos son entornos en forma de grupos de recursos y permiten a los equipos multifuncionales implementar soluciones de datos y cargas de trabajo. Un equipo asociado se encarga del ciclo de vida completo de la solución de datos, el cual incluye la ingesta, limpieza, agregación y tareas de servicio.
El análisis de escala en la nube aborda la integración de datos y el problema de responsabilidad que se mencionó anteriormente. En lugar de responsabilidades funcionales monolíticas para la ingesta de tablas y la integración del sistema de origen, el diseño de referencia proporciona una arquitectura distribuida controlada por dominios de datos. En él, los equipos multifuncionales asumen la responsabilidad funcional integral y la propiedad del ámbito de datos.
En lugar de tener una pila técnica centralizada y un equipo responsable de todas las tareas del flujo de trabajo de procesamiento de datos, puede distribuir la responsabilidad de principio a fin entre varios equipos autónomos y multifuncionales de integración de datos. Cada equipo posee una funcionalidad de dominio o subdominio y se recomienda que sirva a los conjuntos de datos según lo requieran los consumidores de datos.
Estas diferencias arquitectónicas conducen a una mayor velocidad de la plataforma de datos. Los consumidores de datos ya no tienen que confiar en un conjunto de equipos centralizados ni luchar por que se prioricen sus cambios solicitados. A medida que los equipos más pequeños asumen la propiedad de su flujo de trabajo de integración de extremo a extremo, el bucle de retroalimentación entre el proveedor de datos y el consumidor de datos es mucho más corto. Este enfoque permite una priorización más rápida, ciclos de desarrollo más rápidos y un proceso de desarrollo más ágil. Los equipos ya no necesitan sincronizar los procesos y los planes de lanzamiento entre sí, ya que el equipo multifuncional de integración de datos tiene conocimiento completo de la pila técnica de un extremo a otro y de las implicaciones de los cambios. Este equipo puede usar procedimientos de ingeniería de software para ejecutar pruebas unitarias y de integración para minimizar el efecto general en los consumidores.
Idealmente, el equipo que posee los sistemas de integración de datos también posee los sistemas de origen. Este equipo debe constar de ingenieros de datos que trabajan en los sistemas de origen, expertos en la materia (PYME) para sus conjuntos de datos, ingenieros en la nube y propietarios de productos de datos. La creación de este tipo de equipo multiplataforma reduce la cantidad de comunicación necesaria con equipos externos y es esencial al desarrollar la pila completa de su infraestructura a las canalizaciones de datos reales.
La base de su plataforma de datos son los conjuntos de datos integrados desde los sistemas de origen. Estos conjuntos de datos permiten a sus equipos de productos de datos innovar en tablas de hechos empresariales y mejorar la toma de decisiones y los procesos empresariales. Los equipos de integración de datos y los equipos de productos de datos deben ofrecer Acuerdos de Nivel de Servicio a los consumidores y asegurarse de que se cumplan todos los contratos. Los Acuerdos de Nivel de Servicio ofrecidos pueden estar relacionados con la calidad de los datos, la puntualidad, las tasas de error, el tiempo de actividad y otras tareas.
Resumen
Mediante el uso de los mecanismos de escalado dentro de su arquitectura de análisis a escala en la nube, su organización aumenta el patrimonio de datos en Azure con el tiempo, a la vez que evita limitaciones técnicas conocidas. Ambos métodos de escalado descritos en este artículo le ayudan a superar diferentes complejidades técnicas y se pueden usar de forma sencilla y eficaz.