Google の BigQuery がどのようにしてデータ分析を民主化したか。 パート1

おい、ハブル！ 新しいコースストリームへの登録は現在OTUSで受付中です データエンジニア。 コースの開始に備えて、私たちは伝統的に興味深い資料の翻訳を用意してきました。

毎日 XNUMX 億人以上の人々が Twitter を訪れ、世界で何が起こっているかを調べ、議論しています。 各ツイートやその他のユーザーアクションにより、Twitter 内の内部データ分析に使用できるイベントが生成されます。 何百人もの従業員がこのデータを分析して視覚化しており、エクスペリエンスを向上させることが Twitter データ プラットフォーム チームの最優先事項です。

私たちは、幅広い技術スキルを持つユーザーがデータを検索し、適切に機能する SQL ベースの分析および視覚化ツールにアクセスできる必要があると考えています。 これにより、データ アナリストやプロダクト マネージャーなど、技術に詳しくないまったく新しいユーザー グループがデータから洞察を抽出できるようになり、Twitter の力をより深く理解し、活用できるようになります。 これが、Twitter でのデータ分析を民主化する方法です。

内部データ分析のツールと機能が向上するにつれて、Twitter サービスも向上しました。 ただし、まだ改善の余地があります。 Scalding などの現在のツールにはプログラミング経験が必要です。 Presto や Vertica などの SQL ベースの分析ツールには、大規模なパフォーマンスの問題があります。 また、データに常時アクセスせずに複数のシステムにデータを分散させることにも問題があります。

昨年発表しました Googleとの新たなコラボレーション、その中で私たちの一部を転送します データインフラストラクチャ Google Cloud Platform (GCP) 上で。 Google Cloud ツールは ビッグデータ Twitter 上で分析、視覚化、機械学習を民主化する取り組みに役立ちます。

• ビッグクエリー: SQL エンジンベースのエンタープライズ データ ウェアハウス ドレメル、そのスピード、シンプルさで有名で、 機械学習.
• データスタジオ: Google ドキュメントのようなコラボレーション機能を備えたビッグデータ視覚化ツール。

この記事では、これらのツールを使用した私たちの経験、つまり私たちがこれまでに行ったこと、学んだこと、そして次に何を行うかについて学びます。 ここでは、バッチ分析と対話型分析に焦点を当てます。 リアルタイム分析については次の記事で説明します。

Twitter 上のデータ ウェアハウスの歴史

BigQuery について説明する前に、Twitter でデータ ウェアハウスの歴史を簡単に振り返ってみる価値があります。 2011 年には、Twitter データ分析が Vertica と Hadoop で実行されました。 MapReduce Hadoop ジョブを作成するには、Pig を使用しました。 2012 年に、Pig を Scalding に置き換えました。Scalding には、複雑なパイプラインの作成機能やテストの容易さなどの利点を備えた Scala API がありました。 ただし、SQL の操作に慣れている多くのデータ アナリストやプロダクト マネージャーにとって、これは非常に急な学習曲線でした。 2016 年頃、私たちは Hadoop データの SQL フロントエンドとして Presto を使い始めました。 Spark は、アドホック データ サイエンスや機械学習に適した Python インターフェイスを提供しました。

2018 年以来、データ分析と視覚化に次のツールを使用してきました。

• 生産ラインの熱処理
• アドホックなデータ分析と機械学習のための Scalding と Spark
• アドホックおよびインタラクティブな SQL 分析のための Vertica と Presto
• Druid は、時系列メトリクスへの低インタラクティブ、探索的、低レイテンシーのアクセスを実現します。
• データ視覚化のための Tableau、Zeppelin、Pivo​​t

これらのツールは非常に強力な機能を提供しますが、これらの機能を Twitter でより多くのユーザーが利用できるようにするのは難しいことがわかりました。 Google Cloud でプラットフォームを拡張することで、Twitter 全体の分析ツールを簡素化することに重点を置いています。

Google の BigQuery データ ウェアハウス

Twitter のいくつかのチームは、すでに BigQuery を本番パイプラインの一部に組み込んでいます。 彼らの経験を活用して、私たちは Twitter のあらゆるユースケースに対する BigQuery の可能性を評価し始めました。 私たちの目標は、BigQuery を全社に提供し、Data Platform ツールキット内で BigQuery を標準化してサポートすることでした。 これは多くの理由から困難でした。 大量のデータを確実に受信し、全社的なデータ管理をサポートし、適切なアクセス制御を確保し、顧客のプライバシーを確​​保するためのインフラストラクチャを開発する必要がありました。 また、チームが BigQuery を効果的に使用できるように、リソースの割り当て、モニタリング、チャージバックのためのシステムを作成する必要もありました。

