Cloud Wisdom Weekly: データ管理と分析を最適化するための 6 つのヒント

※この投稿は米国時間 2022 年 9 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

「Cloud Wisdom Weekly: テクノロジー企業とスタートアップのために」は、今秋スタートした新たなブログシリーズで、アプリをこれまでよりも速く、安く、スマートに構築する方法に関して、テクノロジー企業やスタートアップのお客様からよく問われる質問に答えることを目的としています。この記事では、BigQuery を効果的に使い始める方法について、Google Cloud ビッグデータおよび分析コンサルタントの Julianne Cuneo が説明します。

従来のデータ ウェアハウスやデータレイクで遭遇するような大量のデータを扱う作業は、難易度が高く、複雑で、費用がかかる場合があります。また、対応できないような専門スキルを要する場合もあります。今日の顧客中心のデータドリブンな市場で競争していくためには、これらの課題を克服することが大変重要です。

こうした取り組みには大規模なデータ分析が不可欠ですが、コストとリソースの管理も同様に非常に大切です。そのため、多くの企業はソリューションを見つけて適切なバランスを取るために、クラウドに注目しています。この記事では、成長中のテクノロジー企業やスタートアップがどのように BigQuery を活用してイノベーションを推進しているかを探り、業界を牽引する Google のエンタープライズ向けデータ ウェアハウスをさらに活用するための役立つヒントを紹介します。

データの管理と分析の最適化

企業は多くの場合、新しいテクノロジーがどのように機能するかを確認するために、データの読み込みやクエリの実行を急いで行います。これは、概念実証や評価を迅速に行うためには適切ですが、必ずしも長期的な成功につながるとは限りません。長期的な成功のためには、ビジネス、セキュリティ、予算のニーズに対するアプローチをより洗練させることが大切なためです。以下では、BigQuery によってデータ プラットフォーム アーキテクチャを最適化する方法の具体例をはじめ、強固でスケーラブルな基盤のセットアップに役立つヒントを紹介します。

1. ストレージとコンピューティングを個別にスケーリングする

大量のデータを処理する場合、適切なストレージ機能を持つことは最大の課題の一つです。大量の情報を維持するための費用を負担できるとしても、その情報を効果的に分析して価値を引き出すことは、さらに困難になる可能性があります。サーバーレス アーキテクチャは、複数の方法でこれらの課題を克服するサポートを行います。

まず、BigQuery のようなサーバーレスのプラットフォームでは、コンピューティングとストレージが分離されているため、使用するリソースに対して個別に料金を支払うことができ、データのニーズが変化するのに応じて柔軟にスケールアップまたはスケールダウンできます。一部のサービスでは、リソースがバンドルされるために、必要以上のコンピューティングおよびストレージ容量が提供される一方で必要以上の費用も発生します。しかし、サーバーレスのプラットフォームを活用したこのアプローチでは、大量のデータの保存についてのコスト効率が高まるため、実現可能性が高まります。

次に、より多くのデータを保存する予算があれば、分析結果を得られる可能性も高くなります。BigQuery のスケーラブルなコンピューティング容量を活用すれば、1 回のリクエストで数テラバイト、あるいは数ペタバイトのデータをクエリして、分析結果を得ることができます。 

これらの機能を組み合わせると、事前に定義された量のストレージやコンピューティング リソースではなく、ニーズに応じて分析作業をスケーリングできます。

2. ストレージとデータセットを慎重に編成する

適切なコストをかけて、必要な人たちに安全で一貫したデータアクセスを提供することは、データ管理と分析のもう一つの重要な側面です。リソースの最適化を適切に計画すると、時間を節約し、将来的に起こる可能性のあるセキュリティ、料金、ワークフローの問題を回避できます。たとえば、BigQuery のリソース編成では、次のような設計上の主要な考慮事項が挙げられます。

• データセットとオブジェクト（テーブル、ビュー、ML モデルなど）は、1 つのプロジェクトのみに属します。このプロジェクトは、そのデータセットのストレージ コストの請求対象となるプロジェクトです。このリソースの詳細を確認して、一元化されたデータ ウェアハウス アプローチを実装するか、個々のプロジェクトにデータマートを割り当てるか、または両方のアプローチを組み合わせるかを検討してください。

• BigQuery のオブジェクトへのアクセスは、データセット、テーブル、行、列の各レベルで制御できます。このことは、ストレージの設計でも考慮する必要があります（同じデータセット内で密接に関連しているオブジェクトをグループ化して、アクセス許可を簡素化するなど）。

3. 複数のチームやユースケースにわたってコンピューティングのコストとパフォーマンスを最適化する

一部のユースケースでは、厳格なサービスレベル契約（SLA）を満たすために、正確なコスト管理またはリソース プランニングが求められる場合があります。たとえば、BigQuery では、データの所属先は単一のプロジェクトのみですが、どこからでもクエリを実行でき、データの場所に関係なく、クエリを実行するプロジェクトにコンピューティング リソースが請求されます。そのため、クエリの使用状況をきめ細かく追跡するために、さまざまなチーム（財務、営業など）またはユースケース（BI、データ サイエンスなど）用に個別のプロジェクトを作成できます。

