微店的大數(shù)據(jù)平臺建設實踐與探討

微店是全球領先的移動電商網(wǎng)絡，創(chuàng)造了一個便利的手機購物環(huán)境，目前有超過3000萬的店主使用微店銷售商品。微店大數(shù)據(jù)架構師王鋒，將重點描述大數(shù)據(jù)處理平臺中數(shù)據(jù)采集、傳輸、存儲、分析過程中的公共基礎技術部分。

“人類正從IT時代走向DT時代”，2014年三月在北京舉行的一場大數(shù)據(jù)產(chǎn)業(yè)推介會上，阿里巴巴集團創(chuàng)始人馬云在主題演講中發(fā)表了他的這一觀點。這個觀念提法很快就被廣泛傳播開來，并被人們所接受。這里筆者不準備大談DT時代，但是相信DT時代一定是以數(shù)據(jù)處理為核心的，因此大數(shù)據(jù)技術在這里有至關重要的地位，很有幸筆者及各位看官正在這個領域努力。

曾看到一篇文章，里面有個觀點，“DT時代的骨骼——大數(shù)據(jù)處理平臺”，反映了大數(shù)據(jù)處理平臺在互聯(lián)網(wǎng)或者移動互聯(lián)網(wǎng)公司的重要性。大數(shù)據(jù)處理平臺其實包含了整個大數(shù)據(jù)處理過程，它承載了從數(shù)據(jù)采集、傳輸、存儲、分析挖掘（離線 OR、實時 OR、即席查詢）、可視化、價值體現(xiàn)的整體流程。這些在大的互聯(lián)網(wǎng)公司，尤其以BAT為首，已經(jīng)逐步成熟，而且價值體現(xiàn)不斷放大。而在初創(chuàng)公司或者具有一定規(guī)模的創(chuàng)業(yè)公司，大數(shù)據(jù)處理平臺的基礎設施或開始搭建，或處于較初始的狀態(tài)，或者在逐步規(guī)范中?？赡苡腥藭辛硗獾南敕ǎ何覀児疽?guī)模沒有那么大，有必要整這么一套么？是的，如果數(shù)據(jù)量很小，每天新增數(shù)據(jù)（比如應用日志）都是MB級別，或者GB級別，而以后也不會有爆發(fā)式增長，也沒必要太折騰。無論如何，有一個趨勢非常明確，隨著公司業(yè)務發(fā)展，數(shù)據(jù)量的爆發(fā)式增長，大數(shù)據(jù)處理平臺的建設勢在必行。

大數(shù)據(jù)處理平臺建設是對數(shù)據(jù)采集、數(shù)據(jù)傳輸、存儲、分析挖掘（離線 OR 實時 OR 即席查詢）、數(shù)據(jù)展現(xiàn)、價值體現(xiàn)的整體流程梳理。微店是目前全球領先的移動電商網(wǎng)絡（在微店生態(tài)體系，公司旗下還有口袋購物、微店全球購、微店買家版、今日半價、YouShop等5大優(yōu)勢平臺），創(chuàng)造了一個便利的手機購物環(huán)境，是全球年輕人喜愛的移動購物網(wǎng)絡。目前有超過3000萬的店主使用微店銷售商品，在這樣的背景下，技術部門開發(fā)部署的各種應用每天需要服務巨量日志數(shù)據(jù)，這些數(shù)據(jù)既包含用戶的行為特征、興趣愛好，也包含了應用的服務質(zhì)量情況，這些都是要進行深度分析發(fā)掘的數(shù)據(jù)，重要性不言而喻?；诖耍撠煷髷?shù)據(jù)基礎設施建設的我們承擔起了大數(shù)據(jù)處理平臺的建設任務，為業(yè)務分析部門提供公共基礎支撐。接下來，本文將重點描述大數(shù)據(jù)處理平臺中數(shù)據(jù)采集、傳輸、存儲、分析過程中的公共基礎技術部分。

什么是數(shù)據(jù)集

