1、大數據應用案例-如何搭建大數據平臺技術架構？本文章來自于阿里云云棲社區如何搭建大數據平臺技術架構？有沒有好的大數據平臺架構案例？ 本文以掌慧縱盈為案例，闡述了物聯網企業的業務架構和數據架構，以及技術選型的思考過程。如何搭建大數據平臺技術架構？有沒有好的大數據平臺架構案例？ 本文以掌慧縱盈為案例，闡述了物聯網企業的業務架構和數據架構，以及技術選型的思考過程。借助“互聯網+大數據+機場”三輪驅動，掌慧縱盈每年為6.4億人次出行提供無線網絡連接服務。 隨著業務的拓展，隨之后來的挑戰是數據量的暴增。 2016年，掌慧縱盈通過阿里云產品，率先構建了業界領先的大數據平臺。以下來自掌慧縱盈的大數據平臺架構師

2、的分享：業務架構掌慧縱盈的業務架構如圖所示。我們的業務模式主要就是通過自有設備對數據進行收集，對數據的價值進行挖掘，最后對這些數據應用。數據收集層，我們創立了國內機場官方Wi-Fi第一品牌“Airport-Free-WiFi”，網絡遍布全國25個樞紐機場和39個樞紐高鐵站，每年為6.4億人次出行提供無線網絡連接服務；我們擁有全國最大的駕校Wi-Fi網絡，到17年底將覆蓋1500+所駕校；我們也是中國四大車展（北京、上海、廣州、成都）Wi-Fi服務商，為超過120萬人次提供了網絡服務；此外，我們還運營了全國2000+個加油站和600+個汽車4S經銷店的Wi-Fi網絡。數據應用層，我們打通了線上和

3、線下行為數據，用于用戶畫像，為包括SSP，DSP，DMP，RTB在內的廣告業務提供更高效的精準觸達；并和公安部合作，排查公共網絡安全威脅。掌慧縱盈的大數據平臺和廣告投放平臺還為企業輸出技術能力，幫助企業建立自己的大數據平臺，用豐富的量化數據提升企業的運營管理效率。數據架構基于我們的業務架構，我們抽象除了我們的數據架構，其中包含了許多主題，其主題視圖如圖所示。圖中本體可以簡單的理解為人，客體可以簡單的理解為物；本體與客體以各種形式進行連接，這種連接是一種時間維度和空間維度上的交匯，這種連接通過計算機網絡和電信網絡完成。本體在連接網絡中有自己的像，可以簡單的理解為虛擬身份（Avatars）；客體在

4、連接網絡中也有自己的像，例如維基百科對某一事物的描述，再比如某一事物商業化后形成產品或服務，再經過廣告包裝成其廣告形象，這些都是其客像。本體與客體的交互實際上就是本像和客像的交互，這種交互在時間和空間的維度上都會留下軌跡。本體的個體特征和群體特征，客體的個體特征和群體特征，本客交互的所有軌跡，所有這些主題形成的大數據，經過深度挖掘和學習，可以得出強大的洞察力，這種洞察力具有不可估量的商業價值。掌慧縱盈目前在本體域和交互域的數據體量：技術選型接下來說一下我們技術選型的思路。我認為，沒有最好的技術架構，只有最合適的架構。成功的IT規劃就是從業務架構出發，針對其每一個業務場景，給出最合適的技術架構。

5、功能需求首先來看我們的功能需求。以我們的廣告業務為例，目標是日消息處理量達到100億條。其對大數據能力的要求如下：假設記錄大小是2KB，容納這些數據我們需要70PB的物理容量。對查詢范圍的要求，推導出，離線計算的處理時長24小時，在線計算10分鐘。非功能需求希望通過云平臺將基礎設施安裝運維外包。大數據技術日新月異，希組件版本能夠及時更新。外部商業環境迅速變化，希望計算資源可以動態增減，以節約成本。希望以較低的成本獲取相對專業的安全服務。盡量使用開源組件，方便整體輸出。產品選擇綜合考察國內的云服務提供商，我們選擇了阿里云，尤其是其E-MapReduce產品，購買之后，集群馬上就創建好了，Hive

