企業該如何做大資料的分析挖掘?這裡有一份參考指南

UCloud雲端計算發表於2018-08-21

現如今已經進入大資料時代,各種系統、應用、活動所產生的資料浩如煙海,資料不再僅僅是企業儲存的資訊,而是成為可以從中獲取巨大商業價值的企業戰略資產。這樣背景下,如何儲存海量複雜的資料、從紛繁錯綜的資料中找到真正有價值的資料,是大資料時代企業面臨的難題。

8月18日的“UCan下午茶”杭州站,來自UCloud、網易、華為的五位技術專家,從資料庫高可用容災方案設計和實現、新一代公有云分散式資料庫、基於Impala平臺打造互動查詢系統等不同維度出發,分享了他們在大資料查詢、分析、儲存開發過程中遇到的“困惑”與解決方案。

UCloud丁順:資料庫高可用容災方案設計和實現

高可用容災是搭建資料庫服務的一個重要考量特性,搭建高可用資料庫服務需要解決諸多問題,保證最終的容災效果。UCloud雲資料庫產品UDB在研發演進過程中,根據使用者的需要不斷完善和演進,形成了一套完善的高可用架構體系。

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

業界典型的高可用架構可以劃分為四種:第一種,共享儲存方案;第二種,作業系統實時資料塊複製;第三種,資料庫級別的主從複製;第三,高可用資料庫叢集。每種資料同步方式可以衍生出不同的架構。

第一種,共享儲存。共享儲存是指若干DB服務使用同一份儲存,一個主DB,其他的為備用DB,若主服務崩潰,則系統啟動備用DB,成為新的主DB,繼續提供服務。共享儲存方案的優點是沒有資料同步的問題,缺點是對網路效能要求比較高。 第二種,作業系統實時資料塊複製。這種方案的典型場景是DRBD。如下圖所示,左邊資料庫寫入資料以後立即同步到右邊的儲存裝置當中。如果左邊資料庫崩潰,系統直接將右邊的資料庫儲存裝置啟用,完成資料庫的容災切換。這個方案同樣有一些問題,如系統只能有一個資料副本提供服務,無法實現讀寫分離;另外,系統崩潰後需要的容災恢復時間較長。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

第三種,資料庫主從複製。這種方案是較經典的資料同步模式,系統採用一個主庫和多個從庫,主庫同步資料庫日誌到各個從庫,從庫各自回放日誌。它的好處是一個主庫可以連線多個從庫,能很方便地實現讀寫分離,同時,因為每個備庫都在啟動當中,所以備庫當中的資料基本上都是熱資料,容災切換也非常快。 第四種,資料庫高可用叢集。前面三種是通過複製日誌的模式實現高可用,第四種方案是基於一致性演算法來做資料同步。資料庫提供一種多節點的一致性同步機制,然後利用該機制構建多節點同步叢集,這是業界近年來比較流行的高可用叢集的方案。 UCloud綜合了原生MySQL相容、不同版本、不同應用場景的覆蓋等多種因素,最終選擇採用基於資料庫主從複製的方式實現高可用架構,並在原架構基礎上,使用雙主架構、半同步複製、採用GTID等措施進行系列優化,保證資料一致性的同時,實現日誌的自動定址。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

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

UCloud劉堅君:新一代公有云分散式資料庫UCloud Exodus

公有云2.0時代,雲資料庫新產品不斷湧現。諸如AWS Aurora、阿里雲PolarDB等,UCloud在採用最新軟硬體和分散式技術改造傳統資料庫的工作中,也在思考除了分散式資料庫所要求的更大和更快之外,是否還有其他更重要的使用者價值?UCloud資深資料庫研發工程師劉堅君,現場講解了UCloud對於新一代公有云分散式資料庫的思考與設計。

劉堅君首先從1.0時代存在的問題入手,他認為1.0時代雲資料庫帶來了三方面價值:彈性、故障救援、知識複用。但它同樣面臨三大難以解決的問題:容量和效能、租用成本、運營成本。

到2.0時代,解決上述三個問題的思路是計算和讀寫分離。通過計算和讀寫分離,將傳統資料庫的計算層和儲存層拆開,各自獨立擴充套件和演進。這樣做的好處是:1.提供更大的容量和讀寫效能;2.按需擴容和付費;3.優化運營成本並降低運營風險。業界已推出的2.0雲資料庫(如Aurora、PolarDB等),均採用計算和儲存分離的架構。

