這不，就在剛剛結(jié)束不久的UCan下午茶北京站活動中，多位技術(shù)大咖針對云上的分布式實(shí)踐展開了深入探討，干貨滿滿。

由于是年底的收官之作，本次UCan下午茶北京站活動采用了Keynote與開放式演講相結(jié)合的形式，并伴隨別樣精彩的答題活動以及抽獎環(huán)節(jié)，無論是形式的新穎呈現(xiàn)以及內(nèi)容的精彩程度統(tǒng)統(tǒng)往勝從前，現(xiàn)場人頭攢動，開發(fā)者們關(guān)注無限！

現(xiàn)場人頭攢動

據(jù)了解，現(xiàn)場幾百名開發(fā)者熱情參與了交流與互動，尤其對AI平臺、分布式數(shù)據(jù)庫、數(shù)據(jù)庫高可用性容災(zāi)方案以及分布式存儲等十分關(guān)注。此外，這些探討也將為云計(jì)算、大數(shù)據(jù)以及AI領(lǐng)域的從業(yè)者們提供借鑒與新思路，并十分值得廣大開發(fā)者們認(rèn)真學(xué)習(xí)與總結(jié)！

《新一代公有云分布式數(shù)據(jù)庫——UCloud Exodus》

——UCloud關(guān)系型存儲研發(fā)部負(fù)責(zé)人 羅成對

眾所周知，性能和容量一直是數(shù)據(jù)庫關(guān)注的核心議題。尤其在公有云環(huán)境下更是挑戰(zhàn)巨大，而UCloud云數(shù)據(jù)庫團(tuán)隊(duì)一直在嘗試如何優(yōu)雅地解決這個難題。

在最先“揭面”的Keynote的演講環(huán)節(jié)中， UCloud關(guān)系型存儲研發(fā)部負(fù)責(zé)人羅成對在“新一代公有云分布式數(shù)據(jù)庫——UCloud Exodus”的主題分享中表示，在“用戶的需求就是我們下一個產(chǎn)品”的理念影響下，從2013年UCloud推出第一款云數(shù)據(jù)產(chǎn)品MySQL至今，云數(shù)據(jù)庫產(chǎn)品上線將近6年且保持穩(wěn)定運(yùn)營，有數(shù)據(jù)顯示共覆蓋全球29個可用區(qū)，服務(wù)上萬家企業(yè)用戶，實(shí)例數(shù)幾萬個，數(shù)據(jù)量達(dá)到10PB+，單用戶最多實(shí)例數(shù)超過6千個，單用戶數(shù)據(jù)量1.8PB。

除了展現(xiàn)云數(shù)據(jù)庫產(chǎn)品的成熟迭代之外，他還表明在實(shí)踐過程中總結(jié)出的，目前云數(shù)據(jù)庫面臨的運(yùn)營痛點(diǎn)，例如容量、性價(jià)比、性能、兼容性等，而解決這些痛點(diǎn)的高效方式，在于對云數(shù)據(jù)庫的深刻理解，例如1.0階段出現(xiàn)的云數(shù)據(jù)庫就是云+數(shù)據(jù)庫，大家都能意識到這個階段的重點(diǎn)在于托管、零維護(hù)。

但2.0階段如何實(shí)現(xiàn)云計(jì)算的共生，怎樣實(shí)現(xiàn)矩陣式進(jìn)化？本質(zhì)上就是如何滿足各種各樣用戶更高級別的追求，這是需要提升的核心所在，是要達(dá)到數(shù)據(jù)層和基礎(chǔ)設(shè)施層的共生復(fù)用。

在產(chǎn)品層面，UCloud Exodus就是這樣一款應(yīng)時而生的云數(shù)據(jù)庫。羅成對表示，Exodus支持最主流的開源數(shù)據(jù)庫MySQL，協(xié)議完全兼容，通過融合最新軟硬件技術(shù)，包括RDMA、Skylake、SPDK、用戶態(tài)文件系統(tǒng)等來解鎖新的能力。

從架構(gòu)層面看，Exodus可以簡單看分為兩層，分別是上面的計(jì)算層，以及下面的存儲層。 兩層之間通過超高性能網(wǎng)絡(luò)連接。

存儲層是UCloud自研的新一代高性能分布式存儲；而計(jì)算層則采用了原生的MySQL協(xié)議的DBServer，可能未來會發(fā)展支持PostgreSQL協(xié)議；二層之間走用戶態(tài)文件系統(tǒng)UXFS。

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

