公海赌赌船官网jc710北京

現如今已經進入大數據時代，各種係統、應用、活動所產(chan) 生的數據浩如煙海，數據不再僅(jin) 僅(jin) 是企業(ye) 存儲(chu) 的信息，而是成為(wei) 可以從(cong) 中獲取巨大商業(ye) 價(jia) 值的企業(ye) 戰略資產(chan) 。這樣背景下，如何存儲(chu) 海量複雜的數據、從(cong) 紛繁錯綜的數據中找到真正有價(jia) 值的數據，是大數據時代企業(ye) 麵臨(lin) 的難題。

8月18日的“UCan下午茶”杭州站，來自UCloud、網易、華為(wei) 的五位技術專(zhuan) 家，從(cong) 數據庫高可用容災方案設計和實現、新一代公有雲(yun) 分布式數據庫、基於(yu) Impala平台打造交互查詢係統等不同維度出發，分享了他們(men) 在大數據查詢、分析、存儲(chu) 開發過程中遇到的“困惑”與(yu) 解決(jue) 方案。

UCloud丁順：數據庫高可用容災方案設計和實現

高可用容災是搭建數據庫服務的一個(ge) 重要考量特性，搭建高可用數據庫服務需要解決(jue) 諸多問題，保證最終的容災效果。UCloud雲(yun) 數據庫產(chan) 品UDB在研發演進過程中，根據用戶的需要不斷完善和演進，形成了一套完善的高可用架構體(ti) 係。

UCloud資深存儲(chu) 研發工程師丁順從(cong) 高可用數據庫概述、典型的高可用架構分析以及高可用數據庫自動化運維等角度，講述了如何設計和運營一套完善的數據庫高可用架構，保證在出現異常時能夠及時恢複數據庫服務。

業(ye) 界典型的高可用架構可以劃分為(wei) 四種：第一種，共享存儲(chu) 方案;第二種，操作係統實時數據塊複製;第三種，數據庫級別的主從(cong) 複製;第三，高可用數據庫集群。每種數據同步方式可以衍生出不同的架構。

第一種，共享存儲(chu) 。共享存儲(chu) 是指若幹DB服務使用同一份存儲(chu) ，一個(ge) 主DB，其他的為(wei) 備用DB，若主服務崩潰，則係統啟動備用DB，成為(wei) 新的主DB，繼續提供服務。共享存儲(chu) 方案的優(you) 點是沒有數據同步的問題，缺點是對網絡性能要求比較高。 第二種，操作係統實時數據塊複製。這種方案的典型場景是DRBD。如下圖所示，左邊數據庫寫(xie) 入數據以後立即同步到右邊的存儲(chu) 設備當中。如果左邊數據庫崩潰，係統直接將右邊的數據庫存儲(chu) 設備激活，完成數據庫的容災切換。這個(ge) 方案同樣有一些問題，如係統隻能有一個(ge) 數據副本提供服務，無法實現讀寫(xie) 分離;另外，係統崩潰後需要的容災恢複時間較長。

第三種，數據庫主從(cong) 複製。這種方案是較經典的數據同步模式，係統采用一個(ge) 主庫和多個(ge) 從(cong) 庫，主庫同步數據庫日誌到各個(ge) 從(cong) 庫，從(cong) 庫各自回放日誌。它的好處是一個(ge) 主庫可以連接多個(ge) 從(cong) 庫，能很方便地實現讀寫(xie) 分離，同時，因為(wei) 每個(ge) 備庫都在啟動當中，所以備庫當中的數據基本上都是熱數據，容災切換也非常快。 第四種，數據庫高可用集群。前麵三種是通過複製日誌的模式實現高可用，第四種方案是基於(yu) 一致性算法來做數據同步。數據庫提供一種多節點的一致性同步機製，然後利用該機製構建多節點同步集群，這是業(ye) 界近年來比較流行的高可用集群的方案。

UCloud綜合了原生MySQL兼容、不同版本、不同應用場景的覆蓋等多種因素，最終選擇采用基於(yu) 數據庫主從(cong) 複製的方式實現高可用架構，並在原架構基礎上，使用雙主架構、半同步複製、采用GTID等措施進行係列優(you) 化，保證數據一致性的同時，實現日誌的自動尋址。

自動化運維是高可用數據庫當中的難點，UDB在日常例行巡檢之外，也會(hui) 定期做容災演練，查看在不同場景下數據是否丟(diu) 失、是否保持一致性等，同時設置記錄日誌、告警係統等等，以便於(yu) 第一時間發現問題，並追溯問題的根源，找出最佳解決(jue) 方案。

UCloud劉堅君：新一代公有雲(yun) 分布式數據庫UCloud Exodus

公有雲(yun) 2.0時代，雲(yun) 數據庫新產(chan) 品不斷湧現。諸如AWS Aurora、阿裏雲(yun) PolarDB等，UCloud在采用最新軟硬件和分布式技術改造傳(chuan) 統數據庫的工作中，也在思考除了分布式數據庫所要求的更大和更快之外，是否還有其他更重要的用戶價(jia) 值?UCloud資深數據庫研發工程師劉堅君，現場講解了UCloud對於(yu) 新一代公有雲(yun) 分布式數據庫的思考與(yu) 設計。

