這不，就在剛剛結束不久的UCan下午茶北京站活動中，多位技術大咖針對云上的分布式實踐展開了深入探討，干貨滿滿。
由于是年底的收官之作，本次UCan下午茶北京站活動采用了Keynote與開放式演講相結合的形式，并伴隨別樣精彩的答題活動以及抽獎環(huán)節(jié)，無論是形式的新穎呈現(xiàn)以及內(nèi)容的精彩程度統(tǒng)統(tǒng)往勝從前，現(xiàn)場人頭攢動，開發(fā)者們關注無限！
現(xiàn)場人頭攢動
據(jù)了解，現(xiàn)場幾百名開發(fā)者熱情參與了交流與互動，尤其對AI平臺、分布式數(shù)據(jù)庫、數(shù)據(jù)庫高可用性容災方案以及分布式存儲等十分關注。此外，這些探討也將為云計算、大數(shù)據(jù)以及AI領域的從業(yè)者們提供借鑒與新思路，并十分值得廣大開發(fā)者們認真學習與總結！
《新一代公有云分布式數(shù)據(jù)庫——UCloud Exodus》
——UCloud關系型存儲研發(fā)部負責人 羅成對
眾所周知，性能和容量一直是數(shù)據(jù)庫關注的核心議題。尤其在公有云環(huán)境下更是挑戰(zhàn)巨大，而UCloud云數(shù)據(jù)庫團隊一直在嘗試如何優(yōu)雅地解決這個難題。
在最先“揭面”的Keynote的演講環(huán)節(jié)中， UCloud關系型存儲研發(fā)部負責人羅成對在“新一代公有云分布式數(shù)據(jù)庫——UCloud Exodus”的主題分享中表示，在“用戶的需求就是我們下一個產(chǎn)品”的理念影響下，從2013年UCloud推出第一款云數(shù)據(jù)產(chǎn)品MySQL至今，云數(shù)據(jù)庫產(chǎn)品上線將近6年且保持穩(wěn)定運營，有數(shù)據(jù)顯示共覆蓋全球29個可用區(qū)，服務上萬家企業(yè)用戶，實例數(shù)幾萬個，數(shù)據(jù)量達到10PB+，單用戶最多實例數(shù)超過6千個，單用戶數(shù)據(jù)量1.8PB。
除了展現(xiàn)云數(shù)據(jù)庫產(chǎn)品的成熟迭代之外，他還表明在實踐過程中總結出的，目前云數(shù)據(jù)庫面臨的運營痛點，例如容量、性價比、性能、兼容性等，而解決這些痛點的高效方式，在于對云數(shù)據(jù)庫的深刻理解，例如1.0階段出現(xiàn)的云數(shù)據(jù)庫就是云+數(shù)據(jù)庫，大家都能意識到這個階段的重點在于托管、零維護。
但2.0階段如何實現(xiàn)云計算的共生，怎樣實現(xiàn)矩陣式進化？本質上就是如何滿足各種各樣用戶更高級別的追求，這是需要提升的核心所在，是要達到數(shù)據(jù)層和基礎設施層的共生復用。
在產(chǎn)品層面，UCloud Exodus就是這樣一款應時而生的云數(shù)據(jù)庫。羅成對表示，Exodus支持最主流的開源數(shù)據(jù)庫MySQL，協(xié)議完全兼容，通過融合最新軟硬件技術，包括RDMA、Skylake、SPDK、用戶態(tài)文件系統(tǒng)等來解鎖新的能力。
從架構層面看，Exodus可以簡單看分為兩層，分別是上面的計算層，以及下面的存儲層。 兩層之間通過超高性能網(wǎng)絡連接。
存儲層是UCloud自研的新一代高性能分布式存儲；而計算層則采用了原生的MySQL協(xié)議的DBServer，可能未來會發(fā)展支持PostgreSQL協(xié)議；二層之間走用戶態(tài)文件系統(tǒng)UXFS。
可以看到，其中的典型架構與平時使用的主從架構是一樣的，主從可以在不同的可用區(qū)甚至跨域，實現(xiàn)多級容災部署。一主帶多從，靈活而且整體性能強。通過共享存儲來解決高可用的問題，而DB的核心問題之一就是高可用，在這種架構下，可解決很多1.0階段無法搞定的難題。
總結來看，基于計算存儲分離新型架構，UCloud采用了最新一代高性能分布式存儲系統(tǒng)，計算層采用深度定制的MySQL InnoDB引擎，架構設計上支持一主多從。
“前端接入的是UXFS，提供的是用戶態(tài)的IO棧，當DB接入到UXFS之后，直接通過RDMA到存儲節(jié)點。存儲層細分為兩層，上面一層是Segment Server，下一層是ChunkServer。
通過增加SegmentServer，將DB需要的隨機寫IO轉化為ChunkServer的順序IO。整個IO路徑并不完全強依賴MetaNode，將IO路徑去除索引，減少一跳IO，從而提高IO性能。”他補充道。
分布式存儲一個核心點是數(shù)據(jù)分布，很關鍵一點就是告訴人們應該去哪里獲取數(shù)據(jù)。怎么理解？就是內(nèi)部通過一個算法實現(xiàn)，我們采用一個算法計算出數(shù)據(jù)到底在哪兒，這樣的好處是可以減少IO的一跳，這對數(shù)據(jù)庫提升非常明顯。計算存儲分離架構，帶來的另外一個好處是，計算和存儲單獨計費、按量付費，存儲層自帶異步EC，進一步節(jié)省存儲空間，整體體現(xiàn)出來則是Exodus性價比超高。通過這些設計，Exodus一舉解決了云數(shù)據(jù)庫容量、性能、性價比、兼容性等四大痛點。最后，羅成對介紹了Exodus（UXDB）的開發(fā)計劃，并透露該產(chǎn)品會在2019年Q3進行公測。
《Kyligence：釋放大數(shù)據(jù)生產(chǎn)力》
——Kyligence 云與生態(tài)合作部副總裁 劉一鳴
如今大數(shù)據(jù)分析技術層出不窮，技術棧日新月異，在帶來海量數(shù)據(jù)處理能力的同時，數(shù)據(jù)分析的門檻依舊很高，在查詢性能、數(shù)據(jù)建模易用性、語義模型表達能力、高并發(fā)響應等場景均存在最后一公里問題。而Apache Kylin + cloud，是針對數(shù)據(jù)分析生產(chǎn)力場景設計，將行業(yè)最佳數(shù)據(jù)分析實踐沉淀為Apache頂級項目的成熟產(chǎn)品。
在題為《Kyligence：釋放大數(shù)據(jù)生產(chǎn)力》的分享中，劉一鳴針對數(shù)據(jù)分析生產(chǎn)力場景設計，詳細介紹了Kyligence在云端的業(yè)務實踐。
他表示， Kyligence就是要把這套方法論沉淀成一個項目，從數(shù)據(jù)源出發(fā)，我們可以看到支持HIVE、Kafka，以及其他的數(shù)據(jù)作為數(shù)據(jù)源；其次中間有一個環(huán)節(jié)叫計算，麒麟核心思想是通過預計算算出索引，這樣查詢的時候才能快。
具體來說，麒麟內(nèi)部有兩個生命周期，第一是構建的過程，這個過程就是要把原始的數(shù)據(jù)讀取出來，然后通過用戶模型，把用戶關心的事情通過一套可擴展計算框架算出一些中間結果；第二是查詢，查詢時候會查出一般的SQL語句，會直接根據(jù)中間結果獲得最終結果，這個過程并不需要很大的集群，每個查詢看起來都像RPC一樣快，這就是以前查詢HIVE等是以分鐘為單位，現(xiàn)在可以變成以毫秒為單位的原因。
此外，據(jù)了解這兩個過程的復雜程度并不一樣。“第一個構建過程要處理海量數(shù)據(jù)，這部分麒麟利用了很多大數(shù)據(jù)技術，包括存儲方面依賴HDFS，計算方面依賴的YARN來做調度，使用Map Reduce框架和Spark完成分布式計算，所以很有可能構建之初需要處理數(shù)據(jù)可能是100G，過段時間或者明天可能是100T，這完全是可擴展的。”劉一鳴進一步補充道。
關于“數(shù)倉是如何建設的”問題，他在演講中也有詳盡提及。過去，傳統(tǒng)數(shù)倉的建設需要從很多系統(tǒng)中讀取數(shù)據(jù)，例如OLTP、ERP、CRM系統(tǒng)等，其中會涉及到很長的流程，還需要保證數(shù)據(jù)的整合、清理、過濾、語義一致性以及保持模型層的完整，最后的環(huán)節(jié)才是導入一個數(shù)倉中，然后對接整個前端的應用需求。
相比而言，現(xiàn)在的做法可以簡單概括為Kyligence=Kylin+Intelligence，就是加入了很多智能的元素在其中，所以麒麟通過數(shù)據(jù)結構的變化能夠帶來更好的性能、更好的語義層、更多的梳理并發(fā)，但這些事情還是會很依賴建模的準確度，模型設計師對需求場景的掌握、對業(yè)務的掌握以及對表的理解，這一點需要被明確。
據(jù)了解，Kyligence的客戶類型分很多種，早期只是手機互聯(lián)網(wǎng)應用的范疇，后來技術發(fā)展更多向金融、證券、保險、電信以及制造業(yè)轉型，共通的一點，這些行業(yè)都有海量數(shù)據(jù)收集的場景，以及很強的互聯(lián)網(wǎng)式精細化分析的需求。
現(xiàn)場，劉一鳴為開發(fā)者們列舉了招商銀行的應用案例加以說明。他總結道，招商銀行的數(shù)倉建設大概有二十多年的歷史了，所以不可避免遇到一個問題，那就是數(shù)據(jù)孤島。
“不同的部門，例如信用卡部門、數(shù)倉部門、風控部門，數(shù)據(jù)不一致，主要是因為存在不同的平臺上。如果通通放在一起就會發(fā)現(xiàn)，都放入Teradata中有點兒小貴，放在GreenPlum中并發(fā)度又不夠，如果向Hadoop平臺做遷移，作為全公司統(tǒng)一的數(shù)倉平臺，分析的語義層模型能不能統(tǒng)一也是個問題。所以用麒麟做成一個統(tǒng)一的數(shù)據(jù)服務層，上面對接傳統(tǒng)招行中使用的BI工具，包括Cognos、MSTR、Superset等，如此就形成了整個招商銀行內(nèi)部，80多個不同的部門使用的統(tǒng)一場景架構。”
《AI PaaS平臺實踐》
——UCloud LabU深度學習開發(fā)工程師 范融
在UCan 下午茶深圳站曾進行精彩分享的UCloud LabU深度學習開發(fā)工程師范融也準時來到收官現(xiàn)場，作為開放式演講環(huán)節(jié)中唯一的女技術工程師，帶來主題為“AI PaaS平臺實踐”的分享。
首先，范融說明了AI場景下做PaaS面臨的挑戰(zhàn)。在研發(fā)AI的整個周期中，用戶面臨諸如AI選型、AI開發(fā)周期、應用迭代、訓練及推理環(huán)境部署等痛點。無論是普通開發(fā)者還是企業(yè)用戶都希望有一種解決方案，它可以兼容更多深度學習算法以及框架，并保證存儲、網(wǎng)絡性能優(yōu)勢。最后，她將AI PaaS平臺的需求總結為算法兼容性、縱向擴展、橫向擴展、高可用、環(huán)境遷移。
接著，她詳細介紹了UCloud關于基礎平臺架構的很多技術干貨。在整個AI 平臺架構中，中間層是訓練平臺和在線服務平臺兩個基礎平臺，他們都擁有錯誤處理、負載均衡等功能；底層部分通過計算節(jié)點接入層兼容了各種異構的計算節(jié)點，如GPU、CPU; 在存儲方面通過統(tǒng)一的接入層，讓各種類型的存儲介質接入平臺后，面向開發(fā)者們訪問方式都會像本地訪問一樣簡單快捷。由于不同的用戶有不同的使用習慣，例如有的用戶可能習慣圖形化的接入，因為直白，所見即所得；而有的用戶需要與自己的內(nèi)部系統(tǒng)做連接，所以迫切要求SDK做全自動化的腳本介入等。在架構上層有一個API的接入層，做到兼容各類用戶訪問需求。圖形化界面方面，支持訓練日志、服務狀態(tài)、TensorBoard圖表，Jupyter Notebook等實時交互方式。SDK方面，兼容主流深度學習框架，例如TensorFlow、Keras、Caffe、MXNet。
然后，范融針對這套架構如何在滿足之前提出的五項用戶需求，進行了詳細的講解。
通過Docker技術實現(xiàn)運行環(huán)境的逐層分離：統(tǒng)一基礎鏡像層，負責存儲操作系統(tǒng)、驅動、依賴庫；分類基礎鏡像層，負責針對不同深度學習框架進行打包存儲；用戶定義鏡像層，開放給用戶編寫自己的AI代碼。通過這樣的分層管理，鏡像可以做到很好的預裝、定制、重用、兼容的特性，以此滿足第一個需求挑戰(zhàn)“算法兼容性”。
通過中間接入層實現(xiàn)縱向擴展：以存儲類型的縱向擴展為例，通過中間層向下適配各類存儲類型，如對象存儲，NFS等，對使用存儲的上層服務器提供統(tǒng)一的訪問接口，并且在這個層次上實現(xiàn)帶寬控制、權限控制、完整性檢查等。這樣就可以對用戶無影響的情況下，滿足數(shù)據(jù)類型“縱向擴展性”的要求。類似的，計算節(jié)點接入層完成了算力節(jié)點類型的“縱向擴展性”的要求。
此外，為了支持“橫向擴展性”和“高可用”的需求，需要將原來單個的訓練任務分布式化，使其拆分成若干個同構的小任務讓不同的服務器來運行。對于AI訓練服務，支持對于標準Tensorflow和MXNet自動分布式任務拆分；對于AI在線服務，由于是WebService形式，天然支持分布式部署。隨后，動態(tài)監(jiān)控計算節(jié)點運行壓力，憑借UCloud云上海量的計算資源，動態(tài)彈性的擴容，以此滿足“橫向擴展性”。同時，UCloud計算集群分地域部署，隨時災備切換，以此保證“高可用”需求。
在講解完公有云系統(tǒng)架構后，范融轉而介紹私有云實施經(jīng)驗。憑借公有云上良好的分層模塊的架構設計，API接入層、計算節(jié)點接入層、數(shù)據(jù)存儲接入層將UCloud AI PaaS平臺的核心組件全方位包圍，使其能夠方便的接入各類賬號、資源、權限、數(shù)據(jù)管理組件，以此達到快速將公有云AI PaaS平臺特性遷移部署到私有云的“環(huán)境遷移”需求。
針對私有云方案的應用，范融列舉了一個私有云接入層的具體案例，被稱為一體機方案。如果用戶有一個完整一體機，完全可以搭建自己的AI算法庫，將算法庫通過API調入到私有云中進行訓練，訓練出來的模型自動部署到在線服務平臺上，然后與自己業(yè)務系統(tǒng)的微服務對接，這樣一來用戶生態(tài)私有云的布置就能快速部署完成。
最后，范融分享了幾個實際的客戶案例：
案例1：使用UCloud AI平臺部署多場景的圖片特征標簽在線服務，灰度發(fā)布、各場景資源隔離、彈性擴容的特性，為客戶大大節(jié)省了客戶系統(tǒng)的運行維護成本。
案例2：使用UCloud AI平臺對大量樣本文件的OCR圖片識別場景進行自動化分布式訓練。將用戶原本在單機運行訓練算法，自動分布式到8臺4卡P40物理機運行，大大提升了用戶的訓練時間，加快了算法迭代開發(fā)的周期
案例3：使用UCloud AI平臺支撐AI Chanllenger全國挑戰(zhàn)賽。彈性擴容的特性，很好的為大賽高峰使用需求提供穩(wěn)定支撐。按需收費的特性，極大節(jié)省了大賽組委會的賽事運營成本。
《數(shù)據(jù)庫高可用容災方案設計和實現(xiàn)》
——UCloud資深存儲研發(fā)工程師 丁順
開放式的精彩分享仍在繼續(xù)，在有關“數(shù)據(jù)庫高可用容災方案設計和實現(xiàn)”的分享中，UCloud云數(shù)據(jù)庫的資深研發(fā)工程師丁順，對傳統(tǒng)數(shù)據(jù)庫服務與高可用數(shù)據(jù)庫進行了對比。
傳統(tǒng)的數(shù)據(jù)庫服務是一個數(shù)據(jù)庫，一旦發(fā)生宕機的情況，整個數(shù)據(jù)的讀寫全部不可用，就會對服務造成很大的影響，為了解決這個問題就要想辦法提高整個數(shù)據(jù)庫服務的可能性。所以為解決數(shù)據(jù)庫宕機導致數(shù)據(jù)無法讀寫，確保對運維、提供服務帶來更多便利要求的前提下，高可用數(shù)據(jù)庫應運而生。
高可用數(shù)據(jù)庫既然帶來那么多好處，如何設計一個高可用數(shù)據(jù)庫系統(tǒng)？需要著重關注哪些問題呢？首先，各個數(shù)據(jù)庫節(jié)點之間的數(shù)據(jù)是如何做到同步的？丁順表示，這就需要保證數(shù)據(jù)庫在發(fā)生一個切換之后，同時需要最新的數(shù)據(jù)的要求下，數(shù)據(jù)同步是很重要的，否則如果切換之后發(fā)現(xiàn)數(shù)據(jù)不一致，這個問題比較嚴重，所以要保證各個節(jié)點的數(shù)據(jù)及時同步。同步過程中勢必會對整個系統(tǒng)帶來一些影響，也需要關注。
容災是怎么進行。不同架構的容災切換的復雜度是不一樣的，在設計高可用數(shù)據(jù)庫當中要盡可能去簡化容災的步驟，因為只有步驟做到簡化，容災時間才可以縮短，對用戶的影響會更小。
“此外，我們需要關注的是運維效率問題。有可能一個數(shù)據(jù)庫設計出來之后確實具備高可用能力，但一些容災和運維操作十分繁瑣，也不利于數(shù)據(jù)庫的長期維護。”他補充道。
面對高可用數(shù)據(jù)庫帶來的好處，丁順還詳細分析了業(yè)界典型高可用數(shù)據(jù)庫架構，并按照數(shù)據(jù)同步的方式進行了劃分，其中包括共享存儲、操作系統(tǒng)實時數(shù)據(jù)塊復制、基于主從的復制、基于一致性協(xié)議的復制四種數(shù)據(jù)同步的方式。
除此以外，他還提出了UCloud云數(shù)據(jù)庫產(chǎn)品UDB。據(jù)了解，UDB采用經(jīng)典的主從模式設計，為了提高數(shù)據(jù)一致性，采用了半同步的模式，用來保證可靠性。
具體來說，首先要考慮原生的MySQL的兼容；另外架構可以盡可能涵蓋不同的版本，有一些比較老的版本也可以去兼容高可用架構，享受高可用的紅利；整個架構可以涵蓋不同的應用場景，也就是說，假設有很多不同的存儲引擎，都可以進行涵蓋。
基于這樣的設計思路，所以UCloud高可用數(shù)據(jù)庫產(chǎn)品采用比較經(jīng)典的主從模式來進行設計，即Master DB和Standby DB雙主架構；為了提高數(shù)據(jù)一致性采用了半同步的模式，提高它的可靠性；同時由于高可用架構下可能還會掛載其他的備庫，所以使用了GTID，保證做切換的時候可以讓下面的備庫進行無縫感知等。
關于高可用數(shù)據(jù)庫運維經(jīng)驗，其中日常要進行例行巡檢是非常重要的。在巡檢中發(fā)現(xiàn)有時候高可用數(shù)據(jù)庫延時過大是導致高可用數(shù)據(jù)庫無法切換的重要原因之一，所以在日巡檢當中需要把主從延時這個指標作為一個非常重要的時間指標加以關注。
另外，定期容災演練很有必要。丁順說：“因為有時候我們會改變?nèi)轂倪壿嫞托枰约哼M行一個容災演練才能發(fā)現(xiàn)一些問題，尤其需要去滿足演變之后數(shù)據(jù)切換是不是一致，因為非常害怕數(shù)據(jù)切換以后不一致的情況。”
最后，在運維過程中對高可用容災記錄要進行全方位記錄，并且切換失敗時要進行及時的告警，這樣才能幫助做以后的一些日志復盤分析，同時發(fā)現(xiàn)不能容災情況下能夠第一時間人工介入，這點也非常重要。
《技術內(nèi)幕：分布式存儲中的數(shù)據(jù)分布算法》
——奧思數(shù)據(jù) 創(chuàng)始人&CTO 李明宇
不論是云存儲服務、企業(yè)級存儲系統(tǒng)，還是區(qū)塊鏈存儲，分布式存儲已經(jīng)成為了數(shù)據(jù)存儲的主流方案，傳統(tǒng)的集中式存儲設備正在淡出IT舞臺。數(shù)據(jù)分布算法是分布式存儲最核心的技術之一，不僅僅要考慮到數(shù)據(jù)分布的均勻性、尋址的效率，還要考慮擴充和減少容量時數(shù)據(jù)遷移的開銷，兼顧副本的一致性和可用性。
具體到企業(yè)級存儲和區(qū)塊鏈存儲的不同場景，對數(shù)據(jù)分布的需求又有很大不同，一個算法并不能解決所有的問題，奧思數(shù)據(jù)創(chuàng)始人&CTO李明宇在分享中，將比較幾種典型的數(shù)據(jù)分布算法，分析其優(yōu)缺點并討論在具體應用中會遇到的諸多問題。
編程的時候如果有N個小的空間，我們要把數(shù)據(jù)均勻分布下去怎么做？最簡單用哈希表來做，一致性哈希算法首先計算復雜度非常低，只要算一次哈希匹配就可以了，均勻性比較好，但擴容的時候呢？
所以真正應用的時候都是改進型哈希算法，直接應用肯定會遇到一些挑戰(zhàn)。究其原因，他認為，首先數(shù)據(jù)的分布是隨機的，如果用到企業(yè)級存儲往往有哪些要求？其中需要提及的多副本可靠存儲，即一個文件存多個副本，保證任何一個文件發(fā)生故障都不會丟失。有人說，怕數(shù)據(jù)丟失可以存十份，一個硬件存儲的價格、硬件成本，目前做得好的也在50萬左右。存10份，意味著多出來450萬的成本，一個PB，不可接受。
成本接受的前提下數(shù)據(jù)還不能丟，怎么辦？即便存了三份數(shù)據(jù)，五份數(shù)據(jù)，因為算哈希是隨機的，所以怎么保證五個副本不放在一個盤上，或者這個區(qū)間或者那個區(qū)間？其實這是有一定概率的。
另外很重要的一點，一致性哈希算法是最基礎的，它構成了現(xiàn)在分布式存儲數(shù)據(jù)分布的基礎算法，數(shù)據(jù)怎么找到它的存儲位置？算哈希匹配，這樣能夠極大的提高效率。換句話說如果采用查表的方式，Objecto的數(shù)量太多了，查表的負擔非常大，存儲開銷非常大，一致性哈希算法不用查表。
企業(yè)級存儲與區(qū)塊鏈存儲考慮的問題又不一樣，企業(yè)級存儲主要考慮全局可控，故障域和權重的因素，實際上在擴容的時候并不是擴哈希到設備的映射，而是擴PG到設備的映射，會發(fā)現(xiàn)PG可能并沒有增多，但是OSD數(shù)量增多了，隨之PG到OSD的映射也就改變了。
除了精彩的主題分享之外，本次2018 UCan下午茶年終收官還準備了精彩紛呈的展區(qū)互動和抽獎環(huán)節(jié)，不僅增強了現(xiàn)場參會者的互動交流，更為本次沙龍增添光彩。
云計算，為各種新技術提供表演的舞臺；大數(shù)據(jù)技術為人工智能提供了豐富優(yōu)質的數(shù)據(jù)資源；而人工智能技術，則被認為是對人類產(chǎn)生深遠影響的另一項關鍵技術，但如果不能深入理解“分布式”，這些至關重要的前沿科技也就不能被更好地了解和運用。UCan下午茶北京站關于云上“分布式”的探討雖然暫時告一段落，但企業(yè)們對其關注并深入挖掘的歷程似乎才剛剛開始！
京公網(wǎng)安備 11010502049343號