企業(yè)該如何做大數(shù)據(jù)的分析挖掘？這里有一份參考指南

現(xiàn)如今已經(jīng)進入大數(shù)據(jù)時代，各種系統(tǒng)、應(yīng)用、活動所產(chǎn)生的數(shù)據(jù)浩如煙海，數(shù)據(jù)不再僅僅是企業(yè)存儲的信息，而是成為可以從中獲取巨大商業(yè)價值的企業(yè)戰(zhàn)略資產(chǎn)。這樣背景下，如何存儲海量復(fù)雜的數(shù)據(jù)、從紛繁錯綜的數(shù)據(jù)中找到真正有價值的數(shù)據(jù)，是大數(shù)據(jù)時代企業(yè)面臨的難題。

8月18日的“UCan下午茶”杭州站，來自UCloud、網(wǎng)易、華為的五位技術(shù)專家，從數(shù)據(jù)庫高可用容災(zāi)方案設(shè)計和實現(xiàn)、新一代公有云分布式數(shù)據(jù)庫、基于Impala平臺打造交互查詢系統(tǒng)等不同維度出發(fā)，分享了他們在大數(shù)據(jù)查詢、分析、存儲開發(fā)過程中遇到的“困惑”與解決方案。

UCloud丁順：數(shù)據(jù)庫高可用容災(zāi)方案設(shè)計和實現(xiàn)

高可用容災(zāi)是搭建數(shù)據(jù)庫服務(wù)的一個重要考量特性，搭建高可用數(shù)據(jù)庫服務(wù)需要解決諸多問題，保證最終的容災(zāi)效果。UCloud云數(shù)據(jù)庫產(chǎn)品UDB在研發(fā)演進過程中，根據(jù)用戶的需要不斷完善和演進，形成了一套完善的高可用架構(gòu)體系。

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

業(yè)界典型的高可用架構(gòu)可以劃分為四種：第一種，共享存儲方案；第二種，操作系統(tǒng)實時數(shù)據(jù)塊復(fù)制；第三種，數(shù)據(jù)庫級別的主從復(fù)制；第三，高可用數(shù)據(jù)庫集群。每種數(shù)據(jù)同步方式可以衍生出不同的架構(gòu)。

第一種，共享存儲。共享存儲是指若干DB服務(wù)使用同一份存儲，一個主DB，其他的為備用DB，若主服務(wù)崩潰，則系統(tǒng)啟動備用DB，成為新的主DB，繼續(xù)提供服務(wù)。共享存儲方案的優(yōu)點是沒有數(shù)據(jù)同步的問題，缺點是對網(wǎng)絡(luò)性能要求比較高。 第二種，操作系統(tǒng)實時數(shù)據(jù)塊復(fù)制。這種方案的典型場景是DRBD。如下圖所示，左邊數(shù)據(jù)庫寫入數(shù)據(jù)以后立即同步到右邊的存儲設(shè)備當中。如果左邊數(shù)據(jù)庫崩潰，系統(tǒng)直接將右邊的數(shù)據(jù)庫存儲設(shè)備激活，完成數(shù)據(jù)庫的容災(zāi)切換。這個方案同樣有一些問題，如系統(tǒng)只能有一個數(shù)據(jù)副本提供服務(wù)，無法實現(xiàn)讀寫分離；另外，系統(tǒng)崩潰后需要的容災(zāi)恢復(fù)時間較長。

第三種，數(shù)據(jù)庫主從復(fù)制。這種方案是較經(jīng)典的數(shù)據(jù)同步模式，系統(tǒng)采用一個主庫和多個從庫，主庫同步數(shù)據(jù)庫日志到各個從庫，從庫各自回放日志。它的好處是一個主庫可以連接多個從庫，能很方便地實現(xiàn)讀寫分離，同時，因為每個備庫都在啟動當中，所以備庫當中的數(shù)據(jù)基本上都是熱數(shù)據(jù)，容災(zāi)切換也非?？?。 第四種，數(shù)據(jù)庫高可用集群。前面三種是通過復(fù)制日志的模式實現(xiàn)高可用，第四種方案是基于一致性算法來做數(shù)據(jù)同步。數(shù)據(jù)庫提供一種多節(jié)點的一致性同步機制，然后利用該機制構(gòu)建多節(jié)點同步集群，這是業(yè)界近年來比較流行的高可用集群的方案。

