OSSデータカタログ「Datahub」をAWS EKSで簡単に構築できます
どーもsutoです。
LinkedIn製のOSSデータカタログ「DataHub」はクイックスタートの手順が簡易で、すぐにDatahubの機能を体験できるように開発が進んでいます。
通常のクイックスタートガイドではローカル環境のDockerで起動する手順のですが、AWS上に構築する際もAWS EKSを用いたクイックスタートができるための手順をご紹介します。
今回のゴール
今回は、Dastahubを構成するすべてのリソースをEKSクラスタ上のコンテナで立ち上げる構成でインフラを構築し、実際にGlueデータカタログを対象にメタデータ取り込みを試してみようと思います。
※Datahubのストレージレイヤー部分をそれぞれAWSのサービス（RDS、AWS Opensearch、AWS MSK、Glueスキーマレジストリ）に移行した構成で構築する手順はいずれ別の記事でご紹介しようと考えています。
前提条件と作業環境の設定について
事前に以下のツールをインストールしておく必要があります。Python3については省略させていただきますが、その他はリンク先を参考に実施できると思います。
私の作業環境はMacなのでhomebrewを使ってインストールを行いました。
- Pthon3.6以降の環境をセットアップしておく
- AWS CLIインストールとCredentials,Config設定
- kubectlインストール
brew install kubectl kubectl version --client
brew tap weaveworks/tap brew install weaveworks/tap/eksctl eksctl version
brew install helm
EKSクラスター作成
eksctlコマンドを使用してクラスターを作成します。今回は以下のパラメータで作成します。
- VPC：CIDRを指定して新規作成（10.1.0.0/16）
- クラスター名：datahub-test
- リージョン：ap-northeast-1
- インスタンスタイプ：m5.large
- ノード数：3
Datahubのストレージレイヤを含むすべてのコンポーネントをEKSクラスター内のpodでデプロイさせるには少なくともm5.large以上が３ノード必要となります。（それ以下のスペックだとCrashLoopbackが発生しデプロイすることができませんでした）
※Datahubのストレージレイヤ（RDS、Kafka、スキーマレジストリなど）をEKS上にデプロイしないならば、ある程度インスタンスタイプやノード数を低くしても大丈夫でした。
eksctl create cluster \ --vpc-cidr 10.1.0.0/16 \ --name datahub-test \ --region ap-northeast-1 \ --with-oidc \ --node-type m5.large \ --nodes 3
既存のサブネットに作成する場合は、 --vpc-cidr の代わりに以下のオプションで既存サブネットを指定できます。
--vpc-private-subnets=subnet-xxxxxxxx,subnet-xxxxxxxx,subnet-xxxxxxxx \ --vpc-public-subnets=subnet-xxxxxxxx,subnet-xxxxxxxx,subnet-xxxxxxxx \
実行するとCloudformationスタックが実行され、完了後にkubectl get nodesを実行することで以下のように３ノードが表示されます
% kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-1-12-57.ap-northeast-1.compute.internal Ready <none> 17m v1.20.11-eks-f17b81 ip-10-1-60-101.ap-northeast-1.compute.internal Ready <none> 17m v1.20.11-eks-f17b81 ip-10-1-72-207.ap-northeast-1.compute.internal Ready <none> 16m v1.20.11-eks-f17b81
Helmを使用してEKSクラスターにDataHubをセットアップ
- DatahubのリポジトリをHelmに追加します。
helm repo add datahub https://helm.datahubproject.io/
- クラスター上にデプロイするMySQLデータベースとNeo4jのパスワードを格納したkubernetesシークレットを作成します。
kubectl create secret generic mysql-secrets --from-literal=mysql-root-password=datahub kubectl create secret generic neo4j-secrets --from-literal=neo4j-password=datahub
- 以下を実行してDatahubのストレージレイヤ部分を先にデプロイします
% helm install prerequisites datahub/datahub-prerequisites NAME: prerequisites LAST DEPLOYED: Wed Dec 1 01:31:18 2021 NAMESPACE: default STATUS: deployed REVISION: 1
kubectl get podsを実行して、以下のように依存関係のすべてのポッドが実行されているかどうかを確認します。
% kubectl get pods NAME READY STATUS RESTARTS AGE elasticsearch-master-0 1/1 Running 0 2m6s elasticsearch-master-1 0/1 Running 0 2m6s elasticsearch-master-2 1/1 Running 0 2m6s prerequisites-cp-schema-registry-cf79bfccf-hxw5g 2/2 Running 0 2m6s prerequisites-kafka-0 1/1 Running 0 2m6s prerequisites-mysql-0 1/1 Running 0 2m6s prerequisites-neo4j-community-0 1/1 Running 0 2m6s prerequisites-zookeeper-0 1/1 Running 0 2m6s
- 以下を実行してDatahubをデプロイします
helm install datahub datahub/datahub
- デプロイ完了後、podの一覧が以下のようになるはずです。
% kubectl get pods NAME READY STATUS RESTARTS AGE datahub-datahub-frontend-6c47c77468-v2hsn 1/1 Running 0 4m23s datahub-datahub-gms-59dfd97556-9vrsr 1/1 Running 0 4m23s datahub-datahub-upgrade-job-8xbhc 0/1 Error 0 4m23s datahub-datahub-upgrade-job-g4qpn 0/1 Completed 0 3m14s datahub-elasticsearch-setup-job-kj95r 0/1 Completed 0 6m9s datahub-kafka-setup-job-kwkqs 0/1 Completed 0 6m datahub-mysql-setup-job-64grv 0/1 Completed 0 4m29s elasticsearch-master-0 1/1 Running 0 13m elasticsearch-master-1 1/1 Running 0 13m elasticsearch-master-2 1/1 Running 0 13m prerequisites-cp-schema-registry-cf79bfccf-hxw5g 2/2 Running 0 13m prerequisites-kafka-0 1/1 Running 0 13m prerequisites-mysql-0 1/1 Running 0 13m prerequisites-neo4j-community-0 1/1 Running 0 13m prerequisites-zookeeper-0 1/1 Running 0 13m
※【2021年11月現在】upgrade-jobでErrorが発生しているようですが、仕様で発生するものらしくサービス自体は正常にデプロイされていました。
- デプロイ完了後、2つのELBが作成されています。
- 1つはポート「9002」のもので、WebUIにアクセスするためのエンドポイントです。
- もう1つはポート「8080」で、こちらはメタデータ取り込み時に使用するエンドポイントです。
- ポート構成が9002のELBのDNS名をコピーし、
:9002を追加してブラウザでアクセスしてみると以下のようにログイン画面が表示されます。
- デフォルトユーザとパスワード(datahub:datahub)でログインできるはずです。
メタデータ取り込みをやってみる
では実際にGlueデータカタログのメタデータを取り込んでみようと思います。
- まず、Datahubメタデータの操作を行うためのPyPIパッケージをインストールします。
% python3 -m pip install --upgrade pip wheel setuptools % python3 -m pip install --upgrade acryl-datahub % datahub version DataHub CLI version: 0.8.16.4
- 以下のコマンドでPuluginのインストールを行い、datahub-rest、Glueプラグインを有効にします。
% pip install 'acryl-datahub[datahub-rest] % pip install 'acryl-datahub[glue]'
- 以下のようにGlueがenableになっていることを確認します
% datahub check plugins Sources: athena (disabled) 〜省略〜 file glue hive (disabled)
- Datahubの取り込みスクリプトにデータをどこからプルするか（ソース）、どこに置くか（シンク）を指示する構成ファイルである「レシピ」をyamlファイルで作成します。
- レシピの書き方についてはこちらのリンクを参考に作成できます。
- Glueの場合は以下のように作成しました（ファイル名はdatahub-glue.ymlとして作成しました）
source:
type: glue
config:
# Coordinates
aws_region: "<<対象のリージョン>>"
extract_transforms: true
aws_role: "<<Glueにアクセス可能なIAMロールのArn>>"
# see https://datahubproject.io/docs/metadata-ingestion/sink_docs/datahub for complete documentation
sink:
type: "datahub-rest"
config:
server: "<<Datahubデプロイ時に作成されたポート構成が8080のELBのDNS名>>:8080"
- 以下のコマンドを実行してGlueメタデータを取り込みます
datahub ingest -c ./datahub-glue.yml
Pipeline finished successfullyというメッセージが出れば取り込み成功です。
私の検証アカウントでは、S3バケットをデータソースとしたelb_logというGlueデータテーブルを登録していました。
Web画面で確認してみると
各々のカラム、Description、Tagなどの情報がしっかり取り込まれています。
まとめ
OSSデータカタログであるDatahubは、AWS上でも比較簡易な手順でデプロイができるように開発側で作り込まれていることがわかりました。
次はストレージレイヤをAWSマネージドサービスに移行した構成でデプロイができるところまで検証していこうと思います。
参考
構築したDatahub環境を削除する際は以下のコマンドで削除できます。
helm uninstall datahub helm uninstall prerequisites eksctl delete cluster \ --name datahub-test \ --region ap-northeast-1
【注意】上記コマンドで環境を削除しても「kubernetes-dynamic-pvc-〜」という名前のEBSボリューム群が残り続けていたので忘れずに削除してください。
