雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
5月14日，TPC 官網正式公布，阿裡雲自研的 AnalyticDB 通過了TPC-DS全流程測試，将前世界紀錄的性能提升了29%，并把機關成本降低了三分之二，成功奪得全球資料倉庫的桂冠。
雲市場“隻見新人笑、不見老牌哭”。
目前業界普遍認為容器、物聯網、資料庫和數倉會是雲計算未來四大增長技術。尤其是物聯網将帶來的30倍于目前網際網路的流量，将會促使業界從傳統的 Big Data 向 Fast Data 的演進曆史。
據最新預測資料，到 2025 年企業 50% 的資料是雲存儲，企業 75% 的資料庫運作在雲上。可以說一個性能強大的數倉産品，已經成為雲服務商的必選項了。
據Gartner最新資料，亞馬遜、微軟、阿裡巴巴三家雲計算巨頭之間激戰正酣。赢者通吃，是雲計算市場真實的寫照。相信本次AnalyticDB的表現，對于阿裡雲繼續擴大市場佔有率，有一些推動作用。
1 初識資料倉庫
資料倉庫是由比爾•恩門（Bill Inmon）教授在1990年提出，在概念提出伊始，主要功能是将通過聯機事務處理(OLTP)所産生大量資料，透過資料倉庫理論的資料儲存架構，進行資料的分析整理，進而支援如決策支援系統(DSS)、主管資訊系統(EIS)的建立，幫助使用者在快速有效的大量資料中，分析出有價值的資訊，以利決策拟定及快速回應外在環境變動，幫助建構商業智能(BI)。與傳統的資料庫相比資料倉庫的不同之處有以下幾點：
1、資料倉庫是面向主題。操作型資料庫的資料組織面向事務處理任務，資料倉庫中的資料是按照一定的主題域進行組織。主題是指使用者使用資料倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型資訊系統相關。
2、資料倉庫的資料是其它資料源抽取而來。資料倉庫的資料有來自于分散的操作型資料，将所需資料從原來的資料中抽取出來，進行加工與內建，統一與綜合後才能進入資料倉庫。數倉中的資料是在對原有分散的資料庫資料抽取、清理的基礎上經過系統加工、彙總和整理得到的，必須消除源資料中的不一緻性，以保證資料倉庫内的資訊是關于整個企業的一緻的全局資訊。
3、資料倉庫是不可更新的。資料倉庫的資料主要供企業決策分析之用，所涉及的資料操作主要是資料查詢，一旦資料被修改，其實就涉嫌資料造假，一旦某個資料進入資料倉庫以後，一般情況下将被長期保留，也就是資料倉庫中一般有大量的查詢操作，修改和删除操作，通常隻是定期的加載、重新整理。
TP資料庫是面向事務處理的，所謂事務其實就是交易各個狀态之間的遷移與記錄，是以TP庫各個業務系統之間各自分離。AP數倉中的則是按照一定的主題域進行組織的。主題是與TP資料庫的面向應用相對應的，是一個抽象概念，是在較高層次上将企業資訊系統中的資料綜合、歸類并進行分析利用的抽象。每一個主題對應一個宏觀的分析領域。可以說處理任務的不同是TP資料庫與AP數倉之間的本質差別。
2 資料倉庫的江湖慢是“原罪”
在這個Fast Data的時代，誰的數倉能先跑出結果，誰就能掌握先機。比如目前筆者所在銀行業的核心系統一般都用Oracle資料庫，來進行交易處理（TP），完成整個流程性應用的内容，并産生應用資料資料。等交易結束了，資料的生命周期也結束了。要想把資料價值做二次表達，要每天做ETL，跑批作業，存到資料倉庫中，然後在資料倉庫中模組化、挖掘、資料集市、ODS，一層一層地建構起資料倉庫報表。
這時可能一些更細節、隐含的問題，比如非線性問題還是回答不了，那麼就要把資料複制到SAS中做機器學習，再做統計的名額體系，去做進一步的挖掘。資料要在這裡搬動三次，複制三份備援，還要管理資料一緻性，每天資料中心運維的大量工作在做資料搬家。而是以分析處理（AP）操作結束往往都已經是T+1日的下午了，這樣的效率是無法滿足雲時代快速展示的競争要求。
是以雲時代的資料中心急需要一款融合性的計算架構，AnalyticDB所帶來的極緻速度，堪稱雲時代計算架構的典範。在Forrester釋出《The Forrester Wave: Cloud Data Warehouse》研究報告中，阿裡雲入選強勁表現者象限，位列中國廠商中的第一。
3 AnalyticDB的速度之源
在翻閱了AnalyticDB的論文（
https://dl.acm.org/doi/10.14778/3352063.3352124）之後，筆者ADB最大的亮點在于其基于 Raft 協定建構了一套分布式強一緻高可靠的輕量級存儲。ADB存儲可實作高吞吐實時寫入，在實時寫入強一緻可見、支援 ACID ，特别極緻分析性能場景，在SQL 分析性能上有較大優勢。AnalyticDB 存儲整體架構如下：
目前在一緻性算法領域幾乎是Paxos的天下，如阿裡的金融級分布式資料庫OceanBase是使用Paxos算法來保證節點一緻性的，詳見《200行代碼解讀國産資料庫阿裡在OceanBase的速度頭源》。本次ADB使用RAFT協定做為其自研存儲的一緻性算法，則給業界帶來了一股清新的氣息。
一個最小化的Raft叢集，典型節點數量是5個，這樣的配置可以同時容忍兩台伺服器出現故障。伺服器可能會處于如下三種角色：leader、candidate、follower，正常運作的情況下，會有一個leader，其他全為follower，follower隻會響應leader和candidate的請求，用戶端的請求則全部由leader處理，即使有用戶端請求了一個follower也會将請求重定向到leader。candidate代表候選人，出現在選舉leader階段，選舉成功後candidate将會成為新的leader。可能出現的狀态轉換關系如下圖：
可以看到，在RAFT叢集剛啟動時，所有節點都是follower，之後在time out信号的驅使下，follower會轉變成candidate去拉取選票，獲得大多數選票後就會成為leader，這時候如果其他候選人發現了新的leader已經誕生，就會自動轉變為follower；而如果另一個time out信号發出時，将會重新開始一次新的選舉。
不光是自研存儲，ADB在高性能批量導入、高吞吐實時更新 DML、行列混存和智能索引等方面也有很多創新點，後續有機會筆者再詳細向大家介紹。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-05-13
本文作者：馬超
本文來自：“
CSDN”，了解相關資訊可以關注“
”