最初の部分を読む
データ管理
強力なデータガバナンスは、Twitterエンジニアリングの主要な信条です。 BigQueryをプラットフォームに統合する際、データ検出、アクセス制御、セキュリティ、およびプライバシーに重点を置いています。
データの検出と管理のために、データアクセスレイヤー（DAL）を拡張して、ローカルデータとGoogleクラウドデータの両方にツールを提供し、ユーザーに単一のインターフェイスとAPIを提供します。 Googleデータカタログが一般提供に移行するにつれて、列検索などの機能をユーザーに提供するために、プロジェクトに含めます。
BigQueryを使用すると、データの共有とアクセスが簡単になりますが、データの漏えいを防ぐための制御が必要でした。他のツールの中で、2つの機能を選択しました。
- ドメイン制限付き共有：ユーザーがBigQueryデータセットをTwitter以外のユーザーと共有できないようにするベータ機能。
- VPCサービスコントロール：データの漏えいを防ぎ、ユーザーが既知のIP範囲からBigQueryにアクセスする必要があるコントロール。
次のように、認証、承認、および監査（AAA）のセキュリティ要件を実装しました。
- 認証：アドホックリクエストにはGCPユーザーアカウントを使用し、ワークリクエストにはサービスアカウントを使用しました。
- 承認：各データセットには、所有者サービスアカウントとリーダーのグループが必要でした。
- : BigQuery, , BigQuery .
Twitterユーザーの個人データが適切に処理されるようにするには、すべてのBigQueryデータセットを登録し、個人データに注釈を付け、適切なストレージを維持し、ユーザーによって削除されたデータを削除（クリーンアップ）する必要があります。機械学習を使用して機密データを分類および編集するGoogleCloud Data Loss Prevention API
を確認しましたが、正確さのためにデータセットの手動注釈を選択しました。カスタム注釈を補完するために、Data Loss PreventionAPIを使用する予定です。 Twitterでは、BigQueryデータセット用に4つのプライバシーカテゴリを作成しました。ここでは、感度の高い順にリストします。
- . , .
- ( ) (Personally Identifiable Information — PII) . . , , , , .
- , . , .
- ( Twitter) Twitter.
登録する前に、スケジュールされたタスクを使用してBigQueryデータセットを列挙し、Twitterのメタデータストアであるデータアクセスレイヤー（DAL）に登録しました。ユーザーは、機密情報と保存期間でデータセットに注釈を付けます。スクラブ用として、私たちは二つの選択肢の性能とコストの見積もり：1のBigQueryに火傷のようなツールと読み込み、それらを持つGCSでのスクラブのデータセットを、2. BigQueryDML演算子を使用します。さまざまなグループやデータの要件を満たすために、おそらく両方の方法を組み合わせて使用します。
システム機能
BigQueryはマネージドサービスであるため、システム管理や業務にTwitterのSREチームを関与させる必要はありませんでした。ストレージとコンピューティングの両方により多くの容量を提供するのは簡単でした。Googleサポートでチケットを作成することで、スロットの予約を変更できます。スロット割り当てのセルフサービスやダッシュボードの監視の改善など、改善できる点を見つけ、それらのリクエストをGoogleに渡しました。
コスト
予備分析では、BigQueryとPrestoのクエリのコストは同じレベルであることが示されました。処理済みデータのTBをオンデマンドで支払うのではなく、安定した月額料金でスロットを固定価格で購入しました。この決定は、各リクエストを行う前にコストについて考えたくないユーザーからのフィードバックにも基づいています。 BigQueryにデータを保存すると、GCSコストに加えてコストが発生しました。火傷などのツールは、GCSでデータセットを必要とし、アクセスのBigQueryに、私たちは、BigQueryのに同じデータセットをロードしなければならなかったコンデンサフォーマット
..。GCSとBigQueryの両方にデータセットを保存する必要をなくすBigQueryデータセットへのScalding接続に取り組んでいます。
数十ペタバイトの頻繁な要求を必要としないまれなケースでは、BigQueryにデータセットを保存することは費用効果が高くないと判断し、Prestoを使用してGCSのデータセットに直接アクセスしました。これを行うために、BigQuery外部データソースを検討しています。
次のステップ
アルファ版のリリース以来、BigQueryに多くの関心が寄せられていることに気づきました。 BigQueryにデータセットとコマンドを追加しています。 BigQueryストレージの読み取りおよび書き込み用のScaldingなどのデータ分析ツール用のコネクタを開発しています。 BigQueryデータセットを使用して企業品質のレポートとメモを生成するためのLookerやApacheZeppelinなどのツールを検討しています。
Googleとのコラボレーションは非常に生産的であり、このパートナーシップを継続して発展させることを嬉しく思います。 Googleと協力して、Googleに直接リクエストを送信する独自のPartner IssueTrackerを実装しました。 BigQuery Parquet Downloaderのように、それらのいくつかはすでにGoogleによって実装されています。
Googleに対する優先度の高い機能リクエストの一部を次に示します。
- データを簡単に取り込んでLZO-Thrift形式をサポートするためのツール。
- 時間ごとのセグメンテーション
- テーブル、行、列のアクセス許可などのアクセス制御の改善。
- HiveMetastoreの統合とLZO-Thrift形式のサポートを備えたBigQuery外部データソース。
- BigQueryUIでのデータカタログ統合の改善
- スロットの割り当てと監視のためのセルフサービス。
結論
データ分析、視覚化、および機械学習を安全な方法で民主化することは、データプラットフォームチームの最優先事項です。この目標を達成するのに役立つツールとしてGoogleBigQueryとDataStudioを特定し、昨年、会社全体にBigQueryAlphaをリリースしました。
BigQueryクエリはシンプルで効果的であることがわかりました。単純なパイプラインにGoogleツールを使用してデータを受信および変換しましたが、複雑なパイプラインには独自のAirflowインフラストラクチャを作成する必要がありました。データ管理では、認証、承認、および監査のためのBigQueryサービスが私たちのニーズを満たします。メタデータを管理し、機密性を維持するために多くの柔軟性が必要であり、独自のシステムを構築する必要がありました。マネージドサービスであるBigQueryは使いやすかったです。リクエストコストは既存のツールと同様でした。 BigQueryにデータを保存すると、GCSのコストに加えてコストが発生します。
全体として、BigQueryは一般的なSQL分析に適しています。BigQueryには多くの関心が寄せられており、BigQueryを使用して、より多くのデータセットを移行し、より多くのチームを関与させ、より多くのパイプラインを構築するよう取り組んでいます。Twitterはさまざまなデータを使用するため、Scalding、Spark、Presto、Druidなどのツールを組み合わせる必要があります。今後もデータ分析ツールを活用し、ユーザーに製品の最適な使用方法に関する明確なガイダンスを提供していきます。
感謝の言葉
私の協力者でありチームメイトであるAnjouJhaとWillPascucciには、このプロジェクトでの素晴らしい協力と努力に感謝します。また、私たちを助けてくれたTwitterとGoogleのいくつかのチームのエンジニアとマネージャー、そして貴重なフィードバックを提供してくれたBigQueryTwitterユーザーにも感謝します。
これらのタスクに取り組むことに興味がある場合は、データプラットフォームチームの空席を確認してください。
DWHデータ品質-データウェアハウスの一貫性