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

おい、ハブル！ 新しいコースストリームへの登録は現在OTUSで受付中です データエンジニア。 コースの開始に向けて、役立つ資料を引き続き共有していきます。

最初の部分を読む

データ管理

強力なデータ ガバナンスは Twitter エンジニアリングの中核的な理念です。 BigQuery をプラットフォームに実装する際には、データ検出、アクセス制御、セキュリティ、プライバシーに重点を置いています。

データを検出して管理するために、データ アクセス レイヤーを次のように拡張しました。 DAL）オンプレミスと Google Cloud データの両方にツールを提供し、ユーザーに単一のインターフェースと API を提供します。 Googleとして データカタログ は一般公開に向けて進んでおり、列検索などの機能をユーザーに提供するためにプロジェクトに含める予定です。

BigQuery を使用すると、データの共有とアクセスが簡単になりますが、データの漏洩を防ぐためにこれをある程度制御する必要がありました。 他のツールの中から、次の XNUMX つの機能を選択しました。

• ドメイン制限付き共有: ユーザーが Twitter 以外のユーザーと BigQuery データセットを共有できないようにするベータ機能。
• VPC サービス制御: データの漏洩を防止し、ユーザーが既知の IP アドレス範囲から BigQuery にアクセスすることを要求するコントロール。

次のように、セキュリティのための認証、認可、監査 (AAA) 要件を実装しました。

• 認証: アドホック リクエストには GCP ユーザー アカウントを、本番リクエストにはサービス アカウントを使用しました。
• 承認: 各データセットには所有者サービス アカウントとリーダー グループが必要です。
• 監査: 分析を容易にするために、詳細なクエリ実行情報が含まれる BigQuery stackdriver ログを BigQuery データセットにエクスポートしました。

Twitter ユーザーの個人データが適切に扱われるようにするには、すべての BigQuery データセットを登録し、個人データに注釈を付け、適切なストレージを維持し、ユーザーによって削除されたデータを削除（スクレイピング）する必要があります。

私たちはGoogleを見ました クラウドデータ損失防止 API、機密データの分類と編集に機械学習を使用していますが、精度を理由にデータセットに手動で注釈を付けることを選択しました。 Data Loss Prevention API を使用してカスタム アノテーションを強化する予定です。

Twitter では、BigQuery のデータセットに対して XNUMX つのプライバシー カテゴリを作成しました。ここでは、機密性の高い順にリストしています。

• 機密性の高いデータ セットは、最小特権の原則に基づいて必要に応じて利用可能になります。 各データセットには個別のリーダーグループがあり、個別のアカウントごとに使用状況を追跡します。
• 中機密データセット (ソルテッド ハッシュを使用した一方向の仮名) には個人を特定できる情報 (PII) が含まれていないため、より大規模な従業員グループがアクセスできます。 これは、プライバシーへの懸念とデータの有用性との間の適切なバランスです。 これにより、従業員は、実際のユーザーが誰であるかを知らなくても、機能を使用したユーザーの数を計算するなどの分析タスクを実行できます。
• すべてのユーザー識別情報を含む低感度データセット。 これはプライバシーの観点からは優れたアプローチですが、ユーザーレベルの分析には使用できません。
• 公開データセット (Twitter 社外で公開) は、Twitter 従業員全員が利用できます。

ロギングに関しては、スケジュールされたタスクを使用して BigQuery データセットを列挙し、データ アクセス レイヤーに登録しました (DAL)、Twitter メタデータ リポジトリ。 ユーザーはデータセットにプライバシー情報の注釈を付け、保存期間も指定します。 洗浄に関しては、次の XNUMX つのオプションのパフォーマンスとコストを評価します。 1. Scalding などのツールを使用して GCS 内のデータセットをクリーニングし、BigQuery にロードします。 2. BigQuery DML ステートメントの使用。 さまざまなグループやデータの要件を満たすために、両方の方法を組み合わせて使用​​する可能性があります。

システム機能

BigQuery はマネージド サービスであるため、Twitter の SRE チームがシステム管理やデスク業務に関与する必要はありませんでした。 ストレージとコンピューティングの両方にさらに多くの容量を提供するのは簡単でした。 Google サポートでチケットを作成することで、スロットの予約を変更できます。 私たちは、セルフサービスのスロット割り当てやモニタリングのためのダッシュボードの改善など、改善できる領域を特定し、それらのリクエストを Google に送信しました。

