從分布式視角看大數據與AI平臺的構建

如果不能深刻理解分布式，實際上也就無法真正理解云計算、大數據以及人工智能。

云計算，賦予IT資源可伸縮的力量，從而可以整合算力，為各種新技術提供表演的舞臺，同時也為社會積蓄了豐富的資源，為大數據、人工智能提供底層技術的支撐。大數據技術則將通過對數據的存儲、加工、處理、分析，在為人們發掘數據價值的同時，也為人工智能提供了豐富優質的數據資源。而人工智能技術，則是人類社會智能化的關鍵，它將是除了互聯網以外，對人類產生深遠影響的另一項技術，其釋放的力量將再次徹底改變我們的生活。

不過，這三項技術都離不開一個關鍵點，那就是分布式，如果不能深刻理解分布式，實際上也就無法真正理解云計算、大數據以及人工智能。2018年UCan下午茶收官戰，以“回歸云核心，服務大數據和AI的分布式實踐”為主題，來自UCloud、奧思數據、Kyligence的技術專家，就大數據和AI平臺的分布式設計實踐進行了深入的探討和分享。

UCloud羅成對：新一代公有云分布式數據庫UCloud Exodus

UCloud上線商用至今，已穩定運營6年，覆蓋全球29個可用區，服務上萬家企業用戶。目前，UCloud云數據庫的實例數達幾萬，整個系統的數據量超數據量10PB+，單用戶實例數達到6k+，單用戶數據量1.8PB。在這樣急劇擴張的數據規模之下，無疑給云數據庫的容量上限、性價比、性能以及兼容性帶來了前所未有的挑戰。UCloud關系型存儲研發部負責人羅成對認為，想要解決這些挑戰，需要改變傳統的云+數據庫思維，實現數據層和基礎設施層的共生復用。

傳統的分布式數據庫下，數據庫可以簡單抽象兩層，第一層是SQL層，第二層是Storage，SQL層的典型實現是基于分布式存儲，這種方案可以兼容各種協議，無限擴容，不存在分布式事務和分布式Join問題，但其缺點也很明顯，SQL層存在多節點緩存一致性和分布式鎖的問題；Storage層最典型的實現是基于Sharding架構，該架構下也可以進行無限擴容，但協議無法100%兼容，存在分布式事務和分布式Join難題。

總體來說基于傳統的分布式存儲方案可以實現無線擴容問題，但它的缺點是協議無法兼容，且存在分布式事務和分布式Join難題。在這樣的背景之下，UCloud基于高性能分布式存儲架構，通過融合最新軟硬件技術，著手研發新一代公有云分布式數據庫Exodus。

Exodus支持主流的開源數據庫MySQL，完全兼容各種協議，包括RDMA、Skylake、SPDK、用戶態文件系統等，計算層采用深度定制的MySQL InnoDB引擎，架構設計上支持一主多從，通過這些設計，Exodus一舉解決云數據庫容量、性能、性價比、兼容性四大痛點。

系統基于用戶態的協議棧，更能適應新的硬件紅利，單核理論能到百萬IOPS的能力，減少傳統內核中斷，上下文切換的開銷。網絡的時延開銷在傳統分布式存儲中本來就是大頭，基于融合以太網的 RDMA 協議 (RoCE) 網絡實質上是一種允許通過以太網使用遠程直接內存訪問的網絡協議，可以實現Zero Copy。

而底層采用了AppendOnly的模式，相較于傳統的原地更新方式 ，在EC數據安全性以及實現Snapshot等方面更加友好，對于靜默錯誤等磁盤異常也有更好的檢測手段。IO路徑上，則采用CRUSH算法來計算所有分片的placement，不需要緩存或者查詢索引。LSMT Log-structure merge tree 通過LSMT來支持隨機讀寫。

傳統分布式存儲一般采用的是三副本的方式來保證數據可靠性（10-11個9），Exodus在采用底層為追加寫的方式來實現后，可以采用EC和壓縮的方式，在不影響可靠性的前提下將數據副本成本從3降到1左右。計算層采用深度定制的MySQL+InnoDB，可以直接復用公有云分布式存儲產品（如UCloud 塊存儲產品 UDisk ）。

基于這樣的架構設計，羅成對判斷，未來云平臺的底層的分布式存儲產品，在IO路徑上將實現極致優化，主流云平臺底層分布式存儲將實現微秒級延遲，百萬級IOPS，足以支持高性能業務（如數據庫）。

UCloud范融：AI PaaS平臺實踐

如何有效降低成本，加快AI方案的試錯，是每個想把AI算法產品化的企業都需要考慮的問題。UCloud LabU深度學習開發工程師范融結合UCloud AI PaaS平臺的技術實踐，講述了UCloud如何為公有云用戶提供一套開箱即用的AI開發、測試、部署一體化環境。