總結(jié)來看，基于計(jì)算存儲分離新型架構(gòu)，UCloud采用了最新一代高性能分布式存儲系統(tǒng)，計(jì)算層采用深度定制的MySQL InnoDB引擎，架構(gòu)設(shè)計(jì)上支持一主多從。

“前端接入的是UXFS，提供的是用戶態(tài)的IO棧，當(dāng)DB接入到UXFS之后，直接通過RDMA到存儲節(jié)點(diǎn)。存儲層細(xì)分為兩層，上面一層是Segment Server，下一層是ChunkServer。

通過增加SegmentServer，將DB需要的隨機(jī)寫IO轉(zhuǎn)化為ChunkServer的順序IO。整個IO路徑并不完全強(qiáng)依賴MetaNode，將IO路徑去除索引，減少一跳IO，從而提高IO性能。”他補(bǔ)充道。

分布式存儲一個核心點(diǎn)是數(shù)據(jù)分布，很關(guān)鍵一點(diǎn)就是告訴人們應(yīng)該去哪里獲取數(shù)據(jù)。怎么理解？就是內(nèi)部通過一個算法實(shí)現(xiàn)，我們采用一個算法計(jì)算出數(shù)據(jù)到底在哪兒，這樣的好處是可以減少IO的一跳，這對數(shù)據(jù)庫提升非常明顯。計(jì)算存儲分離架構(gòu)，帶來的另外一個好處是，計(jì)算和存儲單獨(dú)計(jì)費(fèi)、按量付費(fèi)，存儲層自帶異步EC，進(jìn)一步節(jié)省存儲空間，整體體現(xiàn)出來則是Exodus性價(jià)比超高。通過這些設(shè)計(jì)，Exodus一舉解決了云數(shù)據(jù)庫容量、性能、性價(jià)比、兼容性等四大痛點(diǎn)。最后，羅成對介紹了Exodus（UXDB）的開發(fā)計(jì)劃，并透露該產(chǎn)品會在2019年Q3進(jìn)行公測。

《Kyligence：釋放大數(shù)據(jù)生產(chǎn)力》

——Kyligence 云與生態(tài)合作部副總裁 劉一鳴

如今大數(shù)據(jù)分析技術(shù)層出不窮，技術(shù)棧日新月異，在帶來海量數(shù)據(jù)處理能力的同時，數(shù)據(jù)分析的門檻依舊很高，在查詢性能、數(shù)據(jù)建模易用性、語義模型表達(dá)能力、高并發(fā)響應(yīng)等場景均存在最后一公里問題。而Apache Kylin + cloud，是針對數(shù)據(jù)分析生產(chǎn)力場景設(shè)計(jì)，將行業(yè)最佳數(shù)據(jù)分析實(shí)踐沉淀為Apache頂級項(xiàng)目的成熟產(chǎn)品。

在題為《Kyligence：釋放大數(shù)據(jù)生產(chǎn)力》的分享中，劉一鳴針對數(shù)據(jù)分析生產(chǎn)力場景設(shè)計(jì)，詳細(xì)介紹了Kyligence在云端的業(yè)務(wù)實(shí)踐。

他表示， Kyligence就是要把這套方法論沉淀成一個項(xiàng)目，從數(shù)據(jù)源出發(fā)，我們可以看到支持HIVE、Kafka，以及其他的數(shù)據(jù)作為數(shù)據(jù)源；其次中間有一個環(huán)節(jié)叫計(jì)算，麒麟核心思想是通過預(yù)計(jì)算算出索引，這樣查詢的時候才能快。

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

此外，據(jù)了解這兩個過程的復(fù)雜程度并不一樣。“第一個構(gòu)建過程要處理海量數(shù)據(jù)，這部分麒麟利用了很多大數(shù)據(jù)技術(shù)，包括存儲方面依賴HDFS，計(jì)算方面依賴的YARN來做調(diào)度，使用Map Reduce框架和Spark完成分布式計(jì)算，所以很有可能構(gòu)建之初需要處理數(shù)據(jù)可能是100G，過段時間或者明天可能是100T，這完全是可擴(kuò)展的。”劉一鳴進(jìn)一步補(bǔ)充道。

