Google Cloud 上の Hadoop に可視化ソフトウェアを接続する

Last reviewed 2024-04-17 UTC

このチュートリアルシリーズのパート 2 では、データアナリストがビジネスインテリジェンス（BI）ツールを使用してデータにアクセスできるように、エンドツーエンドのソリューションを構築する方法について説明します。

このチュートリアルは、データアナリストが使用するビジネスインテリジェンス（BI）ツールにデータと処理機能を提供する環境の設定を行う運用者と IT 管理者を対象としています。

このチュートリアルでは、BI ツールとして Tableau を使用します。始める前に、Tableau Desktop をワークステーションにインストールしておく必要があります。

このシリーズは、次のパートで構成されています。

パート 1 の可視化ソフトウェアを Google Cloud 上の Hadoop に接続するためのアーキテクチャでは、ソリューションのアーキテクチャとそのコンポーネント、コンポーネント間のやり取りについて説明しています。
パート 2 では、Google Cloud でエンドツーエンドの Hive トポロジを構成するアーキテクチャコンポーネントの設定方法について説明します。このチュートリアルでは、Hadoop エコシステムのオープンソースツールを使用し、BI ツールには Tableau を使用します。

このチュートリアルのコードスニペットは GitHub リポジトリで入手できます。GitHub リポジトリには、作業用のプロトタイプの設定に役立つ Terraform 構成ファイルも含まれています。

このチュートリアルでは、データアナリストの架空のユーザー ID として sara を使用します。このユーザー ID は、Apache Knox と Apache Ranger の両方が使用する LDAP ディレクトリにあります。LDAP グループを構成することもできますが、このチュートリアルでは説明しません。

目標

BI ツールで Hadoop 環境のデータを使用できるように、エンドツーエンドの設定を行う。
ユーザーリクエストの認証と承認を行う。
BI ツールとクラスタ間で安全な通信チャネルを設定して使用する。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Dataproc, Cloud SQL, and Cloud Key Management Service (Cloud KMS) API を有効にします。

API を有効にする

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Dataproc, Cloud SQL, and Cloud Key Management Service (Cloud KMS) API を有効にします。

API を有効にする

環境を初期化する

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする
Cloud Shell で、プロジェクト ID、Dataproc クラスタのリージョンとゾーンを環境変数に設定します。
```
export PROJECT_ID=$(gcloud info --format='value(config.project)')
export REGION=us-central1
export ZONE=us-central1-b
```
このチュートリアルで説明するように、任意のリージョンとゾーンを選択できますが、一貫性を維持してください。

サービスアカウントの設定

Cloud Shell で、サービスアカウントを作成します。

gcloud iam service-accounts create cluster-service-account \
  --description="The service account for the cluster to be authenticated as." \
  --display-name="Cluster service account"

クラスタは、このアカウントを使用して Google Cloud リソースにアクセスします。

サービスアカウントに次のロールを追加します。
- Dataproc ワーカー: Dataproc クラスタの作成、管理を行います。
- Cloud SQL 編集者: Cloud SQL Proxy を使用して Ranger からデータベースに接続します。
- Cloud KMS 暗号鍵の復号: Cloud KMS で暗号化されたパスワードを復号します。
```
bash -c 'array=( dataproc.worker cloudsql.editor cloudkms.cryptoKeyDecrypter )
for i in "${array[@]}"
do
  gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member "serviceAccount:cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role roles/$i
done'
```

バックエンドクラスタの作成

このセクションでは、Ranger を配置するバックエンドクラスタを作成します。また、ポリシールールを格納する Ranger データベースと、Ranger ポリシーを適用するサンプルテーブルを作成します。

Ranger データベースインスタンスを作成する

Apache Ranger ポリシーを保存する MySQL インスタンスを作成します。
```
export CLOUD_SQL_NAME=cloudsql-mysql
gcloud sql instances create ${CLOUD_SQL_NAME} \
    --tier=db-n1-standard-1 --region=${REGION}
```
このコマンドを実行すると、${REGION} 変数に指定されたリージョンに、マシンタイプが db-n1-standard-1 の cloudsql-mysql というインスタンスが作成されます。詳細については、Cloud SQL のドキュメントをご覧ください。
任意のホストから接続するユーザー root のインスタンスパスワードを設定します。デモ用のサンプルパスワードを使用することも、独自のパスワードを作成することもできます。独自のパスワードを作成する場合は、8 文字以上にし、文字と数字をそれぞれ 1 個以上使用してください。
```
gcloud sql users set-password root \
  --host=% --instance ${CLOUD_SQL_NAME} --password mysql-root-password-99
```

