大話雲上「分散式實踐」，理解 B、A、C 並不難！

雲計算，驚喜於可伸縮與算力集合；大數據、人工智慧帶給我們無可比擬的技術震撼；細探究竟，這三種技術都無法離開一個關鍵點，那就是經常被圈內人提及的「分散式」。

這不，就在剛剛結束不久的UCan下午茶北京站活動中，多位技術大咖針對雲上的分散式實踐展開了深入探討，乾貨滿滿。

由於是年底的收官之作，本次UCan下午茶北京站活動採用了Keynote與開放式演講相結合的形式，並伴隨別樣精彩的答題活動以及抽獎環節，無論是形式的新穎呈現以及內容的精彩程度統統往勝從前，現場人頭攢動，開發者們關注無限！

現場人頭攢動

據了解，現場幾百名開發者熱情參與了交流與互動，尤其對AI平台、分散式資料庫、資料庫高可用性容災方案以及分散式存儲等十分關注。此外，這些探討也將為雲計算、大數據以及AI領域的從業者們提供借鑒與新思路，並十分值得廣大開發者們認真學習與總結！

《新一代公有雲分散式資料庫——UCloud Exodus》

——UCloud關係型存儲研發部負責人 羅成對

眾所周知，性能和容量一直是資料庫關注的核心議題。尤其在公有雲環境下更是挑戰巨大，而UCloud雲資料庫團隊一直在嘗試如何優雅地解決這個難題。

在最先「揭面」的Keynote的演講環節中， UCloud關係型存儲研發部負責人羅成對在「新一代公有雲分散式資料庫——UCloud Exodus」的主題分享中表示，在「用戶的需求就是我們下一個產品」的理念影響下，從2013年UCloud推出第一款雲數據產品MySQL至今，雲資料庫產品上線將近6年且保持穩定運營，有數據顯示共覆蓋全球29個可用區，服務上萬家企業用戶，實例數幾萬個，數據量達到10PB+，單用戶最多實例數超過6千個，單用戶數據量1.8PB。

除了展現雲資料庫產品的成熟迭代之外，他還表明在實踐過程中總結出的，目前雲資料庫面臨的運營痛點，例如容量、性價比、性能、兼容性等，而解決這些痛點的高效方式，在於對雲資料庫的深刻理解，例如1.0階段出現的雲資料庫就是雲+資料庫，大家都能意識到這個階段的重點在於託管、零維護。

但2.0階段如何實現雲計算的共生，怎樣實現矩陣式進化？本質上就是如何滿足各種各樣用戶更高級別的追求，這是需要提升的核心所在，是要達到數據層和基礎設施層的共生復用。

在產品層面，UCloud Exodus就是這樣一款應時而生的雲資料庫。羅成對表示，Exodus支持最主流的開源資料庫MySQL，協議完全兼容，通過融合最新軟硬體技術，包括RDMA、Skylake、SPDK、用戶態文件系統等來解鎖新的能力。

從架構層面看，Exodus可以簡單看分為兩層，分別是上面的計算層，以及下面的存儲層。 兩層之間通過超高性能網路連接。

存儲層是UCloud自研的新一代高性能分散式存儲；而計算層則採用了原生的MySQL協議的DBServer，可能未來會發展支持PostgreSQL協議；二層之間走用戶態文件系統UXFS。

可以看到，其中的典型架構與平時使用的主從架構是一樣的，主從可以在不同的可用區甚至跨域，實現多級容災部署。一主帶多從，靈活而且整體性能強。通過共享存儲來解決高可用的問題，而DB的核心問題之一就是高可用，在這種架構下，可解決很多1.0階段無法搞定的難題。

總結來看，基於計算存儲分離新型架構，UCloud採用了最新一代高性能分散式存儲系統，計算層採用深度定製的MySQL InnoDB引擎，架構設計上支持一主多從。

「前端接入的是UXFS，提供的是用戶態的IO棧，當DB接入到UXFS之後，直接通過RDMA到存儲節點。存儲層細分為兩層，上面一層是Segment Server，下一層是ChunkServer。

