“人類正從IT時代走向DT時代”，2014年三月在北京舉行的一場大數(shù)據(jù)產(chǎn)業(yè)推介會上，阿里巴巴集團創(chuàng)始人馬云在主題演講中發(fā)表了他的這一觀點。這個觀念提法很快就被廣泛傳播開來，并被人們所接受。這里筆者不準(zhǔn)備大談DT時代，但是相信DT時代一定是以數(shù)據(jù)處理為核心的，因此大數(shù)據(jù)技術(shù)在這里有至關(guān)重要的地位，很有幸筆者及各位看官正在這個領(lǐng)域努力。
曾看到一篇文章，里面有個觀點，“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ù)處理平臺的基礎(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 實時 OR 即席查詢）、數(shù)據(jù)展現(xiàn)、價值體現(xiàn)的整體流程梳理。微店是目前全球領(lǐng)先的移動電商網(wǎng)絡(luò)（在微店生態(tài)體系，公司旗下還有口袋購物、微店全球購、微店買家版、今日半價、YouShop等5大優(yōu)勢平臺），創(chuàng)造了一個便利的手機購物環(huán)境，是全球年輕人喜愛的移動購物網(wǎng)絡(luò)。目前有超過3000萬的店主使用微店銷售商品，在這樣的背景下，技術(shù)部門開發(fā)部署的各種應(yīng)用每天需要服務(wù)巨量日志數(shù)據(jù)，這些數(shù)據(jù)既包含用戶的行為特征、興趣愛好，也包含了應(yīng)用的服務(wù)質(zhì)量情況，這些都是要進行深度分析發(fā)掘的數(shù)據(jù)，重要性不言而喻�；诖耍�(fù)責(zé)大數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)的我們承擔(dān)起了大數(shù)據(jù)處理平臺的建設(shè)任務(wù)，為業(yè)務(wù)分析部門提供公共基礎(chǔ)支撐。接下來，本文將重點描述大數(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ù)運維人員部署維護；分析挖掘這些數(shù)據(jù)的是數(shù)據(jù)分析人員、推薦算法開發(fā)人員等等，在實際工作過程中，由于各方關(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實時收集、Rsync傳輸、HdfsClient上傳、API推送；存儲方式分為：HDFS、分布式消息隊列Kafka、實時數(shù)據(jù)搜索Elasticsearch、第三方存儲；數(shù)據(jù)規(guī)模預(yù)估可以對要收集的數(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配置中一個很重要的屬性，標(biāo)識數(shù)據(jù)傳輸對象，這里我們沿用了這個單詞，并從開始到存儲落地全程被攜帶。
數(shù)據(jù)集的劃分是很重要的一個過程，決定了數(shù)據(jù)如何傳輸、存儲，并被如何分析處理。一般由業(yè)務(wù)部門及分析部門確定。數(shù)據(jù)集內(nèi)數(shù)據(jù)格式應(yīng)一致，方便進行處理。但在實際場景下，尤其創(chuàng)業(yè)公司，單個業(yè)務(wù)部門內(nèi)數(shù)據(jù)格式也未必統(tǒng)一，數(shù)據(jù)散落在多個日志文件中，單個體積相對較小，而分析人員也會關(guān)注這些數(shù)據(jù)，這種情況下為了方便處理，可以將這些劃分到一個數(shù)據(jù)集下，同時在采集端對數(shù)據(jù)進行標(biāo)注。典型方法，如在實時采集時日志行中加入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ù)據(jù)采集流程如圖3所示。
圖3 數(shù)據(jù)采集流程
- 由業(yè)務(wù)開發(fā)部門申請數(shù)據(jù)集
- 大數(shù)據(jù)組發(fā)布DataAgent
- 業(yè)務(wù)運維人員在業(yè)務(wù)機器部署DataAgent
- DataAgent采集數(shù)據(jù)并傳輸
目前大部分業(yè)務(wù)的日志數(shù)據(jù)采用這種方式采集。DataAgent基于Flume實現(xiàn)，自開發(fā)Flume插件Tailsource支持多數(shù)據(jù)集、多文件實時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ù)中
- 借鑒美團DualChannel，開發(fā)了我們自己的DualChannel，支持MemChannel+FileChannel。
- 支持Kafkachannel，并修改kafkachannel源碼，支持將原始數(shù)據(jù)寫入Kafka，對業(yè)務(wù)分析程序透明
- Agent自維護及智能升級
- 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在很多場景下，都可以達到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ù)運維人員使用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ù)收集上。因為Hadoop集群使用白名單方式對寫入端IP進行授權(quán)，如果存在大量的這類客戶端，會嚴(yán)重降低數(shù)據(jù)的傳輸效率，同時提高了客戶端的維護成本。
數(shù)據(jù)傳輸層
業(yè)務(wù)運維人員部署DataAgent，或者其他收集方式后，數(shù)據(jù)集進入數(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ù)端機器發(fā)出后中間經(jīng)過LVS負(fù)載均衡層，進入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端，我們提供了具有較強通用性的支持�；贔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ù)。交換機設(shè)備的穩(wěn)定對業(yè)務(wù)服務(wù)至關(guān)重要。以前我們?nèi)狈粨Q機的監(jiān)控，在6月底，我們專門對公司內(nèi)各機房幾乎所有交換機以syslog方式收集設(shè)備日志到Kafka，并對日志進行實時分析，發(fā)現(xiàn)異常及時報警。
絕大部分?jǐn)?shù)據(jù)需要寫入HDFS數(shù)據(jù)長時間存儲。我們使用改造后Flume HdfsSink寫入HDFS。原生的HdfsSink有一些缺點，我們對部分源碼進行改造：
- 在我們的場景中，單個機器上多個HdfsSink進程有出現(xiàn)文件同名的風(fēng)險，修改其源碼，在目前filepath+fileprefix+時間戳+filesuffix基礎(chǔ)上，在時間戳及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ù)對應(yīng)md5驗證碼確定），然后將此文件加入此Queue。
- 上傳線程從Queue中拿要上傳的文件，從本地磁盤mv到uploading目錄下，并上傳。
- 上傳結(jié)束，將已上傳文件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)成為事實標(biāo)準(zhǔn)，目前不僅在各大互聯(lián)網(wǎng)公司，甚至在電信領(lǐng)域以及銀行也都開始陸續(xù)落地。Hadoop2對比Hadoop1，無論在HA、namenode擴展性、權(quán)限控制、資源調(diào)度及分配、資源隔離等都有極大提升。目前我們使用Hadoop 2.6.0作為公司最新集群使用版本，并對已知的重要bug打了patch。
相信在很多公司，尤其是創(chuàng)業(yè)型公司，初期業(yè)務(wù)快速擴張，為了方便，內(nèi)部存在多個集群，且集群規(guī)�？赡芏疾皇呛艽螅鳂I(yè)務(wù)使用的集群版本可能也不一樣，相互依賴也很少。初期的散列部署結(jié)構(gòu)，可以輕松應(yīng)對業(yè)務(wù)的迅速發(fā)展。隨著業(yè)務(wù)的逐步發(fā)展，各個業(yè)務(wù)部門數(shù)據(jù)共享需求越來越強烈，同時數(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ù)在多個集群間來回折騰的案例（并非多機房災(zāi)備），十分典型。
在微店同樣如此，單個機房內(nèi)存在著若干個大大小小的集群，集群規(guī)模在幾個節(jié)點到近百個節(jié)點不等，最小規(guī)模才4個節(jié)點，版本也不近相同。資源整合尤為重要，同時兼顧各業(yè)務(wù)部門的效率。為大家謀福利，才能更好的推進資源整合工作。在實際整合過程中，集群不同的業(yè)務(wù)處理類型，計算引擎，決定如何去資源整合。我們整合的原則是存儲共享優(yōu)先，計算類型分類，兼顧特殊業(yè)務(wù)需求。在此原則下，我們多個集群將共享統(tǒng)一的HDFS存儲資源，解決數(shù)據(jù)來回搬運的問題，同時各個集群統(tǒng)一版本，方便集群管理；按照計算類型進行整合，整合后將會有：
- 公共計算集群，負(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é)點），各計算集群物理隔離，服務(wù)器類型單獨配置，有利于成本節(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è)管理（提交、運行、停止離線OR實時分析任務(wù)、Spark作業(yè)等等）、數(shù)據(jù)流轉(zhuǎn)關(guān)系；查看資源使用情況報表等等。提交的作業(yè)由作業(yè)調(diào)度中心進行調(diào)度；支持公共UDF類庫。元數(shù)據(jù)管理提供對業(yè)務(wù)數(shù)據(jù)倉庫元數(shù)據(jù)的共享支持。
當(dāng)前情況下，存在著很多客戶機（任務(wù)提交機），用來提交作業(yè)�？蛻魴C必須經(jīng)過平臺管理方授權(quán)才可訪問集群。
分析開發(fā)人員對數(shù)據(jù)集進行分析處理，需要經(jīng)過數(shù)據(jù)集或Hive庫表的授權(quán)，并提交到指定的隊列（由集群管理房提前建立，對分析人員透明）。主要包括：
1.客戶機授權(quán)。訪問Hadoop集群的服務(wù)器稱為客戶機，授權(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)限才可進行相應(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ù)組劃分隊列，并分配資源;支持隊列嵌套�！咀ⅲ篐ive原生代碼無法做到超級管理員角色，需要自行修改代碼實現(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進行報警。圖6、圖7分別是平臺下各基礎(chǔ)組件的監(jiān)控布局及DataAgent端按業(yè)務(wù)分類監(jiān)控。
圖6 平臺下各基礎(chǔ)組件的監(jiān)控布局
圖7 DataAgent端按業(yè)務(wù)分類監(jiān)控
作者簡介：王鋒。曾任職并負(fù)責(zé)新浪研發(fā)dip分析平臺架構(gòu)設(shè)計、開發(fā)工作，承載了新浪及微博各產(chǎn)品線的離線、實時等各類業(yè)務(wù)分析需求。目前任職微店大數(shù)據(jù)架構(gòu)師，負(fù)責(zé)微店大數(shù)據(jù)（hadoop）基礎(chǔ)技術(shù)架構(gòu)及服務(wù)運營，并負(fù)責(zé)完成業(yè)務(wù)類及運維類指標(biāo)分析需求，逐步構(gòu)建微店的監(jiān)控分析平臺。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的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)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：微店的大數(shù)據(jù)平臺建設(shè)實踐與探討
相關(guān)文章
