|
在前往今日頭條的路上，一直考慮對(duì)于這樣一家數(shù)據(jù)驅(qū)動(dòng)的公司，訪問(wèn)哪個(gè)方向會(huì)更受關(guān)注，是個(gè)性化新聞推薦、不同業(yè)務(wù)之間算法差異，還是敏感信息屏蔽、新聞源抓?。靠墒?，在這個(gè)陽(yáng)光溫暖的午后，與今日頭條基礎(chǔ)數(shù)據(jù)平臺(tái)架構(gòu)師王燁長(zhǎng)達(dá)一個(gè)多小時(shí)的交流中，我們的話題不知不覺(jué)一直圍繞著一個(gè)主題，那就是如何使用數(shù)據(jù)。 王燁·今日頭條基礎(chǔ)數(shù)據(jù)平臺(tái)架構(gòu)師 什么時(shí)候需要建設(shè)基礎(chǔ)數(shù)據(jù)平臺(tái)？對(duì)于初創(chuàng)公司來(lái)講，核心是服務(wù)好用戶，做好產(chǎn)品功能的迭代。當(dāng)公司發(fā)展到一定階段，業(yè)務(wù)開始多元化并開始精細(xì)化運(yùn)營(yíng)，數(shù)據(jù)需求變多，產(chǎn)生的數(shù)據(jù)量和數(shù)據(jù)處理復(fù)雜度也大幅增加，這時(shí)就該建設(shè)基礎(chǔ)數(shù)據(jù)平臺(tái)了。王燁介紹，2014年的頭條每天只有幾百萬(wàn)活躍用戶，支撐好產(chǎn)品是首要任務(wù)，并沒(méi)有專門的人負(fù)責(zé)做數(shù)據(jù)。眾多復(fù)雜業(yè)務(wù)的上線，同步會(huì)招聘大量的PM（產(chǎn)品經(jīng)理）和運(yùn)營(yíng)。基于刻到骨子里的數(shù)據(jù)驅(qū)動(dòng)的思想，各種各樣的數(shù)據(jù)需求源源不斷的被提上來(lái)，這時(shí)不再是幾個(gè)數(shù)據(jù)工程師單打獨(dú)斗就能解決問(wèn)題了，而讓PM和運(yùn)營(yíng)直接分析數(shù)據(jù)的門檻也很高。面對(duì)這些情況，頭條的做法是成立數(shù)據(jù)平臺(tái)團(tuán)隊(duì)，把數(shù)據(jù)基礎(chǔ)設(shè)施像Hadoop、Hive、Spark、Kylin等封裝成工具，把這些工具結(jié)合通用的分析模式整合成完整的解決方案，再把這些解決方案通過(guò)平臺(tái)的形式，提供給業(yè)務(wù)部門使用。數(shù)據(jù)平臺(tái)也有一個(gè)演進(jìn)的過(guò)程，并不需要追求從開始就大而全，不同階段采用的技術(shù)能匹配當(dāng)時(shí)需求就好。 基礎(chǔ)數(shù)據(jù)平臺(tái)的職責(zé)什么？推薦業(yè)務(wù)是頭條最重要的業(yè)務(wù)之一，從其需求出發(fā)，搭建面向全公司的通用數(shù)據(jù)平臺(tái)。用戶數(shù)據(jù)（內(nèi)容偏愛、行為軌跡、閱讀時(shí)間等）是頭條最龐大的數(shù)據(jù)源，這些被記錄下來(lái)的數(shù)據(jù)反映了用戶的興趣，會(huì)以各種形式傳輸和存儲(chǔ)，并提供給全公司各個(gè)業(yè)務(wù)系統(tǒng)來(lái)調(diào)用。還要維護(hù)面向RD（分析師）數(shù)據(jù)工具集（日志收集、入庫(kù)、調(diào)度、依賴管理、查詢、元數(shù)據(jù)、報(bào)表），面向PM、運(yùn)營(yíng)的通用用戶行為分析平臺(tái)，底層查詢引擎（Hive, Presto, Kylin等OLAP查詢引擎，支撐上層數(shù)據(jù)平臺(tái)和數(shù)據(jù)倉(cāng)庫(kù)），平臺(tái)基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)及協(xié)助維護(hù)業(yè)務(wù)部門數(shù)據(jù)倉(cāng)庫(kù)。 建設(shè)基礎(chǔ)數(shù)據(jù)平臺(tái)需要面臨哪些挑戰(zhàn)？數(shù)據(jù)生命周期分為生成、傳輸、入庫(kù)和統(tǒng)計(jì)/分析/挖掘，每個(gè)環(huán)節(jié)的難度都會(huì)隨著數(shù)據(jù)規(guī)模的變大而上升。當(dāng)前，頭條每日處理數(shù)據(jù)量為7.8PB、訓(xùn)練樣本量200億條、服務(wù)器總量40000臺(tái)、Hadoop節(jié)點(diǎn)3000臺(tái)。龐大數(shù)據(jù)量和業(yè)務(wù)復(fù)雜度給數(shù)據(jù)生成、采集、傳輸、存儲(chǔ)和計(jì)算等帶來(lái)的一系列問(wèn)題是平臺(tái)建設(shè)要克服的挑戰(zhàn)。 數(shù)據(jù)生成與采集——SDK、用戶埋點(diǎn) 一般情況下，數(shù)據(jù)生成與采集是很簡(jiǎn)單的事，但對(duì)于頭條這個(gè)功能眾多的APP來(lái)講，難點(diǎn)就在于每個(gè)功能背后都是一個(gè)團(tuán)隊(duì)獨(dú)立運(yùn)營(yíng)。如果每個(gè)團(tuán)隊(duì)都用自研的數(shù)據(jù)采集的方法，那會(huì)給后續(xù)的進(jìn)程帶來(lái)巨大的困擾。那怎么辦呢？王燁介紹了他們分析和決策的過(guò)程，頭條屬于C端業(yè)務(wù)公司，主要以日志形式為主，數(shù)據(jù)的主要來(lái)源是用戶行為，那么就以采用事件模型來(lái)描述日志，以SDK形式接入，支持客戶端、服務(wù)端埋點(diǎn)。這里需要注意的是：數(shù)據(jù)質(zhì)量很重要，埋點(diǎn)規(guī)范趁早確立，臟數(shù)據(jù)是不可避免的，可以引入必要的約束、清洗等。 埋點(diǎn)就是用戶在使用某一個(gè)功能時(shí)，產(chǎn)生的一段數(shù)據(jù)。頭條初期，埋點(diǎn)由各業(yè)務(wù)場(chǎng)景自定義日志格式，之后埋點(diǎn)統(tǒng)一到事件模型，保證了信息的結(jié)構(gòu)化和自描述，降低了后續(xù)使用成本，并復(fù)用統(tǒng)一的解析和清洗流程、數(shù)據(jù)倉(cāng)庫(kù)的入庫(kù)和行為分析平臺(tái)的導(dǎo)入。埋點(diǎn)的管理，也由通過(guò)文檔、Wiki等方式演進(jìn)成埋點(diǎn)管理系統(tǒng)，覆蓋整個(gè)埋點(diǎn)生命周期。這樣一來(lái)，也得到了埋點(diǎn)元信息的描述，后續(xù)可應(yīng)用在數(shù)據(jù)清洗、分析平臺(tái)等場(chǎng)景，同時(shí)埋點(diǎn)的上線流程實(shí)現(xiàn)標(biāo)準(zhǔn)化，客戶端也可進(jìn)行自動(dòng)化測(cè)試。 數(shù)據(jù)平臺(tái)實(shí)現(xiàn)了通用的客戶端埋點(diǎn)SDK和服務(wù)端埋點(diǎn)SDK，放棄之前按約定生成數(shù)據(jù)的方式，可以保證生成的日志符合埋點(diǎn)規(guī)范，并統(tǒng)一App啟動(dòng)、設(shè)備標(biāo)識(shí)等的基本口徑，也減少了新App適配成本。對(duì)數(shù)據(jù)的描述由使用JSON改為Protobuf，這樣就可通過(guò)IDL實(shí)現(xiàn)強(qiáng)制約束，包括數(shù)據(jù)類型、字段命名等。 除了日志數(shù)據(jù)，關(guān)系數(shù)據(jù)庫(kù)中的數(shù)據(jù)也是數(shù)據(jù)分析的重要來(lái)源。頭條在數(shù)據(jù)的采集方式上，用Spark實(shí)現(xiàn)類Sqoop的分布式抓取替代了早期定期用單機(jī)全量抓取Mysql數(shù)據(jù)表的方式，有效的提升了抓取速度，突破了單機(jī)瓶頸。再之后為了減少M(fèi)ysql壓力，選用Canal來(lái)接收Mysql binlog，離線merge出全量表，這樣就不再直接讀Mysql了，而且對(duì)千萬(wàn)/億級(jí)大表的處理速度也會(huì)更快
數(shù)據(jù)傳輸——Kafka做消息總線 連接在線和離線系統(tǒng) 數(shù)據(jù)在客戶端向服務(wù)端回傳或者直接在服務(wù)端產(chǎn)生時(shí)，可以認(rèn)為是在線狀態(tài)。當(dāng)數(shù)據(jù)落地到統(tǒng)計(jì)分析相關(guān)的基礎(chǔ)設(shè)施時(shí)，就變成離線的狀態(tài)了。在線系統(tǒng)和離線系統(tǒng)采用消息隊(duì)列來(lái)連接。頭條的數(shù)據(jù)傳輸以以Kafka作為數(shù)據(jù)總線，所有實(shí)時(shí)和離線數(shù)據(jù)的接入都要通過(guò)Kafka，包括日志、binlog等。王燁提醒，這里值得注意的是：盡早引入消息隊(duì)列，與業(yè)務(wù)系統(tǒng)解耦。 頭條的數(shù)據(jù)基礎(chǔ)設(shè)施以社區(qū)開源版本作為基礎(chǔ)，并做了大量的改進(jìn)，也回饋給了社區(qū)，同時(shí)還有很多自研的組件。因?yàn)橐阅壳暗臄?shù)據(jù)和集群規(guī)模，直接使用社區(qū)版本乃至企業(yè)版的產(chǎn)品，都會(huì)遇到大量困難。像數(shù)據(jù)接入，就自研Databus，作為單機(jī)Agent，封裝Kafka寫入，提供異步寫入、buffer、統(tǒng)一配置等f(wàn)eature。 Kafka數(shù)據(jù)通過(guò)Dump落地到HDFS，供后續(xù)離線處理使用。隨著數(shù)據(jù)規(guī)模的增加，Dump的實(shí)現(xiàn)也經(jīng)歷了幾個(gè)階段。最初實(shí)現(xiàn)成的是類似Flume模式的單機(jī)上傳，很快遇到了瓶頸，實(shí)現(xiàn)改成了通過(guò)Storm來(lái)實(shí)現(xiàn)多機(jī)分布式的上傳，支持的數(shù)據(jù)吞吐量大幅增加?，F(xiàn)在開發(fā)了一個(gè)叫DumpService的服務(wù)，作為托管服務(wù)方便整合到平臺(tái)工具上，底層實(shí)現(xiàn)切換到了Spark Streaming，并實(shí)現(xiàn)了exactly-once語(yǔ)義，保證Dump數(shù)據(jù)不丟不重。 數(shù)據(jù)入庫(kù)——數(shù)據(jù)倉(cāng)庫(kù)、ETL（抽取轉(zhuǎn)換加載） 頭條的數(shù)據(jù)源很復(fù)雜，直接拿來(lái)做分析并不方便。但是到數(shù)據(jù)倉(cāng)庫(kù)這一層級(jí)，會(huì)通過(guò)數(shù)據(jù)處理的過(guò)程，也就是ETL，把它建設(shè)成一個(gè)層次完備的適合分析的一個(gè)個(gè)有價(jià)值的數(shù)倉(cāng)。在數(shù)倉(cāng)之上，就可以讓數(shù)據(jù)分析師和數(shù)據(jù)RD通過(guò)SQL和多維分析等更高效的手段使用數(shù)據(jù)。 數(shù)據(jù)倉(cāng)庫(kù)中數(shù)據(jù)表的元信息都放在Hive metastore里，數(shù)據(jù)表在HDFS上的存儲(chǔ)格式以Parquet為主，這是一種列式存儲(chǔ)格式，對(duì)于嵌套數(shù)據(jù)結(jié)構(gòu)的支持也很好。 頭條有多種ETL的實(shí)現(xiàn)模式在并存，對(duì)于底層數(shù)據(jù)構(gòu)建，一種選擇是使用Python通過(guò)Hadoop Streaming來(lái)實(shí)現(xiàn)Map Reduce的任務(wù)，但現(xiàn)在更傾向于使用Spark直接生成Parquet數(shù)據(jù)，Spark相比MapReduce有更豐富的處理原語(yǔ)，代碼實(shí)現(xiàn)可以更簡(jiǎn)潔，也減少了中間數(shù)據(jù)的落地量。對(duì)于高層次的數(shù)據(jù)表，會(huì)直接使用Hive SQL來(lái)描述ETL過(guò)程。 數(shù)據(jù)計(jì)算——計(jì)算引擎的演進(jìn) 數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)表如何能被高效的查詢很關(guān)鍵，因?yàn)檫@會(huì)直接關(guān)系到數(shù)據(jù)分析的效率。常見的查詢引擎可以歸到三個(gè)模式中，Batch類、MPP類、Cube類，頭條在3種模式上都有所應(yīng)用。 頭條最早使用的查詢引擎是Infopight，Infopight可以認(rèn)為是支持了列式存儲(chǔ)的Mysql，對(duì)分析類查詢更友好，但I(xiàn)nfopight只支持單機(jī)。隨著數(shù)據(jù)量的增加，很快換成了Hive，Hive是一個(gè)很穩(wěn)定的選擇，但速度一般。為了更好的支持Adhoc交互式查詢，頭條開始調(diào)研MPP類查詢引擎，先后使用過(guò)Impala和Presto，但在頭條的數(shù)據(jù)量級(jí)下都遇到了穩(wěn)定性的問(wèn)題。頭條現(xiàn)在的方案是混合使用Spark SQL和Hive，并自研QAP查詢分析系統(tǒng)，自動(dòng)分析并分發(fā)查詢SQL到適合的查詢引擎。在Cube類查詢引擎上，頭條采用了Kylin，現(xiàn)在也是Kylin在國(guó)內(nèi)最大的用戶之一。 數(shù)據(jù)中心——為業(yè)務(wù)的數(shù)據(jù)分析提供整體解決方案 對(duì)于大部分需求相對(duì)簡(jiǎn)單的公司來(lái)說(shuō)，數(shù)據(jù)最終可以產(chǎn)出報(bào)表就夠用了，如做一個(gè)面向管理層的報(bào)表，可以讓老板直觀的了解一些關(guān)鍵性指標(biāo)，這是最基礎(chǔ)的數(shù)據(jù)應(yīng)用模式。再深入一點(diǎn)，就需要匯總各種來(lái)源的業(yè)務(wù)數(shù)據(jù)，提供多種維度和指標(biāo)來(lái)進(jìn)行更深入的探索型分析，得到的結(jié)論用來(lái)指導(dǎo)產(chǎn)品的迭代和運(yùn)營(yíng)。王燁表示，頭條絕大部分業(yè)務(wù)都是數(shù)據(jù)驅(qū)動(dòng)的，都需要產(chǎn)出和分析大量的數(shù)據(jù)，這就或多或少需要用到平臺(tái)的提供的系列工具。 頭條開發(fā)了一套叫數(shù)據(jù)門戶的平臺(tái)系統(tǒng)，提供給業(yè)務(wù)部門使用，對(duì)數(shù)據(jù)生命周期各個(gè)環(huán)節(jié)都提供了相應(yīng)支持。數(shù)據(jù)門戶提供的工具都是聲明式的，也就是讓使用者只需要說(shuō)明要實(shí)現(xiàn)什么目的，具體實(shí)現(xiàn)的復(fù)雜細(xì)節(jié)都隱藏起來(lái)，對(duì)使用者更友好。通過(guò)這些工具，可以讓業(yè)務(wù)部門的RD、分析師、PM等將精力放在業(yè)務(wù)分析本身，而不是去學(xué)習(xí)大量數(shù)據(jù)基礎(chǔ)設(shè)施的使用方法。
|
|
|
