作者 | 馬超責編 | 伍杏玲出品 | CSDN(ID：CSDNnews)

5月14日，TPC 官網正式公布，阿里云自研的 AnalyticDB 通過了TPC-DS全流程測試，將前世界紀錄的性能提升了29%，并把單位成本降低了三分之二，成功奪得全球數據倉庫的桂冠。

云市場“只見新人笑、不見老牌哭”。

目前業界普遍認為容器、物聯網、數據庫和數倉會是云計算未來四大增長技術。尤其是物聯網將帶來的30倍于目前互聯網的流量，將會促使業界從傳統的 Big Data 向 Fast Data 的演進歷史。

據最新預測數據，到 2025 年企業 50% 的數據是云存儲，企業 75% 的數據庫運行在云上。可以說一個性能強大的數倉產品，已經成為云服務商的必選項了。

據Gartner最新數據，亞馬遜、微軟、阿里巴巴三家云計算巨頭之間激戰正酣。贏者通吃，是云計算市場真實的寫照。相信本次AnalyticDB的表現，對于阿里云繼續擴大市場份額，有一些推動作用。

初識數據倉庫

數據倉庫是由比爾?恩門(Bill Inmon)教授在1990年提出，在概念提出伊始，主要功能是將通過聯機事務處理(OLTP)所產生大量數據，透過數據倉庫理論的資料儲存架構，進行數據的分析整理，進而支持如決策支持系統(DSS)、主管資訊系統(EIS)的創建，幫助用戶在快速有效的大量數據中，分析出有價值的資訊，以利決策擬定及快速回應外在環境變動，幫助建構商業智能(BI)。與傳統的數據庫相比數據倉庫的不同之處有以下幾點：

1、數據倉庫是面向主題。操作型數據庫的數據組織面向事務處理任務，數據倉庫中的數據是按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。

2、數據倉庫的數據是其它數據源抽取而來。數據倉庫的數據有來自于分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合后才能進入數據倉庫。數倉中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關于整個企業的一致的全局信息。

3、數據倉庫是不可更新的。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦數據被修改，其實就涉嫌數據造假，一旦某個數據進入數據倉庫以后，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，修改和刪除操作，通常只是定期的加載、刷新。

TP數據庫是面向事務處理的，所謂事務其實就是交易各個狀態之間的遷移與記錄，因此TP庫各個業務系統之間各自分離。AP數倉中的則是按照一定的主題域進行組織的。主題是與TP數據庫的面向應用相對應的，是一個抽象概念，是在較高層次上將企業信息系統中的數據綜合、歸類并進行分析利用的抽象。每一個主題對應一個宏觀的分析領域?？梢哉f處理任務的不同是TP數據庫與AP數倉之間的本質區別。

數據倉庫的江湖慢是“原罪”

在這個Fast Data的時代，誰的數倉能先跑出結果，誰就能掌握先機。比如目前筆者所在銀行業的核心系統一般都用Oracle數據庫，來進行交易處理(TP)，完成整個流程性應用的內容，并產生應用數據數據。等交易結束了，數據的生命周期也結束了。要想把數據價值做二次表達，要每天做ETL，跑批作業，存到數據倉庫中，然后在數據倉庫中建模、挖掘、數據集市、ODS，一層一層地構建起數據倉庫報表。

這時可能一些更細節、隱含的問題，比如非線性問題還是回答不了，那么就要把數據復制到SAS中做機器學習，再做統計的指標體系，去做進一步的挖掘。數據要在這里搬動三次，復制三份冗余，還要管理數據一致性，每天數據中心運維的大量工作在做數據搬家。而所以分析處理(AP)操作結束往往都已經是T+1日的下午了，這樣的效率是無法滿足云時代快速展示的競爭要求。

因此云時代的數據中心急需要一款融合性的計算框架，AnalyticDB所帶來的極致速度，堪稱云時代計算框架的典范。在Forrester發布《The Forrester Wave: Cloud Data Warehouse》研究報告中，阿里云入選強勁表現者象限，位列中國廠商中的第一。

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、行列混存和智能索引等方面也有很多創新點，后續有機會筆者再詳細向大家介紹。

更多精彩推薦

?自動化神經網絡理論進展緩慢，AutoML 算法的邊界到底在哪？

?瑞幸咖啡 CEO 和 COO 被暫停職務；快手起訴抖音索賠 500 萬元；Wine 5.8 發布 | 極客頭條

?任正非談“狼文化”：華為沒有 996，更沒有 007

?作詞家下崗系列：教你用 AI 做一個寫歌詞的軟件！

?手把手教你配置VS Code 遠程開發工具，工作效率提升N倍

?區塊鏈必讀“上鏈”哲學：“胖鏈下”與“瘦鏈上”

你點的每個“在看”，我都認真當成了喜歡

總結

以上是生活随笔為你收集整理的仓库处理中 无法修改_阿里云自研数据仓库 AnalyticDB 再捧 TPC 全球冠军的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。