Usa Apache Hive en Dataproc

Last reviewed 2022-04-06 UTC

En este instructivo, se muestra cómo usar Apache Hive en Dataproc de manera eficiente y flexible mediante el almacenamiento de datos de Hive en Cloud Storage y el alojamiento del almacén de metadatos en una base de datos MySQL en Cloud SQL. Esta separación entre 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.

Hive es un popular sistema de almacén de datos de código abierto desarrollado en Apache Hadoop. Hive ofrece un lenguaje de consulta similar a SQL llamado HiveQL, que se usa para analizar grandes conjuntos de datos estructurados. El almacén de metadatos de Hive conserva los metadatos de las tablas de Hive, como esquemas y ubicaciones. Mientras que MySQL se suele usar como backend para el almacén de metadatos de Hive, Cloud SQL facilita la configuración, el mantenimiento y la administración de las bases de datos relacionales en Google Cloud.

Objetivos

  • Crear una instancia de MySQL en Cloud SQL para el almacén de datos de Hive
  • Implementar servidores de Hive en Dataproc
  • Instalar el proxy de Cloud SQL en las instancias de clústeres de Dataproc
  • Subir los datos de Hive a Cloud Storage
  • Ejecutar consultas de Hive en varios clústeres de Dataproc

Costos

En este instructivo, 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.

Antes de comenzar

Crear un nuevo proyecto

  1. In the Google Cloud console, go to the project selector page.

    Go to project selector

  2. Select or create a Google Cloud project.

Habilita la facturación

Inicializa el entorno

  1. Inicia una instancia de Cloud Shell:

    Ir a Cloud Shell

  2. En Cloud Shell, configura la zona en la que crearás los clústeres de Dataproc como zona predeterminada de Compute Engine.

    export PROJECT=$(gcloud info --format='value(config.project)')
    export REGION=REGION
    export ZONE=ZONE
    gcloud config set compute/zone ${ZONE}

    Reemplaza lo siguiente:

    • REGION: Es la región en la que deseas crear el clúster, como us-central1.
    • ZONE: La zona en la que deseas crear el clúster, como us-central1-a.
  3. Habilita las API de administrador de Dataproc y Cloud SQL mediante la ejecución del siguiente comando en Cloud Shell:

    gcloud services enable dataproc.googleapis.com sqladmin.googleapis.com

Arquitectura de referencia

Para simplificar, en este instructivo, implementarás todos los servicios de procesamiento y almacenamiento en la misma región de Google Cloud, a fin de minimizar la latencia de red y los costos de transporte de red. En la figura 1 se muestra la arquitectura para este instructivo.

Diagrama de una arquitectura de una sola región
Figure 1. Ejemplo de una arquitectura de Hive de una sola región

Con esta arquitectura, el ciclo de vida de una consulta de Hive sigue estos pasos:

  1. El cliente de Hive envía una consulta a un servidor de Hive que se ejecuta en un clúster de Dataproc efímero.
  2. El servidor procesa los metadatos de la consulta y las solicitudes desde el servidor de almacén de metadatos.
  3. El servido de almacén de metadatos recupera estos datos desde Cloud SQL a través del proxy de Cloud SQL.
  4. El servidor carga los datos desde el almacén de Hive ubicado en un depósito regional en Cloud Storage.
  5. El servidor muestra el resultado al cliente.

Consideraciones para arquitecturas multirregionales

En este instructivo, nos enfocaremos en la arquitectura de una sola región. Sin embargo, puedes considerar 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 2 nodos trabajadores en clústeres estándar y clústeres con alta disponibilidad. Si quieres evitar desperdiciar recursos en nodos trabajadores que no se usan, puedes crear un clúster de 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 la figura 2 se muestra un ejemplo de la arquitectura multirregional.

Diagrama de una arquitectura multiregional de Hive
Figure 2. Ejemplo de una arquitectura multirregional de Hive

Como puedes observar, la situación de arquitectura multirregional es un poco más compleja. Para ser concisos, en este instructivo se utiliza la arquitectura de una sola región.

Crea el bucket de almacenamiento (opcional)

Si no tienes un bucket de Cloud Storage para almacenar datos de Hive, crea un bucket de almacenamiento (puedes ejecutar los siguientes comandos en Cloud Shell) y reemplaza BUCKET_NAME por un nombre de bucket único:

