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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

另外支持業(yè)務(wù)端直接使用HDFSClient寫入HDFS，這種方式目前主要存在于以前遺留的一些數(shù)據(jù)收集上。因?yàn)?a href='/map/hadoop/' style='color:#000;font-size:inherit;'>Hadoop集群使用白名單方式對寫入端IP進(jìn)行授權(quán)，如果存在大量的這類客戶端，會嚴(yán)重降低數(shù)據(jù)的傳輸效率，同時提高了客戶端的維護(hù)成本。

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

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

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

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

• 基于Flume的Avro數(shù)據(jù)接收層，接收Agent端AvroSink發(fā)出的數(shù)據(jù)；
• 使用KafkaChannel實(shí)時消費(fèi)Kafka數(shù)據(jù)；
• 接收syslog收集方式傳入的數(shù)據(jù)，如交換機(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即可消費(fèi)數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.客戶機(jī)授權(quán)。訪問Hadoop集群的服務(wù)器稱為客戶機(jī)，授權(quán)才能訪問。

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

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

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

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

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

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

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

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

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

監(jiān)控層

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

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

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

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

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