UCloud綜合了原生MySQL兼容、不同版本、不同應(yīng)用場景的覆蓋等多種因素，最終選擇采用基于數(shù)據(jù)庫主從復(fù)制的方式實現(xiàn)高可用架構(gòu)，并在原架構(gòu)基礎(chǔ)上，使用雙主架構(gòu)、半同步復(fù)制、采用GTID等措施進行系列優(yōu)化，保證數(shù)據(jù)一致性的同時，實現(xiàn)日志的自動尋址。

自動化運維是高可用數(shù)據(jù)庫當中的難點，UDB在日常例行巡檢之外，也會定期做容災(zāi)演練，查看在不同場景下數(shù)據(jù)是否丟失、是否保持一致性等，同時設(shè)置記錄日志、告警系統(tǒng)等等，以便于第一時間發(fā)現(xiàn)問題，并追溯問題的根源，找出最佳解決方案。

UCloud劉堅君：新一代公有云分布式數(shù)據(jù)庫UCloud Exodus

公有云2.0時代，云數(shù)據(jù)庫新產(chǎn)品不斷涌現(xiàn)。諸如AWS Aurora、阿里云PolarDB等，UCloud在采用最新軟硬件和分布式技術(shù)改造傳統(tǒng)數(shù)據(jù)庫的工作中，也在思考除了分布式數(shù)據(jù)庫所要求的更大和更快之外，是否還有其他更重要的用戶價值？UCloud資深數(shù)據(jù)庫研發(fā)工程師劉堅君，現(xiàn)場講解了UCloud對于新一代公有云分布式數(shù)據(jù)庫的思考與設(shè)計。

劉堅君首先從1.0時代存在的問題入手，他認為1.0時代云數(shù)據(jù)庫帶來了三方面價值：彈性、故障救援、知識復(fù)用。但它同樣面臨三大難以解決的問題：容量和性能、租用成本、運營成本。

到2.0時代，解決上述三個問題的思路是計算和讀寫分離。通過計算和讀寫分離，將傳統(tǒng)數(shù)據(jù)庫的計算層和存儲層拆開，各自獨立擴展和演進。這樣做的好處是：1.提供更大的容量和讀寫性能；2.按需擴容和付費；3.優(yōu)化運營成本并降低運營風(fēng)險。業(yè)界已推出的2.0云數(shù)據(jù)庫（如Aurora、PolarDB等），均采用計算和存儲分離的架構(gòu)。

UCloud Exodus的產(chǎn)品和技術(shù)理念則更進一步：計算和存儲分離后，存儲層將完全復(fù)用云平臺的高性能分布式存儲（如UCloud UDisk、阿里云盤古等），而Exodus則專注于構(gòu)建一款數(shù)據(jù)庫內(nèi)核，去適配主流公有云和私有云廠商發(fā)布的高性能分布式存儲產(chǎn)品。Exodus的這種產(chǎn)品架構(gòu)，稱之為Shared-ALL-DISK架構(gòu)。

Shared-ALL-DISK架構(gòu)的優(yōu)點明顯，在提供云數(shù)據(jù)庫2.0創(chuàng)新功能的同時，賦予用戶業(yè)務(wù)自由遷徙的能力，不被某個云平臺綁架，同時能夠連接上下游的軟硬件廠商，共建Exodus數(shù)據(jù)庫生態(tài)。

更為重要的是，Exodus將最終將開源， UCloud會將核心系統(tǒng)的每一行源碼開放，賦予用戶深入了解和優(yōu)化Exodus的能力。并建設(shè)開源社區(qū)，吸收全行業(yè)的優(yōu)化成果，共同改進和完善Exodus。

網(wǎng)易蔣鴻翔：基于Impala平臺打造交互查詢系統(tǒng)

