Google BigQuery 如何實現數據分析民主化。 第2部分

嘿哈布爾！ OTUS 現已開放新課程報名 數據工程師。 在課程開始之前，我們將繼續與您分享有用的材料。

閱讀第一部分

數據管理

強大的資料治理是 Twitter 工程的核心宗旨。 當我們在平台中實施 BigQuery 時，我們專注於資料發現、存取控制、安全性和隱私。

為了發現和管理數據，我們將數據存取層擴展到 DAL）為本地和 Google Cloud 資料提供工具，為我們的用戶提供單一介面和 API。 正如Google 資料目錄 正朝著普遍可用性的方向發展，我們將把它包含在我們的專案中，為用戶提供列搜尋等功能。

BigQuery 讓共享和存取資料變得容易，但我們需要對此進行一些控制以防止資料外洩。 在其他工具中，我們選擇了兩個功能：

• 域限制共享：測試版功能可防止使用者與 Twitter 以外的使用者分享 BigQuery 資料集。
• VPC 服務控制：防止資料外洩並要求使用者從已知 IP 位址範圍存取 BigQuery 的控制項。

我們已實施身份驗證、授權和審核 (AAA) 安全性要求，如下所示：

• 身份驗證：我們使用 GCP 使用者帳戶來處理臨時請求，使用服務帳戶來處理生產請求。
• 授權：我們要求每個資料集都有一個所有者服務帳戶和一個讀者群組。
• 審核：我們將包含詳細查詢執行資訊的 BigQuery stackdriver 日誌匯出到 BigQuery 資料集中，以便於分析。

為了確保 Twitter 用戶的個人資料正確處理，我們必須註冊所有 BigQuery 資料集、註釋個人資料、維護適當的儲存空間以及刪除（抓取）用戶已刪除的資料。

我們查看了谷歌 雲端資料遺失防護 API，它使用機器學習來分類和編輯敏感數據，但由於準確性而決定支援手動註釋資料集。 我們計劃使用資料遺失防護 API 來增強自訂註解。

在 Twitter，我們為 BigQuery 中的資料集建立了四個隱私類別，此處按敏感度降序列出：

• 根據最小權限原則按需提供高度敏感的資料集。 每個資料集都有一個單獨的讀者群組，我們將追蹤各個帳戶的使用情況。
• 中等敏感度資料集（使用加鹽雜湊的單向假名）不包含個人識別資訊 (PII)，可供更多員工存取。 這是隱私問題和資料有用性之間的良好平衡。 這使得員工可以執行分析任務，例如計算使用某個功能的使用者數量，而無需知道真正的使用者是誰。
• 包含所有使用者識別資訊的低敏感度資料集。 從隱私角度來看，這是一個很好的方法，但不能用於使用者層級分析。
• 公開資料集（在 Twitter 外部發布）可供所有 Twitter 員工使用。

至於日誌記錄，我們使用排程任務來列舉 BigQuery 資料集並將它們註冊到資料存取層（DAL），Twitter 元資料儲存庫。 使用者將使用隱私資訊註釋資料集，並指定保留期限。 至於清潔，我們評估了兩種選擇的性能和成本： 1. 使用 Scalding 等工具清理 GCS 中的資料集並將其載入到 BigQuery 中； 2. 使用 BigQuery DML 語句。 我們可能會結合這兩種方法來滿足不同群體和數據的要求。

系統功能

由於 BigQuery 是一項託管服務，因此無需讓 Twitter 的 SRE 團隊參與系統管理或辦公室職責。 為儲存和運算提供更多容量很容易。 我們可以透過在 Google 支援下建立票證來更改時段預訂。 我們確定了可以改進的領域，例如自助服務時段分配和用於監控的儀表板改進，並向 Google 提交了這些請求。

成本

我們的初步分析表明，BigQuery 和 Presto 的查詢成本處於同一水平。 我們購買了插槽 固定的 價格有穩定的每月費用而不是付款 一經請求 每 TB 處理的資料。 這項決定也是基於用戶的回饋，他們不想在提出每個請求之前考慮成本。

除了 GCS 成本之外，在 BigQuery 中儲存資料還帶來了成本。 像 Scalding 這樣的工具需要 GCS 中的資料集，要存取 BigQuery，我們必須將相同的資料集載入為 BigQuery 格式 電容器。 我們正在研究與 BigQuery 資料集的 Scalding 連接，這將消除在 GCS 和 BigQuery 中儲存資料集的需要。

對於需要數十 PB 的不頻繁查詢的極少數情況，我們認為將資料集儲存在 BigQuery 中並不划算，因此使用 Presto 直接存取 GCS 中的資料集。 為此，我們正在研究 BigQuery 外部資料來源。

下一步

自從 Alpha 版本發布以來，我們看到了人們對 BigQuery 的濃厚興趣。 我們正在為 BigQuery 添加更多資料集和更多命令。 我們為 Scalding 等資料分析工具開發連接器，以讀取和寫入 BigQuery 儲存。 我們正在研究 Looker 和 Apache Zeppelin 等工具，用於使用 BigQuery 資料集建立企業品質報告和註釋。

我們與 Google 的合作非常富有成效，我們很高興能繼續並發展這種合作關係。 我們與 Google 合作實施我們自己的 合作夥伴問題追蹤器直接向 Google 發送查詢。 其中一些，例如 BigQuery Parquet 載入器，已經由 Google 實作。

以下是我們向 Google 提出的一些高優先功能請求：

• 用於方便資料接收並支援 LZO-Thrift 格式的工具。
• 按小時細分
• 存取控制改進，例如表級、行級和列級權限。
• BigQuery的 外部數據源 與 Hive Metastore 整合並支援 LZO-Thrift 格式。
• 改進了 BigQuery 使用者介面中的資料目錄集成
• 時段分配和監控的自助服務。

結論

以安全的方式實現資料分析、視覺化和機器學習的大眾化是資料平台團隊的首要任務。 我們將 Google BigQuery 和 Data Studio 確定為可以協助實現這一目標的工具，並於去年在全公司範圍內發布了 BigQuery Alpha。

我們發現 BigQuery 中的查詢既簡單又有效率。 我們使用 Google 工具來提取和轉換簡單管道的數據，但對於複雜的管道，我們必須建立自己的 Airflow 框架。 在資料管理領域，BigQuery 的身份驗證、授權和審計服務滿足了我們的需求。 為了管理元資料和維護隱私，我們需要更大的靈活性，並且必須建立自己的系統。 BigQuery 作為託管服務，很容易使用。 查詢成本與現有工具類似。 除了 GCS 成本之外，在 BigQuery 中儲存資料還會產生成本。

總體而言，BigQuery 非常適合常規 SQL 分析。 我們看到人們對 BigQuery 很感興趣，我們正在努力遷移更多資料集，引入更多團隊，並使用 BigQuery 建立更多管道。 Twitter 使用各種數據，需要結合使用 Scalding、Spark、Presto 和 Druid 等工具。 我們打算繼續加強我們的數據分析工具，並就如何最好地使用我們的產品向我們的用戶提供明確的指導。

感恩的話語

我要感謝我的合著者和隊友 Anju Jha 和 Will Pascucci 在這個項目上的出色合作和辛勤工作。 我還要感謝 Twitter 和 Google 多個團隊的工程師和經理為我們提供的協助，以及 Twitter 上提供寶貴回饋的 BigQuery 用戶。

如果您有興趣解決這些問題，請查看我們的 職位空缺 在數據平台團隊中。

DWH 中的資料品質 - 資料倉儲一致性

來源： www.habr.com