劉堅君首先從(cong) 1.0時代存在的問題入手，他認為(wei) 1.0時代雲(yun) 數據庫帶來了三方麵價(jia) 值：彈性、故障救援、知識複用。但它同樣麵臨(lin) 三大難以解決(jue) 的問題：容量和性能、租用成本、運營成本。

到2.0時代，解決(jue) 上述三個(ge) 問題的思路是計算和讀寫(xie) 分離。通過計算和讀寫(xie) 分離，將傳(chuan) 統數據庫的計算層和存儲(chu) 層拆開，各自獨立擴展和演進。這樣做的好處是：1.提供更大的容量和讀寫(xie) 性能;2.按需擴容和付費;3.優(you) 化運營成本並降低運營風險。業(ye) 界已推出的2.0雲(yun) 數據庫(如Aurora、PolarDB等)，均采用計算和存儲(chu) 分離的架構。

UCloud Exodus的產(chan) 品和技術理念則更進一步：計算和存儲(chu) 分離後，存儲(chu) 層將完全複用雲(yun) 平台的高性能分布式存儲(chu) (如UCloud UDisk、阿裏雲(yun) 盤古等)，而Exodus則專(zhuan) 注於(yu) 構建一款數據庫內(nei) 核，去適配主流公有雲(yun) 和私有雲(yun) 廠商發布的高性能分布式存儲(chu) 產(chan) 品。Exodus的這種產(chan) 品架構，稱之為(wei) Shared-ALL-DISK架構。

Shared-ALL-DISK架構的優(you) 點明顯，在提供雲(yun) 數據庫2.0創新功能的同時，賦予用戶業(ye) 務自由遷徙的能力，不被某個(ge) 雲(yun) 平台綁架，同時能夠連接上下遊的軟硬件廠商，共建Exodus數據庫生態。

更為(wei) 重要的是，Exodus將最終將開源， UCloud會(hui) 將核心係統的每一行源碼開放，賦予用戶深入了解和優(you) 化Exodus的能力。並建設開源社區，吸收全行業(ye) 的優(you) 化成果，共同改進和完善Exodus。

網易蔣鴻翔：基於(yu) Impala平台打造交互查詢係統

在數據分析當中，因為(wei) 數據基數龐大、關(guan) 係模型複雜、響應時間要求高等特性，數據之間的交互查詢就顯得尤為(wei) 重要。來自網易的大數據技術專(zhuan) 家蔣鴻翔現場從(cong) 交互式查詢特點著手，深入淺出講解了Impala架構、原理，以及網易對Impala的改進思路和使用場景。

Impala是Cloudera公司主導開發的新型查詢係統，它提供SQL語義(yi) ，能查詢存儲(chu) 在Hadoop的HDFS和HBase中的PB級大數據。已有的Hive係統雖然也提供了SQL語義(yi) ，但由於(yu) Hive底層執行使用的是MapReduce引擎，仍然是一個(ge) 批處理過程，難以滿足查詢的交互性。相比之下，Impala能夠很快速的實現數據查詢。下圖是一個(ge) Impala的架構圖。

Impala擁有元數據緩存、MPP並行計算、支持LLVM與(yu) JIT以及支持HDFS本地讀、算子下推等特性。但它也有一些缺陷，如服務單點、Web信息無法持久化、資源隔離並不精確、負載均衡需要外部支持等。

網易針對上述不足之處，在原有的Impala查詢係統下，進行了係列改進優(you) 化：

基於(yu) ZK的Loadbalance。原始的Impala負載均衡需要外部支持，為(wei) 此網易基於(yu) ZK做了一個(ge) Loadbalance方案; 管理服務器。主要為(wei) 了解決(jue) 當某一個(ge) 節點掛掉時數據丟(diu) 失的問題，管理服務器會(hui) 將所有的狀態信息搜集進來，後續如果做分析都可以通過關(guan) 聯的服務器查詢; 細粒度權限和代理; Json格式; 兼容Ranger權限管理; 批量元數據刷新; 元數據同步; 元數據過濾; 對接ElasticSearch查詢。

據蔣鴻翔介紹，改造後的交互查詢係統，已經成功應用於(yu) 網易數據科學中心的一站式大數據平台自助查詢係統上。同時，數據分析中心的一站式報表係統底層，也搭載在Impala上。相信未來，基於(yu) Impala的查詢係統將會(hui) 應用於(yu) 更多不同的場景。

UCloud王仆：UCloud分布式KV存儲(chu) 係統

分布式KV存儲(chu) 係統在互聯網公司中扮演著重要角色，各類上層業(ye) 務對於(yu) KV存儲(chu) 係統的高可用性、可擴展性和數據一致性都有著很高的要求。UCloud存儲(chu) 部門在迭代升級分布式Redis架構的同時，也一直致力於(yu) 研發基於(yu) 硬盤存儲(chu) 的大容量分布式KV係統。來自UCloud的技術專(zhuan) 家王仆，著重介紹了UCloud在大容量分布式KV係統設計方麵的經驗，以及應對線上業(ye) 務高性能、高容量要求的係統架構設計思路。