在數(shù)據(jù)分析當中，因為數(shù)據(jù)基數(shù)龐大、關(guān)系模型復(fù)雜、響應(yīng)時間要求高等特性，數(shù)據(jù)之間的交互查詢就顯得尤為重要。來自網(wǎng)易的大數(shù)據(jù)技術(shù)專家蔣鴻翔現(xiàn)場從交互式查詢特點著手，深入淺出講解了Impala架構(gòu)、原理，以及網(wǎng)易對Impala的改進思路和使用場景。

Impala是Cloudera公司主導(dǎo)開發(fā)的新型查詢系統(tǒng)，它提供SQL語義，能查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù)。已有的Hive系統(tǒng)雖然也提供了SQL語義，但由于Hive底層執(zhí)行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的交互性。相比之下，Impala能夠很快速的實現(xiàn)數(shù)據(jù)查詢。下圖是一個Impala的架構(gòu)圖。

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

網(wǎng)易針對上述不足之處，在原有的Impala查詢系統(tǒng)下，進行了系列改進優(yōu)化：

基于ZK的Loadbalance。原始的Impala負載均衡需要外部支持，為此網(wǎng)易基于ZK做了一個Loadbalance方案； 管理服務(wù)器。主要為了解決當某一個節(jié)點掛掉時數(shù)據(jù)丟失的問題，管理服務(wù)器會將所有的狀態(tài)信息搜集進來，后續(xù)如果做分析都可以通過關(guān)聯(lián)的服務(wù)器查詢； 細粒度權(quán)限和代理； Json格式； 兼容Ranger權(quán)限管理； 批量元數(shù)據(jù)刷新； 元數(shù)據(jù)同步； 元數(shù)據(jù)過濾； 對接ElasticSearch查詢。

據(jù)蔣鴻翔介紹，改造后的交互查詢系統(tǒng)，已經(jīng)成功應(yīng)用于網(wǎng)易數(shù)據(jù)科學(xué)中心的一站式大數(shù)據(jù)平臺自助查詢系統(tǒng)上。同時，數(shù)據(jù)分析中心的一站式報表系統(tǒng)底層，也搭載在Impala上。相信未來，基于Impala的查詢系統(tǒng)將會應(yīng)用于更多不同的場景。

UCloud王仆：UCloud分布式KV存儲系統(tǒng)

分布式KV存儲系統(tǒng)在互聯(lián)網(wǎng)公司中扮演著重要角色，各類上層業(yè)務(wù)對于KV存儲系統(tǒng)的高可用性、可擴展性和數(shù)據(jù)一致性都有著很高的要求。UCloud存儲部門在迭代升級分布式Redis架構(gòu)的同時，也一直致力于研發(fā)基于硬盤存儲的大容量分布式KV系統(tǒng)。來自UCloud的技術(shù)專家王仆，著重介紹了UCloud在大容量分布式KV系統(tǒng)設(shè)計方面的經(jīng)驗，以及應(yīng)對線上業(yè)務(wù)高性能、高容量要求的系統(tǒng)架構(gòu)設(shè)計思路。

下圖為UCloud分布式KV存儲系統(tǒng)架構(gòu)，底層為多個Storage，每一個Storage有三個節(jié)點，這三個節(jié)點需要放在不同的物理機上，防止一臺機器宕機后系統(tǒng)不可用；標紅框的屬于Master節(jié)點，Master節(jié)點通過日志同步的方式，同步到層節(jié)點，整個數(shù)據(jù)的請求從Proxy進入。

整個系統(tǒng)是有中心節(jié)點的系統(tǒng)，路由管理由Master來管理，Master通過每個機器上的Host管理Storage節(jié)點，由Zookeeper確定誰是主誰是從，因此，一些管理方面的請求都是直接連接到Master上的，包括創(chuàng)建、刪除和控制臺方面的功能等。

在測試過程中也發(fā)現(xiàn)了一些性能方面的問題，如采用的部分Raft協(xié)議是單Raft，設(shè)計之初并沒有實現(xiàn)并行Raft功能，因此數(shù)據(jù)同步較慢；其次，請求是通過代理的方式實現(xiàn)，代理的延遲會比直接訪問的延遲更高，后期，會考慮提供一些客戶端的SDK，讓請求可以跳過代理，減少一次網(wǎng)絡(luò)交互。

