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

基礎(chǔ)數(shù)據(jù)平臺——是數(shù)據(jù)驅(qū)動型公司發(fā)展到一定階的必需

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

[[187961]]

王燁·今日頭條基礎(chǔ)數(shù)據(jù)平臺架構(gòu)師

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

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

建設(shè)基礎(chǔ)數(shù)據(jù)平臺需要面臨哪些挑戰(zhàn)？數(shù)據(jù)生命周期分為生成、傳輸、入庫和統(tǒng)計/分析/挖掘，每個環(huán)節(jié)的難度都會隨著數(shù)據(jù)規(guī)模的變大而上升。當(dāng)前，頭條每日處理數(shù)據(jù)量為7.8PB、訓(xùn)練樣本量200億條、服務(wù)器總量40000臺、Hadoop節(jié)點3000臺。龐大數(shù)據(jù)量和業(yè)務(wù)復(fù)雜度給數(shù)據(jù)生成、采集、傳輸、存儲和計算等帶來的一系列問題是平臺建設(shè)要克服的挑戰(zhàn)。

數(shù)據(jù)生成與采集——SDK、用戶埋點

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

埋點就是用戶在使用某一個功能時，產(chǎn)生的一段數(shù)據(jù)。頭條初期，埋點由各業(yè)務(wù)場景自定義日志格式，之后埋點統(tǒng)一到事件模型，保證了信息的結(jié)構(gòu)化和自描述，降低了后續(xù)使用成本，并復(fù)用統(tǒng)一的解析和清洗流程、數(shù)據(jù)倉庫的入庫和行為分析平臺的導(dǎo)入。埋點的管理，也由通過文檔、Wiki等方式演進成埋點管理系統(tǒng)，覆蓋整個埋點生命周期。這樣一來，也得到了埋點元信息的描述，后續(xù)可應(yīng)用在數(shù)據(jù)清洗、分析平臺等場景，同時埋點的上線流程實現(xiàn)標(biāo)準(zhǔn)化，客戶端也可進行自動化測試。

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

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

數(shù)據(jù)傳輸——Kafka做消息總線 連接在線和離線系統(tǒng)

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

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

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

數(shù)據(jù)入庫——數(shù)據(jù)倉庫、ETL（抽取轉(zhuǎn)換加載）

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

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

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

數(shù)據(jù)計算——計算引擎的演進

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

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

數(shù)據(jù)門戶——為業(yè)務(wù)的數(shù)據(jù)分析提供整體解決方案

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

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

數(shù)據(jù)抽取平臺QueryEditor

數(shù)據(jù)抽取平臺QueryEdito使用界面

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

基礎(chǔ)數(shù)據(jù)平臺理念及方向——降低使用門檻 提升工具易用性  

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