のコスト

予備的な分析では、BigQuery と Presto のクエリ コストが同じレベルであることがわかりました。 スロットを購入しました 固定 支払いの代わりに毎月安定した費用がかかる価格 オンデマンド 処理されたデータの TB あたり。 この決定は、リクエストを行う前にコストについて考えたくないというユーザーからのフィードバックにも基づいています。

BigQuery にデータを保存すると、GCS のコストに加えてコストも発生します。 Scalding のようなツールには GCS のデータセットが必要で、BigQuery にアクセスするには同じデータセットを BigQuery 形式で読み込む必要がありました。 。 私たちは、GCS と BigQuery の両方にデータセットを保存する必要性を排除する BigQuery データセットへの Scalding 接続に取り組んでいます。

数十ペタバイトの頻度の低いクエリを必要とするまれなケースでは、BigQuery にデータセットを保存するのは費用対効果が高くないと判断し、Presto を使用して GCS のデータセットに直接アクセスしました。 これを行うために、BigQuery 外部データ ソースに注目します。

次のステップ

アルファ版のリリース以来、BigQuery に対する多くの関心が寄せられてきました。 BigQuery にはさらに多くのデータセットとコマンドが追加されています。 私たちは、BigQuery ストレージに読み書きするための Scalding などのデータ分析ツール用のコネクタを開発しています。 BigQuery データセットを使用してエンタープライズ品質のレポートやメモを作成するための Looker や Apache Zeppelin などのツールを検討しています。

Google とのコラボレーションは非常に生産的であり、このパートナーシップを継続し、発展させていくことを嬉しく思います。 Google と協力して独自の実装を行いました パートナーの問題追跡ツールクエリを Google に直接送信します。 BigQuery Parquet ローダーなどの一部は、Google によってすでに実装されています。

Google に対する優先度の高い機能リクエストの一部を以下に示します。

• 便利なデータ受信と LZO-Thrift 形式のサポートのためのツール。
• 時間ごとのセグメンテーション
• テーブル、行、列レベルの権限などのアクセス制御の改善。
• ビッグクエリー 外部データソース Hive Metastore の統合と LZO-Thrift 形式のサポートを備えています。
• BigQuery ユーザー インターフェースでのデータ カタログの統合の改善
• セルフサービスによるスロット割り当てと監視。

まとめ

データ分析、視覚化、機械学習を安全な方法で民主化することは、データ プラットフォーム チームにとっての最優先事項です。 私たちは、この目標の達成に役立つツールとして Google BigQuery とデータポータルを特定し、昨年 BigQuery Alpha を全社にリリースしました。

BigQuery のクエリはシンプルで効率的であることがわかりました。 単純なパイプラインのデータの取り込みと変換には Google ツールを使用しましたが、複雑なパイプラインの場合は独自の Airflow フレームワークを構築する必要がありました。 データ管理の分野では、BigQuery の認証、認可、監査のサービスがニーズを満たします。 メタデータを管理し、プライバシーを維持するには、さらなる柔軟性が必要であり、独自のシステムを構築する必要がありました。 BigQuery はマネージド サービスなので使いやすかったです。 クエリのコストは既存のツールと同様でした。 BigQuery にデータを保存するには、GCS のコストに加えてコストも発生します。

全体として、BigQuery は一般的な SQL 分析に適しています。 BigQuery には多くの関心が寄せられており、より多くのデータセットを移行し、より多くのチームを招集し、BigQuery を使用してより多くのパイプラインを構築することに取り組んでいます。 Twitter はさまざまなデータを使用するため、Scalding、Spark、Presto、Druid などのツールを組み合わせる必要があります。 当社は今後もデータ分析ツールを強化し、当社のサービスを最大限に活用する方法についてユーザーに明確なガイダンスを提供するつもりです。

感謝の言葉

このプロジェクトで多大な協力と尽力をしてくれた共著者でありチームメイトの Anju Jha と Will Pascucci に感謝します。 また、私たちを助けてくれた Twitter と Google のいくつかのチームのエンジニアとマネージャー、そして貴重なフィードバックを提供してくれた Twitter の BigQuery ユーザーにも感謝したいと思います。

これらの問題に取り組むことに興味がある場合は、こちらをチェックしてください。 欠員 データプラットフォームチームの一員です。

DWH のデータ品質 - データ ウェアハウスの一貫性

出所： habr.com