下圖為(wei) UCloud分布式KV存儲(chu) 係統架構，底層為(wei) 多個(ge) Storage，每一個(ge) Storage有三個(ge) 節點，這三個(ge) 節點需要放在不同的物理機上，防止一台機器宕機後係統不可用;標紅框的屬於(yu) Master節點，Master節點通過日誌同步的方式，同步到層節點，整個(ge) 數據的請求從(cong) Proxy進入。

整個(ge) 係統是有中心節點的係統，路由管理由Master來管理，Master通過每個(ge) 機器上的Host管理Storage節點，由Zookeeper確定誰是主誰是從(cong) ，因此，一些管理方麵的請求都是直接連接到Master上的，包括創建、刪除和控製台方麵的功能等。

在測試過程中也發現了一些性能方麵的問題，如采用的部分Raft協議是單Raft，設計之初並沒有實現並行Raft功能，因此數據同步較慢;其次，請求是通過代理的方式實現，代理的延遲會(hui) 比直接訪問的延遲更高，後期，會(hui) 考慮提供一些客戶端的SDK，讓請求可以跳過代理，減少一次網絡交互。

在KV係統的後續優(you) 化上，王仆介紹到，為(wei) 了能夠將存儲(chu) 係統應用於(yu) 更多不同的業(ye) 務場景，未來會(hui) 考慮更高的通用性，適配多種的存儲(chu) 引擎;另外，因為(wei) Redis比較流行，係統設計之初主要是支持Redis，但是業(ye) 界還有一些其他協議，這時候需要特殊的轉化流程，未來希望做成一個(ge) 支持各種協議的通用結構化存儲(chu) 係統，適配其他不同協議。

華為(wei) 時金魁：實時流計算技術及其應用

隨著Flink/Spark Streaming的大受歡迎，實時流計算開始為(wei) 人熟知，進入大眾(zhong) 視野。流計算在物聯網行業(ye) 、車聯網、智慧城市等行業(ye) 快速落地，亦創造出越來越多的價(jia) 值。來自華為(wei) 的架構師時金魁，現場分享了實時流計算的一些技術方案和落地應用。

在傳(chuan) 統的數據處理流程中，總是先收集數據，然後將數據放到DB中。當人們(men) 需要的時候通過DB對數據做query，得到答案或進行相關(guan) 的處理。這個(ge) 流程看起來雖然合理，但是結果卻非常的緊湊，尤其是對於(yu) 一些實時搜索應用環境中的某些具體(ti) 問題，類似於(yu) MapReduce方式的離線處理並不能很好地解決(jue) 問題。這就引出了一種新的數據計算結構---流計算方式。它可以很好地對大規模流動數據在不斷變化的運動過程中實時地進行分析，捕捉到可能有用的信息，並把結果發送到下一計算節點。

目前，業(ye) 界開源的流計算框架很多，最早有Storm、Heron，後來還有Akka，Beam，以及現在的Kafka等等。在諸多的開源框架中，時金魁認為(wei) ，Flink是最恰當的流計算框架，Spark Streaming則是最有潛力的流計算框架，但這兩(liang) 個(ge) 框架在落地應用中都有各自的優(you) 缺點。

華為(wei) 根據Flink與(yu) Spark框架各自的特點，摒棄其劣勢，設計開發出一款全新的實時流計算服務Cloud Stream Service(簡稱CS)。CS采用Apache Flink的Dataflow模型，實現完全的實時計算，同時，采用在線SQL編輯平台編寫(xie) Stream SQL，定義(yi) 數據流入、數據處理、數據流出，用戶無需關(guan) 心計算集群, 無需學習(xi) 編程技能，降低流數據分析門檻。下圖為(wei) 華為(wei) 的實時流計算服務概覽圖。

據介紹，CS聚焦於(yu) 互聯網和物聯網場景，適用於(yu) 實時性要求高、吞吐量大的業(ye) 務場景。主要應用在互聯網行業(ye) 中小企業(ye) 、物聯網、車聯網、金融反欺詐等多種行業(ye) 應用場景，如互聯網汽車、日誌在線分析、在線機器學習(xi) 、在線圖計算、在線推薦算法應用等。

總結

雖然說開源軟件因為(wei) 其強大的成本優(you) 勢而擁有極其強大的力量，數據庫、雲(yun) 計算廠商仍會(hui) 嚐試推出性能、穩定性、維護服務等指標上更加強大的產(chan) 品與(yu) 之進行差異化競爭(zheng) ，並同時參與(yu) 開源社區，借力開源軟件來豐(feng) 富自己的產(chan) 品線、提升自己的競爭(zheng) 力，並通過更多的高附加值服務來滿足部分消費者需求。

總的來看，未來的大數據分析技術、存儲(chu) 將會(hui) 變得越來越成熟、越來越便宜、越來越易用，相應的，用戶將會(hui) 更容易、更方便地從(cong) 自己的大數據中挖掘出有價(jia) 值的商業(ye) 信息。