回顧·大數據平臺從0到1以後

時間 2019-11-30

標籤回顧數據平臺以後简体版

原文原文鏈接

本文根據鏈家（現：貝殼）趙國賢老師在DataFun Talk數據架構系列活動「海量數據下數據引擎的選擇及應用」中所分享的《大數據平臺架構從0到1以後》編輯整理而成，在未改變原意的基礎上稍作修改。node

大數據平臺構建方法大同小異，可是平臺構建之後也面臨不少挑戰，在面臨這些挑戰咱們如何去克服、修復它，讓平臺更好知足用戶需求，這就是本次主題的重點。下面是本次分享的內容章節，首先講一下架構1.0與2.0，二者分別是怎麼樣的，從1.0到2.0遇到了哪些問題；第二部分講一下數據平臺，都有哪些數據平臺，這些數據平臺都解決什麼問題；第三個介紹下當前比較重要的項目「olap引擎的選型與效果」以及遇到的一些問題；第四個簡單講一下在透明壓縮方面的研究。mysql

架構1.0階段，底層是Hadoop，用來存儲數據和分析數據。須要把log數據和事務數據傳輸到Hadoop平臺上，咱們使用的是kafka和sqoop進行數據傳輸。而後在Hadoop平臺基礎上，經過一個開源的Hive和oozie作一個調度，開發者寫Hql來完成業務需求，而後將數據mysql集羣或redis集羣，上層承接的是一個報表系統。這個需求基本跑了一年，也解決了一些問題。但存在的問題有：（1）架構簡單，不易解耦，結合太緊密出現問題須要從底層一直查到上面；（2）平臺架構是需求驅動，面臨一個需求後須要兩週時間來解決問題，有時開發出來運營已經不須要；（3）將大數據工程師作成一個取數工程師，大量時間在獲取怎樣數據；（4）故障頻發，好比Hql跑失敗了或者網絡延遲沒成功，oozie是經過xml配置發佈任務，咱們解決須要從數據倉庫最底層跑到數據倉庫最高層，還要重刷msl，花費時間。nginx

面對這些問題咱們作了一次架構調整，數據平臺分爲三層，第一層就是集羣層（Cluster），主要是一些開源產品，Hadoop實現分佈式存儲，資源調度Yarn，計算引擎MapReduce、spark、Presto等，在這些基礎上構建數據倉庫Hive。還有一些分佈式實時數據庫HBase還有oozie、sqoop等，這些做用就是作數據存儲、計算和調度，另外還有一個數據安全。第二層就是工具鏈，這一層是一個自研發調度平臺，架構1.0用的oozie。基本知足需求有調度分發，監控報警，還有智能調度、依賴觸發，後續會詳細介紹。出問題後會有一個依賴關係可視化，數據出問題能夠很快定位與修復。而後就是Meta（元數據管理平臺），數據倉庫目前有3萬多張表，經過元數據管理平臺實現數據倉庫數據可視化。還有一個AdHoc，將數據倉庫中的表暴露出去，經過平臺需求方就能夠自主查找本身須要的數據，我只須要優化查詢引擎、記錄維護、權限控制、限速和分流。最上層將整個大數據的數據抽象爲API，分爲三個，面向大數據內部的API，面向公司業務API，通用API。大數據內部API能夠知足數據平臺一些需求，如可視化平臺、數據管理平臺等，裏面有專有API來管理這些API。面向公司業務API，咱們是爲業務服務的，經過咱們的技術讓業務產生更多產出，將用戶須要的數據API化，經過API獲取數據就行。通用API，數據倉庫內部的報表都產生一些API，業務需求方根據本身的需求自動組裝就OK了。架構2.0基本解決了咱們架構1.0解決的問題。redis

第二部分就簡單介紹下平臺，第一個是存儲層-集羣層，解決運維工做，咱們基於開源作了一個presto。實習人員通過一兩週能適應這個工做，釋放了運維的壓力，數據量目前有18PB,天天的任務有9萬+，平均3-4任務/分鐘；第二個就是元數據管理平臺，這種表抽象爲各個層，分析數據、基礎細節數據等抽象，提供一個相似百度的搜索框，經過搜索得到所需數據，這樣業務人員可以很是方便的使用咱們的數據。它能實現數據地圖（數據長怎樣，關聯關係是怎麼樣均可以顯示出來），數據倉庫可視化，管理運維數據，數據資產很是好的管理和運維，將數據開發的工做便捷化、簡易化。算法

第三個數據平臺調度系統，數據倉庫中的各個層須要流轉，數據出現問題後如何去恢復數據。數據調度系統主要的工做有：（1）數據流轉調度，能夠很是簡易的配置出數據的流轉調度。（2）依賴觸發，充分利用資源，可以讓調度任務很是緊湊，可以儘量快的產出咱們的數據。（3）對接多個數據源，須要將多種多樣的數據源集成到數據倉庫中，如何將sql server數據、Oracle數據等數據導入到數據倉庫中，系統可以對接多種數據源，所以咱們財務人員、運營人員、業務人員均可以自主將數據接入到數據倉庫，而後分析和調度。（4）依賴關係可視化。好比咱們有100個任務是關聯的，最底層std層有50個任務，中間層有20個任務，若是中間ODS層出問題了，會影響上層依賴層任務，經過可視化就能很方便定位。sql