6、, Spark, HBase等開源大數據組件即刻可用。首先我們選擇數據存儲引擎。我們以存儲25TB的數據為基準，考察各個選項的性能和價格。從圖中可以看出，針對離線分析來說，如果想用開源組件，可以考慮Hive on OSS的模式，來存儲近一年的數據。針對在線分析的場景，使用HBase存儲近三個月的數據，可以獲得很高的性價比，這個方案可以多表聯查，但是SQL的響應對場景敏感，不同復雜度的SQL響應時間是不一樣的。如果希望響應時間恒定，可以考慮基于索引的方案，即日志服務，缺點就是不能多表聯查；如果想使用開源組件，可以自行在ECS上搭建ELK。接下來我們選擇查詢引擎。我們使用一個基準SQL，方便對其響

7、應時間進行橫向對比，基準SQL如下圖所示：結論是，使用Phoenix基于HBase進行交互式查詢，可以獲得很滿意的響應周期。選型部分告一段，接下來給出大數據平臺的技術架構。技術架構大數據平臺的技術架構概覽如圖所示，圖中幾乎所有的服務和功能都是通過阿里云產品來實現的，其中開發測試環境也是基于阿里云的ECS搭建的。從圖中可以看出，我們并不需要關心機房的電源、網絡、虛擬化、硬盤更換等一系列基礎設施問題，直接基于云平臺，專注于我們自己的業務。產品使用中有一些心得，總結如下：E-MapReduce阿里云的E-MapReduce是我們大數據平臺的核心產品，其涵蓋了Hive, Spark, HBase, S

8、torm等大數據領域核心的開源組件，還有Phoenix, Presto等業界前沿的查詢引擎，其Zeppelin, Hue等交互組件也是開箱即用。E-MapReduce不斷有新的版本發布，其中的組件版本也是不斷更新，但是已經購買的E-MapReduce是無法方便的升級的，為了及時升級組件版本，我們采取包月而不是包年模式。包月到期，想要升級，直接買新的，舊的不續費，自行銷毀。阿里的E-MapReduce只能增加節點不能減少節點，通過上述的滾動模式，還可以隨時調整集群規模和各種配置。上述的這種滾動模式，對于計算集群來說沒問題，數據存儲怎么辦呢？E-MapReduce所用的機器配置都很高，用來存儲數據

9、就可惜了，數據可以存儲在OSS上，使用Hive加載即可。不過要使用HBase還是要把數據存到E-MapReduce上，一但放到E-MapReduce上，這個集群就不能隨意銷毀了。所以，我們實踐當中將數據集群和計算集群分開，計算集群可以隨時銷毀和升級，數據集群需要長期穩定提供服務。這兩種的集群配置也是不一樣的，計算集群用SSD，主攻“快”，數據集群（HBase）用高效云盤，主攻“大”。那按量付費呢，什么場景下使用？我們計算過，如果計算時長超過7天，那么還是直接購買包月的集群比較劃算。按量付費的集群可以用于臨時突發的計算任務。工單管理使用阿里的云服務，最吸引人的就是工單服務。由于我們的運維團隊會經

10、常遇到復雜且需要緊迫解決的問題，團隊成員可以直接通過工單請求阿里的工程師協助解決。溝通問題的過程也是我們學習的過程，我們向阿里云服務的工程師們學到了不少的東西。軟件視圖基于技術概覽，我們技術架構中的軟件視圖如下所示：一些使用心得總結如下：負載均衡SLB原來，為了管理方便，我們好多云服務器ECS都開通了外網，但是實際使用率不高，外網帶寬的成本占用云服務器成本很大的一部分，現在我們所有云服務器都去掉了外網帶寬，統一走負載均衡SLB，共享負載均衡SLB的外網帶寬，包括SSH等所有應用的端口都是用負載均衡SLB轉發。負載均衡SLB帶寬不受限制，速度上來了，成本下來了，算是我們對負載均衡SLB的一個活用