關(guān)于“數(shù)倉是如何建設(shè)的”問題，他在演講中也有詳盡提及。過去，傳統(tǒng)數(shù)倉的建設(shè)需要從很多系統(tǒng)中讀取數(shù)據(jù)，例如OLTP、ERP、CRM系統(tǒng)等，其中會涉及到很長的流程，還需要保證數(shù)據(jù)的整合、清理、過濾、語義一致性以及保持模型層的完整，最后的環(huán)節(jié)才是導(dǎo)入一個數(shù)倉中，然后對接整個前端的應(yīng)用需求。

相比而言，現(xiàn)在的做法可以簡單概括為Kyligence=Kylin+Intelligence，就是加入了很多智能的元素在其中，所以麒麟通過數(shù)據(jù)結(jié)構(gòu)的變化能夠帶來更好的性能、更好的語義層、更多的梳理并發(fā)，但這些事情還是會很依賴建模的準(zhǔn)確度，模型設(shè)計(jì)師對需求場景的掌握、對業(yè)務(wù)的掌握以及對表的理解，這一點(diǎn)需要被明確。

據(jù)了解，Kyligence的客戶類型分很多種，早期只是手機(jī)互聯(lián)網(wǎng)應(yīng)用的范疇，后來技術(shù)發(fā)展更多向金融、證券、保險(xiǎn)、電信以及制造業(yè)轉(zhuǎn)型，共通的一點(diǎn)，這些行業(yè)都有海量數(shù)據(jù)收集的場景，以及很強(qiáng)的互聯(lián)網(wǎng)式精細(xì)化分析的需求。

現(xiàn)場，劉一鳴為開發(fā)者們列舉了招商銀行的應(yīng)用案例加以說明。他總結(jié)道，招商銀行的數(shù)倉建設(shè)大概有二十多年的歷史了，所以不可避免遇到一個問題，那就是數(shù)據(jù)孤島。

“不同的部門，例如信用卡部門、數(shù)倉部門、風(fēng)控部門，數(shù)據(jù)不一致，主要是因?yàn)榇嬖诓煌钠脚_上。如果通通放在一起就會發(fā)現(xiàn)，都放入Teradata中有點(diǎn)兒小貴，放在GreenPlum中并發(fā)度又不夠，如果向Hadoop平臺做遷移，作為全公司統(tǒng)一的數(shù)倉平臺，分析的語義層模型能不能統(tǒng)一也是個問題。所以用麒麟做成一個統(tǒng)一的數(shù)據(jù)服務(wù)層，上面對接傳統(tǒng)招行中使用的BI工具，包括Cognos、MSTR、Superset等，如此就形成了整個招商銀行內(nèi)部，80多個不同的部門使用的統(tǒng)一場景架構(gòu)。”

《AI PaaS平臺實(shí)踐》

——UCloud LabU深度學(xué)習(xí)開發(fā)工程師 范融

在UCan 下午茶深圳站曾進(jìn)行精彩分享的UCloud LabU深度學(xué)習(xí)開發(fā)工程師范融也準(zhǔn)時來到收官現(xiàn)場，作為開放式演講環(huán)節(jié)中唯一的女技術(shù)工程師，帶來主題為“AI PaaS平臺實(shí)踐”的分享。

首先，范融說明了AI場景下做PaaS面臨的挑戰(zhàn)。在研發(fā)AI的整個周期中，用戶面臨諸如AI選型、AI開發(fā)周期、應(yīng)用迭代、訓(xùn)練及推理環(huán)境部署等痛點(diǎn)。無論是普通開發(fā)者還是企業(yè)用戶都希望有一種解決方案，它可以兼容更多深度學(xué)習(xí)算法以及框架，并保證存儲、網(wǎng)絡(luò)性能優(yōu)勢。最后，她將AI PaaS平臺的需求總結(jié)為算法兼容性、縱向擴(kuò)展、橫向擴(kuò)展、高可用、環(huán)境遷移。

接著，她詳細(xì)介紹了UCloud關(guān)于基礎(chǔ)平臺架構(gòu)的很多技術(shù)干貨。在整個AI 平臺架構(gòu)中，中間層是訓(xùn)練平臺和在線服務(wù)平臺兩個基礎(chǔ)平臺，他們都擁有錯誤處理、負(fù)載均衡等功能；底層部分通過計(jì)算節(jié)點(diǎn)接入層兼容了各種異構(gòu)的計(jì)算節(jié)點(diǎn)，如GPU、CPU; 在存儲方面通過統(tǒng)一的接入層，讓各種類型的存儲介質(zhì)接入平臺后，面向開發(fā)者們訪問方式都會像本地訪問一樣簡單快捷。由于不同的用戶有不同的使用習(xí)慣，例如有的用戶可能習(xí)慣圖形化的接入，因?yàn)橹卑祝娂此?；而有的用戶需要與自己的內(nèi)部系統(tǒng)做連接，所以迫切要求SDK做全自動化的腳本介入等。在架構(gòu)上層有一個API的接入層，做到兼容各類用戶訪問需求。圖形化界面方面，支持訓(xùn)練日志、服務(wù)狀態(tài)、TensorBoard圖表，Jupyter Notebook等實(shí)時交互方式。SDK方面，兼容主流深度學(xué)習(xí)框架，例如TensorFlow、Keras、Caffe、MXNet。