通過增加SegmentServer，將DB需要的隨機寫IO轉化為ChunkServer的順序IO。整個IO路徑並不完全強依賴MetaNode，將IO路徑去除索引，減少一跳IO，從而提高IO性能。」他補充道。

分散式存儲一個核心點是數據分布，很關鍵一點就是告訴人們應該去哪裡獲取數據。怎麼理解？就是內部通過一個演算法實現，我們採用一個演算法計算出數據到底在哪兒，這樣的好處是可以減少IO的一跳，這對資料庫提升非常明顯。計算存儲分離架構，帶來的另外一個好處是，計算和存儲單獨計費、按量付費，存儲層自帶非同步EC，進一步節省存儲空間，整體體現出來則是Exodus性價比超高。通過這些設計，Exodus一舉解決了雲資料庫容量、性能、性價比、兼容性等四大痛點。最後，羅成對介紹了Exodus（UXDB）的開發計劃，並透露該產品會在2019年Q3進行公測。

《Kyligence：釋放大數據生產力》

——Kyligence 雲與生態合作部副總裁 劉一鳴

如今大數據分析技術層出不窮，技術棧日新月異，在帶來海量數據處理能力的同時，數據分析的門檻依舊很高，在查詢性能、數據建模易用性、語義模型表達能力、高並發響應等場景均存在最後一公里問題。而Apache Kylin + cloud，是針對數據分析生產力場景設計，將行業最佳數據分析實踐沉澱為Apache頂級項目的成熟產品。

在題為《Kyligence：釋放大數據生產力》的分享中，劉一鳴針對數據分析生產力場景設計，詳細介紹了Kyligence在雲端的業務實踐。

他表示， Kyligence就是要把這套方法論沉澱成一個項目，從數據源出發，我們可以看到支持HIVE、Kafka，以及其他的數據作為數據源；其次中間有一個環節叫計算，麒麟核心思想是通過預計算算出索引，這樣查詢的時候才能快。

具體來說，麒麟內部有兩個生命周期，第一是構建的過程，這個過程就是要把原始的數據讀取出來，然後通過用戶模型，把用戶關心的事情通過一套可擴展計算框架算出一些中間結果；第二是查詢，查詢時候會查出一般的SQL語句，會直接根據中間結果獲得最終結果，這個過程並不需要很大的集群，每個查詢看起來都像RPC一樣快，這就是以前查詢HIVE等是以分鐘為單位，現在可以變成以毫秒為單位的原因。

此外，據了解這兩個過程的複雜程度並不一樣。「第一個構建過程要處理海量數據，這部分麒麟利用了很多大數據技術，包括存儲方面依賴HDFS，計算方面依賴的YARN來做調度，使用Map Reduce框架和Spark完成分散式計算，所以很有可能構建之初需要處理數據可能是100G，過段時間或者明天可能是100T，這完全是可擴展的。」劉一鳴進一步補充道。

關於「數倉是如何建設的」問題，他在演講中也有詳盡提及。過去，傳統數倉的建設需要從很多系統中讀取數據，例如OLTP、ERP、CRM系統等，其中會涉及到很長的流程，還需要保證數據的整合、清理、過濾、語義一致性以及保持模型層的完整，最後的環節才是導入一個數倉中，然後對接整個前端的應用需求。

相比而言，現在的做法可以簡單概括為Kyligence=Kylin+Intelligence，就是加入了很多智能的元素在其中，所以麒麟通過數據結構的變化能夠帶來更好的性能、更好的語義層、更多的梳理並發，但這些事情還是會很依賴建模的準確度，模型設計師對需求場景的掌握、對業務的掌握以及對錶的理解，這一點需要被明確。

據了解，Kyligence的客戶類型分很多種，早期只是手機互聯網應用的範疇，後來技術發展更多向金融、證券、保險、電信以及製造業轉型，共通的一點，這些行業都有海量數據收集的場景，以及很強的互聯網式精細化分析的需求。

現場，劉一鳴為開發者們列舉了招商銀行的應用案例加以說明。他總結道，招商銀行的數倉建設大概有二十多年的歷史了，所以不可避免遇到一個問題，那就是數據孤島。

