Data Fusion と Composer を使って Google Cloud でデータレイクを構築
Google Cloud Japan Team
※この投稿は米国時間 2021 年 2 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
データ プラットフォームをクラウドに移行する組織が増えるにつれ、組織内にすでに存在するスキルセットを活用しながら、確実に移行を実現できるクラウド テクノロジーが求められています。
組織の多くでは通常、データチームの大多数を ETL デベロッパーが占めています。こうしたデベロッパーは GUI ベースの ETL ツールだけでなく複雑な SQL にも精通しており、Python をはじめとする言語のプログラミング スキルもすでに備わっているか、習得しつつあります。
この連載では、以下 2 点について、それぞれの概要を紹介していきます。
前述のスキルセットに適したデータ統合サービスやオーケストレーション サービスを使った、構造化データのスケーラブルなデータレイク アーキテクチャ [本記事]
取り込みのスケーリングが簡単な、Cloud Data Fusion と Cloud Composer を使ったソリューション設計の詳細
このソリューションについてさらに掘り下げて学びたい方、プロトタイプを使ってみたい方のために、近々このソリューションのコードを公開する予定です。コードのリンクが公開される後続の記事をどうぞお楽しみに。
この記事の対象者
この連載記事では、GCP を使い始めたばかり、または GCP でデータ プラットフォームやデータレイクを作成しようと考えているソリューション アーキテクトやソリューション デザイナーの皆様に役立つ内容を紹介しています。
今回のユースケースでの主な要件
このアーキテクチャでは、大まかに以下の要件を前提としています。
組織内にすでに存在する ETL スキルセットを活用すること
オンプレミスの RDBMS（SQL Server、Postgres など）、フラット ファイル、サードパーティの API ソースなどのハイブリッド ソースから取り込むこと
取り込みジョブだけでなく、取り込み前後のカスタムタスクも含めたジョブ オーケストレーションにおける複雑な依存関係の管理をサポートすること
無駄のないコードベースと構成に基づく取り込みパイプラインを設計すること
適切なアクセス制御を行いながらデータ検出を可能にすること
ソリューション アーキテクチャ
前述の要件を満たすデータレイク アーキテクチャの設計を以下に示します。このアーキテクチャでは主に、データ統合、ストレージ、オーケストレーション、データ検出などの GCP サービスが関与してきます。
ツールを選択する際の考慮事項
GCP では、包括的なデータセットと分析サービスを提供しています。機能ごとに利用可能なサービスのオプションが複数あるので、アーキテクトやデザイナーは各自のシナリオにあてはまるいくつかの考慮事項を踏まえたうえで適したサービスを選択する必要があります。
以降のセクションでは、アーキテクトやデザイナーがさまざまなタイプのサービスからアーキテクチャに合ったサービスを選ぶ際に考慮すべき点と、各サービス タイプで私が最終的に選んだサービスとその理由を説明しています。
異なるサービスを組み合わせてアーキテクチャを設計する方法は複数あり、ここで挙げた方法はその一つにすぎません。GCP でデータレイクを構築する方法は、独自の要件や優先順位、考慮事項によってさまざまな方法が考えられます。
データ統合サービス
下の図は、GCP でデータ統合サービスを選択するときの考慮事項を詳しく説明したものです。
選択した統合サービス
私のユースケースでは、オンプレミスのフラット ファイルや RDBMS を含む多種多様なデータソース（Oracle、SQL Server、PostgreSQL など）だけでなく、サードパーティのデータソース（SFTP サーバーや API など）からもデータを取り込む必要があり、ソースシステムについては今後も多様化していくことが予想されていました。また、このユースケースで対象となった組織のデータ・分析チームには、ETL スキルのある頼もしい人材が揃っていました。
これらの要因を考慮した結果、データ パイプラインの構築に Cloud Data Fusion を選択しました。
Cloud Data Fusion とは
Cloud Data Fusion は、データ パイプランを構築、管理できる GUI ベースのデータ統合サービスです。これは、オンプレミスやクラウドソース向けのデータ分析アプリケーションを構築するオープンソース フレームワーク、CDAP をベースに設計されています。また、Cloud Data Fusion には、GCP、他のパブリック クラウド、オンプレミスのソースに対してすぐに利用できるさまざまなコネクタが揃っています。
下の図は Data Fusion の単純なパイプラインを示しています。
Data Fusion でできること
コーディングなしで GUI ベースのパイプラインを作成できる機能に加えて、Data Fusion では、視覚的なデータのプロファイリングや準備、シンプルなオーケストレーション機能、きめ細かなパイプラインのリネージなどの機能が利用できます。
仕組み
内部的には、Data Fusion は Dataproc クラスタでパイプラインを実行します。パイプラインが実行されるたびに GUI ベースのパイプラインが自動的に Dataproc ジョブに変換されます。Data Fusion は MapReduce と Apache Spark の 2 つの実行エンジンをサポートしています。
オーケストレーション
下のツリーは、GCP でオーケストレーション サービスを選択する際の考慮事項を示しています。
私のユースケースでは、実行制御の合流や分岐など、複雑な依存関係を管理する必要がありました。また、実行履歴やログ履歴などの運用情報にアクセスできる UI 機能や、障害点からワークフローを再開できる機能も必要でした。こうした要件から、オーケストレーション サービスとして Cloud Composer を選択しました。
Cloud Composer とは
Cloud Composer は、フルマネージド型のワークフロー オーケストレーション サービスです。オープンソースの Apache Airflow のマネージド バージョンであり、他の多くの GCP サービスと完全に統合されています。
Airflow のワークフローは、有向非巡回グラフ（DAG）形式で表示されます。DAG とは、簡単にいえば、実行される必要のある一連のタスクを表したグラフのことです。次のスクリーンショットは単純な Airflow DAG です。
Airflow DAG は Python を使用して定義されます。
初めて DAG を作成する方のために、こちらのチュートリアルで、DAG の作成方法について説明しています。詳細については、Apache Airflow のドキュメントのチュートリアルをご覧ください。Airflow 演算子は、多数の GCP サービスに加え、他のパブリック クラウドでも利用できます。こちらの Airflow のドキュメント ページで、利用可能なさまざまな GCP 演算子 をご紹介しています。
Data Fusion と Composer の機能の分離
このソリューションでは、Data Fusion はソースから宛先へのデータ移動だけに使用されます。Cloud Composer は、Data Fusion パイプラインのオーケストレーションや、Data Fusion 外の他のカスタムタスクの実行に使用されます。カスタムタスクは、監査ログ、テーブルの列の説明の更新、ファイルのアーカイブ、データ統合ライフサイクルの他のタスクの自動化など、さまざまなタスク用に作成することができます。これについては、連載の次回記事で詳しく説明します。
データレイクのストレージ
データレイク用のストレージ レイヤでは、取り込むデータの性質や使用目的を考慮する必要があります。下の図では、こうした考慮事項に基づいてストレージ サービスを選択するためのディシジョン ツリーを示しています。
この記事は、分析ユースケースで使用する構造化データ向けのソリューション アーキテクチャを検討することが目的ですので、このデータレイク ソリューションのストレージ サービスとデータベースには GCP BigQuery を選択しました。
データの検出
Cloud Data Catalog は GCP のデータ検出サービスです。フルマネージド型かつスケーラビリティの高いデータ検出およびメタデータ管理サービスで、BigQuery、Pub/Sub、Google Cloud Storage のテクニカル メタデータを自動検出します。
BigQuery、Cloud Storage、Pub/Sub のデータアセットを Data Catalog で利用可能にするために、プロセスやワークフローを追加する必要はありません。Data Catalog がデータアセットを自己検出して、さらなる検出に利用できるようにします。
アーキテクチャについての補足点
これで Data Fusion サービスと Cloud Composer サービスを選んだ理由がおわかりいただけたと思いますので、アーキテクチャについてはこれ以上の説明は必要ないでしょう。
一点付け加えるとすれば、Cloud Storage のランディング レイヤを選択した理由です。
ファイルを Cloud Storage に格納すべきか否か
このソリューションでは、オンプレミスのフラット ファイルと SFTP のデータは、レイクに取り込まれる前に Cloud Storage に格納されます。これは、「機密ファイルがデータレイクに公開されてしまうのを防ぐために、統合サービスでは指定したファイルへのアクセスのみ許可すること」という要件に対応するためです。
下のディシジョン テーブルは、BigQuery に読み込む前にファイルを Cloud Storage に格納すべきかどうかを決定する際考慮すべき点を示したものです。一般に、ディシジョン テーブルはこのような要素を組み合わせたもので、ご自身に当てはまるすべての要素に対応したアプローチを採用することになります。
ソース: オンプレミス ファイルと SFTP ファイル
** Samba はサポートされていますが、Connect:Direct、WebDav などの他のファイル共有プロトコルやツールはサポートされていません。
サードパーティ API
* API ソース用にすぐ利用できる Data Fusion のソース コネクタ（HTTP ソースのプラグインなど）は、基本認証（ID およびパスワード ベース）と OAUTH2 ベースのソース API 認証をサポートしています。
RDBMS
このアーキテクチャでは、オンプレミスの RDBMS システムからのデータに対してランディング ゾーンは使用されません。Data Fusion パイプラインを使用し、すぐに利用できる JDBC コネクタを介してソース RDBMS から直接データを読み取ります。この設計は、これらのソースにデータレイクへの取り込みを制限すべき機密データがなかったことを考慮したものです。
まとめ
以上のように、GCP ではデータや分析用の包括的なサービスを多数取り揃えており、タスクごとに複数のサービス オプションをご利用いただけます。独自のシナリオに適したサービス オプションをお選びいただくためには、その選択に至るまでの各要素にも目を向ける必要があります。
この記事では、データレイクの設計に際して、ニーズに合った GCP サービスを選択するうえで考慮すべき点についてお話ししてきました。
前提とするスキルセットについては ETL デベロッパーのそれを主に想定したうえで、さまざまなハイブリッド ソースからデータを取り込むデータレイクの GCP アーキテクチャについても説明させていただきました。
次のステップ
本連載の次回の記事では、今回解説したアーキテクチャを基に、構造化データをデータレイクに取り込むソリューション設計について詳しくご説明します。また、このソリューションのソースコードも公開します。
学習用リソース
本投稿でご説明したアーキテクチャで使用されるツールを今まで使ったことがない場合は、ぜひ以下のリンク先からそれぞれの詳細をご確認ください。
Data Fusion
こちらの3 分の動画では、Data Fusion について手短にわかりやすく紹介しています。より詳しい説明については、Cloud Next のこちらの動画をご覧ください。。次に、Codelab の Ingest CSV data to BigQuery（CSV データを BigQuery に取り込む）を参考にして、Data Fusion を実際に試してみてください。
Composer
こちらの 4 分の動画では、Composer について手短にわかりやすく紹介しています。より詳しい説明については、Cloud OnAir のこちらの動画をご覧ください。実際にお試しになる場合は、こちらのクイックスタートの手順に沿って操作してください。
BigQuery
こちらの 4 分の動画では、BigQuery サンドボックスを使用して BigQuery に無料でアクセスする方法について説明しています（サンドボックスの制限が適用されます）。
Codelab で BigQuery UI Navigation and Data Exploration（BigQuery UI ナビゲーションやデータ探索）や、Load and query data with the bq command-line tool（bqコマンドライン ツールでのデータの読み込みやクエリ）の方法を学びましょう。
BigQuery の一般公開データセットを使ったり、Query the Wikipedia dataset in BigQuery で Wikipedia のデータセットをクエリしたりもできます。
本連載のパート 2、「Data Fusion と Composer を使って、構成に基づくデータレイクを構築するためのフレームワーク」もお楽しみに！
-GCP プロフェッショナル サービス担当クラウド コンサルタント Neha Joshi