然后，范融針對這套架構(gòu)如何在滿足之前提出的五項(xiàng)用戶需求，進(jìn)行了詳細(xì)的講解。

通過Docker技術(shù)實(shí)現(xiàn)運(yùn)行環(huán)境的逐層分離：統(tǒng)一基礎(chǔ)鏡像層，負(fù)責(zé)存儲操作系統(tǒng)、驅(qū)動、依賴庫；分類基礎(chǔ)鏡像層，負(fù)責(zé)針對不同深度學(xué)習(xí)框架進(jìn)行打包存儲；用戶定義鏡像層，開放給用戶編寫自己的AI代碼。通過這樣的分層管理，鏡像可以做到很好的預(yù)裝、定制、重用、兼容的特性，以此滿足第一個需求挑戰(zhàn)“算法兼容性”。

通過中間接入層實(shí)現(xiàn)縱向擴(kuò)展：以存儲類型的縱向擴(kuò)展為例，通過中間層向下適配各類存儲類型，如對象存儲，NFS等，對使用存儲的上層服務(wù)器提供統(tǒng)一的訪問接口，并且在這個層次上實(shí)現(xiàn)帶寬控制、權(quán)限控制、完整性檢查等。這樣就可以對用戶無影響的情況下，滿足數(shù)據(jù)類型“縱向擴(kuò)展性”的要求。類似的，計(jì)算節(jié)點(diǎn)接入層完成了算力節(jié)點(diǎn)類型的“縱向擴(kuò)展性”的要求。

此外，為了支持“橫向擴(kuò)展性”和“高可用”的需求，需要將原來單個的訓(xùn)練任務(wù)分布式化，使其拆分成若干個同構(gòu)的小任務(wù)讓不同的服務(wù)器來運(yùn)行。對于AI訓(xùn)練服務(wù)，支持對于標(biāo)準(zhǔn)Tensorflow和MXNet自動分布式任務(wù)拆分；對于AI在線服務(wù)，由于是WebService形式，天然支持分布式部署。隨后，動態(tài)監(jiān)控計(jì)算節(jié)點(diǎn)運(yùn)行壓力，憑借UCloud云上海量的計(jì)算資源，動態(tài)彈性的擴(kuò)容，以此滿足“橫向擴(kuò)展性”。同時，UCloud計(jì)算集群分地域部署，隨時災(zāi)備切換，以此保證“高可用”需求。

在講解完公有云系統(tǒng)架構(gòu)后，范融轉(zhuǎn)而介紹私有云實(shí)施經(jīng)驗(yàn)。憑借公有云上良好的分層模塊的架構(gòu)設(shè)計(jì)，API接入層、計(jì)算節(jié)點(diǎn)接入層、數(shù)據(jù)存儲接入層將UCloud AI PaaS平臺的核心組件全方位包圍，使其能夠方便的接入各類賬號、資源、權(quán)限、數(shù)據(jù)管理組件，以此達(dá)到快速將公有云AI PaaS平臺特性遷移部署到私有云的“環(huán)境遷移”需求。

針對私有云方案的應(yīng)用，范融列舉了一個私有云接入層的具體案例，被稱為一體機(jī)方案。如果用戶有一個完整一體機(jī)，完全可以搭建自己的AI算法庫，將算法庫通過API調(diào)入到私有云中進(jìn)行訓(xùn)練，訓(xùn)練出來的模型自動部署到在線服務(wù)平臺上，然后與自己業(yè)務(wù)系統(tǒng)的微服務(wù)對接，這樣一來用戶生態(tài)私有云的布置就能快速部署完成。

最后，范融分享了幾個實(shí)際的客戶案例：