2018 年 250 月に、全社向けに BigQuery とデータポータルのアルファ リリースをリリースしました。 私たちは、最もよく使用されている個人データを消去したスプレッドシートの一部を Twitter スタッフに提供しました。 BigQuery は、エンジニアリング、財務、マーケティングなどのさまざまなチームの 8 人を超えるユーザーによって使用されています。 ごく最近では、スケジュールされたリクエストを除いて、約 100 件のリクエストを実行し、毎月約 XNUMX PB を処理していました。 非常に肯定的なフィードバックを受けた後、私たちはさらに前進し、Twitter 上のデータを操作するための主要なリソースとして BigQuery を提供することにしました。

これは、Google BigQuery データ ウェアハウスの高レベル アーキテクチャの図です。

内部 Cloud Replicator ツールを使用して、ローカル Hadoop クラスターから Google Cloud Storage (GCS) にデータをコピーします。 次に、Apache Airflow を使用して、「bq_load» GCS から BigQuery にデータを読み込みます。 Presto を使用して、GCS で Parquet または Thrift-LZO データセットをクエリします。 BQ Blaster は、HDFS Vertica および Thrift-LZO データセットを BigQuery にロードするための内部 Scalding ツールです。

次のセクションでは、使いやすさ、パフォーマンス、データ管理、システムの健全性、コストに関する当社のアプローチと専門知識について説明します。

使いやすさ

BigQuery はソフトウェアのインストールが不要で、直感的なウェブ インターフェースを通じてアクセスできるため、ユーザーは簡単に使い始めることができることがわかりました。 ただし、ユーザーは、プロジェクト、データセット、テーブルなどのリソースを含む、GCP の一部の機能と概念に慣れる必要がありました。 ユーザーが使い始めるのに役立つチュートリアルとチュートリアルを開発しました。 基本的な理解があれば、ユーザーはデータセットの移動、スキーマとテーブル データの表示、単純なクエリの実行、データポータルでの結果の視覚化を簡単に行うことができます。

BigQuery へのデータ入力に関する私たちの目標は、ワンクリックで HDFS または GCS データセットをシームレスに読み込めるようにすることでした。 検討しました CloudComposer (Airflow によって管理されています) が、「ドメイン制限付き共有」セキュリティ モデルのため使用できませんでした (これについては、以下のデータ管理セクションで詳しく説明します)。 Google Data Transfer Service (DTS) を使用して BigQuery の読み込みタスクを整理することを実験しました。 DTS はセットアップが迅速でしたが、依存関係のあるパイプラインの構築には柔軟性がありませんでした。 アルファ リリースでは、GCE で独自の Apache Airflow 環境を作成し、本番環境と Vertica などのより多くのデータ ソースをサポートできるように準備しています。

データを BigQuery に変換するには、ユーザーはスケジュールされたクエリを使用して単純な SQL データ パイプラインを作成します。 依存関係のある複雑なマルチステージ パイプラインの場合は、独自の Airflow フレームワークまたは Cloud Composer を使用する予定です。 クラウドデータフロー.

Производительность

BigQuery は、大量のデータを処理する汎用 SQL クエリ向けに設計されています。 これは、トランザクション データベースに必要な低レイテンシ、高スループットのクエリ、またはトランザクション データベースによって実装される低レイテンシの時系列分析を目的としたものではありません。 アパッチドルイド。 インタラクティブな分析クエリの場合、ユーザーは XNUMX 分未満の応答時間を期待しています。 これらの期待に応えるために、BigQuery の使用を設計する必要がありました。 ユーザーに予測可能なパフォーマンスを提供するために、固定料金ベースで顧客が利用できる BigQuery 機能を使用しました。これにより、プロジェクト オーナーはリクエストに対して最小限のスロットを予約できます。 スロット BigQuery は、SQL クエリを実行するために必要なコンピューティング能力の単位です。

それぞれ約 800 TB のデータを処理する 1 を超えるクエリを分析したところ、平均実行時間は 30 秒であることがわかりました。 また、パフォーマンスはさまざまなプロジェクトやタスクでのスロットの使用に大きく依存することもわかりました。 実稼働ユースケースと対話型分析のパフォーマンスを維持するには、実稼働スロットとアドホックスロットの予約を明確に分離する必要がありました。 これは、スロット予約とプロジェクト階層の設計に大きな影響を与えました。

システムのデータ管理、機能、コストについては、数日以内に翻訳の第 XNUMX 部で説明する予定です。 無料のライブウェビナーここでは、コースの詳細を学んだり、当社の専門家である Egor Matesshuk (MaximaTelecom のシニア データ エンジニア) に質問したりすることができます。

続きを読む：

• データ構築ツール、またはデータ ウェアハウスとスムージーの共通点
• Delta Lake の詳細: スキーマの適用と進化
• Apache Arrow を使用した Python での高速 Apache Parquet

出所： habr.com