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