隨著業(yè)務的爆發(fā)式增長，公司部署了各種各樣的應用服務，新的服務也不斷被開發(fā)出來。日志數(shù)據(jù)由應用服務產(chǎn)生，應用服務由業(yè)務開發(fā)人員開發(fā)，由業(yè)務運維人員部署維護；分析挖掘這些數(shù)據(jù)的是數(shù)據(jù)分析人員、推薦算法開發(fā)人員等等，在實際工作過程中，由于各方關注角度不同，帶來很多不必要的溝通交流成本。數(shù)據(jù)集（DATASET）正是為了在數(shù)據(jù)采集、傳輸、存儲、分析過程中，數(shù)據(jù)關聯(lián)各方對目標數(shù)據(jù)有統(tǒng)一的稱謂、同時規(guī)范數(shù)據(jù)的使用。

圖1 數(shù)據(jù)集的一些重要屬性

圖1顯示了數(shù)據(jù)集的一些重要屬性，原則上由業(yè)務開發(fā)部門申請創(chuàng)建新的數(shù)據(jù)集，申請者作為數(shù)據(jù)的owner，同時標識出其所屬產(chǎn)品線、項目、數(shù)據(jù)類型，擬采用的數(shù)據(jù)收集方式、存儲方式，數(shù)據(jù)規(guī)模情況預估以及要存儲的時間。其中數(shù)據(jù)類型包含www日志（access log）、應用日志、錯誤日志、MySQL日志等等；數(shù)據(jù)收集包括：Agent實時收集、Rsync傳輸、HdfsClient上傳、API推送；存儲方式分為：HDFS、分布式消息隊列Kafka、實時數(shù)據(jù)搜索Elasticsearch、第三方存儲；數(shù)據(jù)規(guī)模預估可以對要收集的數(shù)據(jù)規(guī)模進行評估，傳輸層及存儲層是否可以承載的一個初步判斷。存儲時間確定該數(shù)據(jù)集保存時間，到期后由平臺方對數(shù)據(jù)集統(tǒng)一清理。

在數(shù)據(jù)集創(chuàng)建后，由數(shù)據(jù)采集端采集，經(jīng)由數(shù)據(jù)傳輸層進入數(shù)據(jù)存儲層。在這個過程中，category是數(shù)據(jù)集的一個代名詞。category最初是Facebook開源的scribe配置中一個很重要的屬性，標識數(shù)據(jù)傳輸對象，這里我們沿用了這個單詞，并從開始到存儲落地全程被攜帶。

數(shù)據(jù)集的劃分是很重要的一個過程，決定了數(shù)據(jù)如何傳輸、存儲，并被如何分析處理。一般由業(yè)務部門及分析部門確定。數(shù)據(jù)集內(nèi)數(shù)據(jù)格式應一致，方便進行處理。但在實際場景下，尤其創(chuàng)業(yè)公司，單個業(yè)務部門內(nèi)數(shù)據(jù)格式也未必統(tǒng)一，數(shù)據(jù)散落在多個日志文件中，單個體積相對較小，而分析人員也會關注這些數(shù)據(jù)，這種情況下為了方便處理，可以將這些劃分到一個數(shù)據(jù)集下，同時在采集端對數(shù)據(jù)進行標注。典型方法，如在實時采集時日志行中加入header，由文件名或者其他特征區(qū)分數(shù)據(jù)。就像萬事萬物有其生命規(guī)律一樣，數(shù)據(jù)集也不例外。圖2描述了數(shù)據(jù)集的生命周期。

圖2 數(shù)據(jù)集的生命周期

數(shù)據(jù)采集層

某一天，一個分析人員興沖沖過來，“某某某，我要分析xxx服務打出的日志，xxx服務昨天上線了，這個需求非常重要，balabalabala……”。然后我們告訴他，讓業(yè)務開發(fā)部門申請個數(shù)據(jù)集吧，數(shù)據(jù)集傳輸過來你就可以分析了：）。

數(shù)據(jù)集在創(chuàng)建后，所屬產(chǎn)品線、項目、數(shù)據(jù)類型，擬采用的數(shù)據(jù)收集方式、存儲方式，數(shù)據(jù)規(guī)模情況預估以及要存儲的時間一一確定。以Agent實時采集為例，數(shù)據(jù)采集流程如圖3所示。

圖3 數(shù)據(jù)采集流程

