“人類正從IT時(shí)代走向DT時(shí)代”，2014年三月在北京舉行的一場(chǎng)大數(shù)據(jù)產(chǎn)業(yè)推介會(huì)上，阿里巴巴集團(tuán)創(chuàng)始人馬云在主題演講中發(fā)表了他的這一觀點(diǎn)。這個(gè)觀念提法很快就被廣泛傳播開來，并被人們所接受。這里筆者不準(zhǔn)備大談DT時(shí)代，但是相信DT時(shí)代一定是以數(shù)據(jù)處理為核心的，因此大數(shù)據(jù)技術(shù)在這里有至關(guān)重要的地位，很有幸筆者及各位看官正在這個(gè)領(lǐng)域努力。
曾看到一篇文章，里面有個(gè)觀點(diǎn)，“DT時(shí)代的骨骼——大數(shù)據(jù)處理平臺(tái)”，反映了大數(shù)據(jù)處理平臺(tái)在互聯(lián)網(wǎng)或者移動(dòng)互聯(lián)網(wǎng)公司的重要性。大數(shù)據(jù)處理平臺(tái)其實(shí)包含了整個(gè)大數(shù)據(jù)處理過程，它承載了從數(shù)據(jù)采集、傳輸、存儲(chǔ)、分析挖掘（離線 OR、實(shí)時(shí) OR、即席查詢）、可視化、價(jià)值體現(xiàn)的整體流程。這些在大的互聯(lián)網(wǎng)公司，尤其以BAT為首，已經(jīng)逐步成熟，而且價(jià)值體現(xiàn)不斷放大。而在初創(chuàng)公司或者具有一定規(guī)模的創(chuàng)業(yè)公司，大數(shù)據(jù)處理平臺(tái)的基礎(chǔ)設(shè)施或開始搭建，或處于較初始的狀態(tài)，或者在逐步規(guī)范中�？赡苡腥藭�(huì)有另外的想法：我們公司規(guī)模沒有那么大，有必要整這么一套么？是的，如果數(shù)據(jù)量很小，每天新增數(shù)據(jù)（比如應(yīng)用日志）都是MB級(jí)別，或者GB級(jí)別，而以后也不會(huì)有爆發(fā)式增長(zhǎng)，也沒必要太折騰。無論如何，有一個(gè)趨勢(shì)非常明確，隨著公司業(yè)務(wù)發(fā)展，數(shù)據(jù)量的爆發(fā)式增長(zhǎng)，大數(shù)據(jù)處理平臺(tái)的建設(shè)勢(shì)在必行。
大數(shù)據(jù)處理平臺(tái)建設(shè)是對(duì)數(shù)據(jù)采集、數(shù)據(jù)傳輸、存儲(chǔ)、分析挖掘（離線 OR 實(shí)時(shí) OR 即席查詢）、數(shù)據(jù)展現(xiàn)、價(jià)值體現(xiàn)的整體流程梳理。微店是目前全球領(lǐng)先的移動(dòng)電商網(wǎng)絡(luò)（在微店生態(tài)體系，公司旗下還有口袋購(gòu)物、微店全球購(gòu)、微店買家版、今日半價(jià)、YouShop等5大優(yōu)勢(shì)平臺(tái)），創(chuàng)造了一個(gè)便利的手機(jī)購(gòu)物環(huán)境，是全球年輕人喜愛的移動(dòng)購(gòu)物網(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ù)處理平臺(tái)的建設(shè)任務(wù)，為業(yè)務(wù)分析部門提供公共基礎(chǔ)支撐。接下來，本文將重點(diǎn)描述大數(shù)據(jù)處理平臺(tái)中數(shù)據(jù)采集、傳輸、存儲(chǔ)、分析過程中的公共基礎(chǔ)技術(shù)部分。
什么是數(shù)據(jù)集
隨著業(yè)務(wù)的爆發(fā)式增長(zhǎng)，公司部署了各種各樣的應(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ù)采集、傳輸、存儲(chǔ)、分析過程中，數(shù)據(jù)關(guān)聯(lián)各方對(duì)目標(biāo)數(shù)據(jù)有統(tǒng)一的稱謂、同時(shí)規(guī)范數(shù)據(jù)的使用。
圖1 數(shù)據(jù)集的一些重要屬性
圖1顯示了數(shù)據(jù)集的一些重要屬性，原則上由業(yè)務(wù)開發(fā)部門申請(qǐng)創(chuàng)建新的數(shù)據(jù)集，申請(qǐng)者作為數(shù)據(jù)的owner，同時(shí)標(biāo)識(shí)出其所屬產(chǎn)品線、項(xiàng)目、數(shù)據(jù)類型，擬采用的數(shù)據(jù)收集方式、存儲(chǔ)方式，數(shù)據(jù)規(guī)模情況預(yù)估以及要存儲(chǔ)的時(shí)間。其中數(shù)據(jù)類型包含www日志（access log）、應(yīng)用日志、錯(cuò)誤日志、MySQL日志等等；數(shù)據(jù)收集包括：Agent實(shí)時(shí)收集、Rsync傳輸、HdfsClient上傳、API推送；存儲(chǔ)方式分為：HDFS、分布式消息隊(duì)列Kafka、實(shí)時(shí)數(shù)據(jù)搜索Elasticsearch、第三方存儲(chǔ)；數(shù)據(jù)規(guī)模預(yù)估可以對(duì)要收集的數(shù)據(jù)規(guī)模進(jìn)行評(píng)估，傳輸層及存儲(chǔ)層是否可以承載的一個(gè)初步判斷。存儲(chǔ)時(shí)間確定該數(shù)據(jù)集保存時(shí)間，到期后由平臺(tái)方對(duì)數(shù)據(jù)集統(tǒng)一清理。
在數(shù)據(jù)集創(chuàng)建后，由數(shù)據(jù)采集端采集，經(jīng)由數(shù)據(jù)傳輸層進(jìn)入數(shù)據(jù)存儲(chǔ)層。在這個(gè)過程中，category是數(shù)據(jù)集的一個(gè)代名詞。category最初是Facebook開源的scribe配置中一個(gè)很重要的屬性，標(biāo)識(shí)數(shù)據(jù)傳輸對(duì)象，這里我們沿用了這個(gè)單詞，并從開始到存儲(chǔ)落地全程被攜帶。
數(shù)據(jù)集的劃分是很重要的一個(gè)過程，決定了數(shù)據(jù)如何傳輸、存儲(chǔ)，并被如何分析處理。一般由業(yè)務(wù)部門及分析部門確定。數(shù)據(jù)集內(nèi)數(shù)據(jù)格式應(yīng)一致，方便進(jìn)行處理。但在實(shí)際場(chǎng)景下，尤其創(chuàng)業(yè)公司，單個(gè)業(yè)務(wù)部門內(nèi)數(shù)據(jù)格式也未必統(tǒng)一，數(shù)據(jù)散落在多個(gè)日志文件中，單個(gè)體積相對(duì)較小，而分析人員也會(huì)關(guān)注這些數(shù)據(jù)，這種情況下為了方便處理，可以將這些劃分到一個(gè)數(shù)據(jù)集下，同時(shí)在采集端對(duì)數(shù)據(jù)進(jìn)行標(biāo)注。典型方法，如在實(shí)時(shí)采集時(shí)日志行中加入header，由文件名或者其他特征區(qū)分?jǐn)?shù)據(jù)。就像萬事萬物有其生命規(guī)律一樣，數(shù)據(jù)集也不例外。圖2描述了數(shù)據(jù)集的生命周期。
圖2 數(shù)據(jù)集的生命周期
數(shù)據(jù)采集層
某一天，一個(gè)分析人員興沖沖過來，“某某某，我要分析xxx服務(wù)打出的日志，xxx服務(wù)昨天上線了，這個(gè)需求非常重要，balabalabala……”。然后我們告訴他，讓業(yè)務(wù)開發(fā)部門申請(qǐng)個(gè)數(shù)據(jù)集吧，數(shù)據(jù)集傳輸過來你就可以分析了：）。
數(shù)據(jù)集在創(chuàng)建后，所屬產(chǎn)品線、項(xiàng)目、數(shù)據(jù)類型，擬采用的數(shù)據(jù)收集方式、存儲(chǔ)方式，數(shù)據(jù)規(guī)模情況預(yù)估以及要存儲(chǔ)的時(shí)間一一確定。以Agent實(shí)時(shí)采集為例，數(shù)據(jù)采集流程如圖3所示。
圖3 數(shù)據(jù)采集流程
- 由業(yè)務(wù)開發(fā)部門申請(qǐng)數(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í)時(shí)tail，DataAgent具有以下特性：
- 支持?jǐn)?shù)據(jù)集(category)配置，支持同時(shí)tail多個(gè)數(shù)據(jù)文件
- 支持checkpoint，定期（默認(rèn)10s）將讀出的文件offset寫入本地磁盤
- 開發(fā)限速模塊，可配置，支持在特殊場(chǎng)景下的限速傳輸
- 支持按照文件名tail文件，同時(shí)支持根據(jù)inode文件查找
- 支持文件軟連接，在軟連接改變后讀取源日志文件剩余內(nèi)容
- 修改Flume源碼支持將Event Header寫入原始數(shù)據(jù)中
- 借鑒美團(tuán)DualChannel，開發(fā)了我們自己的DualChannel，支持MemChannel+FileChannel。
- 支持Kafkachannel，并修改kafkachannel源碼，支持將原始數(shù)據(jù)寫入Kafka，對(duì)業(yè)務(wù)分析程序透明
- Agent自維護(hù)及智能升級(jí)
- Agent端將監(jiān)控指標(biāo)發(fā)到指定ganglia監(jiān)控端口，統(tǒng)一由監(jiān)控層收集，支持?jǐn)?shù)據(jù)比對(duì)，并支持根據(jù)應(yīng)用參數(shù)設(shè)置報(bào)警。
DataAgent采集方式具體使用Flume，何種channel由數(shù)據(jù)類型、存儲(chǔ)方式、數(shù)據(jù)量及業(yè)務(wù)場(chǎng)景綜合確定。根據(jù)我們的測(cè)試，單個(gè)Agent，MemoryChannel在很多場(chǎng)景下，都可以達(dá)到6w+/s；KafkaChannel可以到到2.5w-3w+每秒，而FileChannel最高在1w/s，有些場(chǎng)景下甚至在5000/s以下。對(duì)應(yīng)用日志，我們需要保證數(shù)據(jù)的高可靠性傳輸，同時(shí)需要保證效率，所以目前大量采用tailsource+Kafkachannel方式；而訪問日志主要采用tailsource+DualChannel+AVROSink方式。
一些業(yè)務(wù)數(shù)據(jù)也會(huì)采用Rsync方式（存儲(chǔ)方式僅限于HDFS存儲(chǔ)）：在數(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ù)場(chǎng)景下，業(yè)務(wù)端可以直接調(diào)用我們提供的數(shù)據(jù)API，將數(shù)據(jù)直接寫入KAFKA。
另外支持業(yè)務(wù)端直接使用HDFSClient寫入HDFS，這種方式目前主要存在于以前遺留的一些數(shù)據(jù)收集上。因?yàn)镠adoop集群使用白名單方式對(duì)寫入端IP進(jìn)行授權(quán)，如果存在大量的這類客戶端，會(huì)嚴(yán)重降低數(shù)據(jù)的傳輸效率，同時(shí)提高了客戶端的維護(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é)對(duì)數(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í)時(shí)消費(fèi)Kafka數(shù)據(jù)；
- 接收syslog收集方式傳入的數(shù)據(jù)，如交換機(jī)日志；
- HadoopLoader接收Rsync傳入的數(shù)據(jù)寫入HDFS；
- 接收API post的數(shù)據(jù)
支持的存儲(chǔ)方式包括：
- HDFS存儲(chǔ)集群
- Kafka分布式消息隊(duì)列
- Elasticsearch集群
- 第三方存儲(chǔ)
其中，數(shù)據(jù)寫入Kafka的topic由數(shù)據(jù)集（或者category）唯一確定，分析開發(fā)人員在自己的kafka consumer端配置topic為category即可消費(fèi)數(shù)據(jù)。
對(duì)于向Elasticsearch的寫入格式化數(shù)據(jù)需求，在Databus端，我們提供了具有較強(qiáng)通用性的支持�；贔lume 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)定對(duì)業(yè)務(wù)服務(wù)至關(guān)重要。以前我們?nèi)狈?duì)交換機(jī)的監(jiān)控，在6月底，我們專門對(duì)公司內(nèi)各機(jī)房幾乎所有交換機(jī)以syslog方式收集設(shè)備日志到Kafka，并對(duì)日志進(jìn)行實(shí)時(shí)分析，發(fā)現(xiàn)異常及時(shí)報(bào)警。
絕大部分?jǐn)?shù)據(jù)需要寫入HDFS數(shù)據(jù)長(zhǎng)時(shí)間存儲(chǔ)。我們使用改造后Flume HdfsSink寫入HDFS。原生的HdfsSink有一些缺點(diǎn)，我們對(duì)部分源碼進(jìn)行改造：
- 在我們的場(chǎng)景中，單個(gè)機(jī)器上多個(gè)HdfsSink進(jìn)程有出現(xiàn)文件同名的風(fēng)險(xiǎn)，修改其源碼，在目前filepath+fileprefix+時(shí)間戳+filesuffix基礎(chǔ)上，在時(shí)間戳及filesuffix之間增加4位隨機(jī)數(shù)，使用過程中沒有再出現(xiàn)文件同名情況。
- HdfsSink在解析filepath及fileprefix過程中使用正則matcher去匹配，并且在每個(gè)Event處理過程中都會(huì)走這個(gè)過程，效率很低（對(duì)正則解析代碼段單獨(dú)測(cè)試500w event，正則解析代碼段耗時(shí)53s），因?yàn)槲覀儗懭際DFS時(shí)按照數(shù)據(jù)集統(tǒng)一存儲(chǔ)規(guī)范寫入，所以將路徑解析重寫優(yōu)化，并增加自己的配置屬性，優(yōu)化后，寫入HDFS效率提升40%以上（lzo壓縮）。
- 寫入HDFS統(tǒng)一使用lzo方式寫入，達(dá)到一定大小或者超過配置時(shí)間進(jìn)行回滾。
目前Databus寫入HDFS或者Kafka配置比較繁瑣，后面需要針對(duì)此進(jìn)行優(yōu)化。
HadoopLoader是我們自行開發(fā)的組件，用以定期掃描Rsync推送過來的本地磁盤數(shù)據(jù)集存儲(chǔ)目錄，根據(jù)統(tǒng)一存儲(chǔ)規(guī)范上傳至HDFS。簡(jiǎn)單流程如下：
- 對(duì)每個(gè)數(shù)據(jù)集在內(nèi)存中維護(hù)一個(gè)uploadingQueue。掃描線程發(fā)現(xiàn)待上傳文件后，驗(yàn)證文件是否完整（根據(jù)對(duì)應(yīng)md5驗(yàn)證碼確定），然后將此文件加入此Queue。
- 上傳線程從Queue中拿要上傳的文件，從本地磁盤mv到uploading目錄下，并上傳。
- 上傳結(jié)束，將已上傳文件mv到本地磁盤done目錄下。同時(shí)將本次上傳文件路徑，所屬數(shù)據(jù)集、大小、md5驗(yàn)證碼、上傳時(shí)間、HDFS路徑等信息入庫(kù)。
客戶端使用API post數(shù)據(jù)目前還在開發(fā)驗(yàn)證階段，暫時(shí)不便透漏更多。Databus支持向第三方轉(zhuǎn)發(fā)，基于Flume replica策略配置實(shí)現(xiàn)。
數(shù)據(jù)存儲(chǔ)及分析層
上文已經(jīng)提到，數(shù)據(jù)集在Databus中支持向HDFS、Kafka、Elasticsearch寫入數(shù)據(jù)。這里主要對(duì)HDFS存儲(chǔ)及公共分析平臺(tái)搭建重點(diǎn)介紹。
對(duì)于海量數(shù)據(jù)的分布式存儲(chǔ)，Hadoop/HDFS已經(jīng)成為事實(shí)標(biāo)準(zhǔn)，目前不僅在各大互聯(lián)網(wǎng)公司，甚至在電信領(lǐng)域以及銀行也都開始陸續(xù)落地。Hadoop2對(duì)比Hadoop1，無論在HA、namenode擴(kuò)展性、權(quán)限控制、資源調(diào)度及分配、資源隔離等都有極大提升。目前我們使用Hadoop 2.6.0作為公司最新集群使用版本，并對(duì)已知的重要bug打了patch。
相信在很多公司，尤其是創(chuàng)業(yè)型公司，初期業(yè)務(wù)快速擴(kuò)張，為了方便，內(nèi)部存在多個(gè)集群，且集群規(guī)�？赡芏疾皇呛艽�，各業(yè)務(wù)使用的集群版本可能也不一樣，相互依賴也很少。初期的散列部署結(jié)構(gòu)，可以輕松應(yīng)對(duì)業(yè)務(wù)的迅速發(fā)展。隨著業(yè)務(wù)的逐步發(fā)展，各個(gè)業(yè)務(wù)部門數(shù)據(jù)共享需求越來越強(qiáng)烈，同時(shí)數(shù)據(jù)依賴關(guān)系也越來越復(fù)雜，分析數(shù)據(jù)中集群間數(shù)據(jù)來回搬動(dòng)越來越多，同時(shí)隨著數(shù)據(jù)量的迅速猛增，各集群存儲(chǔ)空間壓力加大，這時(shí)集群間資源整合就越來越必要，散列的集群部署結(jié)構(gòu)阻礙了數(shù)據(jù)的共享，增加了數(shù)據(jù)處理過程外的許多數(shù)據(jù)遷移環(huán)節(jié)，降低了數(shù)據(jù)處理的性能，并且不利于集群資源的最大化利用，集群管理成本太高。曾見到有個(gè)業(yè)務(wù)每天將近20個(gè)TB的數(shù)據(jù)在多個(gè)集群間來回折騰的案例（并非多機(jī)房災(zāi)備），十分典型。
在微店同樣如此，單個(gè)機(jī)房?jī)?nèi)存在著若干個(gè)大大小小的集群，集群規(guī)模在幾個(gè)節(jié)點(diǎn)到近百個(gè)節(jié)點(diǎn)不等，最小規(guī)模才4個(gè)節(jié)點(diǎn)，版本也不近相同。資源整合尤為重要，同時(shí)兼顧各業(yè)務(wù)部門的效率。為大家謀福利，才能更好的推進(jìn)資源整合工作。在實(shí)際整合過程中，集群不同的業(yè)務(wù)處理類型，計(jì)算引擎，決定如何去資源整合。我們整合的原則是存儲(chǔ)共享優(yōu)先，計(jì)算類型分類，兼顧特殊業(yè)務(wù)需求。在此原則下，我們多個(gè)集群將共享統(tǒng)一的HDFS存儲(chǔ)資源，解決數(shù)據(jù)來回搬運(yùn)的問題，同時(shí)各個(gè)集群統(tǒng)一版本，方便集群管理；按照計(jì)算類型進(jìn)行整合，整合后將會(huì)有：
- 公共計(jì)算集群，負(fù)責(zé)MR、Hive、Pig、Streaming作業(yè)的處理；
- Spark集群，對(duì)內(nèi)存資源需求大，專門跑Spark作業(yè)；
- GPU集群，負(fù)責(zé)高性能計(jì)算；
- UDC集群，專門處理領(lǐng)導(dǎo)關(guān)心的時(shí)間要求高的業(yè)務(wù)指標(biāo)數(shù)據(jù)報(bào)表。
整合后，集群使用統(tǒng)一的HDFS集群（規(guī)模300個(gè)節(jié)點(diǎn)），各計(jì)算集群物理隔離，服務(wù)器類型單獨(dú)配置，有利于成本節(jié)約。
存儲(chǔ)共享后，數(shù)據(jù)的存儲(chǔ)規(guī)范、數(shù)據(jù)安全訪問、讀寫權(quán)限規(guī)范等亟待建立。同時(shí)需要有統(tǒng)一的供數(shù)據(jù)分析開發(fā)人員使用的大數(shù)據(jù)處理平臺(tái)Portal，作為唯一的用戶授權(quán)、元數(shù)據(jù)訪問、提交并管理作業(yè)、權(quán)限申請(qǐng)、集群資源使用情況查詢、資源限額等等功能的入口。圖5是對(duì)資源整合后的數(shù)據(jù)存儲(chǔ)及分析處理流程簡(jiǎn)圖。
圖5 資源整合后的數(shù)據(jù)存儲(chǔ)及分析處理流程
分析開發(fā)人員由統(tǒng)一Portal訪問大數(shù)據(jù)基礎(chǔ)資源，支持用戶對(duì)有權(quán)限的數(shù)據(jù)集查詢數(shù)據(jù)集屬性信息、數(shù)據(jù)集數(shù)據(jù)；按條件查找數(shù)據(jù)集、權(quán)限申請(qǐng)；支持權(quán)限的精細(xì)化管理（如業(yè)務(wù)組內(nèi)權(quán)限分配）；作業(yè)管理（提交、運(yùn)行、停止離線OR實(shí)時(shí)分析任務(wù)、Spark作業(yè)等等）、數(shù)據(jù)流轉(zhuǎn)關(guān)系；查看資源使用情況報(bào)表等等。提交的作業(yè)由作業(yè)調(diào)度中心進(jìn)行調(diào)度；支持公共UDF類庫(kù)。元數(shù)據(jù)管理提供對(duì)業(yè)務(wù)數(shù)據(jù)倉(cāng)庫(kù)元數(shù)據(jù)的共享支持。
當(dāng)前情況下，存在著很多客戶機(jī)（任務(wù)提交機(jī)），用來提交作業(yè)。客戶機(jī)必須經(jīng)過平臺(tái)管理方授權(quán)才可訪問集群。
分析開發(fā)人員對(duì)數(shù)據(jù)集進(jìn)行分析處理，需要經(jīng)過數(shù)據(jù)集或Hive庫(kù)表的授權(quán)，并提交到指定的隊(duì)列（由集群管理房提前建立，對(duì)分析人員透明）。主要包括：
1.客戶機(jī)授權(quán)。訪問Hadoop集群的服務(wù)器稱為客戶機(jī)，授權(quán)才能訪問。
2.用戶及用戶組。當(dāng)前賬號(hào)沿用Linux的user及group；將來會(huì)使用LDAP；用戶組按照業(yè)務(wù)部門或產(chǎn)品線劃分，靈活支持業(yè)務(wù)方的權(quán)限需求。
3.數(shù)據(jù)集授權(quán)。對(duì)數(shù)據(jù)集有讀/寫權(quán)限才可進(jìn)行相應(yīng)操作（得益于hadoop2.4新增的acl特性）。
3-1. 原始數(shù)據(jù)：Owner為超級(jí)管理員，業(yè)務(wù)部門只允許有讀權(quán)限；生命周期由超級(jí)管理員統(tǒng)一管理。
3-2. 歸檔數(shù)據(jù)：為老數(shù)據(jù)(>6month)，統(tǒng)一使用LZMA壓縮，提高壓縮比。
3-3. 結(jié)果數(shù)據(jù)：Owner為業(yè)務(wù)方，建議使用統(tǒng)一存儲(chǔ)結(jié)構(gòu)統(tǒng)一管理。
3-4. 用戶目錄：Owner為業(yè)務(wù)方，采用容量配額管理。
3-5. tmp目錄：都可讀寫，存放臨時(shí)數(shù)據(jù)，由管理方定時(shí)清理。
4. Hive服務(wù)授權(quán)。統(tǒng)一的Hive MetaStore服務(wù)，按照業(yè)務(wù)部門或產(chǎn)品線對(duì)DB及表劃分權(quán)限，并配合使用HDFS授權(quán)。
5. 隊(duì)列授權(quán)。按照業(yè)務(wù)組劃分隊(duì)列，并分配資源;支持隊(duì)列嵌套。【注：Hive原生代碼無法做到超級(jí)管理員角色，需要自行修改代碼實(shí)現(xiàn)�！�
監(jiān)控層
大數(shù)據(jù)處理平臺(tái)的最后一環(huán)無疑是監(jiān)控。監(jiān)控像是我們的眼睛，無時(shí)無刻盯著大數(shù)據(jù)平臺(tái)的整個(gè)處理流程，當(dāng)將要出現(xiàn)問題時(shí)觸發(fā)報(bào)警，平臺(tái)管理人員及時(shí)切入避免故障發(fā)生。我們統(tǒng)一使用Ganglia從采集端、傳輸層到存儲(chǔ)層、分析層的基礎(chǔ)資源指標(biāo)、應(yīng)用指標(biāo)寫入Ganglia，并使用Nagios進(jìn)行報(bào)警。圖6、圖7分別是平臺(tái)下各基礎(chǔ)組件的監(jiān)控布局及DataAgent端按業(yè)務(wù)分類監(jiān)控。
圖6 平臺(tái)下各基礎(chǔ)組件的監(jiān)控布局
圖7 DataAgent端按業(yè)務(wù)分類監(jiān)控
作者簡(jiǎn)介：王鋒。曾任職并負(fù)責(zé)新浪研發(fā)dip分析平臺(tái)架構(gòu)設(shè)計(jì)、開發(fā)工作，承載了新浪及微博各產(chǎn)品線的離線、實(shí)時(shí)等各類業(yè)務(wù)分析需求。目前任職微店大數(shù)據(jù)架構(gòu)師，負(fù)責(zé)微店大數(shù)據(jù)（hadoop）基礎(chǔ)技術(shù)架構(gòu)及服務(wù)運(yùn)營(yíng)，并負(fù)責(zé)完成業(yè)務(wù)類及運(yùn)維類指標(biāo)分析需求，逐步構(gòu)建微店的監(jiān)控分析平臺(tái)。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：微店的大數(shù)據(jù)平臺(tái)建設(shè)實(shí)踐與探討
相關(guān)文章