案例1：使用UCloud AI平臺部署多場景的圖片特征標(biāo)簽在線服務(wù)，灰度發(fā)布、各場景資源隔離、彈性擴(kuò)容的特性，為客戶大大節(jié)省了客戶系統(tǒng)的運(yùn)行維護(hù)成本。

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

案例3：使用UCloud AI平臺支撐AI Chanllenger全國挑戰(zhàn)賽。彈性擴(kuò)容的特性，很好的為大賽高峰使用需求提供穩(wěn)定支撐。按需收費(fèi)的特性，極大節(jié)省了大賽組委會的賽事運(yùn)營成本。

《數(shù)據(jù)庫高可用容災(zāi)方案設(shè)計(jì)和實(shí)現(xiàn)》

——UCloud資深存儲研發(fā)工程師 丁順

開放式的精彩分享仍在繼續(xù)，在有關(guān)“數(shù)據(jù)庫高可用容災(zāi)方案設(shè)計(jì)和實(shí)現(xiàn)”的分享中，UCloud云數(shù)據(jù)庫的資深研發(fā)工程師丁順，對傳統(tǒng)數(shù)據(jù)庫服務(wù)與高可用數(shù)據(jù)庫進(jìn)行了對比。

傳統(tǒng)的數(shù)據(jù)庫服務(wù)是一個數(shù)據(jù)庫，一旦發(fā)生宕機(jī)的情況，整個數(shù)據(jù)的讀寫全部不可用，就會對服務(wù)造成很大的影響，為了解決這個問題就要想辦法提高整個數(shù)據(jù)庫服務(wù)的可能性。所以為解決數(shù)據(jù)庫宕機(jī)導(dǎo)致數(shù)據(jù)無法讀寫，確保對運(yùn)維、提供服務(wù)帶來更多便利要求的前提下，高可用數(shù)據(jù)庫應(yīng)運(yùn)而生。

高可用數(shù)據(jù)庫既然帶來那么多好處，如何設(shè)計(jì)一個高可用數(shù)據(jù)庫系統(tǒng)？需要著重關(guān)注哪些問題呢？首先，各個數(shù)據(jù)庫節(jié)點(diǎn)之間的數(shù)據(jù)是如何做到同步的？丁順表示，這就需要保證數(shù)據(jù)庫在發(fā)生一個切換之后，同時需要最新的數(shù)據(jù)的要求下，數(shù)據(jù)同步是很重要的，否則如果切換之后發(fā)現(xiàn)數(shù)據(jù)不一致，這個問題比較嚴(yán)重，所以要保證各個節(jié)點(diǎn)的數(shù)據(jù)及時同步。同步過程中勢必會對整個系統(tǒng)帶來一些影響，也需要關(guān)注。

容災(zāi)是怎么進(jìn)行。不同架構(gòu)的容災(zāi)切換的復(fù)雜度是不一樣的，在設(shè)計(jì)高可用數(shù)據(jù)庫當(dāng)中要盡可能去簡化容災(zāi)的步驟，因?yàn)橹挥胁襟E做到簡化，容災(zāi)時間才可以縮短，對用戶的影響會更小。

“此外，我們需要關(guān)注的是運(yùn)維效率問題。有可能一個數(shù)據(jù)庫設(shè)計(jì)出來之后確實(shí)具備高可用能力，但一些容災(zāi)和運(yùn)維操作十分繁瑣，也不利于數(shù)據(jù)庫的長期維護(hù)。”他補(bǔ)充道。

面對高可用數(shù)據(jù)庫帶來的好處，丁順還詳細(xì)分析了業(yè)界典型高可用數(shù)據(jù)庫架構(gòu)，并按照數(shù)據(jù)同步的方式進(jìn)行了劃分，其中包括共享存儲、操作系統(tǒng)實(shí)時數(shù)據(jù)塊復(fù)制、基于主從的復(fù)制、基于一致性協(xié)議的復(fù)制四種數(shù)據(jù)同步的方式。

除此以外，他還提出了UCloud云數(shù)據(jù)庫產(chǎn)品UDB。據(jù)了解，UDB采用經(jīng)典的主從模式設(shè)計(jì)，為了提高數(shù)據(jù)一致性，采用了半同步的模式，用來保證可靠性。

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

基于這樣的設(shè)計(jì)思路，所以UCloud高可用數(shù)據(jù)庫產(chǎn)品采用比較經(jīng)典的主從模式來進(jìn)行設(shè)計(jì)，即Master DB和Standby DB雙主架構(gòu)；為了提高數(shù)據(jù)一致性采用了半同步的模式，提高它的可靠性；同時由于高可用架構(gòu)下可能還會掛載其他的備庫，所以使用了GTID，保證做切換的時候可以讓下面的備庫進(jìn)行無縫感知等。