• 由業(yè)務開發(fā)部門申請數(shù)據(jù)集
• 大數(shù)據(jù)組發(fā)布DataAgent
• 業(yè)務運維人員在業(yè)務機器部署DataAgent
• DataAgent采集數(shù)據(jù)并傳輸

目前大部分業(yè)務的日志數(shù)據(jù)采用這種方式采集。DataAgent基于Flume實現(xiàn)，自開發(fā)Flume插件Tailsource支持多數(shù)據(jù)集、多文件實時tail，DataAgent具有以下特性：

• 支持數(shù)據(jù)集(category)配置，支持同時tail多個數(shù)據(jù)文件
• 支持checkpoint，定期（默認10s）將讀出的文件offset寫入本地磁盤
• 開發(fā)限速模塊，可配置，支持在特殊場景下的限速傳輸
• 支持按照文件名tail文件，同時支持根據(jù)inode文件查找
• 支持文件軟連接，在軟連接改變后讀取源日志文件剩余內(nèi)容
• 修改Flume源碼支持將Event Header寫入原始數(shù)據(jù)中
• 借鑒美團DualChannel，開發(fā)了我們自己的DualChannel，支持MemChannel+FileChannel。
• 支持Kafkachannel，并修改kafkachannel源碼，支持將原始數(shù)據(jù)寫入Kafka，對業(yè)務分析程序透明
• Agent自維護及智能升級
• Agent端將監(jiān)控指標發(fā)到指定ganglia監(jiān)控端口，統(tǒng)一由監(jiān)控層收集，支持數(shù)據(jù)比對，并支持根據(jù)應用參數(shù)設置報警。

DataAgent采集方式具體使用Flume，何種channel由數(shù)據(jù)類型、存儲方式、數(shù)據(jù)量及業(yè)務場景綜合確定。根據(jù)我們的測試，單個Agent，MemoryChannel在很多場景下，都可以達到6w+/s；KafkaChannel可以到到2.5w-3w+每秒，而FileChannel最高在1w/s，有些場景下甚至在5000/s以下。對應用日志，我們需要保證數(shù)據(jù)的高可靠性傳輸，同時需要保證效率，所以目前大量采用tailsource+Kafkachannel方式；而訪問日志主要采用tailsource+DualChannel+AVROSink方式。

一些業(yè)務數(shù)據(jù)也會采用Rsync方式（存儲方式僅限于HDFS存儲）：在數(shù)據(jù)集確定后，大數(shù)據(jù)組分配rsync權限，由業(yè)務運維人員使用Rsync經(jīng)過中間LVS層，將數(shù)據(jù)推送到databus指定的Rsync model（由category確定），最后由自開發(fā)的HADOOPLoader組件upload到HDFS。

采集層支持API推送，一些少量數(shù)據(jù)場景下，業(yè)務端可以直接調(diào)用我們提供的數(shù)據(jù)API，將數(shù)據(jù)直接寫入KAFKA。

另外支持業(yè)務端直接使用HDFSClient寫入HDFS，這種方式目前主要存在于以前遺留的一些數(shù)據(jù)收集上。因為Hadoop集群使用白名單方式對寫入端IP進行授權，如果存在大量的這類客戶端，會嚴重降低數(shù)據(jù)的傳輸效率，同時提高了客戶端的維護成本。

數(shù)據(jù)傳輸層

業(yè)務運維人員部署DataAgent，或者其他收集方式后，數(shù)據(jù)集進入數(shù)據(jù)傳輸層。圖4是數(shù)據(jù)傳輸層的整體架構。

圖4 數(shù)據(jù)傳輸層的整體架構

DataBus統(tǒng)一負責對數(shù)據(jù)集的中間層傳輸、數(shù)據(jù)流轉(zhuǎn)及數(shù)據(jù)落地，數(shù)據(jù)從業(yè)務端機器發(fā)出后中間經(jīng)過LVS負載均衡層，進入Databus。Databus由幾部分組成，包括：

• 基于Flume的Avro數(shù)據(jù)接收層，接收Agent端AvroSink發(fā)出的數(shù)據(jù)；
• 使用KafkaChannel實時消費Kafka數(shù)據(jù)；
• 接收syslog收集方式傳入的數(shù)據(jù)，如交換機日志；
• HadoopLoader接收Rsync傳入的數(shù)據(jù)寫入HDFS；
• 接收API post的數(shù)據(jù)

