什麼樣的大資料平臺架構,才是最適合你的?
技術最終為業務服務,沒必要一定要追求先進性,各個企業應根據自己的實際情況去選擇自己的技術路徑。
它不一定具有通用性,但從一定程度講,這個架構可能比BAT的架構更適應大多數企業的情況,畢竟,大多數企業,資料沒到那個份上,也不可能完全自研,商業和開源的結合可能更好一點,權當拋磚引玉。
大資料平臺架構的層次劃分沒啥標準,以前筆者曾經做過大資料應用規劃,也是非常糾結,因為應用的分類也是橫縱交錯,後來還是覺得體現一個“能用”原則,清晰且容易理解,能指導建設,這裡將大資料平臺劃分為“五橫一縱”。
具體見下圖示例,這張圖是比較經典的,也是妥協的結果,跟當前網上很多的大資料架構圖都可以作一定的對映。
何謂五橫,基本還是根據資料的流向自底向上劃分五層,跟傳統的資料倉庫其實很類似,資料類的系統,概念上還是相通的,分別為資料採集層、資料處理層、資料分析層、資料訪問層及應用層。
同時,大資料平臺架構跟傳統資料倉庫有一個不同,就是同一層次,為了滿足不同的場景,會採用更多的技術元件,體現百花齊放的特點,這是一個難點。
- 資料採集層:既包括傳統的ETL離線採集、也有實時採集、網際網路爬蟲解析等等。
- 資料處理層:根據資料處理場景要求不同,可以劃分為HADOOP、MPP、流處理等等。
- 資料分析層:主要包含了分析引擎,比如資料探勘、機器學習、 深度學習等。
- 資料訪問層:主要是實現讀寫分離,將偏向應用的查詢等能力與計算能力剝離,包括實時查詢、多維查詢、常規查詢等應用場景。
- 資料應用層:根據企業的特點不同劃分不同類別的應用,比如針對運營商,對內有精準營銷、客服投訴、基站分析等,對外有基於位置的客流、基於標籤的廣告應用等等。
- 資料管理層:這是一縱,主要是實現資料的管理和運維,它橫跨多層,實現統一管理。
1、資料採集層,這是基礎。
離線批量採集,採用的是HADOOP,這個已經成為當前流線採集的主流引擎了,基於這個平臺,需要部署資料採集應用或工具。
諸如BAT都是自己研發的產品,一般企業,可以採用商用版本,現在這類選擇很多,比如華為BDI等等,很多企業技術實力有,但起步的時候往往對於應用場景的理解比較弱,細節做工很差,導致做出來的產品難以達到要求,比如缺乏統計功能等,跟BAT差距很大,傳統企業去採購這類產品,要謹慎小心。
一個建議是,當採購產品的時候,除了技術先進性和指標外,更多的應該問問是版本啥時候上線的,是否在哪裡成功部署,是否有足夠多的客戶,如果能做個測試就更好,否則,你就是小白鼠哦,這個坑踩了不少。
能做和做成產品是兩個境界的事情,小的網際網路企業當然也能做出對於自己好用的採集工具,但它很難抽象並打造出一個真正的產品,BAT自研其實形成了巨大的優勢。
實時採集現在也成了大資料平臺的標配,估計主流就是FLUME+KAFKA,然後結合流處理+記憶體資料庫吧,這個技術肯定靠譜,但這類開源的東西好是好,但一旦出現問題往往解決週期往往比較長。
除了用FLUME,針對ORACLE資料庫的表為了實現實時採集,也可以採用OGG/DSG等技術實現實時的日誌採集,可以解決傳統資料倉庫抽全量表的負荷問題。
爬蟲當前也逐漸成為很多企業的採集標配,因為網際網路新增資料主要靠它,可以通過網頁的解析獲取大量的上網資訊,什麼輿情分析、網站排名啥的,建議每個企業都應該建立企業級的爬蟲中心,如果它未在你的大資料平臺規劃內,可以考慮一下,能拿的資料都不拿,就沒什麼好說了。
企業級的爬蟲中心的建設難度蠻大,因為不僅僅是需要爬蟲,還需要建立網址和應用知識庫,需要基於網頁文字進行中文分詞,倒排序及文字挖掘等,這一套下來,挑戰很大,當前已經有不少開源元件了,比如solr、lucent、Nutch、ES等等,但要用好它,路漫漫其修遠兮。
總得來講,建設大資料採集平臺非常不易,從客戶的角度講,至少要達到以下三個要求:
- 多樣化資料採集能力:支援對錶、檔案、訊息等多種資料的實時增量資料採集(使用flume、訊息佇列、OGG等技術)和批量資料分散式採集等能力(SQOOP、FTP VOER HDFS),比基於傳統ETL效能有量級上的提升,這是根本。
- 視覺化快速配置能力:提供圖形化的開發和維護介面,支援圖形化拖拽式開發,免程式碼編寫,降低採集難度,每配置一個數據介面耗時很短,以降低人工成本。
- 統一排程管控能力:實現採集任務的統一排程,可支援Hadoop的多種技術元件(如 MapReduce、Spark 、HIVE)、關係型資料庫儲存過程、 shell指令碼等,支援多種排程策略(時間/介面通知/手工)。
2、資料處理層,現在有個詞叫混搭,的確是這樣。
Hadoop的HIVE是傳統資料倉庫的一種分散式替代。應用在傳統ETL中的資料的清洗、過濾、轉化及直接彙總等場景很適合,資料量越大,它的價效比越高。但目前為止看,其支撐的資料分析場景也是有限的, 簡單的離線的海量分析計算是它所擅長的,相對應的,複雜的關聯交叉運算其速度很慢。
一定程度講,比如企業客戶統一檢視寬表用HIVE做比較低效,因為涉及到多方資料的整合,但不是不可以做,最多慢點嘛,還是要講究個平衡。
hadoop到了X000臺叢集的規模也撐不住了,當前很多企業的資料量應該會超過這個數量,除了像阿里等自身有研發能力的企業(比如ODPS),是否也要走向按照業務拆分Hadoop叢集的道路?諸如浙江移動已經拆分了固網、移網、創新等多個hadoop叢集。
Hadoop的SPARK的很適合機器學習的迭代,但能否大規模的應用於資料關聯分析,能否一定程度替代MPP,還需要實踐來驗證。
MPP應該來說,是採用分散式架構對於傳統資料倉庫最好的替代,畢竟其實際上是變了種的關係型資料庫,對於SQL提供完整支援,在HIVE做了轉化分析後,資料倉庫的融合建模用它來做效能綽綽有餘,其價效比較傳統DB2更好一點,比如經過實用,Gbase30-40臺叢集就能超過2臺頂配的IBM 780。
MPP現在產品很多,很難做優劣判斷,但一些實踐結果可以說下,GBASE不錯,公司很多系統已經在上面跑了,主要還是國產的,技術服務保障相對靠譜,ASTER還有待觀望,自帶一些演算法庫是有其一些優勢,GreenPlum、Vertica沒用過,不好說。
大資料平臺的三駕馬車,少不了流處理。
對於很多企業來講,其顯然是核武器般的存在,大量的應用場景需要它,因此務必要進行建設,比如在IOE時代不可想象的實時、準實時資料倉庫場景,在流處理那裡就變得很簡單了,以前統計個實時指標,也是很痛苦的事情,當前比如反欺詐實時系統,一天系統就申請部署好了。
只嘗試過STORM和IBM STREAM,推薦IBM STREAM,雖然是商業版本,但其處理能力超過STORM不是一點半點,據說STORM也基本不更新了,但其實資料量不大,用啥都可以,從應用的角度講,諸如IBM這種商業版本,是不錯的選擇,支撐各類實時應用場景綽綽有餘。
流處理叢集以流處理技術結合記憶體資料庫,用以實時及準實時資料處理,基於IBM Streams流處理叢集承載公司的實時業務:
3、資料分析層,與時俱進吧。
先談談語言,R和Python是當前資料探勘開源領域的一對基友,如果要說取捨,筆者真說不出來,感覺Python更偏向工程一點,比如有對分詞啥的直接支撐,R的繪圖能力異常強大。但他們原來都以樣本統計為主,因此大規模資料的支撐有限。
筆者還是更關注分散式挖掘環境,SPARK是一種選擇,建議可以採用SPARK+scala,畢竟SPARK是用scala寫的,對很多原生的特效能夠快速支援。
TD的MPP資料庫ASTER也內嵌了很多演算法,應該基於並行架構做了很多優化,似乎也是一種選擇,以前做過幾度交往圈,速度的確很快,但使用資料屈指可數,還需要老外的支援。
傳統的資料探勘工具也不甘人後,SPSS現在有IBM SPSS Analytic Server,加強了對於大資料hadoop的支撐,業務人員使用反饋還是不錯的。
無論如何,工具僅僅是工具,最終靠的還是建模工程師駕馭能力。
4、資料開放層,也處在一個戰國時代。
有些工程師直接將HIVE作為查詢輸出,雖然不合理,也體現出計算和查詢對於技術能力要求完全不同,即使是查詢領域,也需要根據不同的場景,選擇不同的技術。
HBASE很好用,基於列儲存,查詢速度毫秒級,對於一般的百億級的記錄查詢那也是能力槓槓的,具有一定的高可用性,我們生產上的詳單查詢、指標庫查詢都是很好的應用場景。但讀取資料方面只支援通過key或者key範圍讀取,因此要設計好rowkey。
Redis是K-V資料庫,讀寫速度比HBASE更快,大多時候,HBASE能做的,Redis也能做,但Redis是基於記憶體的,主要用在key-value 的記憶體快取,有丟失資料的可能,當前標籤實時查詢會用到它,合作過的網際網路或廣告公司大多采用該技術,但如果資料越來越大,那麼,HBASE估計就是唯一的選擇了?
另外已經基於IMPALA提供網際網路日誌的實時線上查詢應用,也在嘗試在營銷平臺採用SQLFire和GemFire實現分散式的基於記憶體的SQL關聯分析,雖然速度可以,但也是BUG多多,引入和改造的代價較大。
Kylin當前算是基於hadoop/SPARK的多維分析的殺手級工具,應用的場景非常多,希望有機會使用。
5、資料應用層,百花齊放吧。
每個企業應根據自己的實際規劃自己的應用,其實搞應用藍圖很難,大資料架構越上層越不穩定,因為變化太快,以下是運營商對外變現當前階段還算通用的一張應用規劃圖,供參考:
6、資料管理層,路漫漫其修遠兮
大資料平臺的管理有應用管理和系統管理之分,從應用的角度講,比如我們建立了DACP的視覺化管理平臺,其能適配11大搭資料技術元件,可以實現對各類技術元件的透明訪問能力,同時通過該平臺實現從資料設計、開發到資料銷燬的全生命週期管理,並把標準、質量規則和安全策略固化在平臺上,實現從事前管理、事中控制和事後稽核、審計的全方位質量管理和安全管理。
其它諸如排程管理、元資料管理、質量管理當然不在話下,因為管住了開發的源頭,資料管理的複雜度會大幅降低。
從系統管理的角度看,公司將大資料平臺納入統一的雲管理平臺管理,雲管理平臺包括支援一鍵部署、增量部署的視覺化運維工具、面向多租戶的計算資源管控體系和完善的使用者許可權管理體系,提供企業級的大資料平臺運維管理能力支撐,當然這麼巨集大的目標要實現也非一日之功。
總結下大資料平臺的一些革命性價值。
大資料時代,大多數企業的架構必然向著分散式、可擴充套件及多元化發展,所謂合久必分,不再有一種技術能包打天下了, 這衝擊著傳統企業集中化的技術外包模式,挑戰是巨大的。
大資料及雲端計算時代,面多這麼多技術元件,要採用一項新的技術,機遇和風險共存:
對於大資料平臺的商業版本,企業面對的是合作伙伴的服務跟不上,因為發展太快,對於開源版本,企業面臨的是自身運維能力和技術能力的挑戰,對於自主能力實際要求更高。