在AI PaaS平臺落地之前，大部分企業面臨的第一個挑戰就是基礎環境構建的復雜性：AI框架的多樣化選擇，環境的諸多變量、硬件的諸多變量以及底層數據存儲的諸多變量。以上這些交叉組合之后直接導致了一個情況：如果需要構建完整的一套軟硬件組合的系統，而每一條業務線都有不同需求時，多環境維護就會變得異常痛苦。其次，需要在AI系統建設時考量算法的兼容性、平臺需要具備擴展性、彈性伸縮的能力、容災能力等以應對平臺的橫向和縱向擴展。因此，一個完善的AI PaaS 平臺需要具備如下特點：

· 算法兼容性：更好地兼容各類AI框架和算法；

· 橫向擴展能力：支持CPU、GPU，支持S3、NFS、HDFS等多種存儲；

· 縱向擴展能力：平臺具備橫向擴展能力，支持業務規模的不斷擴大；

· 高可用：具備彈性伸縮的能力以及容災能力；

· 環境遷移：可遷移公有云能力到私有云環境中。

基于以上五大要素，UCloud構建了自有的AI基礎平臺，里面包含AI Train和AI Inference兩大核心服務。如下圖所示，最上層最側是訓練日志、服務狀態、TensorBoard框架和Jupyter，下面接著就是圖形化界面，這里面主要是完成一些基本的部署操作，右側是Python SDK接口，接入層下面即為平臺核心的AI Train和AI Service，最底層封裝了所有的計算節點和存儲接入。

AI Train方面，為了實現橫向擴展能力，UCloud不僅提供單機訓練，同時還提供了分布式訓練能力。也就是說除了提供單節點的程序，只要用戶滿足開發框架要求，平臺還可自動部署分布式框架，海量訓練服務下，可極大縮減訓練時間，提高效率。另外，平臺也提供交互式訓練方式，用戶可以和云上空間進行實時互動，并獲取云上實時訓練結果。

此外，在AI Training和AI Inference平臺算力方面，UCloud設計了兩大資源池，如果用戶的算力要求比較低，希望實現很好的彈性擴容能力，可以采用CPU資源池。如果對算力要求比較高，可以采用GPU資源池，這樣，就可以根據不同的用戶計算力需求提供最優的支持。

UCloud丁順：數據庫高可用容災方案設計和實現

業界有多種數據庫高可用方案，每種方案都有自己的特點和不足，來自UCloud的資深存儲研發工程師丁順，就這些方案的技術實現及優劣進行了詳細的講解，并分享了UCloud云數據庫產品UDB在高可用容災方案上面的設計和實現，以及UDB產品大規模高可用數據庫運維中的一些經驗和心得。

據丁順介紹，業界典型的高可用架構可劃分為四種： 第一種，共享存儲方案；第二種，操作系統實時數據塊復制；第三種，數據庫級別的主從復制；第三，高可用數據庫集群。每種數據同步方式可以衍生出不同的架構。

· 第一種，共享存儲。共享存儲是指若干DB服務使用同一份存儲，一個主DB，其他的為備用DB，若主服務崩潰，則系統啟動備用DB，成為新的主DB，繼續提供服務。一般共享存儲采用比較多的是SAN/NAS方案，這種方案的優點是沒有數據同步的問題，缺點是對網絡性能要求比較高。

· 第二種，操作系統實時數據塊復制。這種方案的典型場景是DRBD。如下圖所示，左邊數據庫寫入數據以后立即同步到右邊的存儲設備當中。如果左邊數據庫崩潰，系統直接將右邊的數據庫存儲設備激活，完成數據庫的容災切換。這個方案同樣有一些問題，如系統只能有一個數據副本提供服務，無法實現讀寫分離；另外，系統崩潰后需要的容災恢復時間較長。

· 第三種，數據庫主從復制。這種方案是較經典的數據同步模式，系統采用一個主庫和多個從庫，主庫同步數據庫日志到各個從庫，從庫各自回放日志。它的好處是一個主庫可以連接多個從庫，能很方便地實現讀寫分離，同時，因為每個備庫都在啟動當中，所以備庫當中的數據基本上都是熱數據，容災切換也非?？?。

· 第四種，數據庫高可用集群。前面三種是通過復制日志的模式實現高可用，第四種方案是基于一致性算法來做數據同步。數據庫提供一種多節點的一致性同步機制，然后利用該機制構建多節點同步集群，這是業界近年來比較流行的高可用集群的方案。

UCloud綜合了原生MySQL兼容，不同版本、不同應用場的覆蓋等多種因素，最終選擇采用基于數據庫主從復制的方式實現高可用架構，并在原架構基礎上，使用雙主架構、半同步復制、采用GTID等措施進行系列優化，保證數據一致性的同時，實現日志的自動尋址。

自動化運維是高可用數據庫當中的難點，UDB在日常例行巡檢之外，也會定期做容災演練，查看在不同場景下數據是否丟失、是否保持一致性等，同時設置記錄日志、告警系統等等，以便于第一時間發現問題，并追溯問題的根源，找出最佳解決方案。

