0
| 本文作者： AI研習(xí)社 | 2019-01-07 15:24 |
云計(jì)算，賦予IT資源可伸縮的力量，從而可以整合算力，為各種新技術(shù)提供表演的舞臺(tái)，同時(shí)也為社會(huì)積蓄了豐富的資源，為大數(shù)據(jù)、人工智能提供底層技術(shù)的支撐。大數(shù)據(jù)技術(shù)則將通過對(duì)數(shù)據(jù)的存儲(chǔ)、加工、處理、分析，在為人們發(fā)掘數(shù)據(jù)價(jià)值的同時(shí)，也為人工智能提供了豐富優(yōu)質(zhì)的數(shù)據(jù)資源。而人工智能技術(shù)，則是人類社會(huì)智能化的關(guān)鍵，它將是除了互聯(lián)網(wǎng)以外，對(duì)人類產(chǎn)生深遠(yuǎn)影響的另一項(xiàng)技術(shù)，其釋放的力量將再次徹底改變我們的生活。
不過，這三項(xiàng)技術(shù)都離不開一個(gè)關(guān)鍵點(diǎn)，那就是分布式，如果不能深刻理解分布式，實(shí)際上也就無法真正理解云計(jì)算、大數(shù)據(jù)以及人工智能。2018年UCan下午茶收官戰(zhàn)，以“回歸云核心，服務(wù)大數(shù)據(jù)和AI的分布式實(shí)踐”為主題，來自UCloud、奧思數(shù)據(jù)、Kyligence的技術(shù)專家，就大數(shù)據(jù)和AI平臺(tái)的分布式設(shè)計(jì)實(shí)踐進(jìn)行了深入的探討和分享。
UCloud上線商用至今，已穩(wěn)定運(yùn)營(yíng)6年，覆蓋全球29個(gè)可用區(qū)，服務(wù)上萬家企業(yè)用戶。目前，UCloud云數(shù)據(jù)庫的實(shí)例數(shù)達(dá)幾萬，整個(gè)系統(tǒng)的數(shù)據(jù)量超數(shù)據(jù)量10PB+，單用戶實(shí)例數(shù)達(dá)到6k+，單用戶數(shù)據(jù)量1.8PB。在這樣急劇擴(kuò)張的數(shù)據(jù)規(guī)模之下，無疑給云數(shù)據(jù)庫的容量上限、性價(jià)比、性能以及兼容性帶來了前所未有的挑戰(zhàn)。UCloud關(guān)系型存儲(chǔ)研發(fā)部負(fù)責(zé)人”羅成對(duì)認(rèn)為，想要解決這些挑戰(zhàn)，需要改變傳統(tǒng)的云+數(shù)據(jù)庫思維，實(shí)現(xiàn)數(shù)據(jù)層和基礎(chǔ)設(shè)施層的共生復(fù)用。
傳統(tǒng)的分布式數(shù)據(jù)庫下，數(shù)據(jù)庫可以簡(jiǎn)單抽象兩層，第一層是SQL層，第二層是Storage，SQL層的典型實(shí)現(xiàn)是基于分布式存儲(chǔ)，這種方案可以兼容各種協(xié)議，無限擴(kuò)容，不存在分布式事務(wù)和分布式Join問題，但其缺點(diǎn)也很明顯，SQL層存在多節(jié)點(diǎn)緩存一致性和分布式鎖的問題；Storage層最典型的實(shí)現(xiàn)是基于Sharding架構(gòu)，該架構(gòu)下也可以進(jìn)行無限擴(kuò)容，但協(xié)議無法100%兼容，存在分布式事務(wù)和分布式Join難題。
總體來說基于傳統(tǒng)的分布式存儲(chǔ)方案可以實(shí)現(xiàn)無線擴(kuò)容問題，但它的缺點(diǎn)是協(xié)議無法兼容，且存在分布式事務(wù)和分布式Join難題。在這樣的背景之下，UCloud基于高性能分布式存儲(chǔ)架構(gòu)，通過融合最新軟硬件技術(shù)，著手研發(fā)新一代公有云分布式數(shù)據(jù)庫Exodus。
Exodus支持主流的開源數(shù)據(jù)庫MySQL，完全兼容各種協(xié)議，包括RDMA、Skylake、SPDK、用戶態(tài)文件系統(tǒng)等，計(jì)算層采用深度定制的MySQL InnoDB引擎，架構(gòu)設(shè)計(jì)上支持一主多從，通過這些設(shè)計(jì)，Exodus一舉解決云數(shù)據(jù)庫容量、性能、性價(jià)比、兼容性四大痛點(diǎn)。
系統(tǒng)基于用戶態(tài)的協(xié)議棧，更能適應(yīng)新的硬件紅利，單核理論能到百萬IOPS的能力，減少傳統(tǒng)內(nèi)核中斷，上下文切換的開銷。網(wǎng)絡(luò)的時(shí)延開銷在傳統(tǒng)分布式存儲(chǔ)中本來就是大頭，基于融合以太網(wǎng)的 RDMA 協(xié)議 (RoCE) 網(wǎng)絡(luò)實(shí)質(zhì)上是一種允許通過以太網(wǎng)使用遠(yuǎn)程直接內(nèi)存訪問的網(wǎng)絡(luò)協(xié)議，可以實(shí)現(xiàn)Zero Copy。
而底層采用了AppendOnly的模式，相較于傳統(tǒng)的原地更新方式 ，在EC數(shù)據(jù)安全性以及實(shí)現(xiàn)Snapshot等方面更加友好，對(duì)于靜默錯(cuò)誤等磁盤異常也有更好的檢測(cè)手段。IO路徑上，則采用CRUSH算法來計(jì)算所有分片的placement，不需要緩存或者查詢索引。LSMT Log-structure merge tree 通過LSMT來支持隨機(jī)讀寫。
傳統(tǒng)分布式存儲(chǔ)一般采用的是三副本的方式來保證數(shù)據(jù)可靠性（10-11個(gè)9），Exodus在采用底層為追加寫的方式來實(shí)現(xiàn)后，可以采用EC和壓縮的方式，在不影響可靠性的前提下將數(shù)據(jù)副本成本從3降到1左右。計(jì)算層采用深度定制的MySQL+InnoDB，可以直接復(fù)用公有云分布式存儲(chǔ)產(chǎn)品（如UCloud 塊存儲(chǔ)產(chǎn)品 UDisk ）。
基于這樣的架構(gòu)設(shè)計(jì)，羅成對(duì)判斷，未來云平臺(tái)的底層的分布式存儲(chǔ)產(chǎn)品，在IO路徑上將實(shí)現(xiàn)極致優(yōu)化，主流云平臺(tái)底層分布式存儲(chǔ)將實(shí)現(xiàn)微秒級(jí)延遲，百萬級(jí)IOPS，足以支持高性能業(yè)務(wù)（如數(shù)據(jù)庫）。
如何有效降低成本，加快AI方案的試錯(cuò)，是每個(gè)想把AI算法產(chǎn)品化的企業(yè)都需要考慮的問題。UCloud LabU深度學(xué)習(xí)開發(fā)工程師范融結(jié)合UCloud AI PaaS平臺(tái)的技術(shù)實(shí)踐，講述了UCloud如何為公有云用戶提供一套開箱即用的AI開發(fā)、測(cè)試、部署一體化環(huán)境。
在AI PaaS平臺(tái)落地之前，大部分企業(yè)面臨的第一個(gè)挑戰(zhàn)就是基礎(chǔ)環(huán)境構(gòu)建的復(fù)雜性：AI框架的多樣化選擇，環(huán)境的諸多變量、硬件的諸多變量以及底層數(shù)據(jù)存儲(chǔ)的諸多變量。以上這些交叉組合之后直接導(dǎo)致了一個(gè)情況：如果需要構(gòu)建完整的一套軟硬件組合的系統(tǒng)，而每一條業(yè)務(wù)線都有不同需求時(shí)，多環(huán)境維護(hù)就會(huì)變得異常痛苦。其次，需要在AI系統(tǒng)建設(shè)時(shí)考量算法的兼容性、平臺(tái)需要具備擴(kuò)展性、彈性伸縮的能力、容災(zāi)能力等以應(yīng)對(duì)平臺(tái)的橫向和縱向擴(kuò)展。因此，一個(gè)完善的AI PaaS 平臺(tái)需要具備如下特點(diǎn)：
算法兼容性：更好地兼容各類AI框架和算法；
橫向擴(kuò)展能力：支持CPU、GPU，支持S3、NFS、HDFS等多種存儲(chǔ)；
縱向擴(kuò)展能力：平臺(tái)具備橫向擴(kuò)展能力，支持業(yè)務(wù)規(guī)模的不斷擴(kuò)大；
高可用：具備彈性伸縮的能力以及容災(zāi)能力；
環(huán)境遷移：可遷移公有云能力到私有云環(huán)境中。
基于以上五大要素，UCloud構(gòu)建了自有的AI基礎(chǔ)平臺(tái)，里面包含AI Train和AI Inference兩大核心服務(wù)。如下圖所示，最上層最側(cè)是訓(xùn)練日志、服務(wù)狀態(tài)、TensorBoard框架和Jupyter，下面接著就是圖形化界面，這里面主要是完成一些基本的部署操作，右側(cè)是Python SDK接口，接入層下面即為平臺(tái)核心的AI Train和AI Service，最底層封裝了所有的計(jì)算節(jié)點(diǎn)和存儲(chǔ)接入。
AI Train方面，為了實(shí)現(xiàn)橫向擴(kuò)展能力，UCloud不僅提供單機(jī)訓(xùn)練，同時(shí)還提供了分布式訓(xùn)練能力。也就是說除了提供單節(jié)點(diǎn)的程序，只要用戶滿足開發(fā)框架要求，平臺(tái)還可自動(dòng)部署分布式框架，海量訓(xùn)練服務(wù)下，可極大縮減訓(xùn)練時(shí)間，提高效率。另外，平臺(tái)也提供交互式訓(xùn)練方式，用戶可以和云上空間進(jìn)行實(shí)時(shí)互動(dòng)，并獲取云上實(shí)時(shí)訓(xùn)練結(jié)果。
此外，在AI Training和AI Inference平臺(tái)算力方面，UCloud設(shè)計(jì)了兩大資源池，如果用戶的算力要求比較低，希望實(shí)現(xiàn)很好的彈性擴(kuò)容能力，可以采用CPU資源池。如果對(duì)算力要求比較高，可以采用GPU資源池，這樣，就可以根據(jù)不同的用戶計(jì)算力需求提供最優(yōu)的支持。
業(yè)界有多種數(shù)據(jù)庫高可用方案，每種方案都有自己的特點(diǎn)和不足，來自UCloud的資深存儲(chǔ)研發(fā)工程師丁順，就這些方案的技術(shù)實(shí)現(xiàn)及優(yōu)劣進(jìn)行了詳細(xì)的講解，并分享了UCloud云數(shù)據(jù)庫產(chǎn)品UDB在高可用容災(zāi)方案上面的設(shè)計(jì)和實(shí)現(xiàn)，以及UDB產(chǎn)品大規(guī)模高可用數(shù)據(jù)庫運(yùn)維中的一些經(jīng)驗(yàn)和心得。
據(jù)丁順介紹，業(yè)界典型的高可用架構(gòu)可劃分為四種： 第一種，共享存儲(chǔ)方案；第二種，操作系統(tǒng)實(shí)時(shí)數(shù)據(jù)塊復(fù)制；第三種，數(shù)據(jù)庫級(jí)別的主從復(fù)制；第三，高可用數(shù)據(jù)庫集群。每種數(shù)據(jù)同步方式可以衍生出不同的架構(gòu)。
第一種，共享存儲(chǔ)。共享存儲(chǔ)是指若干DB服務(wù)使用同一份存儲(chǔ)，一個(gè)主DB，其他的為備用DB，若主服務(wù)崩潰，則系統(tǒng)啟動(dòng)備用DB，成為新的主DB，繼續(xù)提供服務(wù)。一般共享存儲(chǔ)采用比較多的是SAN/NAS方案，這種方案的優(yōu)點(diǎn)是沒有數(shù)據(jù)同步的問題，缺點(diǎn)是對(duì)網(wǎng)絡(luò)性能要求比較高。
第二種，操作系統(tǒng)實(shí)時(shí)數(shù)據(jù)塊復(fù)制。 這種方案的典型場(chǎng)景是DRBD。如下圖所示，左邊數(shù)據(jù)庫寫入數(shù)據(jù)以后立即同步到右邊的存儲(chǔ)設(shè)備當(dāng)中。如果左邊數(shù)據(jù)庫崩潰，系統(tǒng)直接將右邊的數(shù)據(jù)庫存儲(chǔ)設(shè)備激活，完成數(shù)據(jù)庫的容災(zāi)切換。這個(gè)方案同樣有一些問題，如系統(tǒng)只能有一個(gè)數(shù)據(jù)副本提供服務(wù)，無法實(shí)現(xiàn)讀寫分離；另外，系統(tǒng)崩潰后需要的容災(zāi)恢復(fù)時(shí)間較長(zhǎng)。
第三種，數(shù)據(jù)庫主從復(fù)制。 這種方案是較經(jīng)典的數(shù)據(jù)同步模式，系統(tǒng)采用一個(gè)主庫和多個(gè)從庫，主庫同步數(shù)據(jù)庫日志到各個(gè)從庫，從庫各自回放日志。它的好處是一個(gè)主庫可以連接多個(gè)從庫，能很方便地實(shí)現(xiàn)讀寫分離，同時(shí)，因?yàn)槊總€(gè)備庫都在啟動(dòng)當(dāng)中，所以備庫當(dāng)中的數(shù)據(jù)基本上都是熱數(shù)據(jù)，容災(zāi)切換也非?？臁?/p>
第四種，數(shù)據(jù)庫高可用集群。前面三種是通過復(fù)制日志的模式實(shí)現(xiàn)高可用，第四種方案是基于一致性算法來做數(shù)據(jù)同步。數(shù)據(jù)庫提供一種多節(jié)點(diǎn)的一致性同步機(jī)制，然后利用該機(jī)制構(gòu)建多節(jié)點(diǎn)同步集群，這是業(yè)界近年來比較流行的高可用集群的方案。
UCloud綜合了原生MySQL兼容，不同版本、不同應(yīng)用場(chǎng)的覆蓋等多種因素，最終選擇采用基于數(shù)據(jù)庫主從復(fù)制的方式實(shí)現(xiàn)高可用架構(gòu)，并在原架構(gòu)基礎(chǔ)上，使用雙主架構(gòu)、半同步復(fù)制、采用GTID等措施進(jìn)行系列優(yōu)化，保證數(shù)據(jù)一致性的同時(shí)，實(shí)現(xiàn)日志的自動(dòng)尋址。
自動(dòng)化運(yùn)維是高可用數(shù)據(jù)庫當(dāng)中的難點(diǎn)，UDB在日常例行巡檢之外，也會(huì)定期做容災(zāi)演練，查看在不同場(chǎng)景下數(shù)據(jù)是否丟失、是否保持一致性等，同時(shí)設(shè)置記錄日志、告警系統(tǒng)等等，以便于第一時(shí)間發(fā)現(xiàn)問題，并追溯問題的根源，找出最佳解決方案。
數(shù)據(jù)分布算法是分布式存儲(chǔ)的核心技術(shù)之一，不僅僅要考慮到數(shù)據(jù)分布的均勻性、尋址的效率，還要考慮擴(kuò)充和減少容量時(shí)數(shù)據(jù)遷移的開銷，兼顧副本的一致性和可用性。奧思數(shù)據(jù)創(chuàng)始人兼CTO 李明宇現(xiàn)場(chǎng)分析了幾種典型的數(shù)據(jù)分布算法的優(yōu)缺點(diǎn)，并分享了具體實(shí)現(xiàn)中會(huì)遇到的一些問題。
一致性哈希算法因其不需要查表或通信過程即可定位數(shù)據(jù)，計(jì)算復(fù)雜度不隨數(shù)據(jù)量增長(zhǎng)而改變，且效率高、均勻性好、增加/減少節(jié)點(diǎn)時(shí)數(shù)據(jù)遷移量小等特性受到開發(fā)者喜愛。但具體到實(shí)際應(yīng)用中，這種算法也因其自身局限性遇到了諸多挑戰(zhàn)，如在“存儲(chǔ)區(qū)塊鏈”場(chǎng)景下，幾乎不可能獲取全局視圖，甚至沒有一刻是穩(wěn)定的；企業(yè)級(jí)IT場(chǎng)景下，存在多副本可靠存儲(chǔ)問題，數(shù)據(jù)遷移開銷巨大。
所謂存儲(chǔ)區(qū)塊鏈，可以理解為分布式存儲(chǔ)（p2p存儲(chǔ)） + 區(qū)塊鏈，它通過token激勵(lì)，鼓勵(lì)大家貢獻(xiàn)存儲(chǔ)資源，參與構(gòu)建一個(gè)全世界范圍的分布式存儲(chǔ)系統(tǒng)。因?yàn)樾枰?lì)大量用戶自發(fā)參與，因此會(huì)涉及上億甚至幾十億節(jié)點(diǎn)的尋址和路由問題，目前業(yè)界主要的解決方案主要有Chord、Kademlia等。不過，Chord算法效率較低，會(huì)產(chǎn)生較高延遲，可以采用Finger table，除了記錄當(dāng)前節(jié)點(diǎn)以及下一節(jié)點(diǎn)位置，同時(shí)還記錄當(dāng)前節(jié)點(diǎn)2^i+1的位置，降低計(jì)算復(fù)雜度，最終降低延遲。
企業(yè)級(jí)IT場(chǎng)景下，數(shù)據(jù)分布算法包括Dynamo、Ceph的CRUSH、Gluster的Elastic Hashing以及Swift的Ring等。這些算法都有相似的特點(diǎn)，首先它們都是基于/借鑒一致性哈希，增加/減少節(jié)點(diǎn)時(shí)數(shù)據(jù)遷移量小。其次，引入對(duì)數(shù)據(jù)中心物理拓?fù)涞慕＃–luster Map），數(shù)據(jù)多副本 / EC分片跨故障域 / 可用區(qū)分布。另外，這些算法還可以對(duì)節(jié)點(diǎn)劃分權(quán)重，數(shù)據(jù)分布和容量/性能匹配，輔助擴(kuò)容。
總體來說，這兩類方案均是基于一致性哈希算法實(shí)現(xiàn)，只是因?yàn)樾枨蟛煌?，才有了不同的改進(jìn)方向。企業(yè)級(jí)更注重副本故障域的分布；而對(duì)于P2P存儲(chǔ)，則更注重在節(jié)點(diǎn)隨時(shí)退出隨時(shí)加入的情況下，保證數(shù)據(jù)能夠在有效時(shí)間內(nèi)尋址。
大數(shù)據(jù)分析場(chǎng)景在豐富的技術(shù)產(chǎn)品棧面前，依舊面臨著技術(shù)門檻高、人才短缺、項(xiàng)目開發(fā)周期長(zhǎng)等問題。IT部門如何從被動(dòng)的業(yè)務(wù)實(shí)現(xiàn)者轉(zhuǎn)變?yōu)闃I(yè)務(wù)的賦能者，業(yè)務(wù)部門如何通過優(yōu)秀的工具更好地理解數(shù)據(jù)、挖掘數(shù)據(jù)的價(jià)值，是每一個(gè)數(shù)據(jù)團(tuán)隊(duì)、IT 團(tuán)隊(duì)需要思考的問題。來自Kyligence云與生態(tài)合作部副總裁劉一鳴基于上述問題，講述了Apache Kylin技術(shù)的設(shè)計(jì)思考和最佳實(shí)踐。
Apache Kylin是一個(gè)開源的分布式分析引擎 ，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力（可以把Kylin定義為 OLAP on Hadoop ）。據(jù)介紹，它是首個(gè)完全由中國(guó)人貢獻(xiàn)到國(guó)際頂級(jí)開源社區(qū)的開源項(xiàng)目，也是首個(gè)來自中國(guó)的Apache頂級(jí)開源項(xiàng)目。
Apache Kylin作為OLAP引擎包含了從數(shù)據(jù)源（Hive／Kafka等）獲取源數(shù)據(jù)，基于MapReduce 構(gòu)建多維立方體(Cube) ，并充分利用 HBase 的列式特性來分布式的 存儲(chǔ)立方體數(shù)據(jù) ，提供標(biāo)準(zhǔn)SQL解析與查詢優(yōu)化，以及ODBC／JDBC驅(qū)動(dòng)及REST API等多個(gè)模塊。
如下圖所示，Kylin基于HBase的列式存儲(chǔ)，計(jì)算結(jié)果集保存在HBase中，原有的基于行的關(guān)系模型被轉(zhuǎn)換成基于鍵值對(duì)的列式存儲(chǔ)，維度組合作為Rowkey，查詢?cè)L問不再需要昂貴的表掃描，維度值通過編碼算法（字典、定長(zhǎng)、時(shí)間戳等）高度壓縮，指標(biāo)通過Column存儲(chǔ)，可以靈活、無限制的增加指標(biāo)數(shù)量，此外，預(yù)先計(jì)算的結(jié)果也為高速高并發(fā)分析帶來了可能。
大多數(shù)的Hadoop分析工具和SQL是友好的，所以Apache Kylin擁有SQL接口這一點(diǎn)就顯得尤為重要。Kylin用的SQL解析器是開源的Apache Calcite，支持幾乎所有的SQL標(biāo)準(zhǔn)。Hive用的也是Calcite。
與其它SQL ON Hadoop不同，Kylin主要采用預(yù)計(jì)算（離線計(jì)算）的實(shí)現(xiàn)方式 。用戶在使用之前先選擇一個(gè)Hive Table的集合，然后在這個(gè)基礎(chǔ)上做一個(gè)離線的Cube構(gòu)建，Cube構(gòu)建完了之后就可以做SQL查詢了。用離線計(jì)算來代替在線計(jì)算，在離線過程當(dāng)中把復(fù)雜的、計(jì)算量很大的工作做完，在線計(jì)算量就會(huì)變小，就可以更快的返回查詢結(jié)果。通過這種方式，Kylin可以用更少的計(jì)算，獲取更高的吞吐量。
由于篇幅限制，本文僅整理了現(xiàn)場(chǎng)部分精彩演講內(nèi)容，感興趣的讀者可以點(diǎn)擊 閱讀原文 下載講師PPT進(jìn)行深入了解！雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)
雷峰網(wǎng)版權(quán)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
