今日頭條（以下簡稱頭條）成立於 2012 年，本文作者王燁在 2014 年加入，那時公司人員僅三百人。2014 年，對頭條來說是很關鍵的階段，當時 DAU 只有幾百萬的級別；到 2016 年，DAU 達到 7800 萬，目前更多。

隨著公司規模的發展，資料量呈遞增式爆棚，他也見證了基礎資料平臺從無到有、從小到大的歷程。頭條在這一發展過程中對於資料使用及難度都經歷了數量級的變化。本文將與大家分享資料平臺經歷的各種坑及一些重要的技術決策。

基礎資料平臺的建設歷程

為什麼要建設基礎資料平臺？

對於初創公司來講，核心是服務好使用者，做好產品功能的迭代。當公司發展到一定階段，業務開始多元化並開始精細化運營，資料需求變多，產生的資料量和資料處理複雜度也大幅增加，這時就該建設基礎資料平臺了。

2014 年，頭條每天只有幾百萬活躍使用者，支撐好產品是首要任務，並沒有專門的人負責做資料。眾多複雜業務的上線，同步會招聘大量的 PM（產品經理）和運營。基於刻到骨子裡的資料驅動的思想，各種各樣的資料需求源源不斷的被提上來，這時不再是幾個資料工程師單打獨鬥就能解決問題了，而讓PM 和運營直接分析資料的門檻也很高。

面對這些情況，頭條的做法是成立資料平臺團隊，把資料基礎設施像 Hadoop、Hive、Spark、Kylin 等封裝成工具，把這些工具結合通用的分析模式整合成完整的解決方案，再把這些解決方案通過平臺的形式，提供給業務部門使用。

這裡需要注意資料平臺的發展是一個演進的過程，並不需要追求一開始就大而全，不同階段採用的技術能匹配當時需求就好。

基礎資料平臺的職責什麼？

資料平臺的需求最初來自推薦業務，從使用者的閱讀需求出發，搭建面向全公司的通用資料平臺。其中，使用者資料（內容偏愛、行為軌跡、閱讀時間等）是頭條最龐大的資料來源，這些被記錄下來的資料反映了使用者的興趣，會以各種形式傳輸和儲存，並提供給全公司各個業務系統來呼叫。

還要維護面向 RD（分析師）資料工具集（日誌收集、入庫、排程、依賴管理、查詢、元資料、報表），面向 PM、運營的通用使用者行為分析平臺，底層查詢引擎（Hive，Presto，Kylin 等 OLAP 查詢引擎，支撐上層資料平臺和資料倉庫），平臺基礎資料倉庫及協助維護業務部門資料倉庫。

面臨哪些挑戰？

當前，頭條每日處理資料量為 7.8 PB、訓練樣本量 200 億條、伺服器總量 40000 臺、Hadoop 節點3000 臺。

資料生命週期分為生成、傳輸、入庫和統計/分析/挖掘，每個環節的難度都會隨著資料規模的變大而上升。平臺建設面臨的挑戰是由龐大的資料量和業務複雜度給資料生成、採集、傳輸、儲存和計算等帶來的一系列問題。

（1）資料生成與採集——SDK、使用者埋點

一般情況下，資料生成與採集是很簡單的事，但對於頭條這個功能眾多的 APP 來講，難點就在於每個功能背後都是一個團隊獨立運營。如果每個團隊都用自研的資料採集方法，那會給後續的程序帶來巨大的困擾。

怎麼辦呢？因為頭條屬於 C 端業務公司，主要以日誌形式為主，資料的主要來源是使用者行為，那麼就採用事件模型來描述日誌，以 SDK 形式接入，支援客戶端、服務端埋點。

這裡需要注意的是：資料質量很重要，埋點規範趁早確立，髒資料是不可避免的，可以引入必要的約束、清洗等。

• 埋點。埋點是使用者在使用某一個功能時，產生的一段資料。頭條初期，埋點由各業務場景自定義日誌格式，之後埋點統一到事件模型，保證了資訊的結構化和自描述，降低了後續使用成本，並複用統一的解析和清洗流程、資料倉庫的入庫和行為分析平臺的匯入。埋點的管理，也由通過文件、Wiki 等方式演進成埋點管理系統，覆蓋整個埋點生命週期。這樣一來，也得到了埋點元資訊的描述，後續可應用在資料清洗、分析平臺等場景，同時埋點的上線流程實現標準化，客戶端也可進行自動化測試。
• SDK。資料平臺實現了通用的客戶端埋點 SDK 和服務端埋點 SDK，放棄之前按約定生成資料的方式，可以保證生成的日誌符合埋點規範，並統一 App 啟動、裝置標識等的基本口徑，也減少了新 App 適配成本。對資料的描述由使用 JSON 改為 Protobuf，這樣就可通過 IDL 實現強制約束，包括資料型別、欄位命名等。

除了日誌資料，關係資料庫中的資料也是資料分析的重要來源。頭條在資料的採集方式上，用 Spark 實現類 Sqoop 的分散式抓取替代了早期定期用單機全量抓取 MySQL 資料表的方式，有效的提升了抓取速度，突破了單機瓶頸。

再之後為了減少 MySQL 壓力，選用 Canal 來接收 MySQL binlog，離線 merge 出全量表，這樣就不再直接讀 MySQL 了，而且對千萬/億級大表的處理速度也會更快。

（2）資料傳輸——Kafka 做訊息匯流排連線線上和離線系統