export WAREHOUSE_BUCKET=BUCKET_NAME
gsutil mb -l ${REGION} gs://${WAREHOUSE_BUCKET}

Crea la instancia de Cloud SQL

En esta sección, crearás una instancia nueva de Cloud SQL, que luego se usará para alojar el almacén de metadatos de Hive.

En Cloud Shell, crea una instancia nueva de Cloud SQL:

gcloud sql instances create hive-metastore \
    --database-version="MYSQL_5_7" \
    --activation-policy=ALWAYS \
    --zone ${ZONE}

Este comando puede llevar unos minutos en completarse.

Cómo crear un clúster de Dataproc

Crea el primer clúster de Dataproc y reemplaza CLUSTER_NAME por un nombre como hive-cluster :

gcloud dataproc clusters create CLUSTER_NAME \
    --scopes sql-admin \
    --region ${REGION} \
    --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
    --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
    --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore" \
    --metadata "enable-cloud-sql-proxy-on-workers=false"

Notas:

  • Proporciona el permiso de acceso de sql-admin para permitir que las instancias de clústeres accedan a la API de Administrador de Cloud SQL.
  • Debes colocar la acción de inicialización en una secuencia de comandos que almacenas en un bucket de Cloud Storage y hacer referencia a ese bucket con la marca --initialization-actions. Consulta Acciones de inicialización: consideraciones y lineamientos importantes para obtener más información.
  • Proporciona el URI al bucket de almacenamiento de Hive en la propiedad hive:hive.metastore.warehouse.dir. Esta acción configura los servidores de Hive para que lean y escriban en la ubicación correcta. Esta propiedad debe contener al menos un directorio (por ejemplo, gs://my-bucket/my-directory). Hive no funcionará correctamente si esta propiedad se configura como un nombre de bucket sin un directorio (por ejemplo, gs://my-bucket).
  • Especifica enable-cloud-sql-proxy-on-workers=false para asegurarte de que el proxy de Cloud SQL solo se ejecute en nodos principales, lo que es suficiente para que el servicio de almacén de metadatos de Hive funcione y evita la carga innecesaria en Cloud SQL.
  • Proporciona la acción de inicialización del proxy de Cloud SQL que Dataproc ejecuta de forma automática en todas las instancias de clústeres. La acción realiza lo siguiente:

    • Instala el proxy de Cloud SQL.
    • Establece una conexión segura con la instancia de Cloud SQL especificada en el parámetro de metadatos hive-metastore-instance.
    • Crea el usuario de hive y la base de datos del almacén de metadatos de Hive.

    Puedes ver el código completo de la acción de inicialización del proxy de Cloud SQL en GitHub.

  • Para que este instructivo sea más simple, se 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.

  • En este instructivo, se usa una instancia de Cloud SQL con una dirección IP pública. Si, en cambio, usas una instancia con solo una dirección IP privada, puedes forzar al proxy a usar la dirección IP privada mediante el parámetro --metadata "use-cloud-sql-private-ip=true".

Crea una tabla de Hive

En esta sección, subirás un conjunto de datos de ejemplo al bucket de almacenamiento, crearás una tabla de Hive nueva y ejecutarás las consultas de HiveQL en ese conjunto de datos.

  1. Copia el conjunto de datos de ejemplo en el bucket de almacenamiento:

    gsutil cp gs://hive-solution/part-00000.parquet \
    gs://${WAREHOUSE_BUCKET}/datasets/transactions/part-00000.parquet

    Este conjunto de datos se comprime en formato Parquet y contiene miles de registros de transacciones en un banco ficticio con tres columnas: fecha, importe y tipo de transacción.

  2. Crea una tabla de Hive externa para el conjunto de datos:

    gcloud dataproc jobs submit hive \
        --cluster CLUSTER_NAME \
        --region ${REGION} \
        --execute "
          CREATE EXTERNAL TABLE transactions
          (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING)
          STORED AS PARQUET
          LOCATION 'gs://${WAREHOUSE_BUCKET}/datasets/transactions';"

Ejecuta consultas de Hive

Puedes usar diferentes herramientas dentro de Dataproc para ejecutar consultas de Hive. En esta sección, aprenderás a realizar consultas con las siguientes herramientas:

En cada sección, ejecuta una consulta de ejemplo.

Consulta Hive con la API de trabajos de Dataproc

Ejecuta la siguiente consulta simple de HiveQL para verificar que el archivo parquet esté correctamente vinculado a la tabla de Hive:

gcloud dataproc jobs submit hive \
    --cluster CLUSTER_NAME \
    --region ${REGION} \
    --execute "
      SELECT *
      FROM transactions
      LIMIT 10;"

Se muestra el siguiente resultado:

+-----------------+--------------------+------------------+
| submissiondate  | transactionamount  | transactiontype  |
+-----------------+--------------------+------------------+
| 2017-12-03      | 1167.39            | debit            |
| 2017-09-23      | 2567.87            | debit            |
| 2017-12-22      | 1074.73            | credit           |
| 2018-01-21      | 5718.58            | debit            |
| 2017-10-21      | 333.26             | debit            |
| 2017-09-12      | 2439.62            | debit            |
| 2017-08-06      | 5885.08            | debit            |
| 2017-12-05      | 7353.92            | authorization    |
| 2017-09-12      | 4710.29            | authorization    |
| 2018-01-05      | 9115.27            | debit            |
+-----------------+--------------------+------------------+

Realiza consultas en Hive con Beeline

  1. Abre una sesión SSH con la instancia principal de Dataproc (CLUSTER_NAME-m):

    gcloud compute ssh CLUSTER_NAME-m
  2. En el símbolo del sistema de la instancia principal, abre una sesión de Beeline:

    beeline -u "jdbc:hive2://localhost:10000"

    Notas:

    • También puedes hacer referencia al nombre de la instancia principal como host en lugar de localhost:

      beeline -u "jdbc:hive2://CLUSTER_NAME-m:10000"
    • Si usaras el modo de alta disponibilidad con 3 instancias principales, deberías usar el siguiente comando:

      beeline -u "jdbc:hive2://CLUSTER_NAME-m-0:2181,CLUSTER_NAME-m-1:2181,CLUSTER_NAME-m-2:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2"
  3. Cuando se muestra el mensaje de Beeline, ejecuta la siguiente consulta de HiveQL:

    SELECT TransactionType, AVG(TransactionAmount) AS AverageAmount
    FROM transactions
    WHERE SubmissionDate = '2017-12-22'
    GROUP BY TransactionType;

    Se muestra el siguiente resultado:

    +------------------+--------------------+
    | transactiontype  |   averageamount    |
    +------------------+--------------------+
    | authorization    | 4890.092525252529  |
    | credit           | 4863.769269565219  |
    | debit            | 4982.781458176331  |
    +------------------+--------------------+
  4. Cierre la sesión de Beeline:

    !quit
  5. Cierra la conexión de SSH:

    exit

Realiza consultas en Hive con SparkSQL

  1. Abre una sesión SSH con la instancia principal de Dataproc:

    gcloud compute ssh CLUSTER_NAME-m
  2. En el mensaje del comando de la instancia principal, abre una sesión de shell nueva de PySpark:

    pyspark
  3. Cuando se muestra el mensaje de shell de PySpark, escribe el siguiente código de Python:

    from pyspark.sql import HiveContext
    hc = HiveContext(sc)
    hc.sql("""
    SELECT SubmissionDate, AVG(TransactionAmount) as AvgDebit
    FROM transactions
    WHERE TransactionType = 'debit'
    GROUP BY SubmissionDate
    HAVING SubmissionDate >= '2017-10-01' AND SubmissionDate < '2017-10-06'
    ORDER BY SubmissionDate
    """).show()

    Se muestra el siguiente resultado:

    +-----------------+--------------------+
    | submissiondate  |      avgdebit      |
    +-----------------+--------------------+
    | 2017-10-01      | 4963.114920399849  |
    | 2017-10-02      | 5021.493300510582  |
    | 2017-10-03      | 4982.382279569891  |
    | 2017-10-04      | 4873.302702503676  |
    | 2017-10-05      | 4967.696333583777  |
    +-----------------+--------------------+
  4. Cierra la sesión de PySpark:

    exit()
  5. Cierra la conexión de SSH:

    exit

Inspecciona el almacén de metadatos de Hive

Verifica que el almacén de metadatos de Hive en Cloud SQL contenga información sobre la tabla transactions.

  1. En Cloud Shell, inicia una sesión nueva de MySQL en la instancia de Cloud SQL:

    gcloud sql connect hive-metastore --user=root

    Cuando se te solicite la contraseña de usuario root, no escribas nada y solo presiona la tecla RETURN. A fin de simplificar, en este instructivo, no estableciste una contraseña para el usuario root. Para obtener información sobre cómo configurar una contraseña a fin de proteger aún más la base de datos del almacén de metadatos, consulta la documentación de Cloud SQL. La acción de inicialización del proxy de Cloud SQL también proporciona un mecanismo para proteger contraseñas mediante la encriptación. Si deseas obtener más información, consulta el repositorio de código de la acción.

  2. En el símbolo del sistema de MySQL, establece hive_metastore como la base de datos predeterminada para el resto de la sesión:

    USE hive_metastore;
  3. Verifica que la ubicación del depósito de almacenamiento esté registrada en el almacén de metadatos:

    SELECT DB_LOCATION_URI FROM DBS;

    El resultado obtenido se verá así:

    +-------------------------------------+
    | DB_LOCATION_URI                     |
    +-------------------------------------+
    | gs://[WAREHOUSE_BUCKET]/datasets   |
    +-------------------------------------+
  4. Verifica que la tabla esté correctamente mencionada en el almacén de metadatos:

    SELECT TBL_NAME, TBL_TYPE FROM TBLS;

    El resultado obtenido se verá así:

    +--------------+----------------+
    | TBL_NAME     | TBL_TYPE       |
    +--------------+----------------+
    | transactions | EXTERNAL_TABLE |
    +--------------+----------------+
  5. Verifica que las columnas de la tabla estén correctamente mencionadas:

    SELECT COLUMN_NAME, TYPE_NAME
    FROM COLUMNS_V2 c, TBLS t
    WHERE c.CD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

    El resultado obtenido se verá así:

    +-------------------+-----------+
    | COLUMN_NAME       | TYPE_NAME |
    +-------------------+-----------+
    | submissiondate    | date      |
    | transactionamount | double    |
    | transactiontype   | string    |
    +-------------------+-----------+
  6. Verifica que el formato de entrada y la ubicación estén correctamente mencionados:

    SELECT INPUT_FORMAT, LOCATION
    FROM SDS s, TBLS t
    WHERE s.SD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

    El resultado obtenido se verá así:

    +---------------------------------------------------------------+------------------------------------------------+
    | INPUT_FORMAT                                                  | LOCATION                                       |
    +---------------------------------------------------------------+------------------------------------------------+
    | org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat | gs://[WAREHOUSE_BUCKET]/datasets/transactions |
    +---------------------------------------------------------------+------------------------------------------------+
    
  7. Cierra la sesión de MySQL:

    exit

Crea otro clúster de Dataproc

En esta sección, crearás otro clúster de Dataproc para verificar que los datos y el almacén de metadatos de Hive puedan compartirse entre varios clústeres.

  1. Crea un clúster de Dataproc nuevo:

    gcloud dataproc clusters create other-CLUSTER_NAME \
        --scopes cloud-platform \
        --image-version 2.0 \
        --region ${REGION} \
        --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
        --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
        --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore"\
        --metadata "enable-cloud-sql-proxy-on-workers=false"
  2. Verifica que el clúster nuevo pueda acceder a los datos:

    gcloud dataproc jobs submit hive \
        --cluster other-CLUSTER_NAME \
        --region ${REGION} \
        --execute "
          SELECT TransactionType, COUNT(TransactionType) as Count
          FROM transactions
          WHERE SubmissionDate = '2017-08-22'
          GROUP BY TransactionType;"

    Se muestra el siguiente resultado:

    +------------------+--------+
    | transactiontype  | count  |
    +------------------+--------+
    | authorization    | 696    |
    | credit           | 1722   |
    | debit            | 2599   |
    +------------------+--------+

Felicitaciones. Completaste el instructivo.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Para evitar que se generen costos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, sigue estos pasos:

  • Limpia todos los recursos que creaste para evitar que se apliquen cargos en el futuro. La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el instructivo.
  • Como alternativa, puedes borrar recursos individuales.

Borra el proyecto

  1. En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Borra recursos individuales

Ejecuta los siguientes comandos en Cloud Shell para borrar los recursos individuales, en vez de eliminar el proyecto completo:

gcloud dataproc clusters delete CLUSTER_NAME --region ${REGION} --quiet
gcloud dataproc clusters delete other-CLUSTER_NAME --region ${REGION} --quiet
gcloud sql instances delete hive-metastore --quiet
gsutil rm -r gs://${WAREHOUSE_BUCKET}/datasets

Pasos siguientes

  • 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.
  • Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.