【51CTO.com原創稿件】在前往今日頭條的路上，一直考慮對于這樣一家數據驅動的公司，訪問哪個方向會更受關注，是個性化新聞推薦、不同業務之間算法差異，還是敏感信息屏蔽、新聞源抓??？可是，在這個陽光溫暖的午后，與今日頭條基礎數據平臺架構師王燁長達一個多小時的交流中，我們的話題不知不覺一直圍繞著一個主題，那就是如何使用數據。

基礎數據平臺——是數據驅動型公司發展到一定階的必需

今日頭條（以下簡稱頭條）于2012成立，王燁于2014年加入，那時候，公司僅三百人。隨著公司發展，數據量遞增式爆棚，見證了基礎數據平臺從無到有、從小到大的歷程，所以他由來解讀平臺的方方面面，再合適不過。 

[[187961]]

王燁·今日頭條基礎數據平臺架構師

什么時候需要建設基礎數據平臺？對于初創公司來講，核心是服務好用戶，做好產品功能的迭代。當公司發展到一定階段，業務開始多元化并開始精細化運營，數據需求變多，產生的數據量和數據處理復雜度也大幅增加，這時就該建設基礎數據平臺了。王燁介紹，2014年的頭條每天只有幾百萬活躍用戶，支撐好產品是首要任務，并沒有專門的人負責做數據。眾多復雜業務的上線，同步會招聘大量的PM（產品經理）和運營。基于刻到骨子里的數據驅動的思想，各種各樣的數據需求源源不斷的被提上來，這時不再是幾個數據工程師單打獨斗就能解決問題了，而讓PM和運營直接分析數據的門檻也很高。面對這些情況，頭條的做法是成立數據平臺團隊，把數據基礎設施像Hadoop、Hive、Spark、Kylin等封裝成工具，把這些工具結合通用的分析模式整合成完整的解決方案，再把這些解決方案通過平臺的形式，提供給業務部門使用。數據平臺也有一個演進的過程，并不需要追求從開始就大而全，不同階段采用的技術能匹配當時需求就好。

基礎數據平臺的職責什么？推薦業務是頭條最重要的業務之一，從其需求出發，搭建面向全公司的通用數據平臺。用戶數據（內容偏愛、行為軌跡、閱讀時間等）是頭條最龐大的數據源，這些被記錄下來的數據反映了用戶的興趣，會以各種形式傳輸和存儲，并提供給全公司各個業務系統來調用。還要維護面向RD（分析師）數據工具集（日志收集、入庫、調度、依賴管理、查詢、元數據、報表），面向PM、運營的通用用戶行為分析平臺，底層查詢引擎（Hive, Presto, Kylin等OLAP查詢引擎，支撐上層數據平臺和數據倉庫），平臺基礎數據倉庫及協助維護業務部門數據倉庫。

建設基礎數據平臺需要面臨哪些挑戰？數據生命周期分為生成、傳輸、入庫和統計/分析/挖掘，每個環節的難度都會隨著數據規模的變大而上升。當前，頭條每日處理數據量為7.8PB、訓練樣本量200億條、服務器總量40000臺、Hadoop節點3000臺。龐大數據量和業務復雜度給數據生成、采集、傳輸、存儲和計算等帶來的一系列問題是平臺建設要克服的挑戰。

數據生成與采集——SDK、用戶埋點

一般情況下，數據生成與采集是很簡單的事，但對于頭條這個功能眾多的APP來講，難點就在于每個功能背后都是一個團隊獨立運營。如果每個團隊都用自研的數據采集的方法，那會給后續的進程帶來巨大的困擾。那怎么辦呢？王燁介紹了他們分析和決策的過程，頭條屬于C端業務公司，主要以日志形式為主，數據的主要來源是用戶行為，那么就以采用事件模型來描述日志，以SDK形式接入，支持客戶端、服務端埋點。這里需要注意的是：數據質量很重要，埋點規范趁早確立，臟數據是不可避免的，可以引入必要的約束、清洗等。

埋點就是用戶在使用某一個功能時，產生的一段數據。頭條初期，埋點由各業務場景自定義日志格式，之后埋點統一到事件模型，保證了信息的結構化和自描述，降低了后續使用成本，并復用統一的解析和清洗流程、數據倉庫的入庫和行為分析平臺的導入。埋點的管理，也由通過文檔、Wiki等方式演進成埋點管理系統，覆蓋整個埋點生命周期。這樣一來，也得到了埋點元信息的描述，后續可應用在數據清洗、分析平臺等場景，同時埋點的上線流程實現標準化，客戶端也可進行自動化測試。

數據平臺實現了通用的客戶端埋點SDK和服務端埋點SDK，放棄之前按約定生成數據的方式，可以保證生成的日志符合埋點規范，并統一App啟動、設備標識等的基本口徑，也減少了新App適配成本。對數據的描述由使用JSON改為Protobuf，這樣就可通過IDL實現強制約束，包括數據類型、字段命名等。