「不同的部門，例如信用卡部門、數倉部門、風控部門，數據不一致，主要是因為存在不同的平台上。如果通通放在一起就會發現，都放入Teradata中有點兒小貴，放在GreenPlum中並發度又不夠，如果向Hadoop平台做遷移，作為全公司統一的數倉平台，分析的語義層模型能不能統一也是個問題。所以用麒麟做成一個統一的數據服務層，上面對接傳統招行中使用的BI工具，包括Cognos、MSTR、Superset等，如此就形成了整個招商銀行內部，80多個不同的部門使用的統一場景架構。」

《AI PaaS平台實踐》

——UCloud LabU深度學習開發工程師 范融

在UCan 下午茶深圳站曾進行精彩分享的UCloud LabU深度學習開發工程師範融也準時來到收官現場，作為開放式演講環節中唯一的女技術工程師，帶來主題為「AI PaaS平台實踐」的分享。

首先，范融說明了AI場景下做PaaS面臨的挑戰。在研發AI的整個周期中，用戶面臨諸如AI選型、AI開發周期、應用迭代、訓練及推理環境部署等痛點。無論是普通開發者還是企業用戶都希望有一種解決方案，它可以兼容更多深度學習演算法以及框架，並保證存儲、網路性能優勢。最後，她將AI PaaS平台的需求總結為演算法兼容性、縱向擴展、橫向擴展、高可用、環境遷移。

接著，她詳細介紹了UCloud關於基礎平台架構的很多技術乾貨。在整個AI 平台架構中，中間層是訓練平台和在線服務平台兩個基礎平台，他們都擁有錯誤處理、負載均衡等功能；底層部分通過計算節點接入層兼容了各種異構的計算節點，如GPU、CPU; 在存儲方面通過統一的接入層，讓各種類型的存儲介質接入平台後，面向開發者們訪問方式都會像本地訪問一樣簡單快捷。由於不同的用戶有不同的使用習慣，例如有的用戶可能習慣圖形化的接入，因為直白，所見即所得；而有的用戶需要與自己的內部系統做連接，所以迫切要求SDK做全自動化的腳本介入等。在架構上層有一個API的接入層，做到兼容各類用戶訪問需求。圖形化界面方面，支持訓練日誌、服務狀態、TensorBoard圖表，Jupyter Notebook等實時交互方式。SDK方面，兼容主流深度學習框架，例如TensorFlow、Keras、Caffe、MXNet。

然後，范融針對這套架構如何在滿足之前提出的五項用戶需求，進行了詳細的講解。

通過Docker技術實現運行環境的逐層分離：統一基礎鏡像層，負責存儲操作系統、驅動、依賴庫；分類基礎鏡像層，負責針對不同深度學習框架進行打包存儲；用戶定義鏡像層，開放給用戶編寫自己的AI代碼。通過這樣的分層管理，鏡像可以做到很好的預裝、定製、重用、兼容的特性，以此滿足第一個需求挑戰「演算法兼容性」。

通過中間接入層實現縱向擴展：以存儲類型的縱向擴展為例，通過中間層向下適配各類存儲類型，如對象存儲，NFS等，對使用存儲的上層伺服器提供統一的訪問介面，並且在這個層次上實現帶寬控制、許可權控制、完整性檢查等。這樣就可以對用戶無影響的情況下，滿足數據類型「縱向擴展性」的要求。類似的，計算節點接入層完成了算力節點類型的「縱向擴展性」的要求。

此外，為了支持「橫向擴展性」和「高可用」的需求，需要將原來單個的訓練任務分散式化，使其拆分成若干個同構的小任務讓不同的伺服器來運行。對於AI訓練服務，支持對於標準Tensorflow和MXNet自動分散式任務拆分；對於AI在線服務，由於是WebService形式，天然支持分散式部署。隨後，動態監控計算節點運行壓力，憑藉UCloud雲上海量的計算資源，動態彈性的擴容，以此滿足「橫向擴展性」。同時，UCloud計算集群分地域部署，隨時災備切換，以此保證「高可用」需求。

