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

曾看到一篇文章，里面有個觀點，“DT時代的骨骼——大數據處理平臺”，反映了大數據處理平臺在互聯網或者移動互聯網公司的重要性。大數據處理平臺其實包含了整個大數據處理過程，它承載了從數據采集、傳輸、存儲、分析挖掘(離線 OR、實時 OR、即席查詢)、可視化、價值體現的整體流程。這些在大的互聯網公司，尤其以BAT為首，已經逐步成熟，而且價值體現不斷放大。而在初創公司或者具有一定規模的創業公司，大數據處理平臺的基礎設施或開始搭建，或處于較初始的狀態，或者在逐步規范中。可能有人會有另外的想法：我們公司規模沒有那么大，有必要整這么一套么?是的，如果數據量很小，每天新增數據(比如應用日志)都是MB級別，或者GB級別，而以后也不會有爆發式增長，也沒必要太折騰。無論如何，有一個趨勢非常明確，隨著公司業務發展，數據量的爆發式增長，大數據處理平臺的建設勢在必行。

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

什么是數據集

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

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

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

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

數據采集層

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

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

由業務開發部門申請數據集

大數據組發布DataAgent

業務運維人員在業務機器部署DataAgent

DataAgent采集數據并傳輸

目前大部分業務的日志數據采用這種方式采集。DataAgent基于Flume實現，自開發Flume插件Tailsource支持多數據集、多文件實時tail，DataAgent具有以下特性：

支持數據集(category)配置，支持同時tail多個數據文件

支持checkpoint，定期(默認10s)將讀出的文件offset寫入本地磁盤

開發限速模塊，可配置，支持在特殊場景下的限速傳輸

支持按照文件名tail文件，同時支持根據inode文件查找

支持文件軟連接，在軟連接改變后讀取源日志文件剩余內容

修改Flume源碼支持將Event Header寫入原始數據中

借鑒美團DualChannel，開發了我們自己的DualChannel，支持MemChannel+FileChannel。

支持Kafkachannel，并修改kafkachannel源碼，支持將原始數據寫入Kafka，對業務分析程序透明

Agent自維護及智能升級

Agent端將監控指標發到指定ganglia監控端口，統一由監控層收集，支持數據比對，并支持根據應用參數設置報警。

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

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

采集層支持API推送，一些少量數據場景下，業務端可以直接調用我們提供的數據API，將數據直接寫入KAFKA。

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

數據傳輸層

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

DataBus統一負責對數據集的中間層傳輸、數據流轉及數據落地，數據從業務端機器發出后中間經過LVS負載均衡層，進入Databus。Databus由幾部分組成，包括：

基于Flume的Avro數據接收層，接收Agent端AvroSink發出的數據;

使用KafkaChannel實時消費Kafka數據;

接收syslog收集方式傳入的數據，如交換機日志;

HadoopLoader接收Rsync傳入的數據寫入HDFS;

接收API post的數據

支持的存儲方式包括：

HDFS存儲集群

Kafka分布式消息隊列

Elasticsearch集群

第三方存儲

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

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

除訪問日志及應用日志以外，Databus支持以syslog方式收集網絡設備數據。交換機設備的穩定對業務服務至關重要。以前我們缺乏對交換機的監控，在6月底，我們專門對公司內各機房幾乎所有交換機以syslog方式收集設備日志到Kafka，并對日志進行實時分析，發現異常及時報警。

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

在我們的場景中，單個機器上多個HdfsSink進程有出現文件同名的風險，修改其源碼，在目前filepath+fileprefix+時間戳+filesuffix基礎上，在時間戳及filesuffix之間增加4位隨機數，使用過程中沒有再出現文件同名情況。

HdfsSink在解析filepath及fileprefix過程中使用正則matcher去匹配，并且在每個Event處理過程中都會走這個過程，效率很低(對正則解析代碼段單獨測試500w event，正則解析代碼段耗時53s)，因為我們寫入HDFS時按照數據集統一存儲規范寫入，所以將路徑解析重寫優化，并增加自己的配置屬性，優化后，寫入HDFS效率提升40%以上(lzo壓縮)。

寫入HDFS統一使用lzo方式寫入，達到一定大小或者超過配置時間進行回滾。

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

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

對每個數據集在內存中維護一個uploadingQueue。掃描線程發現待上傳文件后，驗證文件是否完整(根據對應md5驗證碼確定)，然后將此文件加入此Queue。

上傳線程從Queue中拿要上傳的文件，從本地磁盤mv到uploading目錄下，并上傳。

上傳結束，將已上傳文件mv到本地磁盤done目錄下。同時將本次上傳文件路徑，所屬數據集、大小、md5驗證碼、上傳時間、HDFS路徑等信息入庫。

客戶端使用API post數據目前還在開發驗證階段，暫時不便透漏更多。Databus支持向第三方轉發，基于Flume replica策略配置實現。

數據存儲及分析層

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

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

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

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

公共計算集群，負責MR、Hive、Pig、Streaming作業的處理;

Spark集群，對內存資源需求大，專門跑Spark作業;

GPU集群，負責高性能計算;

UDC集群，專門處理領導關心的時間要求高的業務指標數據報表。

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

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

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

當前情況下，存在著很多客戶機(任務提交機)，用來提交作業。客戶機必須經過平臺管理方授權才可訪問集群。

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

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

用戶及用戶組。當前賬號沿用Linux的user及group;將來會使用LDAP;用戶組按照業務部門或產品線劃分，靈活支持業務方的權限需求。

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

3-1. 原始數據：Owner為超級管理員，業務部門只允許有讀權限;生命周期由超級管理員統一管理。

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

3-3. 結果數據：Owner為業務方，建議使用統一存儲結構統一管理。

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

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

4. Hive服務授權。統一的Hive MetaStore服務，按照業務部門或產品線對DB及表劃分權限，并配合使用HDFS授權。

5. 隊列授權。按照業務組劃分隊列，并分配資源;支持隊列嵌套。【注：Hive原生代碼無法做到超級管理員角色，需要自行修改代碼實現。】

監控層

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

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