除了前面三個平臺，還須要一個平臺來展現咱們的數據，才能向咱們的用戶顯示數據的價值。咱們的指標平臺支持上卷下鑽、多維分析、自助配置報表，統一公司的各個指標。說一下統一公司的各個指標，好比鏈家場景，好比說一個業績（一週賣出十套房子，須要提傭），16年咱們發現有多個口徑，所以經過指標系統將指標統一化，指標都從這裏出，能夠去作本身的可視化。還有各類財務人員、區長或店長也能夠自主從指標平臺上配置本身的數據，作本身的desktop，指標系統的後端使用後續講Kylin的一個多維分析引擎支撐的。數據庫

指標平臺架構，一個應用的可視化平臺確定須要底層能力的支撐，此次主題也是數據引擎，鏈家使用的是一個叫kylin的開源數據引擎，能夠把數據倉庫中的數據經過集羣調度寫入到HBase中作一個預計算。這樣就能夠支持指標系統千億級數據亞秒級的查詢，不支持明細查詢由於作過預計算。還引入了百度開源的palo，通過優化，經過這樣一個架構就知足上層的地動儀、指標平臺和權限系統。運營、市場、老闆都在用這個指標平臺，可以實現多維分析、sql查詢接口、超大規模數據集、釋放數據的能力以及數據可視化。後端

咱們是需求驅動，天天都會遇到不少需求，數據開發人員就是取出須要的數據。利用adhoc平臺將數據從數據倉庫中取出，基於這個咱們作了一個智能搜索引擎，架構在adhoc上的搜索引擎有不少，好比presto、hive、spark等。用戶也不知道該選擇那種引擎，他的需求就是儘量取出本身所需的數據，所以開發智能選擇引擎、權限控制，而且可以支撐各類接口、自助查詢，這樣就基本解決了數據開發的工做。咱們自研發了一個queryengine，在底層有presto、sparksql、hive等，queryengine特色就是可以發揮各自引擎的特性，如presto查詢快，可是sql支撐能力不強，sparksql一樣，在某些特殊sql查詢不如hive快，hive就是穩可是慢。queryengine就是智能選擇各類引擎，用戶把sql提交過來，queryengine判斷哪一個引擎適合你。如何作的簡單介紹下，對sql進行解析成使用的函數、使用的表、須要返回的字段結構，根據各個引擎的能力判斷哪一個合適。目前還在開發功能就是計費，由於資源是有限的。queryengine支持mysql協議，由於有些用戶須要BI能力，須要對返回的數據進行聚合，咱們不能開各類各樣的BI能力，咱們只需知足mysql協議將數據暴露出去，用戶只需用其餘BI就能使用。緩存

經過架構1.0到架構2.0衍生出不少平臺，大架構已經有了，可是遇到的一些問題如何解決。這裏分享兩個案例，一個是olap引擎的選型與效果，第二個就是爲何要作透明壓縮，是如何作的。Rolap引擎基本是基於關係型數據庫，基於關係模型實時進行聚合運算，主要經過傳統數據庫或spqrk sql和presto，spqrk sql和presto是根據數據實時計算；Molap是基於一個預約義模型，預先進行聚合計算，存儲彙總結果。先計算好一個立方體，基於立方體作上傳下鑽，實現由Kylin/Druid，Druid主要是實時接入（Kylin沒有），實時將kafka數據用Spark sql作一次計算而後將數據上傳上去，能夠支持秒級查詢；還有一個比較流行的是叫olap，混合多引擎，不一樣場景路由到不一樣引擎。安全

Rolap查詢時首先將數據掃描出來，而後進行聚合，經過聚合結果將多個節點數據整合到一個節點上而後返回。優點是支持任何sql查詢，由於數據是硬算，使用明細數據，沒有數據冗餘，一致性很是好，缺點是大數據量或複雜數據量返回慢，由於你是基於明細數據，一條一條數據計算不管如何優化仍是會出現瓶頸，併發性不好。

Molap中間會有一箇中心立方體cube，在數據倉庫經過預計算將數據存儲到cube中，經過預聚合存儲支持少許計算彙總，爲何少許計算，由於數據都已經預計算好了。優勢就是支持超大數據集，快速返回併發高，缺點是不支持明細，須要預先定義維度和指標，適用場景就是能預知查詢模式，併發有要求的場景，固化場景可使用molap。

對於技術選型，當時面臨的需求，基本上開源組件有不少，爲何選擇kylin，由於支持較高的併發，面對百億級數據可以支持亞秒級查詢，以離線爲主，具備必定的靈活性，最好有sql接口，而這些需求恰好kylin能知足。Apache Kylin™是一個開源的分佈式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析能力，以支持超大規模數據，最初由e Bay Inc. 開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。其解決方案就是預先定義維度和指標，預計算cube，存儲到hbase中，查詢時解析sql路由到hbase中獲取結果。