UCloud Exodus的產品和技術理念則更進一步:計算和儲存分離後,儲存層將完全複用雲平臺的高效能分散式儲存(如UCloud UDisk、阿里雲盤古等),而Exodus則專注於構建一款資料庫核心,去適配主流公有云和私有云廠商釋出的高效能分散式儲存產品。Exodus的這種產品架構,稱之為Shared-ALL-DISK架構。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

Shared-ALL-DISK架構的優點明顯,在提供雲資料庫2.0創新功能的同時,賦予使用者業務自由遷徙的能力,不被某個雲平臺綁架,同時能夠連線上下游的軟硬體廠商,共建Exodus資料庫生態。

更為重要的是,Exodus將最終將開源, UCloud會將核心系統的每一行原始碼開放,賦予使用者深入瞭解和優化Exodus的能力。並建設開源社群,吸收全行業的優化成果,共同改進和完善Exodus。

網易蔣鴻翔:基於Impala平臺打造互動查詢系統

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

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

企業該如何做大資料的分析挖掘?這裡有一份參考指南

Impala擁有後設資料快取、MPP平行計算、支援LLVM與JIT以及支援HDFS本地讀、運算元下推等特性。但它也有一些缺陷,如服務單點、Web資訊無法持久化、資源隔離並不精確、負載均衡需要外部支援等。

網易針對上述不足之處,在原有的Impala查詢系統下,進行了系列改進優化:

基於ZK的Loadbalance。原始的Impala負載均衡需要外部支援,為此網易基於ZK做了一個Loadbalance方案; 管理伺服器。主要為了解決當某一個節點掛掉時資料丟失的問題,管理伺服器會將所有的狀態資訊蒐集進來,後續如果做分析都可以通過關聯的伺服器查詢; 細粒度許可權和代理; Json格式; 相容Ranger許可權管理; 批量後設資料重新整理; 後設資料同步; 後設資料過濾; 對接ElasticSearch查詢。 據蔣鴻翔介紹,改造後的互動查詢系統,已經成功應用於網易資料科學中心的一站式大資料平臺自助查詢系統上。同時,資料分析中心的一站式報表系統底層,也搭載在Impala上。相信未來,基於Impala的查詢系統將會應用於更多不同的場景。

UCloud王僕:UCloud分散式KV儲存系統

分散式KV儲存系統在網際網路公司中扮演著重要角色,各類上層業務對於KV儲存系統的高可用性、可擴充套件性和資料一致性都有著很高的要求。UCloud儲存部門在迭代升級分散式Redis架構的同時,也一直致力於研發基於硬碟儲存的大容量分散式KV系統。來自UCloud的技術專家王僕,著重介紹了UCloud在大容量分散式KV系統設計方面的經驗,以及應對線上業務高效能、高容量要求的系統架構設計思路。

下圖為UCloud分散式KV儲存系統架構,底層為多個Storage,每一個Storage有三個節點,這三個節點需要放在不同的物理機上,防止一臺機器當機後系統不可用;標紅框的屬於Master節點,Master節點通過日誌同步的方式,同步到層節點,整個資料的請求從Proxy進入。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

整個系統是有中心節點的系統,路由管理由Master來管理,Master通過每個機器上的Host管理Storage節點,由Zookeeper確定誰是主誰是從,因此,一些管理方面的請求都是直接連線到Master上的,包括建立、刪除和控制檯方面的功能等。

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

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

華為時金魁:實時流計算技術及其應用

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

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

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

華為根據Flink與Spark框架各自的特點,摒棄其劣勢,設計開發出一款全新的實時流計算服務Cloud Stream Service(簡稱CS)。CS採用Apache Flink的Dataflow模型,實現完全的實時計算,同時,採用線上SQL編輯平臺編寫Stream SQL,定義資料流入、資料處理、資料流出,使用者無需關心計算叢集, 無需學習程式設計技能,降低流資料分析門檻。下圖為華為的實時流計算服務概覽圖。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

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

總結

雖然說開源軟體因為其強大的成本優勢而擁有極其強大的力量,資料庫、雲端計算廠商仍會嘗試推出效能、穩定性、維護服務等指標上更加強大的產品與之進行差異化競爭,並同時參與開源社群,借力開源軟體來豐富自己的產品線、提升自己的競爭力,並通過更多的高附加值服務來滿足部分消費者需求。

總的來看,未來的大資料分析技術、儲存將會變得越來越成熟、越來越便宜、越來越易用,相應的,使用者將會更容易、更方便地從自己的大資料中挖掘出有價值的商業資訊。

想要獲取更多技術和活動資訊,可掃描以下二維碼,關注“UCloud技術公告牌”微信公眾號;或搜尋微信ID:ucloud_tech進行關注。

企業該如何做大資料的分析挖掘?這裡有一份參考指南

相關文章