在KV系統(tǒng)的后續(xù)優(yōu)化上，王仆介紹到，為了能夠?qū)⒋鎯ο到y(tǒng)應(yīng)用于更多不同的業(yè)務(wù)場景，未來會考慮更高的通用性，適配多種的存儲引擎；另外，因為Redis比較流行，系統(tǒng)設(shè)計之初主要是支持Redis，但是業(yè)界還有一些其他協(xié)議，這時候需要特殊的轉(zhuǎn)化流程，未來希望做成一個支持各種協(xié)議的通用結(jié)構(gòu)化存儲系統(tǒng)，適配其他不同協(xié)議。

華為時金魁：實時流計算技術(shù)及其應(yīng)用

隨著Flink/Spark Streaming的大受歡迎，實時流計算開始為人熟知，進入大眾視野。流計算在物聯(lián)網(wǎng)行業(yè)、車聯(lián)網(wǎng)、智慧城市等行業(yè)快速落地，亦創(chuàng)造出越來越多的價值。來自華為的架構(gòu)師時金魁，現(xiàn)場分享了實時流計算的一些技術(shù)方案和落地應(yīng)用。

在傳統(tǒng)的數(shù)據(jù)處理流程中，總是先收集數(shù)據(jù)，然后將數(shù)據(jù)放到DB中。當人們需要的時候通過DB對數(shù)據(jù)做query，得到答案或進行相關(guān)的處理。這個流程看起來雖然合理，但是結(jié)果卻非常的緊湊，尤其是對于一些實時搜索應(yīng)用環(huán)境中的某些具體問題，類似于MapReduce方式的離線處理并不能很好地解決問題。這就引出了一種新的數(shù)據(jù)計算結(jié)構(gòu)---流計算方式。它可以很好地對大規(guī)模流動數(shù)據(jù)在不斷變化的運動過程中實時地進行分析，捕捉到可能有用的信息，并把結(jié)果發(fā)送到下一計算節(jié)點。

目前，業(yè)界開源的流計算框架很多，最早有Storm、Heron，后來還有Akka，Beam，以及現(xiàn)在的Kafka等等。在諸多的開源框架中，時金魁認為，Flink是最恰當?shù)牧饔嬎憧蚣?，Spark Streaming則是最有潛力的流計算框架，但這兩個框架在落地應(yīng)用中都有各自的優(yōu)缺點。

華為根據(jù)Flink與Spark框架各自的特點，摒棄其劣勢，設(shè)計開發(fā)出一款全新的實時流計算服務(wù)Cloud Stream Service（簡稱CS）。CS采用Apache Flink的Dataflow模型，實現(xiàn)完全的實時計算，同時，采用在線SQL編輯平臺編寫Stream SQL，定義數(shù)據(jù)流入、數(shù)據(jù)處理、數(shù)據(jù)流出，用戶無需關(guān)心計算集群, 無需學(xué)習(xí)編程技能，降低流數(shù)據(jù)分析門檻。下圖為華為的實時流計算服務(wù)概覽圖。

據(jù)介紹，CS聚焦于互聯(lián)網(wǎng)和物聯(lián)網(wǎng)場景，適用于實時性要求高、吞吐量大的業(yè)務(wù)場景。主要應(yīng)用在互聯(lián)網(wǎng)行業(yè)中小企業(yè)、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、金融反欺詐等多種行業(yè)應(yīng)用場景，如互聯(lián)網(wǎng)汽車、日志在線分析、在線機器學(xué)習(xí)、在線圖計算、在線推薦算法應(yīng)用等。

總結(jié)

雖然說開源軟件因為其強大的成本優(yōu)勢而擁有極其強大的力量，數(shù)據(jù)庫、云計算廠商仍會嘗試推出性能、穩(wěn)定性、維護服務(wù)等指標上更加強大的產(chǎn)品與之進行差異化競爭，并同時參與開源社區(qū)，借力開源軟件來豐富自己的產(chǎn)品線、提升自己的競爭力，并通過更多的高附加值服務(wù)來滿足部分消費者需求。

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