如此背景下，如何更好地存儲復雜海量的數據？如何從紛繁錯綜的數據中找到真正存在的價值？如何為企業數據架構安全的“保護網”？這些統統被稱為困惑企業的數據難題！
這不，就在前不久剛剛結束的UCan下午茶杭州站活動中，多位技術大咖針對以上問題進行了深入探討，涉及大數據技術的重點場景運用、企業級解決方案等諸多方向，干貨滿滿。
現場開發者爆滿
現場超百位開發者，熱情參與了交流與互動，尤其對大數據技術在具體實踐場景、以及云計算中所發揮的作用等十分關注。
此外，這些探討也將為大數據相關領域的從業者們，提供借鑒與新思路，并十分值得廣大開發者們，認真學習與總結！
數據庫高可用容災方案設計和實現
（UCloud存儲研發工程師 丁順）
如今大數據分析挖掘，已經成為各個行業提升競爭力的全新支點，不但助力商業化進程明顯加速，還就如何在各行各業場景中發揮價值產生了熱議，數據使用權、數據安全、數據存儲等問題亟待解決。
對此，UCloud存儲研發工程師丁順，就“高可用數據庫的概念、架構解決方案以及自動化運維”等相關領域，展開了本沙龍的首個主題分享。
丁順認為，隨著技術的發展，如今的高可用數據庫，其實好處很多，例如可以方便完成讀寫分離。
關于讀寫分離，通常情況下，數據庫的諸多操作中，讀操作請求次數遠大于寫操作，高可用數據庫可以將寫操作放到主庫上，將讀操作分擔到多個從庫上執行，通過這種讀寫分離的方式，提升數據庫的整體運行效率。
“高可用數據庫還可以帶來變更不停服的優點。簡單來解釋，高可用架構由多個數據庫節點組成，要升級整個高可用數據庫架構、或者做變更的話，會將備節點升級，再做主從切換。升級后的備節點變成主節點，之前的主節點變成備節點，隨后整個系統升級完畢，這樣的方式對用戶影響非常小。”他補充道。
此外，高可用數據庫的備份，不影響服務性能。
如果按照數據同步方式，將高可用數據庫進行劃分，可以歸類為共享存儲方案、操作系統實時數據塊的復制、數據庫級別的主從復制以及高可用數據庫集群。其中“主從復制”方案，被認為是最經典的數據同步模式。
在分享過程中，丁順還提及了容災切換的問題。
他強調，一個比較重要的、與高可用架構方案，不太一樣的地方，就是需要數據同步的過程，所以容災切換時，一定要同步好數據之后提升為主庫，把數據庫請求流量導入新主庫，才可以順利提供服務。
另外，怎樣準確判斷是否需要容災，也是值得探討的事兒。
例如，經常出現的網絡波動問題，可能有一段時間，被發現不能鏈接主庫，但通常幾秒鐘之后，整個業務就突然恢復了，如果這個時候，著手進行數據庫的容災工作，代價相對較大。
由于容災的實行，可能存在額外風險，所以要準確判斷，是否需要容災，要選擇在最需要容災的時候下手才好。
此外，需要額外關注的一點，在容災切換時，可能主庫和備庫的數據，會出現不一致。假設容災時，主備不容易切換，最后帶來的問題，很可能就是數據丟失，這一點需要格外留心。
分享結束后，與會開發者還就UDB最大的優點、主從復制過程等方面，與丁順展開了細致探討。
行內人都知道，公有云2.0時代，云數據庫新產品不斷涌現，諸如AWS Aurora、阿里云PolarDB等。這對于長期專注分布式數據庫的研發和運營的劉堅君來說，一個問題始終縈繞在他的腦海中希望得到解決：在利用最新軟硬件和分布式技術改造傳統數據庫的工作中， 除了分布式數據庫所要求的更大和更快之外，是否還有其他更重要的作用與價值呢？
新一代公有云分布式數據庫UCloud Exodus
（UCloud資深數據庫研發工程師 劉堅君）
俗話說有新就有舊，關于新舊分布式數據庫的區分，劉堅君表示，云數據庫出現以來，比較重要的時間節點有幾個，分別是2009年AWS正式發布、國內2012年阿里云推出RDS、UCloud在2013年推出UCloud UDB、2014年AWS推出AURORA以及2017年阿里云推出PolarDB。
在我們看來，其實過去的1.0版本，并非毫無用處，確實可以帶來幾方面的價值，其中重要的一方面，就是快速部署免運維的彈性。
隨著云數據庫使用量的增加，問題很難避免，所以云廠商必然會組建專業的DB團隊，來“攻克” 7X24處理問題的模式，隨之而來的就是“無死角”故障救援的推進，包括數據恢復、慢查詢、參數調優等環節。
相比2.0，盡管1.0依然存在用戶價值，但出現的問題，也是不容忽視的。對此劉堅君明確認為，如今通過計算和存儲分離的架構，可以讓這些問題迎刃而解。
首先，在容量與性能方面，分離架構可以幫助容量，達到100個TB，針對大部分業務的數據讀庫多寫少的特點，增加只讀實現讀性能大幅度提升，同時MySQL可達100%兼容，硬件成本有效降低。
另外，針對存儲容量和計算能力按需擴容的問題，相對而言按需付費是最合理的，這表示在多個業務共同開發的過程中，分離架構可以幫助企業新業務達到逐步擴容，老業務也可以同步按照使用量擴容。
一直以來，企業最關注運營成本。“資源成本計算機型和存儲機型分開選型，成本可以大幅降低；MySQL100%兼容的情況，又讓分庫分表的方式成為過去。”他補充道。
談到UCloud Exodus的具體實踐，劉堅君強調，其技術理念則更進一步。計算和存儲分離后，存儲層將完全復用云平臺的高性能分布式存儲（如UCloud UDisk、阿里云盤古等），而會專注于構建一款數據庫內核，去適配主流公有云和私有云廠商發布的高性能分布式存儲產品，這種產品架構，稱之為Shared-All-Disk架構。
Shared-All-Disk架構的優點明顯。在提供云數據庫2.0創新功能的同時，賦予了用戶業務自由遷徙的能力，不被某個云平臺綁架；同時能夠連接上下游的軟硬件廠商，共享云數據庫2.0技術紅利，共建生態。
更為重要的是Exodus最終開源， 會將核心系統的每一行源碼開放，賦予用戶深入了解和優化Exodus的能力。
當然，采用Shared-All-Disk這種開放式架構，有更多技術問題需要解決，其中的核心問題是IO路徑問題。IO路徑的優化，盡管有時候會押寶公有云產品的生產能力，但并不意味著在路徑優化上毫無作為。
具體來說，主要是移除Binlog，主從同步后采用Redolog復制，隨后下游系統數據同步，依據歸檔日志（由Redo log歸檔而來）反向生成Binlog然后同步，Binlog去除后，基于分布式存儲的原子寫能力有效去Double Write。需要說明的是，借鑒大部分2.0數據庫，主從數據庫同步采用了Redolog，主從之間同步Redolog Addr，從收到Addr之后再去底層數據中完成拉取。
分享過程中，在場開發者還提及數據的壓縮性問題，指出所介紹的路徑，是否考慮到數據量擴大的問題，畢竟每天產生的數據量，都要在10億以上。
現場開發者積極互動
關于這個問題，劉堅君表示，該場景應用Aurora，目前來說，也解決不了過多的問題。如今云上場景，用來適配物聯網還比較少，如果可以做到多點同時寫入會更好。
精彩分享仍在繼續，關于數據庫的探討，暫時告一段落后，網易資深數據庫內核&大數據技術專家蔣鴻翔，又為與會開發者帶來了主題為“基于Impala平臺打造交互查詢系統”的演講。
基于Impala平臺打造交互查詢系統
（網易資深數據庫內核&大數據技術專家 蔣鴻翔）
提到“交互查詢”，蔣鴻翔先從交互查詢的選型入手，他表示，項目熟悉程度、大廠背書情況以及熟悉了解其性能和優缺點指標都是考察選型的重要信息。既要拼性能，又要拼優缺點，要前期測試還要后期維護，本就不容易選擇。
打比方來說，如果一個平臺的性能很好，但整體架構部署上，卻很復雜，模塊多樣且需要專人維護，這樣計算下來運維成本顯然很高，所以從性能以及運維成本出發，成本一旦較高，對性能的追求，也就只能以“基本滿足”為標準了。
為了性能和成本的雙舉，他拋出了Impala平臺，總結出該平臺有幾個鮮明的特點與優勢，例如，元數據緩存，是其高性能表現的重要特點之一。
據悉，利用Impala平臺查詢之后，整個表單的數據，在哪個節點上都會一目了然，組織清晰。此外，平臺還高效支持MPP并行計算，只是當集群規模變大時，就會變得相對棘手一些。
如今，代碼生成，是比較流行的方式之一，很多自研數據庫都會做代碼生成，而Impala主要是用C11寫成，此外還支持HDFS本地讀。
盡管Impala平臺優勢多多，但依舊存在服務單點、Web信息不持久化、資源隔離不精準、底層存儲不能區分用戶以及負載均衡需要外部支持等缺陷。
對于此類問題的解決，蔣鴻翔一般情況下選擇將Impala配合大數據平臺綜合使用。
他補充道，大數據服務中比較重要的選型就是ZK，如果基于ZK做成一個Load Balance，客戶關聯的時候，就可以主動選擇，而不是被動接受，如果一臺服務器出現問題，ZK的節點就會自動消掉，不會對全局產生影響。
“如果加入一個管理服務器的組件，就可以更好解決服務器節點出現故障所導致的歷史數據丟失問題，而且還排除了后期排查的種種局限。管理服務器會將所有的狀態信息搜集進來，后續做相關分析時再也不會費力不討好。”蔣鴻翔說。
目前，分布式KV存儲系統，在互聯網公司中，扮演著重要的角色，各類上層業務，對于KV存儲系統的高可用性, 可擴展性和數據一致性都有著近乎苛刻的要求。
支持大部分Redis主要數據結構的協議……
在實際使用中比Key-Value命令更普遍……
還可將純內存的Redis，轉變為硬盤存儲，提高容量，降低成本……
最重要的一點，可以滿足對多副本間的數據強一的要求，在性能優先的情況下，可以將同步方式降級成為最終一致……
一直以來，為了滿足這些，UCloud存儲部門，在迭代升級分布式Redis架構的同時，也一直致力于研發，基于硬盤存儲的大容量分布式KV系統。
“我們發現，目前在線的服務Redis是比較流行的協議，支持較多的數據結構，包括Hash等，所以希望這套KV存儲，能夠用協議轉化的方式支持大部分Redis協議，可以做到將一個純內存的存儲變成硬盤存儲，達到成本降低、容量提升的效果，最高應該可以支持到PD級別。”UCloud技術專家王仆提出。
UCloud分布式KV存儲系統
（UCloud技術專家 王仆）
在長期的實踐探索中，王仆發現，在測試中還是會出現一些性能方面的問題。例如一些Raft協議，可以認為是單Raft，并沒有實現并行Raft功能，同步并不快等。
鑒于此，他表示后期會考慮更高的通用性的嘗試，例如適配多種的存儲引擎，另外一點，就是希望做成一個支持各種協議的通用結構化存儲協議。
關于恰當利用Redis的案例分析，據了解，其實大型社交App的客戶比較適用，此外一個重要的應用，就是關注以及狀態消息發布的場景。
例如，幾百萬用戶的社交群體，要求響應會比較高，用戶一般會使用Redis的數據結構來緩存數據，達成較快的響應。
王仆著重強調，其實KV存儲最大的應用，還是互聯網廣告的DSP。
DSP中，一般會在緩存中，存儲一些用戶定向的標簽，例如健身或者購物。
“之前把這些標簽和要投放的廣告ID聯系起來，比較快的加速定向標簽對應的廣告投放，通過觀察投放效果來修正廣告投放的估算值，這些信息一般來說會用一個獨立的緩存。這種情況下，一般比較大的公司都會自己做緩存服務，如果是一個相對簡單的系統或者平臺，多數用戶還是選擇使用Redis來實現。”王仆說。
作為沙龍最后一位登臺分享的嘉賓，華為云技術專家時金魁表示，其實開源流計算很多，最早是STORM，還有HERON，后來還涉及到Akka等。
實時流計算技術及其應用
（華為云技術專家 時金魁）
在“實時流計算技術及其應用”的分享中，時金魁表示，流計算不能避免Dataflow模型。
原因在于，首先流數據沒有便捷結束的說法，數據作業開始之后就永遠都不會停止；此外，很多操作都是基于一個數據集，數據集是有限的，例如查SQL語句，有開始和結束，但是流式結束查詢的時候，數據結構是持續增加的，流量并沒有結束。
實時云計算適用場景比較多，例如廣告、監控大盤、打車軟件、金融風控、異常檢測、交通、物流、外賣等，而且金融風控，交通、物流、外賣等很多場景都可以看到實時大數據。
談及流計算的技術層面，時金魁認為，Flink做計算還是比較合適的。除了有一個TABLE，還能做一些SQL以及時空數據，主要用在物聯網方向，例如電子圍欄、車輛超速、地理位置，以及智能學習的模型、實時推理等。
“Flink用的最多的就是SQL。現在云上很多用戶，一般直接寫SQL，還有就是API。 Flink的特性，最基本的就是，具備消息事件，有Event Tine、ingest Time和Process Time等。”他補充道。
Flink雖然看似“超能”，但也會有一些潛在的問題存在。例如，Flink數據傾斜有一個問題。因為實時數據，每一個時間點的數據量不一樣，隨著時間點突然增加，這個數據量變大后，要計算資源，還要動態調配，這可以算是一個業界難題了。
大數據，從技術角度看，涉及計算、存儲、網絡等范圍甚廣、學習難度大，但卻可以發揮重要作用。大數據，從產業角度看，可以顯著提升傳統企業的運營效率，助力數字化升級；引領全新的商業模式，為新興企業贏得快速發展機遇……
UCan下午茶關于數據的探討，雖然暫時告一段落，但企業針對數據的深入探索，似乎才剛剛開始！
京公網安備 11010502049343號