パスワードを暗号化する

このセクションでは、暗号鍵を作成して Ranger と MySQL のパスワードを暗号化します。漏えいを防ぐため、暗号鍵を Cloud KMS に保存します。セキュリティ上の理由から、鍵のビットを表示、抽出、エクスポートすることはできません。

暗号鍵でパスワードを暗号化し、ファイルに書き込みます。これらのファイルを Cloud Storage バケットにアップロードして、クラスタの代わりにサービスアカウントからアクセスできるようにします。サービスアカウントは、cloudkms.cryptoKeyDecrypter ロールが付与され、ファイルと暗号鍵に対するアクセスが許可されているため、これらのファイルを復号できます。ファイルが流出しても、ロールと鍵がなければファイルの復号はできません。

追加のセキュリティ対策として、サービスごとに個別のパスワードファイルを作成します。これにより、パスワードが漏えいした場合の被害を最小限に抑えることができます。

鍵管理の詳細については、Cloud KMS のドキュメントをご覧ください。

Cloud Shell で、鍵を格納する Cloud KMS キーリングを作成します。
```
gcloud kms keyrings create my-keyring --location global
```

パスワードを暗号化するには、Cloud KMS 暗号鍵を作成します。

gcloud kms keys create my-key \
  --location global \
  --keyring my-keyring \
  --purpose encryption

この鍵で Ranger 管理ユーザーのパスワードを暗号化します。サンプルパスワードを使用することも、独自のパスワードを作成することもできます。パスワードは 8 文字以上にし、文字と数字をそれぞれ 1 個以上使用してください。
```
echo "ranger-admin-password-99" | \
gcloud kms encrypt \
  --location=global \
  --keyring=my-keyring \
  --key=my-key \
  --plaintext-file=- \
  --ciphertext-file=ranger-admin-password.encrypted
```

この鍵で Ranger データベース管理者ユーザーのパスワードを暗号化します。

echo "ranger-db-admin-password-99" | \
gcloud kms encrypt \
  --location=global \
  --keyring=my-keyring \
  --key=my-key \
  --plaintext-file=- \
  --ciphertext-file=ranger-db-admin-password.encrypted

この鍵で MySQL ルートのパスワードを暗号化します。

echo "mysql-root-password-99" | \
gcloud kms encrypt \
  --location=global \
  --keyring=my-keyring \
  --key=my-key \
  --plaintext-file=- \
  --ciphertext-file=mysql-root-password.encrypted

暗号化されたパスワードファイルを格納する Cloud Storage バケットを作成します。
```
gsutil mb -l ${REGION} gs://${PROJECT_ID}-ranger
```
暗号化されたパスワードファイルを Cloud Storage バケットにアップロードします。
```
gsutil -m cp *.encrypted gs://${PROJECT_ID}-ranger
```

クラスタを作成する

このセクションでは、Ranger をサポートするバックエンドクラスタを作成します。Dataproc の Ranger オプションコンポーネントの詳細については、Dataproc Ranger コンポーネントのドキュメントをご覧ください。

Cloud Shell で、Apache Solr 監査ログを格納する Cloud Storage バケットを作成します。
```
gsutil mb -l ${REGION} gs://${PROJECT_ID}-solr
```
クラスタの作成に必要なすべての変数をエクスポートします。
```
export BACKEND_CLUSTER=backend-cluster

export PROJECT_ID=$(gcloud info --format='value(config.project)')
export REGION=us-central1
export ZONE=us-central1-b
export CLOUD_SQL_NAME=cloudsql-mysql

export RANGER_KMS_KEY_URI=\
projects/${PROJECT_ID}/locations/global/keyRings/my-keyring/cryptoKeys/my-key

export RANGER_ADMIN_PWD_URI=\
gs://${PROJECT_ID}-ranger/ranger-admin-password.encrypted

export RANGER_DB_ADMIN_PWD_URI=\
gs://${PROJECT_ID}-ranger/ranger-db-admin-password.encrypted

export MYSQL_ROOT_PWD_URI=\
gs://${PROJECT_ID}-ranger/mysql-root-password.encrypted
```
便宜上、このコマンドでは以前に設定した変数を再利用しますが、必要に応じて変更することも可能です。