11、。云服務器ECS由于我們的業務環境變化很快，有些機器可能今天還有用，明天就沒用了，所以我們采用包月加自動續費的模式，隨時增減機器，隨時增配減配。ONS也即阿里的日志服務，阿里內部叫MQ，其響應時間很快，吞吐量很大，可以應用于實時性非常高的場景，例如實時競價。日志服務Log Service其包含Logtail，LogStore, LogHub，LogShipper和LogSearch服務，其中日志投遞（LogShipper）功能很有用，可以自動將采集的日志投遞到對象存儲OSS，這樣就可以直接使用Hive加載了，不過目前只支持json格式。在我們的建議下，日志服務團隊將會支持CSV，Sequenc

12、eFile和Parquet格式，預計于2017年1月上線。Spark其官方給出的例子和阿里幫助文檔里的例子都是基于Scala的，不過我們還是選擇了用Java進行Spark應用的開發，這樣我們開發團隊的組建會更加便利。如果能使用Java 8，那么從函數式編程方式尤其是lambda表達式的角度就十分接近Scala的表現能力了。在我們的建議下，目前阿里云新版本的E-MapReduce已經支持了Java 8。需要提一句，數據在大數據計算服務ODPS（現名稱MaxCompute），那也沒關系。E-MapReduce 提供 SparkSQL服務，可以無縫訪問大數據計算服務ODPS數據。使用大數據計算服務O

13、DPS的用戶也可以加入到Spark生態體系中。Storm目前E-MapReduce已經提供了Storm組件，想要使用此組件，有兩個選擇：從日志服務消費；或者通過引導操作在E-MapReduce上安裝Kafka，支持增加節點。對象存儲OSS對象存儲OSS主要用于存儲，與E-MapReduce結合，實現了計算與存儲的分離。Zeppelin這真的是一個好東西，業務人員通過它，可以通過Web的形式使用HiveQL, SparkSQL, Phoenix, Presto等對數據進行探索式和交互式的查詢，而無需編程和登錄SSH，并且可以保存過往的查詢，還可以形成簡單的柱狀圖餅圖。我們的DMP工程師再也不用為

14、了某一個統計數字通宵寫代碼了，業務人員自己就可以搞定。PhoenixHBase本身是NoSQL數據庫，結構化查詢是其弱項，我們就是有很多OLAP的需求，希望交互式出結果，原來的做法是自己創建HBase的二級索引，對非主鍵字段進行跳轉查詢。后來發現，E-MapReduce上，Phoenix已經為我們搭建好了啊，其索引機制生成的HBase索引表，不就是我們原來手工創建的索引表嗎。于是全部轉向使用Phoenix進行交互式查詢。E-MapReduce老版本的Phoenix的默認查詢超時是1分鐘，對我們來說太短了，改參數又要重啟。在我們的建議下，目前E-MapReduce新版本的Phoenix的默認超時

15、時長已經設置為半個小時了。場景舉例批量計算，LogTail + LogHub + LogShipper + OSS + Hive + SparkSQL批量計算重在采集，使用LogTail配置好采集規則，通過LogShipper自動投遞到OSS，使用Hive直接加載形成數據倉庫，在Zeppelin界面上通過SparkSQL直接查詢Hive中的數據，整個ETL的過程十分流暢，幾乎不用寫任何代碼。交互式計算，LogTail + LogHub + Storm + HBase + Phoenix對于響應時間要求更嚴格的OLAP業務，可以以HBase為中心構建OLAP數據庫，為了縮短數據可用的周期，可以單獨一條通道。使用LogTail采集，并將LogHub中的數據對接到Storm上，使用Storm進行轉換并寫入HBase，然后在Zeppelin的界面上使用Phoenix進行查詢。實時計算，Servlet + ONS + Spark Streaming + Redis對于實時競價等實時計算業務，可以充分利用ONS的超快響應（1ms以內），超大并發的特性，通過Spark Streaming進行計算，最后存儲到Redis中。展望未來Spark 2.0 發布了Release，Hadoop 3.0發布了Alpha，HBase 2.0 發布了SNAPSHOT，這些組件中