嘿哈布爾！ OTUS 現已開放新課程報名 。 在課程開始之前，我們按照慣例為您準備了有趣材料的翻譯。
每天都有超過一億人訪問 Twitter，了解世界上正在發生的事情並進行討論。 每條推文和任何其他用戶操作都會生成一個事件，可用於 Twitter 內的內部數據分析。 數百名員工對這些數據進行分析和可視化，改善他們的體驗是 Twitter 數據平台團隊的首要任務。
我們相信，具有廣泛技術技能的用戶應該能夠查找數據並能夠使用功能良好的基於 SQL 的分析和可視化工具。 這將使一群技術含量較低的新用戶（包括數據分析師和產品經理）能夠從數據中提取見解，從而更好地理解和利用 Twitter 的強大功能。 這就是我們在 Twitter 上實現數據分析民主化的方式。
隨著我們內部數據分析工具和能力的改進，我們看到了 Twitter 服務的改進。 然而，仍有改進的空間。 目前的工具（例如 Scalding）需要編程經驗。 Presto 和 Vertica 等基於 SQL 的分析工具存在大規模性能問題。 我們還面臨跨多個系統分發數據而無法持續訪問數據的問題。
去年我們宣布 ，其中我們轉移了我們的部分 在谷歌云平台（GCP）上。 我們的結論是 Google Cloud 工具 可以幫助我們在 Twitter 上實現分析、可視化和機器學習民主化：
- ：基於SQL引擎的企業數據倉庫 ，以其速度、簡單性和應對 .
- 具有 Google Docs 等協作功能的大數據可視化工具。
在本文中，您將了解我們使用這些工具的經驗：我們做了什麼、學到了什麼以及下一步將做什麼。 我們現在將重點關注批量和交互式分析。 實時分析將在下一篇文章中討論。
Twitter 上數據倉庫的歷史
在深入探討 BigQuery 之前，有必要在 Twitter 上簡要回顧一下數據倉庫的歷史。 2011年，Twitter數據分析是在Vertica和Hadoop中進行的。 我們使用 Pig 創建 MapReduce Hadoop 作業。 2012 年，我們用 Scalding 取代了 Pig，Scalding 具有 Scala API，具有創建複雜管道的能力和易於測試等優點。 然而，對於許多更喜歡使用 SQL 的數據分析師和產品經理來說，這是一個相當陡峭的學習曲線。 2016 年左右，我們開始使用 Presto 作為 Hadoop 數據的 SQL 前端。 Spark 提供了 Python 接口，這使其成為臨時數據科學和機器學習的不錯選擇。
自2018年以來，我們使用了以下工具進行數據分析和可視化：
- 生產線燙金
- 用於臨時數據分析和機器學習的 Scalding 和 Spark
- Vertica 和 Presto 用於即席和交互式 SQL 分析
- Druid 用於低交互、探索性和低延遲地訪問時間序列指標
- Tableau、Zeppelin 和 Pivot 實現數據可視化
我們發現，雖然這些工具提供了非常強大的功能，但我們很難讓 Twitter 上更廣泛的受眾使用這些功能。 通過使用 Google Cloud 擴展我們的平台，我們致力於簡化所有 Twitter 的分析工具。
Google 的 BigQuery 數據倉庫
Twitter 的幾個團隊已經將 BigQuery 納入了他們的一些生產管道中。 根據他們的經驗，我們開始評估 BigQuery 對於所有 Twitter 用例的可能性。 我們的目標是向整個公司提供 BigQuery，並在數據平台工具包中對其進行標準化和支持。 由於多種原因，這很困難。 我們需要開發一個基礎設施來可靠地接收大量數據、支持公司範圍內的數據管理、確保適當的訪問控制並確保客戶隱私。 我們還必須創建資源分配、監控和退款系統，以便團隊可以有效地使用 BigQuery。
2018 年 250 月，我們為整個公司發布了 BigQuery 和 Data Studio 的 alpha 版本。 我們已向 Twitter 員工提供了一些最常用的個人數據清除電子表格。 BigQuery 已被來自工程、財務和營銷等各個團隊的 8 多名用戶使用。 最近，他們運行了大約 100 個請求，每月處理大約 XNUMX PB（不包括計劃的請求）。 在收到非常積極的反饋後，我們決定繼續提供 BigQuery 作為與 Twitter 上的數據交互的主要資源。
這是我們的 Google BigQuery 數據倉庫的高級架構圖。
我們使用內部 Cloud Replicator 工具將數據從本地 Hadoop 集群複製到 Google Cloud Storage (GCS)。 然後，我們使用 Apache Airflow 創建使用“的管道”» 將數據從 GCS 加載到 BigQuery 中。 我們使用 Presto 查詢 GCS 中的 Parquet 或 Thrift-LZO 數據集。 BQ Blaster 是一個內部 Scalding 工具，用於將 HDFS Vertica 和 Thrift-LZO 數據集加載到 BigQuery 中。
在以下部分中，我們將討論我們在易用性、性能、數據管理、系統運行狀況和成本方面的方法和專業知識。
易用性
我們發現，用戶很容易開始使用 BigQuery，因為它不需要安裝軟件，並且用戶可以通過直觀的網絡界面訪問它。 但是，用戶需要熟悉一些 GCP 功能和概念，包括項目、數據集和表格等資源。 我們開發了教程和教程來幫助用戶入門。 獲得基本的了解後，用戶可以輕鬆地在 Data Studio 中導航數據集、查看架構和表數據、運行簡單查詢以及可視化結果。
我們在 BigQuery 中輸入數據的目標是只需單擊一下即可無縫加載 HDFS 或 GCS 數據集。 我們考慮過 （由 Airflow 管理），但由於我們的“域限制共享”安全模型而無法使用它（更多信息請參見下面的數據管理部分）。 我們嘗試使用 Google 數據傳輸服務 (DTS) 來組織 BigQuery 加載任務。 雖然 DTS 的設置速度很快，但它在構建具有依賴關係的管道時並不靈活。 對於我們的 alpha 版本，我們在 GCE 中創建了自己的 Apache Airflow 環境，並正在準備將其用於生產以及支持更多數據源（例如 Vertica）的能力。
要將數據轉換為 BigQuery，用戶可以使用計劃查詢創建簡單的 SQL 數據管道。 對於具有依賴關係的複雜多級管道，我們計劃使用我們自己的 Airflow 框架或 Cloud Composer 以及 .
Производительность
BigQuery 專為處理大量數據的通用 SQL 查詢而設計。 它不適用於事務數據庫所需的低延遲、高吞吐量查詢，或由以下實現的低延遲時間序列分析： 。 對於交互式分析查詢，我們的用戶期望響應時間少於一分鐘。 我們必須設計 BigQuery 的使用來滿足這些期望。 為了向用戶提供可預測的性能，我們使用了 BigQuery 功能，該功能以固定費用向客戶提供，允許項目所有者為其查詢保留最少的槽位。 BigQuery 是執行 SQL 查詢所需的計算能力單位。
我們分析了 800 多個查詢，每個查詢處理約 1 TB 的數據，發現平均執行時間為 30 秒。 我們還了解到，性能很大程度上取決於我們在各種項目和任務中的槽位使用情況。 我們必須明確區分生產和臨時槽儲備，以保持生產用例和交互式分析的性能。 這極大地影響了我們對插槽預留和項目層次結構的設計。
我們將在未來幾天的翻譯第二部分中討論系統的數據管理、功能和成本，現在我們邀請大家 ，您可以在其中了解有關課程的更多信息，也可以向我們的專家 Egor Mateshuk（MaximaTelecom 高級數據工程師）提問。
閱讀更多：
來源： www.habr.com