新しい変数には次のものが含まれています。
- バックエンドクラスタの名前。
- 暗号鍵の URI。サービスアカウントは、この URI を使用してパスワードの復号を行います。
- 暗号化されたパスワードを含むファイルの URI。
別のキーリングや鍵、または異なるファイル名を使用した場合は、対応する値をコマンドに使用します。
バックエンド Dataproc クラスタを作成します。
```
gcloud beta dataproc clusters create ${BACKEND_CLUSTER} \
  --optional-components=SOLR,RANGER \
  --region ${REGION} \
  --zone ${ZONE} \
  --enable-component-gateway \
  --scopes=default,sql-admin \
  --service-account=cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com \
  --properties="\
dataproc:ranger.kms.key.uri=${RANGER_KMS_KEY_URI},\
dataproc:ranger.admin.password.uri=${RANGER_ADMIN_PWD_URI},\
dataproc:ranger.db.admin.password.uri=${RANGER_DB_ADMIN_PWD_URI},\
dataproc:ranger.cloud-sql.instance.connection.name=${PROJECT_ID}:${REGION}:${CLOUD_SQL_NAME},\
dataproc:ranger.cloud-sql.root.password.uri=${MYSQL_ROOT_PWD_URI},\
dataproc:solr.gcs.path=gs://${PROJECT_ID}-solr,\
hive:hive.server2.thrift.http.port=10000,\
hive:hive.server2.thrift.http.path=cliservice,\
hive:hive.server2.transport.mode=http"
```
このコマンドでは次のプロパティを使用しています。
- コマンドの最後の 3 行は、Hive モードで HiveServer2 を HTTP モードで構成するための Hive プロパティです。これにより、Apache Knox は HTTP 経由で Apache Hive を呼び出すことができます。
- コマンド内の他のパラメータは、次のように機能します。
  - --optional-components=SOLR,RANGER パラメータは、Apache Ranger とその Solr の依存関係を有効にします。
  - --enable-component-gateway パラメータを使用すると、Dataproc コンポーネントゲートウェイで Google Cloud コンソールのクラスタページから直接 Ranger などの Hadoop ユーザーインターフェースを利用できるようになります。このパラメータを設定した場合、バックエンドマスターノードに SSH トンネリングを行う必要はありません。
  - --scopes=default,sql-admin パラメータは、Apache Ranger から Cloud SQL データベースへのアクセスを許可します。

クラスタの存続期間を超えて存続し、複数のクラスタで使用できる外部の Hive メタストアを作成する必要がある場合は、Dataproc での Apache Hive の使用をご覧ください。プロシージャを実行するには、Beeline で直接テーブルのサンプルを作成する必要があります。gcloud dataproc jobs submit hive コマンドは Hive バイナリトランスポートを使用しますが、HTTP モードで構成している場合、これらのコマンドは HiveServer2 と互換性がありません。

Hive テーブルのサンプルを作成する

Cloud Shell で、サンプルの Apache Parquet ファイルを格納する Cloud Storage バケットを作成します。
```
gsutil mb -l ${REGION} gs://${PROJECT_ID}-hive
```

一般公開されている Parquet サンプルファイルをバケットにコピーします。

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

SSH を使用して、前のセクションで作成したバックエンドクラスタのマスターノードに接続します。
```
gcloud compute ssh --zone ${ZONE} ${BACKEND_CLUSTER}-m
```
クラスタの名前に続く -m. がクラスタマスターノードの名前です。HA クラスタのマスターノード名には、余分なサフィックスが付いています。

Cloud Shell から初めてマスターノードに接続する場合は、SSH 認証鍵を生成するように求められます。
SSH で開いたターミナルで、Apache Beeline（ローカルノードにプリインストールされています）を使用して、ローカル HiveServer2 に接続します。
```
beeline -u "jdbc:hive2://localhost:10000/;transportMode=http;httpPath=cliservice admin admin-password"\
  --hivevar PROJECT_ID=$(gcloud info --format='value(config.project)')
```
このコマンドは、Beeline コマンドラインツールを開始し、Google Cloud プロジェクトの名前を環境変数に渡します。

Hive はユーザー認証を行っていませんが、ほとんどのタスクでユーザー ID が必要になります。ここでは、admin ユーザーが Hive で構成されているデフォルトのユーザーです。このチュートリアルの後半で Apache Knox で構成する ID プロバイダが、BI ツールからのリクエストに対するユーザー認証を処理します。

Beeline プロンプトで、Hive バケットにコピーした Parquet ファイルを使用してテーブルを作成します。

CREATE EXTERNAL TABLE transactions
  (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING)
  STORED AS PARQUET
  LOCATION 'gs://${PROJECT_ID}-hive/dataset/transactions';