如今講一下鏈家olap架構，HBase集羣，數據倉庫計算和預處理在這塊，還有一個爲了知足kylin需求而作的HBase集羣。Kylin須要作預計算，所以有個build集羣，將數據寫入到基於kylin的Hadoop集羣中，而後利用nginx作一個負載均衡，還有一個query集羣，而後就是面向線上的一個查詢，還有一個kylin中間件，解決查詢、cube任務執行、數據管理、統計。指標平臺大部分是查詢kylin，可是kylin不能知足明細查詢，這個就經過queryengine智能匹配，經過spark集羣或presto集羣，還有alluxio作壓縮，而後將明細查詢結果返回指標平臺，最終返回其餘業務的產品。在橫向還作了一個權限管理、監控預警、元數據管理、調度系統，來實現總體平臺支撐。

接下來說一下鏈家kylin能力拓展，基本大同小異，遇到的問題主要有：分佈式構建，cube增加很快，build集羣沒法承載，所以作了分佈式優化可以知足500cube在規定時間跑完；優化構建時字典下載策略，kylin構建時須要將全部元數據字典所有下載下來，所以從Hadoop將元數據字典下載都得好幾分鐘，每次build都去下載元數據字典會很耗時，優化後只須要下載一次就能夠；優化全局字典鎖，build時須要鎖住整個build集羣，完成後鎖才釋放，源碼發現並不須要全局鎖只須要鎖住所須要的字段就能夠，優化將鎖設置到字段級別上；Kylin 的query查詢機器使用G1垃圾回收器。咱們自研發了一箇中間件基本能夠容納一個無限容量的隊列，針對特定cube的預先調度，以及權限的管控、實現任務的併發控制。架構有外面的調度系統，有一個kylin中間件，全部的查詢和build都通過kylin中間件。還作了一個任務隊列、統計、優先級調度、監控報警、cube平分、以及可視化配置和展現。

架構從0到1.0遇到了另外一個問題-集羣，存儲鏈家全部數據，數據量大、數據增加快（0-1PB兩年時間，1PB-16PB不到一年時間，面臨成本問題）、冷數據預期，針對這些問題提出透明壓縮項目。就是分層存儲（Hadoop特性），根據不一樣數據分不一樣級別存儲，好比把一部分數據存儲在ssd，把另外一部分數據存儲到磁盤之上。Hot策略將數據所有存儲到磁盤之上，warm策略就是一部分數據存儲在磁盤上，一部分存儲archive（比較廉價，轉數小）。第二個就是ZFS文件系統，它具備存儲池、自我修復功能、壓縮與可變塊大小、寫時拷貝/校驗和/快照、 ARC（自適應內存緩存）與L2ARC（SSD作二級緩存）。

透明壓縮設計實現思路是：（1）界定要作數據冷處理隔離的主要內容。須要將一部分數據存儲到ZFS文件系統作一個透明壓縮來知足減小成本的需求，這樣須要把冷數據界定出來；（2）生成特定的經過獲取特定的冷數據列表，並標記其冷數據率；而後，按期從冷數據表中取出爲完成冷數據遷移的行，進行移動。經過HDFS目錄把界定出來的冷數據移動到ZFS壓縮之上，把不須要的移除到Ext4上。這樣一部分數據存儲在ZFS上，一部分存儲在EXT4上。

透明壓縮優化工做有：第一個Hadoop冷熱數據分離優化。涉及有異構存儲策略選擇、HDFS冷熱數據移動優化；第二個就是ZFS文件系統優化。ZFS支持不少壓縮算法，通過測試發現Gz壓縮效率最好，下圖是各類算法效率對比。隨着壓縮數據愈來愈大，CPU佔用愈來愈高。海量數據集羣不光是存儲還有計算。Datanode對壓縮數據的加載時間，直接關係到訪問此部分數據時的效率，從表可知,ZFS的gz壓縮在datanode加載數據上對LZ4有部分優點。較爲接近EXT4。綜合考慮壓縮率，讀取，寫入速度，datanode加載速度等，選定gz做爲ZFS文件系統的壓縮算法。

透明壓縮前數據增加是很是快的，接近30%的增加速率，邏輯數據有3PB，3備份後總空間：9.3PB實際總空間：7PB，就目前簡單預估節省成本有300萬。壓縮後雖然實際數據再增加，但真實數據是緩慢降低的。

透明壓縮將來展望，透明壓縮是對cpu是有損耗的，咱們但願將透明壓縮計算提取出來，經過QAT卡進行壓縮，但願將所有數據進行透明壓縮，這樣更節省成本；另外一個就是EC碼與透明壓縮結合，採用EC碼能夠進行兩備份或1.5備份；第三個數據智能回暖，壓縮訪問仍是影響性能，比較熱的數據放到比較熱的存儲設備上，放在SSD上作智能加速；第四個整合大存儲設備、作冷數據存儲。