毎日、1億人以上の人々がTwitterにアクセスして、世界で何が起こっているのかを調べて話し合っています。すべてのツイートおよびその他すべてのユーザーアクションは、Twitterの内部データ分析に使用できるイベントを生成します。何百人もの従業員がこのデータを分析および視覚化しており、Twitter DataPlatformチームの最優先事項はエクスペリエンスの向上です。
幅広い技術スキルを持つユーザーは、データを見つけて、パフォーマンスの高いSQLベースの分析および視覚化ツールにアクセスできる必要があると考えています。これにより、データアナリストや製品マネージャーなど、技術的な偏りが少ないまったく新しいユーザーグループがデータから情報を抽出できるようになり、Twitterの機能をよりよく理解して使用できるようになります。これが、Twitterのデータ分析を民主化する方法です。
内部データ分析のためのツールと機能が向上するにつれて、Twitterサービスも向上しました。ただし、まだ改善の余地があります。 Scaldingのような現在のツールには、プログラミングの経験が必要です。 PrestoやVerticaなどのSQLベースの分析ツールには、大規模なパフォーマンスの問題があります。また、データに常時アクセスせずに複数のシステムにデータを分散させるという問題もあります。
昨年、Googleとの新しいパートナーシップを発表しました。これにより、データインフラストラクチャの一部がGoogle Cloud Platform（GCP）に導入されます。 GoogleCloudビッグデータツールは Twitterでの分析、視覚化、機械学習を民主化するためのイニシアチブを支援できます。
- BigQuery：スピード、シンプルさ、機械学習で有名なDremelベースのSQLエンジンを備えたエンタープライズデータウェアハウス。
- Data Studio： GoogleDocsなどのコラボレーション機能を備えたビッグデータ視覚化ツール。
この記事では、これらのツールの使用経験について学習します。私たちが何をしたか、何を学んだか、そして次に何をするかです。ここでは、バッチ分析とインタラクティブ分析に焦点を当てます。次の記事では、リアルタイム分析について説明します。
Twitterデータストアの履歴
BigQueryに飛び込む前に、Twitterデータストレージの歴史を簡単に説明する価値があります。2011年、Twitterのデータ分析はVerticaとHadoopで行われました。MapReduce Hadoopジョブを作成するために、Pigを使用しました。2012年に、PigをScaldingに置き換えました。これには、複雑なパイプラインを作成する機能やテストの容易さなどの利点を備えたScalaAPIがありました。ただし、SQLの操作に慣れている多くのデータアナリストや製品マネージャーにとって、これは急な学習曲線でした。2016年頃、HadoopデータのSQLインターフェイスとしてPrestoの使用を開始しました。SparkはPythonインターフェースを提供しました。これは、アドホックデータマイニングとマシン学習に適しています。
2018年以降、データの分析と視覚化に次のツールを使用しています。
- 生産コンベヤーの火傷
- アドホックデータ分析と機械学習のためのScaldingとSpark
- アドホックでインタラクティブなSQL分析のためのVerticaとPresto
- 時系列メトリックへの低インタラクティブ、探索的、低遅延アクセスのためのDruid
- データ視覚化のためのTableau、Zeppelin、Pivot
これらのツールは非常に強力な機能を提供しますが、Twitterでこれらの機能をより多くのユーザーが利用できるようにするのは困難であることがわかりました。Google Cloudを使用してプラットフォームを拡張する際、Twitter全体で分析ツールを簡素化することに重点を置いています。
GoogleBigQueryデータウェアハウス
Twitterのいくつかのチームは、すでにいくつかの生産パイプラインにBigQueryを組み込んでいます。彼らの経験を使用して、すべてのTwitterユースケースでBigQueryの機能の評価を開始しました。私たちの目標は、BigQueryを会社全体に提供し、DataPlatformツールボックス内で標準化およびサポートすることでした。これは多くの理由で困難でした。大量のデータを確実に受信し、会社全体のデータ管理をサポートし、適切なアクセス制御を確保し、顧客のプライバシーを確保するためのインフラストラクチャを設計する必要がありました。また、チームがBigQueryを効果的に使用できるように、リソースの割り当て、監視、およびチャージバックのためのシステムを構築する必要がありました。
2018年11月、全社向けにBigQueryとDataStudioのアルファ版リリースをリリースしました。 Twitterの従業員に、最もよく使用される個人データを消去したスプレッドシートの一部を提供しました。 BigQueryは、エンジニアリング、財務、マーケティングなど、さまざまなチームの250人を超えるユーザーによって使用されています。最近では、約8,000のリクエストを実行し、スケジュールされたリクエストを除いて、月に約100PBを処理しました。非常に前向きなフィードバックを受け取った後、私たちは前進し、Twitter上のデータを操作するための主要なリソースとしてBigQueryを提供することにしました。
これは、GoogleBigQueryデータウェアハウスの高レベルアーキテクチャの図です。
内部のCloudReplicatorツールを使用して、オンプレミスのHadoopクラスターからGoogle Cloud Storage（GCS）にデータをコピーします。次に、Apache Airflowを使用して、「bq_load」を使用してGCSからBigQueryにデータをロードするパイプラインを作成します。Prestoを使用して、GCSのParquetまたはThrift-LZOデータセットを照会します。BQ Blasterは、VerticaおよびThrift-LZOHDFSデータセットをBigQueryにロードするための内部Scaldingツールです。
次のセクションでは、使いやすさ、パフォーマンス、データ管理、システムヘルス、およびコストの分野におけるアプローチと知識について説明します。
使いやすさ
BigQueryはソフトウェアのインストールを必要とせず、ユーザーは直感的なWebインターフェイスを介してアクセスできるため、ユーザーは簡単にBigQueryを使い始めることができました。ただし、ユーザーは、プロジェクト、データセット、テーブルなどのリソースを含む、GCPの機能とその概念のいくつかに精通する必要がありました。ユーザーが使い始めるのに役立つチュートリアルとチュートリアルを開発しました。この基本的な理解により、ユーザーはデータスタジオのナビゲート、スキーマとテーブルデータの表示、簡単なクエリの実行、およびDataStudioでの結果の視覚化を簡単に行うことができます。
BigQueryデータ入力の目標は、ワンクリックでHDFSまたはGCSデータセットをスムーズにロードできるようにすることでした。検討したCloud Composer（Airflowによって管理されています）が、ドメイン制限付き共有セキュリティモデルのために使用できませんでした（これについては、以下の「データ管理」セクションで詳しく説明します）。 Google Data Transfer Service（DTS）を使用してBigQueryの読み込みタスクを整理する実験を行いました。 DTSのセットアップは迅速でしたが、依存関係パイプラインの構築には柔軟性がありませんでした。アルファ版では、GCEで独自のApache Airflowフレームワークを作成し、本番環境とVerticaなどのより多くのデータソースをサポートする機能を準備しています。
データをBigQueryに変換するために、ユーザーはスケジュールされたクエリを使用してSQLデータの単純なパイプラインを作成します。複雑な多段階の依存関係パイプラインの場合、独自のAirflowフレームワークまたはCloudComposerをCloudDataflowとともに使用することを計画しています。
パフォーマンス
BigQueryは、大量のデータを処理する汎用SQLクエリ用に設計されています。これは、トランザクションデータベースに必要な低遅延、高スループットのクエリ、またはApacheDruidによって実装される低遅延の時系列分析を対象としていません。インタラクティブな分析クエリの場合、ユーザーは1分未満の応答時間を期待しています。これらの期待に応えるために、BigQueryの使用法を設計する必要がありました。ユーザーに予測可能なパフォーマンスを保証するために、BigQueryを使用しました。これは、お客様が定額で利用できる機能であり、プロジェクトの所有者はクエリ用に最小限のスロットを予約できます。スロットBigQueryは、SQLクエリの実行に必要な計算能力の単位です。
それぞれ約1TBのデータを処理する800を超えるクエリを分析したところ、平均実行時間は30秒でした。また、パフォーマンスはさまざまなプロジェクトやタスクでのスロットの使用に大きく依存することも学びました。プロダクションのユースケースとインタラクティブな分析のパフォーマンスを維持するには、プロダクションとアドホックスロットリザーブを明確に区別する必要がありました。これは、スロット予約とプロジェクト階層の設計に大きな影響を与えました。
翻訳の後半では、データ管理、機能、システムのコストについて今後数日で説明します。今度は、無料のライブウェビナーに全員を招待します。, , — (Senior Data Engineer, MaximaTelecom).