テーブルが正しく作成されたことを確認します。

SELECT *
  FROM transactions
  LIMIT 10;

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

2 つのクエリの結果が Beeline プロンプトに表示されます。

Beeline コマンドラインツールを終了します。
```
!quit
```
バックエンドマスターの内部 DNS 名をコピーします。
```
hostname -A | tr -d '[:space:]'; echo
```
次のセクションでは、この名前を backend-master-internal-dns-name として使用して Apache Knox トポロジを構成します。この名前を使用して Ranger にサービスを構成します。
ノードでターミナルを終了します。
```
exit
```

プロキシクラスタの作成

このセクションでは、プロキシクラスタを作成して Apache Knox 初期化アクションを設定します。

トポロジを作成する

Cloud Shell で、Dataproc initialization-actions GitHub リポジトリのクローンを作成します。
```
git clone https://github.com/GoogleCloudDataproc/initialization-actions.git
```
バックエンドクラスタのトポロジを作成します。
```
export KNOX_INIT_FOLDER=`pwd`/initialization-actions/knox
cd ${KNOX_INIT_FOLDER}/topologies/
mv example-hive-nonpii.xml hive-us-transactions.xml
```
Apache Knox は、ファイル名をトポロジの URL パスとして使用します。このステップでは、トポロジの名前を hive-us-transactions に変更します。これで、サンプル Hive テーブルの作成で Hive に読み込んだ架空のトランザクションデータにアクセスできるようになりました。
トポロジファイルを編集します。
```
vi hive-us-transactions.xml
```
バックエンドサービスの構成方法については、トポロジ記述子ファイルをご覧ください。このファイルでは、1 つ以上のバックエンドサービスを参照するトポロジを定義します。WebHDFS と HIVE の 2 つのサービスがサンプル値で構成されています。このファイルでは、このトポロジ内のサービスの認証プロバイダと認証 ACL も定義します。
データアナリストのサンプル LDAP ユーザー ID sara を追加します。
```
<param>
   <name>hive.acl</name>
   <value>admin,sara;*;*</value>
</param>
```
サンプル ID を追加すると、ユーザーは Apache Knox を介して Hive バックエンドサービスにアクセスできるようになります。
バックエンドクラスタの Hive サービスを参照するように HIVE の URL を変更します。HIVE のサービス定義はファイル下部の WebHDFS の下にあります。
```
<service>
  <role>HIVE</role>
  <url>http://<backend-master-internal-dns-name>:10000/cliservice</url>
</service>
```
<backend-master-internal-dns-name> プレースホルダは、サンプル Hive テーブルの作成で取得したバックエンドクラスタの内部 DNS 名に置き換えます。
ファイルを保存して、エディタを閉じます。

追加のトポロジを作成するには、このセクションの手順を繰り返します。トポロジごとに独立した XML 記述子を作成します。

プロキシクラスタを作成するの手順で、これらのファイルを Cloud Storage バケットにコピーします。新しいトポロジを作成する場合や、プロキシクラスタの作成後にファイルを変更する場合は、ファイルを変更してから、もう一度バケットにアップロードします。Apache Knox 初期化アクションにより、バケットからプロキシクラスタへ変更を定期的にコピーする cron ジョブが作成されます。

SSL / TLS 証明書を構成する

クライアントは、Apache Knox との通信で SSL / TLS 証明書を使用します。初期化アクションで自己署名証明書を生成することも、CA で署名された証明書を使用することもできます。

Cloud Shell で、Apache Knox の一般的な構成ファイルを編集します。
```
vi ${KNOX_INIT_FOLDER}/knox-config.yaml
```
HOSTNAME は、certificate_hostname 属性の値としてプロキシマスターノードの外部 DNS 名に置き換えます。このチュートリアルでは、localhost を使用します。
```
certificate_hostname: localhost
```
このチュートリアルの後半で、SSH トンネルを作成して、localhost 値のプロキシクラスタを作成します。

Apache Knox の一般的な構成ファイルには master_key も含まれています。これは、BI ツールがプロキシクラスタとの通信に使用する証明書を暗号化します。デフォルトでは、この鍵は secret です。
独自の証明書を使用する場合は、次の 2 つのプロパティを変更します。
```
generate_cert: false
custom_cert_name: <filename-of-your-custom-certificate>
```
ファイルを保存して、エディタを閉じます。

独自の証明書を使用する場合は、その証明書をプロパティ custom_cert_name に指定します。