請求目的でコンピューティング プロジェクトをチームまたはユースケースごとにセグメント化することに加えて、ワークロード管理のためにプロジェクト間でコンピューティング リソースを制御する方法を検討する必要があります。BigQuery では、「スロットのコミットメント」を使用して、オンデマンド モデルと定額料金モデルの切り換えが可能です。これには、オンデマンドの効率と定額の予測可能性のバランスを取るための組み合わせアプローチが含まれます。「スロットのコミットメント」は、より小さな割り当て（「予約」とも呼ばれます）にさらに分割できる専用のコンピューティング リソースです。これらの割り当ては、個々のプロジェクトに割り当てることも、複数のプロジェクトで共有することもできます。これにより、オンデマンド クエリ モデルよりもコストを節約しながら、優先度の高いワークロードや計算負荷の高いワークロードのために演算能力を予約できる柔軟性が獲得できます。

たとえば、お客様の会社が 1,000 スロットをコミットしているとします。このような場合、コンピューティング負荷の高いデータ サイエンス プロジェクトに 500、ETL に 300、より柔軟な SLA を有する内部 BI に 200 を割り当てることができます。何よりも素晴らしいのは、アイドル スロットがサイロに分離されて未使用のまま放置されることがないことです。ETL プロジェクトが 300 スロットすべてを使用していない場合、再び必要になるまで、これらのアイドル状態のリソースを他のデータ サイエンスまたは BI プロジェクトとシームレスに共有できます。

4. データスキーマを読み込んで最適化する

データがどのように編成されるかを把握したら、データ ウェアハウスへの入力を開始できます。BigQuery では、Google Cloud Storage のフラット ファイルを介してデータを取り込むさまざまな方法、Data Transfer Service を使用したアプリやデータベースへの事前構築済みコネクタ、ストリーミング挿入、サードパーティによる数多くのデータ移行ツールや ETL ツールとの互換性が提供されます。

テーブル スキーマに対して簡単な最適化をいくつか施すことで、最善の結果を得られます。この最適化とは、ほとんどの場合、クエリがスキャンするデータの量を大幅に削減するために、予想されるクエリパターンに基づいてパーティショニングやクラスタリングを適用することを意味します。

5. データへの投資を統合する

データと分析では、より広く理解されている構造化データだけでなく、非構造化データや半構造化データでの作業も必要になる場合があります。この目的のためには、単なる「エンタープライズ データ ウェアハウス」という枠を超えて考え、一元化された真のデータレイクを提供するソリューションを含めることまで重視するのが役立ちます。

BigQuery を使用している場合、プラットフォームの連携機能によって、Cloud Storage、Google ドライブ、Bigtable、Cloud SQL、Cloud Spanner などの Google サービス内に保存されているデータや、他のクラウドのデータに対して、シームレスにクエリを実行できます。また、BigQuery の Storage API を使用することで、その他のサービス（Dataproc、Dataflow、ML、BI ツールなど）が BigQuery ストレージとの間で大容量で高速な通信を行えるようになります。このような機能によって、データの取り組みをプラットフォームやチーム間で分割することなく、統一された一貫したアプローチの一部として進めることができます。

6. クエリの実行をお楽しみください！

データが利用可能になったところで、いよいよクエリを開始します。つまづかず、すぐに作業が開始できるようにサポートするような機能がプラットフォームに備わっているのが理想です。

ANSI 規格に準拠したソリューションである BigQuery SQL では、標準的な SQL 開発者が既存のスキルを最初から活用できるようになっています。また、BigQuery 向けのネイティブ コネクタを提供したり、BigQuery の JDBC / ODBC ドライバを利用してユーザーに代わってクエリを作成したりするサードパーティ製ツールも数多くあります。以前データ ウェアハウスに投資した際の SQL スクリプトが多数ある場合、BigQuery の移行サービスを使用することで、Teradata、Redshift、およびその他のいくつかのサービスからのジョブを自動的に変換できます。これらの機能によって、データを利用可能にして保護し、適切に予算を設定することができ、使いやすいインターフェースに簡単にプラグインして分析できるようになります。

また、BigQuery への移行を行う際には、ただ既存のクエリを移動して現状のまま運用を続けるのではなく、ぜひ BigQuery に特有の機能を活用してください。別のシステムでは不可能だった大規模な分析を実行できます。SQL ベースの BigQuery ML を使用して、プロトタイプの機械学習モデルのトレーニングをお試しいただけます。ストリーミング データをリアルタイムでクエリしてみてください。組み込まれた GIS 関数を使用して地理空間分析も実施できます。イノベーションを始めましょう。

強固なデータ基盤の構築には時間と計画が必要です

この記事で紹介したヒントは、ビジネスの成長に合わせてウェアハウス ソリューションを再構築する必要をなくし、短期的、長期的に会社を成功に導く一助となるはずです。時間や労力、そして金銭的投資を新しいテクノロジーに投入するという決断は、慎重な評価によって行わなければなりません。そのため、クイックスタートやスタートアップ ページ にアクセスするか、Google Cloud のエキスパートにお問い合わせいただいたうえで、BigQuery を導入することをおすすめします。