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

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

云計算，賦予IT資源可伸縮的力量，從而可以整合算力，為各種新技術(shù)提供表演的舞臺，同時(shí)也為社會(huì )積蓄了豐富的資源，為大數據、人工智能提供底層技術(shù)的支撐。大數據技術(shù)則將通過(guò)對數據的存儲、加工、處理、分析，在為人們發(fā)掘數據價(jià)值的同時(shí)，也為人工智能提供了豐富優(yōu)質(zhì)的數據資源。而人工智能技術(shù)，則是人類(lèi)社會(huì )智能化的關(guān)鍵，它將是除了互聯(lián)網(wǎng)以外，對人類(lèi)產(chǎn)生深遠影響的另一項技術(shù)，其釋放的力量將再次徹底改變我們的生活。

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

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

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

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

總體來(lái)說(shuō)基于傳統的分布式存儲方案可以實(shí)現無(wú)線(xiàn)擴容問(wèn)題，但它的缺點(diǎn)是協(xié)議無(wú)法兼容，且存在分布式事務(wù)和分布式Join難題。在這樣的背景之下，UCloud基于高性能分布式存儲架構，通過(guò)融合最新軟硬件技術(shù)，著(zhù)手研發(fā)新一代公有云分布式數據庫Exodus。

Exodus支持主流的開(kāi)源數據庫MySQL，完全兼容各種協(xié)議，包括RDMA、Skylake、SPDK、用戶(hù)態(tài)文件系統等，計算層采用深度定制的MySQL InnoDB引擎，架構設計上支持一主多從，通過(guò)這些設計，Exodus一舉解決云數據庫容量、性能、性?xún)r(jià)比、兼容性四大痛點(diǎn)。

系統基于用戶(hù)態(tài)的協(xié)議棧，更能適應新的硬件紅利，單核理論能到百萬(wàn)IOPS的能力，減少傳統內核中斷，上下文切換的開(kāi)銷(xiāo)。網(wǎng)絡(luò )的時(shí)延開(kāi)銷(xiāo)在傳統分布式存儲中本來(lái)就是大頭，基于融合以太網(wǎng)的 RDMA 協(xié)議 (RoCE) 網(wǎng)絡(luò )實(shí)質(zhì)上是一種允許通過(guò)以太網(wǎng)使用遠程直接內存訪(fǎng)問(wèn)的網(wǎng)絡(luò )協(xié)議，可以實(shí)現Zero Copy。

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

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

基于這樣的架構設計，羅成對判斷，未來(lái)云平臺的底層的分布式存儲產(chǎn)品，在IO路徑上將實(shí)現極致優(yōu)化，主流云平臺底層分布式存儲將實(shí)現微秒級延遲，百萬(wàn)級IOPS，足以支持高性能業(yè)務(wù)（如數據庫）。

UCloud范融：AI PaaS平臺實(shí)踐

如何有效降低成本，加快AI方案的試錯，是每個(gè)想把AI算法產(chǎn)品化的企業(yè)都需要考慮的問(wèn)題。UCloud LabU深度學(xué)習開(kāi)發(fā)工程師范融結合UCloud AI PaaS平臺的技術(shù)實(shí)踐，講述了UCloud如何為公有云用戶(hù)提供一套開(kāi)箱即用的AI開(kāi)發(fā)、測試、部署一體化環(huán)境。

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

· 算法兼容性：更好地兼容各類(lèi)AI框架和算法；

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

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

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

· 環(huán)境遷移：可遷移公有云能力到私有云環(huán)境中。

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

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

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

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

業(yè)界有多種數據庫高可用方案，每種方案都有自己的特點(diǎn)和不足，來(lái)自UCloud的資深存儲研發(fā)工程師丁順，就這些方案的技術(shù)實(shí)現及優(yōu)劣進(jìn)行了詳細的講解，并分享了UCloud云數據庫產(chǎn)品UDB在高可用容災方案上面的設計和實(shí)現，以及UDB產(chǎn)品大規模高可用數據庫運維中的一些經(jīng)驗和心得。

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

· 第一種，共享存儲。共享存儲是指若干DB服務(wù)使用同一份存儲，一個(gè)主DB，其他的為備用DB，若主服務(wù)崩潰，則系統啟動(dòng)備用DB，成為新的主DB，繼續提供服務(wù)。一般共享存儲采用比較多的是SAN/NAS方案，這種方案的優(yōu)點(diǎn)是沒(méi)有數據同步的問(wèn)題，缺點(diǎn)是對網(wǎng)絡(luò )性能要求比較高。

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

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

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

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

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

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

數據分布算法是分布式存儲的核心技術(shù)之一，不僅僅要考慮到數據分布的均勻性、尋址的效率，還要考慮擴充和減少容量時(shí)數據遷移的開(kāi)銷(xiāo)，兼顧副本的一致性和可用性。奧思數據創(chuàng )始人兼CTO李明宇現場(chǎng)分析了幾種典型的數據分布算法的優(yōu)缺點(diǎn)，并分享了具體實(shí)現中會(huì )遇到的一些問(wèn)題。

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

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

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

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

Kyligence劉一鳴：釋放大數據生產(chǎn)力

大數據分析場(chǎng)景在豐富的技術(shù)產(chǎn)品棧面前，依舊面臨著(zhù)技術(shù)門(mén)檻高、人才短缺、項目開(kāi)發(fā)周期長(cháng)等問(wèn)題。IT部門(mén)如何從被動(dòng)的業(yè)務(wù)實(shí)現者轉變?yōu)闃I(yè)務(wù)的賦能者，業(yè)務(wù)部門(mén)如何通過(guò)優(yōu)秀的工具更好地理解數據、挖掘數據的價(jià)值，是每一個(gè)數據團隊、IT團隊需要思考的問(wèn)題。來(lái)自Kyligence云與生態(tài)合作部副總裁劉一鳴基于上述問(wèn)題，講述了Apache Kylin技術(shù)的設計思考和最佳實(shí)踐。

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

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

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

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

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

最后，記得關(guān)注微信公眾號：鎂客網(wǎng)（im2maker），更多干貨在等你！