除了日志數據，關系數據庫中的數據也是數據分析的重要來源。頭條在數據的采集方式上，用Spark實現類Sqoop的分布式抓取替代了早期定期用單機全量抓取Mysql數據表的方式，有效的提升了抓取速度，突破了單機瓶頸。再之后為了減少Mysql壓力，選用Canal來接收Mysql binlog，離線merge出全量表，這樣就不再直接讀Mysql了，而且對千萬/億級大表的處理速度也會更快。

數據傳輸——Kafka做消息總線 連接在線和離線系統

數據在客戶端向服務端回傳或者直接在服務端產生時，可以認為是在線狀態。當數據落地到統計分析相關的基礎設施時，就變成離線的狀態了。在線系統和離線系統采用消息隊列來連接。頭條的數據傳輸以Kafka作為數據總線，所有實時和離線數據的接入都要通過Kafka，包括日志、binlog等。王燁提醒，這里值得注意的是：盡早引入消息隊列，與業務系統解耦。

頭條的數據基礎設施以社區開源版本作為基礎，并做了大量的改進，也回饋給了社區，同時還有很多自研的組件。因為以目前的數據和集群規模，直接使用社區版本乃至企業版的產品，都會遇到大量困難。像數據接入，就自研Databus，作為單機Agent，封裝Kafka寫入，提供異步寫入、buffer、統一配置等feature。

Kafka數據通過Dump落地到HDFS，供后續離線處理使用。隨著數據規模的增加，Dump的實現也經歷了幾個階段。最初實現成的是類似Flume模式的單機上傳，很快遇到了瓶頸，實現改成了通過Storm來實現多機分布式的上傳，支持的數據吞吐量大幅增加。現在開發了一個叫DumpService的服務，作為托管服務方便整合到平臺工具上，底層實現切換到了Spark Streaming，并實現了exactly-once語義，保證Dump數據不丟不重。

數據入庫——數據倉庫、ETL（抽取轉換加載）

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

數據倉庫中數據表的元信息都放在Hive metastore里，數據表在HDFS上的存儲格式以Parquet為主，這是一種列式存儲格式，對于嵌套數據結構的支持也很好。

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

數據計算——計算引擎的演進

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

頭條最早使用的查詢引擎是InfoBright，Infopight可以認為是支持了列式存儲的Mysql，對分析類查詢更友好，但Infopight只支持單機。隨著數據量的增加，很快換成了Hive，Hive是一個很穩定的選擇，但速度一般。為了更好的支持Adhoc交互式查詢，頭條開始調研MPP類查詢引擎，先后使用過Impala和Presto，但在頭條的數據量級下都遇到了穩定性的問題。頭條現在的方案是混合使用Spark SQL和Hive，并自研QAP查詢分析系統，自動分析并分發查詢SQL到適合的查詢引擎。在Cube類查詢引擎上，頭條采用了Kylin，現在也是Kylin在國內***的用戶之一。

數據門戶——為業務的數據分析提供整體解決方案

對于大部分需求相對簡單的公司來說，數據最終可以產出報表就夠用了，如做一個面向管理層的報表，可以讓老板直觀的了解一些關鍵性指標，這是最基礎的數據應用模式。再深入一點，就需要匯總各種來源的業務數據，提供多種維度和指標來進行更深入的探索型分析，得到的結論用來指導產品的迭代和運營。王燁表示，頭條絕大部分業務都是數據驅動的，都需要產出和分析大量的數據，這就或多或少需要用到平臺的提供的系列工具。

頭條開發了一套叫數據門戶的平臺系統，提供給業務部門使用，對數據生命周期各個環節都提供了相應支持。數據門戶提供的工具都是聲明式的，也就是讓使用者只需要說明要實現什么目的，具體實現的復雜細節都隱藏起來，對使用者更友好。通過這些工具，可以讓業務部門的RD、分析師、PM等將精力放在業務分析本身，而不是去學習大量數據基礎設施的使用方法。

數據抽取平臺QueryEditor

數據抽取平臺QueryEdito使用界面

數據抽取平臺QueryEditor，用于數據生命周期管理，對Kafka數據Dump、數據倉庫入庫、SQL查詢托管等做了統一支持。

基礎數據平臺理念及方向——降低使用門檻 提升工具易用性  

基礎數據平臺的理念就是提供整體解決方案，降低數據使用門檻，方便各種業務接入?；ヂ摼W產品的數據分析模式也是相對固定的，比如事件多維分析、留存分析、漏斗分析等，把這些分析模式抽象出工具，也能覆蓋住大部分常用需求。同時期望參與業務的人比如PM等能更直接的掌握數據，通過相關工具的支持自行實現數據需求，盡量解放業務部門工程師的生產力，不至于被各種臨時跑數需求困擾。而對于更專業的數據分析師的工作，也會提供更專業的工具支持。