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

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

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

　　UCloud上線商用至今，已穩定運營6年，覆蓋全球29個可用區，服務8萬+用戶。目前，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可以用更少的計算，獲取更高的吞吐量。