資料在客戶端向服務端回傳或者直接在服務端產生時，可以認為是線上狀態。當資料落地到統計分析相關的基礎設施時，就變成離線的狀態了。線上系統和離線系統採用訊息佇列來連線。

頭條的資料傳輸以 Kafka 作為資料匯流排，所有實時和離線資料的接入都要通過 Kafka，包括日誌、binlog 等。這裡值得注意的是：儘早引入訊息佇列，與業務系統解耦。

頭條的資料基礎設施以社群開源版本作為基礎，並做了大量的改進，也回饋給了社群，同時還有很多自研的元件。

因為以目前的資料和叢集規模，直接使用社群版本乃至企業版的產品，都會遇到大量困難。像資料接入，就使用自研 Databus，作為單機 Agent，封裝 Kafka 寫入，提供非同步寫入、buffer、統一配置等 feature。

Kafka 資料通過 Dump 落地到 HDFS，供後續離線處理使用。隨著資料規模的增加，Dump 的實現也經歷了幾個階段。最初實現用的是類似 Flume 模式的單機上傳，很快遇到了瓶頸，實現改成了通過Storm 來實現多機分散式的上傳，支援的資料吞吐量大幅增加。

現在開發了一個叫 DumpService 的服務，作為託管服務方便整合到平臺工具上，底層實現切換到了 SparkStreaming，並實現了 exactly-once 語義，保證 Dump 資料不丟不重。

（3）資料入庫——資料倉庫、ETL（抽取轉換載入）

頭條的資料來源很複雜，直接拿來做分析並不方便。但是到資料倉庫這一層級，會通過資料處理的過程，也就是 ETL，把它建設成一個層次完備的適合分析的一個個有價值的數倉。在數倉之上，就可以讓資料分析師和資料 RD 通過 SQL 和多維分析等更高效的手段使用資料。

資料倉庫中資料表的元資訊都放在 Hivemetastore 裡，資料表在 HDFS 上的儲存格式以 Parquet 為主，這是一種列式儲存格式，對於巢狀資料結構的支援也很好。

頭條有多種 ETL 的實現模式在並存，對於底層資料構建，一種選擇是使用 Python 通過 HadoopStreaming 來實現 Map Reduce 的任務，但現在更傾向於使用 Spark 直接生成 Parquet 資料，Spark 相比 MapReduce 有更豐富的處理原語，程式碼實現可以更簡潔，也減少了中間資料的落地量。對於高層次的資料表，會直接使用 HiveSQL 來描述 ETL 過程。

（4）資料計算——計算引擎的演進

資料倉庫中的資料表如何能被高效的查詢很關鍵，因為這會直接關係到資料分析的效率。常見的查詢引擎可以歸到三個模式中，Batch 類、MPP 類、Cube 類，頭條在 3 種模式上都有所應用。

頭條最早使用的查詢引擎是 InfoBright，Infopight 可以認為是支援了列式儲存的 MySQL，對分析類查詢更友好，但 Infopight 只支援單機。隨著資料量的增加，很快換成了 Hive，Hive 是一個很穩定的選擇，但速度一般。

為了更好的支援 Adhoc 互動式查詢，頭條開始調研 MPP 類查詢引擎，先後使用過 Impala 和 Presto，但在頭條的資料量級下都遇到了穩定性的問題。

頭條現在的方案是混合使用 Spark SQL 和 Hive，並自研 QAP 查詢分析系統，自動分析並分發查詢 SQL 到適合的查詢引擎。在 Cube 類查詢引擎上，頭條採用了  Kylin，現在也是 Kylin 在國內最大的使用者之一。

（5）資料門戶——為業務的資料分析提供整體解決方案

對於大部分需求相對簡單的公司來說，資料最終可以產出報表就夠用了，如做一個面向管理層的報表，可以讓老闆直觀的瞭解一些關鍵性指標，這是最基礎的資料應用模式。

再深入一點，就需要彙總各種來源的業務資料，提供多種維度和指標來進行更深入的探索型分析，得到的結論用來指導產品的迭代和運營。頭條絕大部分業務都是資料驅動的，都需要產出和分析大量的資料，這就或多或少需要用到平臺提供的系列工具。

頭條開發了一套叫資料門戶的平臺系統，提供給業務部門使用，對資料生命週期各個環節都提供了相應支援。資料門戶提供的工具都是宣告式的，也就是讓使用者只需要說明要實現什麼目的，具體實現的複雜細節都隱藏起來，對使用者更友好。

通過這些工具，可以讓業務部門的 RD 、分析師、PM 等將精力放在業務分析本身，而不是去學習大量資料基礎設施的使用方法。

資料抽取平臺 QueryEditor

資料抽取平臺 QueryEdito 使用介面

資料抽取平臺 QueryEditor，用於資料生命週期管理，對 Kafka 資料 Dump、資料倉庫入庫、SQL 查詢託管等做了統一支援。

結語

基礎資料平臺的建設理念是通過提供整體解決方案，降低資料使用門檻，方便各種業務接入。網際網路產品的資料分析模式也是相對固定的，比如事件多維分析、留存分析、漏斗分析等，把這些分析模式抽象出工具，也能覆蓋住大部分常用需求。

同時，期望參與業務的人比如 PM 等能更直接的掌握資料，通過相關工具的支援自行實現資料需求，儘量解放業務部門工程師的生產力，不至於被各種臨時跑數需求困擾。而對於更專業的資料分析師的工作，也會提供更專業的工具支援。

作者：王燁

原文來自微信公眾號： 51CTO技術棧