Google Cloud Platform でのデータレイクの作成

ここでは、Google Cloud Platform(GCP)でデータレイクを作成する方法を説明します。データレイクを使用すると、組織はビジネス活動のあらゆる側面をデータ形式で柔軟に取得できるようになります。時間の経過に伴い、このデータが蓄積されてペタバイト単位、あるいはエクサバイト単位に達することがあります。しかし、ストレージ コストは着実に低下し、ストレージとコンピューティングは分離されているため、このデータをすべて保存することは以前よりも経済的に行えるようになりました。

データをキャプチャして保存した後、さまざまな処理技術を利用してデータから分析情報を抽出できます。データ ウェアハウジングは、ビジネス分析を行うための標準的な手法です。ただし、この手法では、注文、注文の詳細、在庫など、よく理解されている種類のデータに対してかなり厳格なスキーマが必要です。従来のデータ ウェアハウジングのみで構築されたアナリティクスでは、適切に定義されたスキーマに準拠していないデータを処理することが困難になります。そのようなデータは破棄されたり、永久に失われたりすることが多いからです。

データ ウェアハウジングからデータレイクの「すべてを保存する」手法に移行しても、すべてのデータから分析情報を引き出すことができないのであれば有用とは言えません。多くの場合、データ サイエンティスト、エンジニア、アナリストは希望する分析ツールを使用してレイク内のデータを処理し、分析したいと思っています。また、レイクでは複数のデータソースから得た膨大な量のデータを取り込める必要があります。

これらの考慮事項を念頭に置いて、Google Cloud Platform でデータレイクを作成する方法を説明します。次の図は、データレイク ソリューションにおける主要なステージを示しています。

データレイク ソリューションにおける主要なステージ

この記事では、各ステージをさらに詳細に説明し、GCP がどのように役立つかを説明します。

保存: データレイクとしての Cloud Storage

Cloud Storage は、多数の理由から、中央ストレージ リポジトリとして機能させるのに非常に適しています。

パフォーマンスと耐久性: Cloud Storage を使用すれば、いくつかの小さいファイルで開始しても、データレイクをエクサバイト規模まで拡張できます。Cloud Storage は Cloud Pub/Sub などのその他のサービスと組み合わせて、新しいデータの大量取り込みや、保存されたデータの大量消費をサポートします。データレイクにとってパフォーマンスは重要ですが、耐久性はさらに重要であり、Cloud Storage は 99.999999999% の年間耐久性を持つように設計されています。

強整合性: Cloud Storage を他の多数のオブジェクト ストアと差別化する重要な特徴の 1 つとして、read-after-write オペレーション、バケットやオブジェクトの一覧表示、リソースへのアクセス権限の付与などが行われる状況で強整合性がサポートされていることが挙げられます。この整合性がなければ、データを処理できる時期を判別するために、複雑で時間を要する回避策を実装する必要があります。

コスト効率: Cloud Storage には、さまざまなアクセス パターンや可用性のニーズに合わせて複数の価格で多数のストレージ クラスが用意されており、データアクセスのコストと頻度のバランスを柔軟にとることができます。パフォーマンスを犠牲にすることなく、一貫した API を使用してさまざまなストレージ クラスからデータにアクセスできます。たとえば、ライフサイクル ポリシーを使用して、使用頻度の低いデータを Cloud Storage Nearline や Coldline にアーカイブし、後でそれにアクセスして、1 秒未満のレイテンシで機械学習用のトレーニング データを収集できます。

柔軟な処理: Cloud Storage では、BigQueryCloud Dataproc(Hadoop エコシステム)、Cloud Dataflow(サーバーレス アナリティクス用)、Cloud Video Intelligence APICloud Vision APICloud Machine Learning Engine など、多数の強力な GCP サービスとのネイティブ統合を行えるため、データの分析に適したツールを柔軟に選択できます。

中央リポジトリ: Cloud Storage ではチームや部門全体にわたり、データの保存やアクセスを行える中核的な場所が用意されているため、同期し続ける必要のあるデータサイロを回避できます。

セキュリティ: データレイクはすべてのタイプのデータを保存するように設計されているため、企業はデータが悪用されないようにするために、強力なアクセス制御機能を使用する必要があります。Cloud Storage には、データアセット全体に詳細なアクセス制御を実装する多数のメカニズムが用意されています。

データの取り込み

データレイク アーキテクチャは、IoT センサー、ウェブサイト上のクリックストリーム アクティビティ、オンライン トランザクション処理(OLTP)データ、オンプレミス データなど、多種多様なソースからさまざまな量のデータを取り込める必要があります。このセクションでは、GCP がどのようにしてさまざまな取り込み事例をサポートできるかを説明します。

Cloud Pub/Sub および Cloud Dataflow: Cloud Pub/Sub および Cloud Dataflow を使用すると、リアルタイム データを直接 Cloud Storage に取り込み、保存して、データ量に応じて入出力の両方をスケーリングできます。

ストレージ転送サービス: 単一のコマンドを発行するだけの簡単な操作で、大量のデータを移動できることはほとんどありません。定期的なデータ転送のスケジューリング、ソースとシンク間でのファイル同期、フィルタに基づいたファイルの選択的移動などの問題に対処する必要があります。 ストレージ転送サービスには、このタスクを実行するための堅牢なメカニズムが用意されています。

gsutil: 1 回限りの転送や手動での転送の場合は、gsutil を使ってみてください。これはオープンソースのコマンドライン ツールで、Windows、Linux、Mac で利用できます。また、マルチスレッド転送、処理済み転送、並列コンポジット アップロード、再試行、再開機能がサポートされています。