プロキシクラスタを作成する

Cloud Shell で、Cloud Storage バケットを作成します。
```
gsutil mb -l ${REGION} gs://${PROJECT_ID}-knox
```
このバケットは、前のセクションで作成した構成を Apache Knox の初期化アクションに提供します。
Apache Knox 初期化アクションフォルダのすべてのファイルをバケットにコピーします。
```
gsutil -m cp -r ${KNOX_INIT_FOLDER}/* gs://${PROJECT_ID}-knox
```
クラスタの作成に必要なすべての変数をエクスポートします。
```
export PROXY_CLUSTER=proxy-cluster
export PROJECT_ID=$(gcloud info --format='value(config.project)')
export REGION=us-central1
export ZONE=us-central1-b
```
このコマンドでは以前に設定した変数を再利用しますが、必要に応じて変更することも可能です。

プロキシクラスタを作成します。

gcloud dataproc clusters create ${PROXY_CLUSTER} \
  --region ${REGION} \
  --zone ${ZONE} \
  --service-account=cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com \
  --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/knox/knox.sh \
  --metadata knox-gw-config=gs://${PROJECT_ID}-knox

プロキシ経由の接続を確認する

プロキシクラスタを作成したら、SSH を使用して Cloud Shell からマスターノードに接続します。
```
gcloud compute ssh --zone ${ZONE} ${PROXY_CLUSTER}-m
```

プロキシクラスタのターミナルから、次のクエリを実行します。

beeline -u "jdbc:hive2://localhost:8443/;\
ssl=true;sslTrustStore=/usr/lib/knox/data/security/keystores/gateway-client.jks;trustStorePassword=secret;\
transportMode=http;httpPath=gateway/hive-us-transactions/hive"\
  -e "SELECT SubmissionDate, TransactionType FROM transactions LIMIT 10;"\
  -n admin -p admin-password

このコマンドでは次のプロパティを使用しています。

beeline コマンドでは、DNS 内部名の代わりに localhost を使用します。これは、Apache Knox の構成時に生成した証明書がホスト名として localhost を使用するためです。独自の DNS 名または証明書を使用している場合は、対応するホスト名を使用します。
ポートは 8443 です。これは、Apache Knox のデフォルトの SSL ポートに対応しています。
ssl=true で始まる行は、SSL を有効にし、Beeline などのクライアントアプリケーションによって使用される SSL トラストストアのパスとパスワードを提供します。
transportMode 行は、リクエストを HTTP 経由で送信することを示し、HiveServer2 サービスのパスを提供します。このパスは、キーワード gateway、前のセクションで定義したトポロジ名、同じトポロジで構成されたサービス名（この場合は hive）で構成されます。
-e パラメータは、Hive で実行するクエリを提供します。このパラメータを省略した場合、Beeline コマンドラインツールでインタラクティブセッションが開きます。
-n パラメータは、ユーザー ID とパスワードを提供します。この手順では、デフォルトの Hive admin ユーザーを使用します。次のセクションでは、アナリストのユーザー ID を作成し、このユーザーの認証情報と認証ポリシーを設定します。

ユーザーを認証ストアに追加する

デフォルトでは、Apache Knox に Apache Shirro に基づく認証プロバイダが含まれています。この認証プロバイダには、ApacheDS LDAP ストアで BASIC 認証が構成されています。このセクションでは、サンプルデータアナリストのユーザー ID sara を認証ストアに追加します。

プロキシのマスターノードのターミナルから、LDAP ユーティリティをインストールします。
```
sudo apt-get install ldap-utils
```

新しいユーザー sara に LDAP Data Interchange Format（LDIF）ファイルを作成します。

export USER_ID=sara

printf '%s\n'\
  "# entry for user ${USER_ID}"\
  "dn: uid=${USER_ID},ou=people,dc=hadoop,dc=apache,dc=org"\
  "objectclass:top"\
  "objectclass:person"\
  "objectclass:organizationalPerson"\
  "objectclass:inetOrgPerson"\
  "cn: ${USER_ID}"\
  "sn: ${USER_ID}"\
  "uid: ${USER_ID}"\
  "userPassword:${USER_ID}-password"\
> new-user.ldif

LDAP ディレクトリにユーザー ID を追加します。
```
ldapadd -f new-user.ldif \
  -D 'uid=admin,ou=people,dc=hadoop,dc=apache,dc=org' \
  -w 'admin-password' \
  -H ldap://localhost:33389
```
-D パラメータには、ldapadd で表されるユーザーがディレクトリにアクセスする際にバインドする識別名（DN）を指定します。DN は、すでにディレクトリに存在するユーザー ID（この場合は admin）にする必要があります。