奧思數據李明宇：分布式存儲中的數據分布算法

數據分布算法是分布式存儲的核心技術之一，不僅僅要考慮到數據分布的均勻性、尋址的效率，還要考慮擴充和減少容量時數據遷移的開銷，兼顧副本的一致性和可用性。奧思數據創始人兼CTO李明宇現場分析了幾種典型的數據分布算法的優缺點，并分享了具體實現中會遇到的一些問題。

一致性哈希算法因其不需要查表或通信過程即可定位數據，計算復雜度不隨數據量增長而改變，且效率高、均勻性好、增加/減少節點時數據遷移量小等特性受到開發者喜愛。但具體到實際應用中，這種算法也因其自身局限性遇到了諸多挑戰，如在“存儲區塊鏈”場景下，幾乎不可能獲取全局視圖，甚至沒有一刻是穩定的；企業級IT場景下，存在多副本可靠存儲問題，數據遷移開銷巨大。

所謂存儲區塊鏈，可以理解為分布式存儲（p2p存儲）+區塊鏈，它通過token激勵，鼓勵大家貢獻存儲資源，參與構建一個全世界范圍的分布式存儲系統。因為需要激勵大量用戶自發參與，因此會涉及上億甚至幾十億節點的尋址和路由問題，目前業界主要的解決方案主要有Chord、Kademlia等。不過，Chord算法效率較低，會產生較高延遲，可以采用Finger table，除了記錄當前節點以及下一節點位置，同時還記錄當前節點2^i+1的位置，降低計算復雜度，最終降低延遲。

企業級IT場景下，數據分布算法包括Dynamo、Ceph的CRUSH、Gluster的Elastic Hashing以及Swift的Ring等。這些算法都有相似的特點，首先它們都是基于/借鑒一致性哈希，增加/減少節點時數據遷移量小。其次，引入對數據中心物理拓撲的建模（Cluster Map），數據多副本 / EC分片跨故障域 / 可用區分布。另外，這些算法還可以對節點劃分權重，數據分布和容量/性能匹配，輔助擴容。

總體來說，這兩類方案均是基于一致性哈希算法實現，只是因為需求不同，才有了不同的改進方向。企業級更注重副本故障域的分布；而對于P2P存儲，則更注重在節點隨時退出隨時加入的情況下，保證數據能夠在有效時間內尋址。

Kyligence劉一鳴：釋放大數據生產力

大數據分析場景在豐富的技術產品棧面前，依舊面臨著技術門檻高、人才短缺、項目開發周期長等問題。IT部門如何從被動的業務實現者轉變為業務的賦能者，業務部門如何通過優秀的工具更好地理解數據、挖掘數據的價值，是每一個數據團隊、IT團隊需要思考的問題。來自Kyligence云與生態合作部副總裁劉一鳴基于上述問題，講述了Apache Kylin技術的設計思考和最佳實踐。

Apache Kylin是一個開源的分布式分析引擎 ，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力（可以把Kylin定義為OLAP on Hadoop）。據介紹，它是首個完全由中國人貢獻到國際頂級開源社區的開源項目，也是首個來自中國的Apache頂級開源項目。

Apache Kylin作為OLAP引擎包含了從數據源（Hive／Kafka等）獲取源數據，基于MapReduce 構建多維立方體（Cube），并充分利用HBase的列式特性來分布式的 存儲立方體數據 ，提供標準SQL解析與查詢優化，以及ODBC／JDBC驅動及REST API等多個模塊。

如下圖所示，Kylin基于HBase的列式存儲，計算結果集保存在HBase中，原有的基于行的關系模型被轉換成基于鍵值對的列式存儲，維度組合作為Rowkey，查詢訪問不再需要昂貴的表掃描，維度值通過編碼算法（字典、定長、時間戳等）高度壓縮，指標通過Column存儲，可以靈活、無限制的增加指標數量，此外，預先計算的結果也為高速高并發分析帶來了可能。

大多數的Hadoop分析工具和SQL是友好的，所以Apache Kylin擁有SQL接口這一點就顯得尤為重要。Kylin用的SQL解析器是開源的Apache Calcite，支持幾乎所有的SQL標準。Hive用的也是Calcite。

與其它SQL ON Hadoop不同，Kylin主要采用預計算（離線計算）的實現方式 。用戶在使用之前先選擇一個Hive Table的集合，然后在這個基礎上做一個離線的Cube構建，Cube構建完了之后就可以做SQL查詢了。用離線計算來代替在線計算，在離線過程當中把復雜的、計算量很大的工作做完，在線計算量就會變小，就可以更快的返回查詢結果。通過這種方式，Kylin可以用更少的計算，獲取更高的吞吐量。

最后，記得關注微信公眾號：鎂客網（im2maker），更多干貨在等你！