支持的存儲方式包括：

• HDFS存儲集群
• Kafka分布式消息隊列
• Elasticsearch集群
• 第三方存儲

其中，數(shù)據(jù)寫入Kafka的topic由數(shù)據(jù)集（或者category）唯一確定，分析開發(fā)人員在自己的kafka consumer端配置topic為category即可消費數(shù)據(jù)。

對于向Elasticsearch的寫入格式化數(shù)據(jù)需求，在Databus端，我們提供了具有較強通用性的支持。基于Flume ElasticsearchSink，修改源碼，支持正則及分隔符的字段切割，并可配置，將Databus傳輸過來的數(shù)據(jù)集原始數(shù)據(jù)，根據(jù)配置的解析方式及字段，格式化數(shù)據(jù)為結構化數(shù)據(jù)適配Elasticsearch，寫入ES集群。

除訪問日志及應用日志以外，Databus支持以syslog方式收集網(wǎng)絡設備數(shù)據(jù)。交換機設備的穩(wěn)定對業(yè)務服務至關重要。以前我們?nèi)狈粨Q機的監(jiān)控，在6月底，我們專門對公司內(nèi)各機房幾乎所有交換機以syslog方式收集設備日志到Kafka，并對日志進行實時分析，發(fā)現(xiàn)異常及時報警。

絕大部分數(shù)據(jù)需要寫入HDFS數(shù)據(jù)長時間存儲。我們使用改造后Flume HdfsSink寫入HDFS。原生的HdfsSink有一些缺點，我們對部分源碼進行改造：

• 在我們的場景中，單個機器上多個HdfsSink進程有出現(xiàn)文件同名的風險，修改其源碼，在目前filepath+fileprefix+時間戳+filesuffix基礎上，在時間戳及filesuffix之間增加4位隨機數(shù)，使用過程中沒有再出現(xiàn)文件同名情況。
• HdfsSink在解析filepath及fileprefix過程中使用正則matcher去匹配，并且在每個Event處理過程中都會走這個過程，效率很低（對正則解析代碼段單獨測試500w event，正則解析代碼段耗時53s），因為我們寫入HDFS時按照數(shù)據(jù)集統(tǒng)一存儲規(guī)范寫入，所以將路徑解析重寫優(yōu)化，并增加自己的配置屬性，優(yōu)化后，寫入HDFS效率提升40%以上（lzo壓縮）。
• 寫入HDFS統(tǒng)一使用lzo方式寫入，達到一定大小或者超過配置時間進行回滾。

目前Databus寫入HDFS或者Kafka配置比較繁瑣，后面需要針對此進行優(yōu)化。

HadoopLoader是我們自行開發(fā)的組件，用以定期掃描Rsync推送過來的本地磁盤數(shù)據(jù)集存儲目錄，根據(jù)統(tǒng)一存儲規(guī)范上傳至HDFS。簡單流程如下：

• 對每個數(shù)據(jù)集在內(nèi)存中維護一個uploadingQueue。掃描線程發(fā)現(xiàn)待上傳文件后，驗證文件是否完整（根據(jù)對應md5驗證碼確定），然后將此文件加入此Queue。
• 上傳線程從Queue中拿要上傳的文件，從本地磁盤mv到uploading目錄下，并上傳。
• 上傳結束，將已上傳文件mv到本地磁盤done目錄下。同時將本次上傳文件路徑，所屬數(shù)據(jù)集、大小、md5驗證碼、上傳時間、HDFS路徑等信息入庫。

客戶端使用API post數(shù)據(jù)目前還在開發(fā)驗證階段，暫時不便透漏更多。Databus支持向第三方轉(zhuǎn)發(fā)，基于Flume replica策略配置實現(xiàn)。

數(shù)據(jù)存儲及分析層

上文已經(jīng)提到，數(shù)據(jù)集在Databus中支持向HDFS、Kafka、Elasticsearch寫入數(shù)據(jù)。這里主要對HDFS存儲及公共分析平臺搭建重點介紹。