新しいユーザーが認証ストアにあることを確認します。

ldapsearch -b "uid=${USER_ID},ou=people,dc=hadoop,dc=apache,dc=org" \
  -D 'uid=admin,ou=people,dc=hadoop,dc=apache,dc=org' \
  -w 'admin-password' \
  -H ldap://localhost:33389

ユーザーの詳細がターミナルに表示されます。

プロキシマスターノードの内部 DNS 名をコピーして保存します。
```
hostname -A | tr -d '[:space:]'; echo
```
次のセクションで、この名前を <proxy-master-internal-dns-name> として使用し、LDAP 同期を構成します。
ノードでターミナルを終了します。
```
exit
```

認証の設定

このセクションでは、LDAP サービスと Ranger 間の ID 同期を構成します。

ユーザー ID を Ranger に同期する

Ranger ポリシーが Apache Knox と同じユーザー ID に適用されるようにするには、同じディレクトリから ID を同期するように Directoryr UserSync デーモンを構成します。

この例では、Apache Knox でデフォルトで使用できるローカル LDAP ディレクトリに接続します。ただし、本番環境では外部 ID ディレクトリを設定することをおすすめします。詳細については、Apache Knox ユーザーガイドと、Google Cloud の Cloud Identity、マネージド Active Directory、フェデレーション AD のドキュメントをご覧ください。

SSH を使用して、作成したバックエンドクラスタのマスターノードに接続します。
```
export BACKEND_CLUSTER=backend-cluster
gcloud compute ssh --zone ${ZONE} ${BACKEND_CLUSTER}-m
```
ターミナルで、UserSync 構成ファイルを編集します。
```
sudo vi /etc/ranger/usersync/conf/ranger-ugsync-site.xml
```

次の LDAP プロパティの値を設定します。類似した名前の group プロパティではなく、user プロパティを変更していることを確認してください。

<property>
  <name>ranger.usersync.sync.source</name>
  <value>ldap</value>
</property>

<property>
  <name>ranger.usersync.ldap.url</name>
  <value>ldap://<proxy-master-internal-dns-name>:33389</value>
</property>

<property>
  <name>ranger.usersync.ldap.binddn</name>
  <value>uid=admin,ou=people,dc=hadoop,dc=apache,dc=org</value>
</property>

<property>
  <name>ranger.usersync.ldap.ldapbindpassword</name>
  <value>admin-password</value>
</property>

<property>
  <name>ranger.usersync.ldap.user.searchbase</name>
  <value>dc=hadoop,dc=apache,dc=org</value>
</property>

<property>
  <name>ranger.usersync.source.impl.class</name>
  <value>org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder</value>
</property>

<proxy-master-internal-dns-name> プレースホルダは、前のセクションで取得したプロキシサーバーの内部 DNS 名で置き換えます。

これらのプロパティは、ユーザーとグループの両方を同期する完全な LDAP 構成のサブセットです。詳しくは、Ranger と LDAP を統合する方法をご覧ください。

ファイルを保存して、エディタを閉じます。
ranger-usersync デーモンを再起動します。
```
sudo service ranger-usersync restart
```
次のコマンドを実行します。
```
grep sara /var/log/ranger-usersync/*
```
ID が同期されている場合、ユーザー sara のログ行が 1 つ以上表示されます。

Ranger ポリシーの作成

このセクションでは、Ranger で新しい Hive サービスを構成します。また、特定の ID の Hive データへのアクセスを制限するために、Ranger ポリシーを設定してテストします。

Ranger サービスを構成する

マスターノードのターミナルから、Ranger Hive の構成を編集します。
```
sudo vi /etc/hive/conf/ranger-hive-security.xml
```

ranger.plugin.hive.service.name プロパティの <value> プロパティを編集します。

<property>
   <name>ranger.plugin.hive.service.name</name>
   <value>ranger-hive-service-01</value>
   <description>
     Name of the Ranger service containing policies for this YARN instance
   </description>
</property>

ファイルを保存して、エディタを閉じます。
HiveServer2 Admin サービスを再起動します。
```
sudo service hive-server2 restart
```
これで Ranger ポリシーを作成する準備ができました。

Ranger Admin コンソールでサービスを設定する

Google Cloud コンソールで、[Dataproc] ページに移動します。
バックエンドクラスタ名をクリックし、[ウェブインターフェース] をクリックします。

