En esta arquitectura de referencia, se describen los beneficios de usar Apache Hive en Dataproc de manera eficiente y flexible mediante el almacenamiento de datos de Hive en Cloud Storage y alojar el almacén de metadatos de Hive en una base de datos de MySQL en Cloud SQL.
Este documento está dirigido a arquitectos de la nube y a ingenieros de datos que estén interesados en implementar Apache Hive en Dataproc y Hive Metastore en Cloud SQL.
Arquitectura
En el siguiente diagrama, se muestra el ciclo de vida de una consulta de Hive.
En el diagrama, el ciclo de vida de una consulta de Hive sigue estos pasos:
- El cliente de Hive envía una consulta a un servidor de Hive que se ejecuta en un clúster de Dataproc efímero.
- El servidor de Hive procesa los metadatos de la consulta y las solicitudes desde el servidor del almacén de metadatos.
- El servidor del almacén de metadatos recupera los metadatos de Hive desde Cloud SQL a través del proxy de Cloud SQL.
- El servidor de Hive carga los datos desde el almacén de Hive ubicado en un bucket regional en Cloud Storage.
- El servidor de Hive muestra el resultado al cliente.
Alternativas de diseño
En la siguiente sección, se presenta una posible alternativa de diseño para esta arquitectura.
Arquitectura multirregional
Considera usar una arquitectura multirregional si necesitas ejecutar servidores de Hive en diferentes regiones geográficas. En ese caso, debes crear clústeres de Dataproc independientes que usen con el fin de alojar el servicio de almacén de metadatos y que residan en la misma región que la instancia de Cloud SQL.
A veces, el servicio de almacén de metadatos puede enviar volúmenes altos de solicitudes a la base de datos de MySQL. Por esto es importante mantener este servicio geográficamente cerca de la base de datos de MySQL para minimizar el impacto en el rendimiento. De la misma manera, el servidor de Hive envía muchas menos solicitudes al servicio de almacén de metadatos. Por lo tanto, puede ser más aceptable que el servidor de Hive y el servicio de almacén de metadatos residan en diferentes regiones a pesar del aumento de latencia.
El servicio de almacén de metadatos solo puede ejecutarse en los nodos principales de Dataproc, no en los nodos trabajadores. Dataproc aplica un mínimo de dos nodos trabajadores en clústeres estándar y en clústeres con alta disponibilidad.
Para evitar desperdiciar recursos en nodos trabajadores que no se utilizan, puedes crear un clúster con un solo nodo para el servicio de almacén de datos. Para lograr una alta disponibilidad, puedes crear varios clústeres con un solo nodo.
El proxy de Cloud SQL debe instalarse solo en los clústeres de servicio del almacén de metadatos, ya que solo estos clústeres deben conectarse directamente a la instancia de Cloud SQL. Luego, los servidores de Hive apuntan a los clústeres del servicio de almacén de datos mediante la configuración de la propiedad hive.metastore.uris en la lista de URI separados por comas. Por ejemplo:
thrift://metastore1:9083,thrift://metastore2:9083
También puedes considerar el uso de un bucket birregional o multirregional si los servidores de Hive en varias ubicaciones necesitan acceder a los datos de Hive. La elección entre diferentes tipos de ubicaciones de bucket depende de tu caso de uso. Debes lograr un equilibrio entre los costos de latencia y disponibilidad.
En el siguiente diagrama, se muestra un ejemplo de la arquitectura multirregional.
Como puedes ver, la situación de arquitectura multirregional es un poco más compleja y mucho más sólida. En la guía de implementación para esta arquitectura de referencia, se usa una situación de una sola región.
Ventajas de una arquitectura multirregional
Separar los recursos de procesamiento y almacenamiento ofrece las siguientes ventajas:
- Flexibilidad y agilidad: puedes adaptar las configuraciones del clúster para cargas de trabajo de Hive específicas y aumentar o disminuir el escalamiento de cada clúster de forma independiente, según sea necesario.
- Ahorro de costos: puedes iniciar un clúster efímero cuando necesites ejecutar un trabajo de Hive y borrarlo cuando se finalice. Los recursos que necesitan tus trabajos solo estarán activos durante su uso; así que solo pagarás por lo que usas. También puedes usar VM interrumpibles para procesar datos no críticos o crear clústeres muy grandes a un costo total más bajo.
- Resiliencia: para que sea más sencillo, esta arquitectura de referencia usa solo una instancia principal. Para aumentar la resiliencia en las cargas de trabajo de producción, puedes crear un clúster con tres instancias principales mediante el modo de alta disponibilidad de Dataproc.
Optimización de costos
En esta implementación y arquitectura de referencia, se usan los siguientes componentes facturables de Google Cloud:
- Dataproc
- Cloud Storage
- Cloud SQL
Puedes usar la calculadora de precios para generar una estimación de costos según el uso previsto.
Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.
Implementación
Para implementar esta arquitectura, consulta Implementa Apache Hive en Dataproc.
¿Qué sigue?
- Prueba BigQuery, el almacén de datos empresarial sin servidores, altamente escalable y económico de Google.
- Consulta esta guía sobre cómo migrar cargas de trabajo de Hadoop a Google Cloud.
- Consulta esta acción de inicialización para obtener más detalles sobre cómo usar HCatalog de Hive en Dataproc.
- Aprende a configurar Cloud SQL para alta disponibilidad a fin de aumentar la confiabilidad del servicio.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.