転送アプライアンス: ネットワーク帯域幅によっては、大量のデータをクラウドに移行して分析する必要がある場合、転送アプライアンスを使用してオフラインで移行を行ったほうが時間を短縮できることがあります。

詳細については、取り込みオプションの概要と、取り込みオプションの選択に関する主要な意思決定基準をご覧ください。

処理と分析

データを取り込んで保存したら、次のステップはそのデータを分析に使用できるようにすることです。場合によっては、取り込み直後によく理解されているスキーマにデータを保存し、インプレース クエリを簡略化できます。たとえば、着信データを Avro 形式で Cloud Storage に保存する場合、次のことを行えます。

  • Cloud Dataproc の Hive を使用して、データに対して SQL クエリを発行する。
  • BigQuery のデータに対してクエリを直接発行する。
  • データを BigQuery にロードしてから、クエリを行う。

しかし、データを取り込んで保存するときに、よく知られたスキーマに沿ってデータを常に形成できるわけではありません。実際に、データ ウェアハウスではなくデータレイクを利用する主な理由は、その時点ですべてを保存して、後で分析情報を抽出できるということです。未加工のデータの性質と、関連する分析の種類に応じて、ワークフローは単純なものから複雑なものまで多岐にわたります。次の図は、その概要を示しています。

データレイク ワークフローの概要

データ マイニングと探索

レイクに保存されているデータの大部分は直ちに使用する準備ができていないため、データ サイエンティストはまず、潜在的な価値を得るためにこのデータをマイニングする必要があります。Jupyter Notebook は未加工のデータを探索するためにデータ サイエンティストが好んで使用するツールです。このため、GCP ではフルマネージド Jupyter Notebook サービスである Cloud Datalab が提供されています。

Cloud Datalab には、TensorFlow や NumPy など、人気のある各種データ サイエンティスト ライブラリがプリインストールされています。Cloud Datalab を使用するほかに、データ サイエンティストは Cloud Dataproc のツールと Cloud Dataflow を使用した完全サーバーレス分析から成る従来型の Hadoop エコシステムにもアクセスできます。強力な SQL ベースの分析を行うために、未加工のデータを Cloud Dataprep by Trifacta で変換し、BigQuery にロードできます。

データ サイエンティストは、レイク内の未加工のデータのサブセットに分析上の潜在的価値があることがわかると、データ エンジニアと協力してそのサブセットをより多くのユーザーが利用できるようにすることができます。

ワークフローの設計とデプロイ

データのサブセットをより広く利用できるようにするには、前の図に示されているように、より焦点を絞ったデータマートを作成する必要があります。未加工のデータを取得し、下流プロセスとユーザーが使用できる形式にそのデータを変換するように調整されたデータ パイプラインを使用すると、このデータマートを最新の状態に保てます。このようなパイプラインは、データの特性と使用されている分析の種類によって異なります。ここでは、一般的なアナリティクスのワークフローと、GCP にそれを実装する方法を説明します。

未加工のデータを変換して BigQuery に読み込む

以下の図に示されているのは単純ですが、一般的なワークフローであり、抽出、変換、読み込み(ETL)プロセスを使用して、BigQuery データ ウェアハウスにデータを取り込みます。その後、SQL を使用してデータをクエリできます。データのクレンジングと準備を行うためのビジュアル ツールである Cloud Dataprep は、単純な ETL ジョブに適しています。一方、Apache Beam 搭載 Cloud Dataflow は、より複雑な ETL をさらに柔軟に処理できます。

BigQuery にデータを読み込むためのワークフロー

バッチ分析

バッチ分析に Hadoop エコシステム サービスを使用する場合は、変換したデータを Cloud Storage の別の場所に保存します。次に、Cloud Dataproc で、Spark、Spark SQL、SQL on Hive、および同様のツールを使用して、そのデータにクエリを行います。Apache Avro、Apache Parquet、Apache ORC は、この詳細化されたデータによく使用される形式です。次の図は、このワークフローをまとめたものです。

バッチ分析に Hadoop サービスを使用する

リアルタイム分析

簡単な SQL ベースのパイプラインが必要な場合は、BigQuery でストリーム処理を行うと、データが取り込まれるときにクエリできます。Cloud Pub/Sub と Cloud Dataflow を Beam とともに追加すると、ストリーム処理能力が向上するため、たとえば、ユーザーは集約、ウィンドウ処理、フィルタリングを行った後、BigQuery にデータを保存できます。時系列分析の場合、取り込んだデータを Cloud Bigtable に保存して、迅速な分析をより簡単に行えます。次の図は、このワークフローを示しています。

Cloud Bigtable にデータを保存してリアルタイム分析を行う

機械学習

機械学習は、データレイク内の膨大な量のデータから多大なメリットを得られます。データ サイエンティストは有用なトレーニング データ、関連するデータ準備ステップ、機械学習ネットワーク アーキテクチャを特定した後、次の図に示すように、そのステップをオーケストレートできます。Cloud ML Engine を使用すると、簡単にモデルを形成し、それらのモデルを使用してバッチとオンラインの両方の予測を行えます。

機械学習のためのデータのオーケストレーション

すべての機械学習のユースケースで、カスタムモデルの設計とトレーニングが保証されるわけではありません。GCP には、スピーチ、ビジョン、ビデオ インテリジェンス、自然言語処理用に事前にトレーニングされたモデルが含まれています。このような場合、オーディオ、画像、動画など、該当する入力をそれぞれの GCP サービスに渡します。次に、価値のあるメタデータを抽出し、BigQuery などのサービスにそのメタデータを保存して、後でクエリや分析を行います。次の図は、このフローを示しています。

事前トレーニングされた機械学習モデルを使用する

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...