コンポーネントゲートウェイでクラスタを作成したため、クラスタにインストールされている Hadoop コンポーネントの一覧が表示されます。
Ranger リンクをクリックして Ranger コンソールを開きます。
ユーザー admin と Ranger の管理者パスワードで Ranger にログインします。Ranger コンソールで、[Service Manager] ページにサービスの一覧が表示されます。
HIVE グループのプラス記号をクリックすると、新しい Hive サービスが作成されます。
フォームで次の値を設定します。
- Service name: ranger-hive-service-01。この名前は、ranger-hive-security.xml 構成ファイルですでに定義されています。
- Username: admin
- Password: admin-password
- jdbc.driverClassName: デフォルト名の org.apache.hive.jdbc.HiveDriver を使用します。
- jdbc.url: jdbc:hive2:<backend-master-internal-dns-name>:10000/;transportMode=http;httpPath=cliservice
- <backend-master-internal-dns-name> プレースホルダは、前のセクションで取得した名前に置き換えます。
[Add] をクリックします。

Ranger プラグインのインストールは、単一の Hive サービスをサポートします。追加のバックエンドクラスタを起動すると、追加の Hive サービスを簡単に構成できます。各クラスタに独自の Ranger プラグインがあります。これらのクラスタは Ranger DB を共有できるため、これらのクラスタから Ranger 管理コンソールにアクセスすると、すべてのサービスを確認できます。

権限が制限された Ranger ポリシーを設定する

ポリシーを設定すると、Hive テーブルの特定の列に対する sara アクセス権をサンプルアナリストの LDAP ユーザーに許可できます。

[Service Manager] ウィンドウで、作成したサービスの名前をクリックします。

Ranger 管理コンソールに [Policies] ウィンドウが表示されます。
[Add New Policy] をクリックします。

このポリシーでは、テーブルトランザクションで submissionDate 列と transactionType 列のみを表示する権限を sara に付与します。
フォームで次の値を設定します。
- Policy name: 任意の名前（allow-tx-columns など）
- Database: default
- Table: transactions
- Hive column: submissionDate, transactionType
- Allow conditions:
  - Select user: sara
  - Permissions: select
画面の下部にある [Add] をクリックします。

Beeline でポリシーをテストする

マスターノードターミナルで、ユーザー sara として Beeline コマンドラインツールを起動します。
```
beeline -u "jdbc:hive2://localhost:10000/;transportMode=http;httpPath=cliservice sara user-password"
```
Beeline コマンドラインツールはパスワードを強制しませんが、上のコマンドを実行するため、パスワードの指定が必要になります。
次のクエリを実行して、Ranger によってブロックされるかどうかを確認します。
```
 SELECT *
   FROM transactions
   LIMIT 10;
```
このクエリには列 sara が含まれますが、transactionAmount には選択権限がありません。

Permission denied エラーが表示されます。

Ranger で次のクエリが許可されることを確認します。

SELECT submissionDate, transactionType
  FROM transactions
  LIMIT 10;

Beeline コマンドラインツールを終了します。
```
!quit
```
ターミナルを終了します。
```
exit
```
Ranger コンソールで、[Audit] タブをクリックします。拒否されたイベントと許可されたイベントが表示されます。以前に定義したサービス名（ranger-hive-service-01 など）でイベントをフィルタリングできます。

BI ツールからの接続

このチュートリアルの最後のステップでは、Tableau デスクトップから Hive データをクエリで取得します。

ファイアウォールルールを作成する

パブリック IP アドレスをコピーして保存します。
Cloud Shell で、ワークステーションからの上り（内向き）の TCP ポート 8443 を開くファイアウォールルールを作成します。
```
gcloud compute firewall-rules create allow-knox\
  --project=${PROJECT_ID} --direction=INGRESS --priority=1000 \
  --network=default --action=ALLOW --rules=tcp:8443 \
  --target-tags=knox-gateway \
  --source-ranges=<your-public-ip>/32
```
<your-public-ip> プレースホルダは、実際のパブリック IP アドレスに置き換えます。
ファイアウォールルールのネットワークタグをプロキシクラスタのマスターノードに適用します。
```
gcloud compute instances add-tags ${PROXY_CLUSTER}-m --zone=${ZONE} \
  --tags=knox-gateway
```

SSH トンネルを作成する

この手順は、localhost に自己署名証明書を使用した場合にのみ行う必要があります。独自の証明書を使用している場合、またはプロキシマスターノードに独自の外部 DNS 名がある場合は、Hive に接続するに進んでください。