對于海量數(shù)據(jù)的分布式存儲，Hadoop/HDFS已經(jīng)成為事實標準，目前不僅在各大互聯(lián)網(wǎng)公司，甚至在電信領域以及銀行也都開始陸續(xù)落地。Hadoop2對比Hadoop1，無論在HA、namenode擴展性、權限控制、資源調(diào)度及分配、資源隔離等都有極大提升。目前我們使用Hadoop 2.6.0作為公司最新集群使用版本，并對已知的重要bug打了patch。

相信在很多公司，尤其是創(chuàng)業(yè)型公司，初期業(yè)務快速擴張，為了方便，內(nèi)部存在多個集群，且集群規(guī)?？赡芏疾皇呛艽螅鳂I(yè)務使用的集群版本可能也不一樣，相互依賴也很少。初期的散列部署結構，可以輕松應對業(yè)務的迅速發(fā)展。隨著業(yè)務的逐步發(fā)展，各個業(yè)務部門數(shù)據(jù)共享需求越來越強烈，同時數(shù)據(jù)依賴關系也越來越復雜，分析數(shù)據(jù)中集群間數(shù)據(jù)來回搬動越來越多，同時隨著數(shù)據(jù)量的迅速猛增，各集群存儲空間壓力加大，這時集群間資源整合就越來越必要，散列的集群部署結構阻礙了數(shù)據(jù)的共享，增加了數(shù)據(jù)處理過程外的許多數(shù)據(jù)遷移環(huán)節(jié)，降低了數(shù)據(jù)處理的性能，并且不利于集群資源的最大化利用，集群管理成本太高。曾見到有個業(yè)務每天將近20個TB的數(shù)據(jù)在多個集群間來回折騰的案例（并非多機房災備），十分典型。

在微店同樣如此，單個機房內(nèi)存在著若干個大大小小的集群，集群規(guī)模在幾個節(jié)點到近百個節(jié)點不等，最小規(guī)模才4個節(jié)點，版本也不近相同。資源整合尤為重要，同時兼顧各業(yè)務部門的效率。為大家謀福利，才能更好的推進資源整合工作。在實際整合過程中，集群不同的業(yè)務處理類型，計算引擎，決定如何去資源整合。我們整合的原則是存儲共享優(yōu)先，計算類型分類，兼顧特殊業(yè)務需求。在此原則下，我們多個集群將共享統(tǒng)一的HDFS存儲資源，解決數(shù)據(jù)來回搬運的問題，同時各個集群統(tǒng)一版本，方便集群管理；按照計算類型進行整合，整合后將會有：

• 公共計算集群，負責MR、Hive、Pig、Streaming作業(yè)的處理；
• Spark集群，對內(nèi)存資源需求大，專門跑Spark作業(yè)；
• GPU集群，負責高性能計算；
• UDC集群，專門處理領導關心的時間要求高的業(yè)務指標數(shù)據(jù)報表。

整合后，集群使用統(tǒng)一的HDFS集群（規(guī)模300個節(jié)點），各計算集群物理隔離，服務器類型單獨配置，有利于成本節(jié)約。

存儲共享后，數(shù)據(jù)的存儲規(guī)范、數(shù)據(jù)安全訪問、讀寫權限規(guī)范等亟待建立。同時需要有統(tǒng)一的供數(shù)據(jù)分析開發(fā)人員使用的大數(shù)據(jù)處理平臺Portal，作為唯一的用戶授權、元數(shù)據(jù)訪問、提交并管理作業(yè)、權限申請、集群資源使用情況查詢、資源限額等等功能的入口。圖5是對資源整合后的數(shù)據(jù)存儲及分析處理流程簡圖。

圖5 資源整合后的數(shù)據(jù)存儲及分析處理流程