在講解完公有雲系統架構後，范融轉而介紹私有雲實施經驗。憑藉公有雲上良好的分層模塊的架構設計，API接入層、計算節點接入層、數據存儲接入層將UCloud AI PaaS平台的核心組件全方位包圍，使其能夠方便的接入各類賬號、資源、許可權、數據管理組件，以此達到快速將公有雲AI PaaS平台特性遷移部署到私有雲的「環境遷移」需求。

針對私有雲方案的應用，范融列舉了一個私有雲接入層的具體案例，被稱為一體機方案。如果用戶有一個完整一體機，完全可以搭建自己的AI演算法庫，將演算法庫通過API調入到私有雲中進行訓練，訓練出來的模型自動部署到在線服務平台上，然後與自己業務系統的微服務對接，這樣一來用戶生態私有雲的布置就能快速部署完成。

最後，范融分享了幾個實際的客戶案例：

案例1：使用UCloud AI平台部署多場景的圖片特徵標籤在線服務，灰度發布、各場景資源隔離、彈性擴容的特性，為客戶大大節省了客戶系統的運行維護成本。

案例2：使用UCloud AI平台對大量樣本文件的OCR圖片識別場景進行自動化分散式訓練。將用戶原本在單機運行訓練演算法，自動分散式到8台4卡P40物理機運行，大大提升了用戶的訓練時間，加快了演算法迭代開發的周期

案例3：使用UCloud AI平台支撐AI Chanllenger全國挑戰賽。彈性擴容的特性，很好的為大賽高峰使用需求提供穩定支撐。按需收費的特性，極大節省了大賽組委會的賽事運營成本。

《資料庫高可用容災方案設計和實現》

——UCloud資深存儲研發工程師 丁順

開放式的精彩分享仍在繼續，在有關「資料庫高可用容災方案設計和實現」的分享中，UCloud雲資料庫的資深研發工程師丁順，對傳統資料庫服務與高可用資料庫進行了對比。

傳統的資料庫服務是一個資料庫，一旦發生宕機的情況，整個數據的讀寫全部不可用，就會對服務造成很大的影響，為了解決這個問題就要想辦法提高整個資料庫服務的可能性。所以為解決資料庫宕機導致數據無法讀寫，確保對運維、提供服務帶來更多便利要求的前提下，高可用資料庫應運而生。

高可用資料庫既然帶來那麼多好處，如何設計一個高可用資料庫系統？需要著重關注哪些問題呢？首先，各個資料庫節點之間的數據是如何做到同步的？丁順表示，這就需要保證資料庫在發生一個切換之後，同時需要最新的數據的要求下，數據同步是很重要的，否則如果切換之後發現數據不一致，這個問題比較嚴重，所以要保證各個節點的數據及時同步。同步過程中勢必會對整個系統帶來一些影響，也需要關注。

容災是怎麼進行。不同架構的容災切換的複雜度是不一樣的，在設計高可用資料庫當中要儘可能去簡化容災的步驟，因為只有步驟做到簡化，容災時間才可以縮短，對用戶的影響會更小。

「此外，我們需要關注的是運維效率問題。有可能一個資料庫設計出來之後確實具備高可用能力，但一些容災和運維操作十分繁瑣，也不利於資料庫的長期維護。」他補充道。

面對高可用資料庫帶來的好處，丁順還詳細分析了業界典型高可用資料庫架構，並按照數據同步的方式進行了劃分，其中包括共享存儲、操作系統實時數據塊複製、基於主從的複製、基於一致性協議的複製四種數據同步的方式。

除此以外，他還提出了UCloud雲資料庫產品UDB。據了解，UDB採用經典的主從模式設計，為了提高數據一致性，採用了半同步的模式，用來保證可靠性。

具體來說，首先要考慮原生的MySQL的兼容；另外架構可以儘可能涵蓋不同的版本，有一些比較老的版本也可以去兼容高可用架構，享受高可用的紅利；整個架構可以涵蓋不同的應用場景，也就是說，假設有很多不同的存儲引擎，都可以進行涵蓋。

基於這樣的設計思路，所以UCloud高可用資料庫產品採用比較經典的主從模式來進行設計，即Master DB和Standby DB雙主架構；為了提高數據一致性採用了半同步的模式，提高它的可靠性；同時由於高可用架構下可能還會掛載其他的備庫，所以使用了GTID，保證做切換的時候可以讓下面的備庫進行無縫感知等。