關(guān)于高可用數(shù)據(jù)庫運(yùn)維經(jīng)驗(yàn)，其中日常要進(jìn)行例行巡檢是非常重要的。在巡檢中發(fā)現(xiàn)有時候高可用數(shù)據(jù)庫延時過大是導(dǎo)致高可用數(shù)據(jù)庫無法切換的重要原因之一，所以在日巡檢當(dāng)中需要把主從延時這個指標(biāo)作為一個非常重要的時間指標(biāo)加以關(guān)注。

另外，定期容災(zāi)演練很有必要。丁順說：“因?yàn)橛袝r候我們會改變?nèi)轂?zāi)邏輯，就需要自己進(jìn)行一個容災(zāi)演練才能發(fā)現(xiàn)一些問題，尤其需要去滿足演變之后數(shù)據(jù)切換是不是一致，因?yàn)榉浅：ε聰?shù)據(jù)切換以后不一致的情況。”

最后，在運(yùn)維過程中對高可用容災(zāi)記錄要進(jìn)行全方位記錄，并且切換失敗時要進(jìn)行及時的告警，這樣才能幫助做以后的一些日志復(fù)盤分析，同時發(fā)現(xiàn)不能容災(zāi)情況下能夠第一時間人工介入，這點(diǎn)也非常重要。

《技術(shù)內(nèi)幕：分布式存儲中的數(shù)據(jù)分布算法》

——奧思數(shù)據(jù) 創(chuàng)始人&CTO 李明宇

不論是云存儲服務(wù)、企業(yè)級存儲系統(tǒng)，還是區(qū)塊鏈存儲，分布式存儲已經(jīng)成為了數(shù)據(jù)存儲的主流方案，傳統(tǒng)的集中式存儲設(shè)備正在淡出IT舞臺。數(shù)據(jù)分布算法是分布式存儲最核心的技術(shù)之一，不僅僅要考慮到數(shù)據(jù)分布的均勻性、尋址的效率，還要考慮擴(kuò)充和減少容量時數(shù)據(jù)遷移的開銷，兼顧副本的一致性和可用性。

具體到企業(yè)級存儲和區(qū)塊鏈存儲的不同場景，對數(shù)據(jù)分布的需求又有很大不同，一個算法并不能解決所有的問題，奧思數(shù)據(jù)創(chuàng)始人&CTO李明宇在分享中，將比較幾種典型的數(shù)據(jù)分布算法，分析其優(yōu)缺點(diǎn)并討論在具體應(yīng)用中會遇到的諸多問題。

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

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

成本接受的前提下數(shù)據(jù)還不能丟，怎么辦？即便存了三份數(shù)據(jù)，五份數(shù)據(jù)，因?yàn)樗愎Ｊ请S機(jī)的，所以怎么保證五個副本不放在一個盤上，或者這個區(qū)間或者那個區(qū)間？其實(shí)這是有一定概率的。

另外很重要的一點(diǎn)，一致性哈希算法是最基礎(chǔ)的，它構(gòu)成了現(xiàn)在分布式存儲數(shù)據(jù)分布的基礎(chǔ)算法，數(shù)據(jù)怎么找到它的存儲位置？算哈希匹配，這樣能夠極大的提高效率。換句話說如果采用查表的方式，Objecto的數(shù)量太多了，查表的負(fù)擔(dān)非常大，存儲開銷非常大，一致性哈希算法不用查表。

企業(yè)級存儲與區(qū)塊鏈存儲考慮的問題又不一樣，企業(yè)級存儲主要考慮全局可控，故障域和權(quán)重的因素，實(shí)際上在擴(kuò)容的時候并不是擴(kuò)哈希到設(shè)備的映射，而是擴(kuò)PG到設(shè)備的映射，會發(fā)現(xiàn)PG可能并沒有增多，但是OSD數(shù)量增多了，隨之PG到OSD的映射也就改變了。

除了精彩的主題分享之外，本次2018 UCan下午茶年終收官還準(zhǔn)備了精彩紛呈的展區(qū)互動和抽獎環(huán)節(jié)，不僅增強(qiáng)了現(xiàn)場參會者的互動交流，更為本次沙龍?jiān)鎏砉獠省?/strong>