Cloud Shell で、トンネルを作成するコマンドを生成します。

echo "gcloud compute ssh ${PROXY_CLUSTER}-m \
  --project ${PROJECT_ID} \
  --zone ${ZONE} \
  -- -L 8443:localhost:8443"

gcloud init を実行してユーザーアカウントを認証し、アクセス権限を付与します。
ワークステーションでターミナルを開きます。
SSH トンネルを作成してポート 8443 を転送します。最初のステップで生成されたコマンドをコピーし、ワークステーションターミナルに貼り付けて実行します。
トンネルをアクティブにしておくため、ターミナルを開いたままにします。

Hive に接続する

ワークステーションに、Hive ODBC ドライバをインストールします。
Tableau Desktop を開きます。すでに開いている場合は再起動します。
ホームページの [Connect / To a Server] で [More] を選択します。
[Cloudera Hadoop] を検索して選択します。
サンプルデータアナリストの LDAP ユーザー sara をユーザー ID として使用し、次のフィールドを入力します。
- Server: トンネルを作成した場合は、localhost を使用します。トンネルを作成していない場合は、プロキシマスターノードの外部 DNS 名を使用します。
- Port: 8443
- Type: HiveServer2
- Authentication: Username と Password
- Username: sara
- Password: sara-password
- HTTP Path: gateway/hive-us-transactions/hive
- Require SSL: yes
[Sign In] をクリックします。

Hive データのクエリ

[Data Source] 画面で [Select Schema] をクリックし、default を検索します。
default スキーマ名をダブルクリックします。

[Table] パネルが読み込まれます。
[Table] パネルで、[New Custom SQL] をダブルクリックします。

[Edit Custom SQL] ウィンドウが開きます。
次のクエリを入力します。このクエリは、トランザクションテーブルから日付とトランザクションタイプを選択します。
```
SELECT `submissiondate`,
       `transactiontype`
FROM `default`.`transactions`
```
[OK] をクリックします。

クエリのメタデータが Hive から取得されます。
[Update Now] をクリックします。

sara に transactions テーブルからこの 2 つの列を読み取る権限があるため、Tableau は Hive からデータを取得します。
transactions テーブルのすべての列を選択するには、[Table] パネルで、もう一度 [New Custom SQL] をダブルクリックします。[Edit Custom SQL] ウィンドウが開きます。
次のクエリを入力します。
```
SELECT *
FROM `default`.`transactions`
```
[OK] をクリックします。次のエラーメッセージが表示されます。

Permission denied: user [sara] does not have [SELECT] privilege on [default/transactions/*]

sara には Ranger から transactionAmount 列を読み取る権限がないため、このメッセージは想定どおりです。この例は、Tableau のユーザーがアクセスできるデータを制限する方法を示しています。

すべての列を表示するには、ユーザー admin を使用して手順を繰り返します。
Tableau とターミナルウィンドウを閉じます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

このシリーズの最初のパートである Google Cloud 上の Hadoop に可視化ソフトウェアを接続するためのアーキテクチャを読む。
Hadoop 移行セキュリティガイドを読む。
Apache Spark ジョブを Dataproc に移行する方法を学習する。
オンプレミスの Hadoop インフラストラクチャを Google Cloud に移行する方法を学習する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

Google Cloud 上の Hadoop に可視化ソフトウェアを接続する

目標

費用

始める前に

環境を初期化する

サービス アカウントの設定

バックエンド クラスタの作成

Ranger データベース インスタンスを作成する

パスワードを暗号化する

クラスタを作成する

Hive テーブルのサンプルを作成する

プロキシ クラスタの作成

トポロジを作成する

SSL / TLS 証明書を構成する

プロキシ クラスタを作成する

プロキシ経由の接続を確認する

ユーザーを認証ストアに追加する

認証の設定

ユーザー ID を Ranger に同期する

Ranger ポリシーの作成

Ranger サービスを構成する

Ranger Admin コンソールでサービスを設定する

権限が制限された Ranger ポリシーを設定する

Beeline でポリシーをテストする

BI ツールからの接続

ファイアウォール ルールを作成する

SSH トンネルを作成する

Hive に接続する

Hive データのクエリ

クリーンアップ

プロジェクトの削除

次のステップ

サービスアカウントの設定

バックエンドクラスタの作成

Ranger データベースインスタンスを作成する

プロキシクラスタの作成

プロキシクラスタを作成する

ファイアウォールルールを作成する