關於高可用資料庫運維經驗，其中日常要進行例行巡檢是非常重要的。在巡檢中發現有時候高可用資料庫延時過大是導致高可用資料庫無法切換的重要原因之一，所以在日巡檢當中需要把主從延時這個指標作為一個非常重要的時間指標加以關注。

另外，定期容災演練很有必要。丁順說：「因為有時候我們會改變容災邏輯，就需要自己進行一個容災演練才能發現一些問題，尤其需要去滿足演變之後數據切換是不是一致，因為非常害怕數據切換以後不一致的情況。」

最後，在運維過程中對高可用容災記錄要進行全方位記錄，並且切換失敗時要進行及時的告警，這樣才能幫助做以後的一些日誌復盤分析，同時發現不能容災情況下能夠第一時間人工介入，這點也非常重要。

《技術內幕：分散式存儲中的數據分布演算法》

——奧思數據 創始人&CTO 李明宇

不論是雲存儲服務、企業級存儲系統，還是區塊鏈存儲，分散式存儲已經成為了數據存儲的主流方案，傳統的集中式存儲設備正在淡出IT舞台。數據分布演算法是分散式存儲最核心的技術之一，不僅僅要考慮到數據分布的均勻性、定址的效率，還要考慮擴充和減少容量時數據遷移的開銷，兼顧副本的一致性和可用性。

具體到企業級存儲和區塊鏈存儲的不同場景，對數據分布的需求又有很大不同，一個演算法並不能解決所有的問題，奧思數據創始人&CTO李明宇在分享中，將比較幾種典型的數據分布演算法，分析其優缺點並討論在具體應用中會遇到的諸多問題。

編程的時候如果有N個小的空間，我們要把數據均勻分布下去怎麼做？最簡單用哈希表來做，一致性哈希演算法首先計算複雜度非常低，只要算一次哈希匹配就可以了，均勻性比較好，但擴容的時候呢？

所以真正應用的時候都是改進型哈希演算法，直接應用肯定會遇到一些挑戰。究其原因，他認為，首先數據的分布是隨機的，如果用到企業級存儲往往有哪些要求？其中需要提及的多副本可靠存儲，即一個文件存多個副本，保證任何一個文件發生故障都不會丟失。有人說，怕數據丟失可以存十份，一個硬體存儲的價格、硬體成本，目前做得好的也在50萬左右。存10份，意味著多出來450萬的成本，一個PB，不可接受。

成本接受的前提下數據還不能丟，怎麼辦？即便存了三份數據，五份數據，因為算哈希是隨機的，所以怎麼保證五個副本不放在一個盤上，或者這個區間或者那個區間？其實這是有一定概率的。

另外很重要的一點，一致性哈希演算法是最基礎的，它構成了現在分散式存儲數據分布的基礎演算法，數據怎麼找到它的存儲位置？算哈希匹配，這樣能夠極大的提高效率。換句話說如果採用查表的方式，Objecto的數量太多了，查表的負擔非常大，存儲開銷非常大，一致性哈希演算法不用查表。

企業級存儲與區塊鏈存儲考慮的問題又不一樣，企業級存儲主要考慮全局可控，故障域和權重的因素，實際上在擴容的時候並不是擴哈希到設備的映射，而是擴PG到設備的映射，會發現PG可能並沒有增多，但是OSD數量增多了，隨之PG到OSD的映射也就改變了。

除了精彩的主題分享之外，本次2018 UCan下午茶年終收官還準備了精彩紛呈的展區互動和抽獎環節，不僅增強了現場參會者的互動交流，更為本次沙龍增添光彩。

雲計算，為各種新技術提供表演的舞台；大數據技術為人工智慧提供了豐富優質的數據資源；而人工智慧技術，則被認為是對人類產生深遠影響的另一項關鍵技術，但如果不能深入理解「分散式」，這些至關重要的前沿科技也就不能被更好地了解和運用。UCan下午茶北京站關於雲上「分散式」的探討雖然暫時告一段落，但企業們對其關注並深入挖掘的歷程似乎才剛剛開始！

-End-

喜歡就點擊「好看」吧！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！