分析開發(fā)人員由統(tǒng)一Portal訪問大數(shù)據(jù)基礎資源，支持用戶對有權限的數(shù)據(jù)集查詢數(shù)據(jù)集屬性信息、數(shù)據(jù)集數(shù)據(jù)；按條件查找數(shù)據(jù)集、權限申請；支持權限的精細化管理（如業(yè)務組內(nèi)權限分配）；作業(yè)管理（提交、運行、停止離線OR實時分析任務、Spark作業(yè)等等）、數(shù)據(jù)流轉(zhuǎn)關系；查看資源使用情況報表等等。提交的作業(yè)由作業(yè)調(diào)度中心進行調(diào)度；支持公共UDF類庫。元數(shù)據(jù)管理提供對業(yè)務數(shù)據(jù)倉庫元數(shù)據(jù)的共享支持。

當前情況下，存在著很多客戶機（任務提交機），用來提交作業(yè)?？蛻魴C必須經(jīng)過平臺管理方授權才可訪問集群。

分析開發(fā)人員對數(shù)據(jù)集進行分析處理，需要經(jīng)過數(shù)據(jù)集或Hive庫表的授權，并提交到指定的隊列（由集群管理房提前建立，對分析人員透明）。主要包括：

1.客戶機授權。訪問Hadoop集群的服務器稱為客戶機，授權才能訪問。

2.用戶及用戶組。當前賬號沿用Linux的user及group；將來會使用LDAP；用戶組按照業(yè)務部門或產(chǎn)品線劃分，靈活支持業(yè)務方的權限需求。

3.數(shù)據(jù)集授權。對數(shù)據(jù)集有讀/寫權限才可進行相應操作（得益于hadoop2.4新增的acl特性）。

3-1. 原始數(shù)據(jù)：Owner為超級管理員，業(yè)務部門只允許有讀權限；生命周期由超級管理員統(tǒng)一管理。

3-2. 歸檔數(shù)據(jù)：為老數(shù)據(jù)(>6month)，統(tǒng)一使用LZMA壓縮，提高壓縮比。

3-3. 結果數(shù)據(jù)：Owner為業(yè)務方，建議使用統(tǒng)一存儲結構統(tǒng)一管理。

3-4. 用戶目錄：Owner為業(yè)務方，采用容量配額管理。

3-5. tmp目錄：都可讀寫，存放臨時數(shù)據(jù)，由管理方定時清理。

4. Hive服務授權。統(tǒng)一的Hive MetaStore服務，按照業(yè)務部門或產(chǎn)品線對DB及表劃分權限，并配合使用HDFS授權。

5. 隊列授權。按照業(yè)務組劃分隊列，并分配資源;支持隊列嵌套?！咀ⅲ?a href='/map/hive/' style='color:#000;font-size:inherit;'>Hive原生代碼無法做到超級管理員角色，需要自行修改代碼實現(xiàn)?！?/span>

監(jiān)控層

大數(shù)據(jù)處理平臺的最后一環(huán)無疑是監(jiān)控。監(jiān)控像是我們的眼睛，無時無刻盯著大數(shù)據(jù)平臺的整個處理流程，當將要出現(xiàn)問題時觸發(fā)報警，平臺管理人員及時切入避免故障發(fā)生。我們統(tǒng)一使用Ganglia從采集端、傳輸層到存儲層、分析層的基礎資源指標、應用指標寫入Ganglia，并使用Nagios進行報警。圖6、圖7分別是平臺下各基礎組件的監(jiān)控布局及DataAgent端按業(yè)務分類監(jiān)控。

圖6 平臺下各基礎組件的監(jiān)控布局

圖7 DataAgent端按業(yè)務分類監(jiān)控

由于時間倉促，未能有更多的時間校對，文章中難免有紕漏，歡迎看官指正。另外微店正在面臨數(shù)據(jù)爆發(fā)式增長，大數(shù)據(jù)技術、Hadoop相關開發(fā)人員急缺，有志于大數(shù)據(jù)方向，并且樂于深耕的技術人，歡迎將簡歷砸來，郵箱地址：wangfeng@weidian.com。

作者簡介：王鋒。曾任職并負責新浪研發(fā)dip分析平臺架構設計、開發(fā)工作，承載了新浪及微博各產(chǎn)品線的離線、實時等各類業(yè)務分析需求。目前任職微店大數(shù)據(jù)架構師，負責微店大數(shù)據(jù)（hadoop）基礎技術架構及服務運營，并負責完成業(yè)務類及運維類指標分析需求，逐步構建微店的監(jiān)控分析平臺。