本文根據鏈家（現：貝殼）趙國賢老師在DataFun Talk資料架構系列活動“海量資料下資料引擎的選擇及應用”中所分享的《大資料平臺架構從0到1之後》編輯整理而成，在未改變原意的基礎上稍做修改。
大資料平臺構建方法大同小異，但是平臺構建以後也面臨很多挑戰，在面臨這些挑戰我們如何去克服、修復它，讓平臺更好滿足使用者需求，這就是本次主題的重點。下面是本次分享的內容章節，首先講一下架構1.0與2.0，兩者分別是怎麼樣的，從1.0到2.0遇到了哪些問題；第二部分講一下資料平臺，都有哪些資料平臺，這些資料平臺都解決什麼問題；第三個介紹下當前比較重要的專案“olap引擎的選型與效果”以及遇到的一些問題；第四個簡單講一下在透明壓縮方面的研究。
架構1.0階段，底層是Hadoop，用來儲存資料和分析資料。需要把log資料和事務資料傳輸到Hadoop平臺上，我們使用的是kafka和sqoop進行資料傳輸。然後在Hadoop平臺基礎上，通過一個開源的Hive和oozie做一個排程，開發者寫Hql來完成業務需求，然後將資料mysql叢集或redis叢集，上層承接的是一個報表系統。這個需求基本跑了一年，也解決了一些問題。但存在的問題有：（1）架構簡單，不易解耦，結合太緊密出現問題需要從底層一直查到上面；（2）平臺架構是需求驅動，面臨一個需求後需要兩週時間來解決問題，有時開發出來運營已經不需要；（3）將大資料工程師做成一個取數工程師，大量時間在獲取怎樣資料；（4）故障頻發，比如Hql跑失敗了或者網路延遲沒成功，oozie是通過xml配置釋出任務，我們解決需要從資料倉儲最底層跑到資料倉儲最高層，還要重刷msl，花費時間。
面對這些問題我們做了一次架構調整，資料平臺分為三層，第一層就是叢集層（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解決的問題。
第二部分就簡單介紹下平臺，第一個是儲存層-叢集層，解決運維工作，我們基於開源做了一個presto。實習人員經過一兩週能適應這個工作，釋放了運維的壓力，資料量目前有18PB,每天的任務有9萬+，平均3-4任務/分鐘；第二個就是後設資料管理平臺，這種表抽象為各個層，分析資料、基礎細節資料等抽象，提供一個類似百度的搜尋框，通過搜尋獲得所需資料，這樣業務人員能夠非常方便的使用我們的資料。它能實現資料地圖（資料長怎樣，關聯關係是怎麼樣都可以顯示出來），資料倉儲視覺化，管理運維資料，資料資產非常好的管理和運維，將資料開發的工作便捷化、簡易化。
第三個資料平臺排程系統，資料倉儲中的各個層需要流轉，資料出現問題後如何去恢復資料。資料排程系統主要的工作有：（1）資料流轉排程，可以非常簡易的配置出資料的流轉排程。（2）依賴觸發，充分利用資源，能夠讓排程任務非常緊湊，能夠儘可能快的產出我們的資料。（3）對接多個資料來源，需要將多種多樣的資料來源整合到資料倉儲中，如何將sql server資料、Oracle資料等資料匯入到資料倉儲中，系統能夠對接多種資料來源，因此我們財務人員、運營人員、業務人員都可以自主將資料接入到資料倉儲，然後分析和排程。（4）依賴關係視覺化。比如我們有100個任務是關聯的，最底層std層有50個任務，中間層有20個任務，如果中間ODS層出問題了，會影響上層依賴層任務，通過視覺化就能很方便定位。
除了前面三個平臺，還需要一個平臺來展示我們的資料，才能向我們的使用者顯示資料的價值。我們的指標平臺支援上卷下鑽、多維分析、自助配置報表，統一公司的各個指標。說一下統一公司的各個指標，比如鏈家場景，比如說一個業績（一週賣出十套房子，需要提傭），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上做智慧加速；第四個整合大儲存裝置、做冷資料儲存。
最後就是總結:
（1）前期做好需求分析和技術選型，不要盲目的看網上的文章；
（2）面對業務需求多變，如何保證技術穩定迭代；
（3）監控先行，把整個的運營資料拿出來先做監控；
（4）優化線上，需要持續的優化。
——END