自研云原生数据仓库AnalyticDB再破权威评测TPC-DS世界纪录
北京時間 2020/5/4 青年節，TPC（全球最知名非盈利的數據管理系統評測基準標準化組織）官網正式上線AnalyticDB TPC-DS成績，AnalyticDB通過嚴苛的TPC-DS全流程測試，性能QphDS分數為14895566，性價比分數為0.08CNY，相比較基于Spark深度優化版的前世界紀錄性能提升29%并且單位成本僅為其1/3，成為TPC-DS官方榜單上全球性能、性價比雙雙領先的數據倉庫，這是繼2019/4/26之后再次獲得全球領先的成績！榜單截圖如下，詳細榜單請參見：TPC-DS Results
隨著云時代全面到來，企業數據需求不斷變化，從傳統的Big Data逐漸向Fast Data演進，主要表現在如下4個方面（部分數據參考Gartner、IDC）：
? 數據規模爆炸性增長，到2020年全球數據預計會到40ZB，而到2025年還會繼續增長4倍以上。
? 企業上云速度明顯加快，預計到2025年企業50%的數據都是云存儲，而企業75%的數據庫都運行在云上。
? 數據的實時化需求強烈，預計2025年全球數據處理中會有30%是實時數據處理。
? 數據智能化趨勢明顯，隨著AI和5G技術的發展，非結構化數據快速增長，到2025年預計80%的數據都是非結構化數據。
在數據爆炸性增長、企業全面上云的大背景下，海量數據的存儲、處理的性能及性價比是云原生數倉面向未來最核心的關鍵技術指標之一，TPC官方推出的TPC-DS基準測試是對一個數據倉庫從數據導入、查詢性能（單并發、多并發）、查詢復雜度（覆蓋星型模型/雪花模型、復雜Window function支持）、可用性（數據一致、壞盤容錯處理等）全方面的嚴格考核，并需要進行全面嚴苛的審計，是目前全球衡量一個數據倉庫成熟度、競爭力的核心基準測試。
AnalyticDB作為云時代的云原生數據倉庫，參與TPC-DS基準測試是我們提升自研產品產品化能力、核心技術突破驗證的重要過程，也是我們技術走向全球領先的必經之路，這個過程中的核心技術突破正在幫我們的客戶提升性能進一步提升實時化進程、大幅降低成本，一起進入數據庫與大數據一體化、業務在線化的新時代。
1. AnalyticDB介紹
AnalyticDB（簡稱ADB，原ADS）?是阿里巴巴自主研發、唯一經過超大規模以及核心業務驗證的PB級實時數據倉庫，自2012年第一次在集團發布上線以來，至今已累計迭代發布近百個版本，支撐起集團內的電商、廣告、物流、文娛、旅游、風控等眾多在線分析業務。AnalyticDB于2014年在阿里云開始正式對外輸出，支撐行業既包括傳統的大中型企業和政府機構，也包括眾多的互聯網公司，覆蓋外部十幾個行業。
AnalyticDB MySQL 3.0 （簡稱ADB 3.0）是在過去8年沉淀的基礎上，基于數據庫大數據一體化的理念及趨勢以及工程上深度打磨出的云原生數倉升級版本。在本次TPC-DS基準測試中，AnalyticDB MySQL 3.0充分展現了出色的云原生技術優勢，對比友商有近10倍的巨大優勢！
2. TPC-DS性能基準介紹
TPC (Transaction Processing Performance Council) 是事務性能管理委員會的簡稱，是最知名的非盈利的數據管理系統評測基準標準化組織，它制定商務應用基準程序（Benchmark）的標準規范、性能和價格度量，并管理測試結果的發布，而TPC Benchmark測試結果是衡量一個數據管理系統性能及性價比的最核心指標之一。
TPC-DS基準測試模擬了一個典型的零售行業數據倉庫的評測決策支持系統（Decision Support），是數據庫界最具挑戰的一個測試基準，是TPC-H的升級版，它采用星型、雪花等多維數據模式，測試集包含對大數據集的統計、報表生成、聯機查詢、數據挖掘等復雜應用，與真實場景非常接近。
TPC-DS的難點和挑戰主要有：
- 數據集規模大，例如事實表store_sales，單表超過280億行。
- 面向真實零售決策場景，SQL非常復雜：覆蓋SQL99和2003的核心部分以及OLAP標準；既包含報表類ad-hoc低延時查詢，又包含海量數據挖掘高吞吐分析查詢。
- 測試項多且維度廣：既要高性能、高可靠、高可用、高性價比，又要ETL和數據更新的ACID能力。
TPC-DS測試流程及數據模型：
3. AnalyticDB MySQL 3.0 技術架構
AnalyticDB MySQL 3.0 采用云原生架構，計算存儲分離、冷熱數據分離，支持高吞吐實時寫入和數據強一致，兼顧高并發查詢和大吞吐批處理的混合負載。
第一層是接入層，由Mulit-Master可線性擴展的協調節點構成，主要負責協議層接入、SQL解析和優化、實時寫入Sharding、數據調度和查詢調度。
第二層是計算引擎，具備分布式MPP+DAG融合執行能力，結合智能優化器，可支持高并發和復雜SQL混合負載，同時借助于云原生基礎設施，計算節點實現了彈性調度，可根據業務需求做到分鐘級甚至秒級擴展，達到了資源的有效利用。
第三層是存儲引擎，基于Raft協議實現的分布式實時強一致高可用存儲引擎，通過數據分片和Multi-Raft實現并行，利用分層存儲實現冷熱分離降低成本，通過行列存儲和智能索引達到極致性能。
4. AnalyticDB存儲技術
4.1 分布式強一致存儲
AnalyticDB MySQL 3.0 存儲完全自主研發，基于Raft協議構建了一套分布式強一致高可靠的輕量級存儲架構，可實現高吞吐實時寫入，適合極致分析性能場景。AnalyticDB MySQL 3.0存儲相比開源HBase、Kudu等在SQL分析性能上有較大優勢，并且在實時寫入強一致可見、支持ACID方面也是開源ElasticSearch、ClickHouse等所不具備的能力。
AnalyticDB存儲整體架構如下：
AnalyticDB MySQL 3.0是基于數據庫的并行數據模型，存儲建模親和MPP計算模型，內部實現為多層并行的架構：
- 第一級是集群實例級并行，用戶實例被劃分為多個存儲節點組（Worker Group），每個Worker Group由 N（通常是3，也可以是其他基數）個Worker構成。Worker相當于用戶數據節點容器，分組的目標是保證系統大規模擴展時不會出現通信膨脹、也方便系統并行升級和運維。
- 第二級是DB并行，用戶數據庫被切分為N個物理分庫（Shard，也叫數據分片），每個Shard是獨立的Raft Group以保證數據強一致，多個Shard就形成了multi-raft的并行。Shard是可以是Hash或者Range分區，通常Hash分區可以做數據對齊以避免數據大表JOIN的數據Shuffle；Shard可以在需要的時候在不同Worker Group之間均衡或者遷移，Shard本身也會支持動態分裂和合并。
- 第三是表內并行，對于數倉場景的歷史數據存儲通常有數據分區的概念，例如TPC-DS中store sales就可以根據時間周期分區，數據分區除方便數據生命周期管理外還可以支持查詢分區裁剪和DFP，有助于大幅縮小數據計算范圍。
在TPC-DS基準測試中，通過分布式并行存儲架構以及感知存儲分布的查詢優化和執行引擎緊密配合，整體性能優異。
4.2 高性能批量導入
數據導入速度是云數倉的基礎能力，在TPC-DS中對導入有著極致的性能要求，我們的第一個優化思路是輕量級build（把實時數據轉換為全量分區數據稱之為build），AnalyticDB MySQL 3.0實現了輕量化的全內存單副本local build，相比之前版本的類MR作業的全量build大幅減少了讀寫DFS和落盤開銷，并且可以充分通過本地化向量指令有效利用CPU提升性能。
第二個思路是IO和網絡優化，在導入鏈路上，我們采用DirectIO、Binary化、全流式、異步化、零拷貝等技術大幅提升導入性能。
第三個思路是減少數據量，通過Raft 2+1技術（2份數據+1份日志）在保證數據高可靠的前提下將數據量減少1/3, 再通過高性能lz4壓縮算法將數據進一步壓縮，整體下來數據的讀寫IO和網絡傳輸開銷都得到大幅優化。
最終，在TPC-DS 18個節點上可以實現超過5000萬/秒 的導入性能。
4.3 高吞吐實時更新DML
AnalyticDB MySQL 3.0基于Raft實現了高吞吐實時數據更新能力，寫入鏈路通過全異步化、零拷貝、高效編碼壓縮等實現了出色的性能，在TPC-DS DML測試中，AnalyticDB十幾個節點可以做到千萬級TPS實時寫入更新，并且能夠保證線性一致性（寫入后立即可查）。在實際生產中，用戶寫入性能完全可擴展，可以輕松實現億級TPS的實時寫入更新。
在TPC-DS中，需要驗證數據倉庫的數據修改和ACID能力，AnalyticDB MySQL 3.0 支持ETL事務，具備ACID能力（可以完整跑TPC-C事務功能測試），在TPC-DS的DML測試中，存儲引擎MVCC能力發揮了巨大的作用：存儲引擎通過切分為實時數據（Delta）和分區數據（Main）+ 異步的數據轉換（Build）實現了類LSM寫優化架構。AnalyticDB實現了Block-level MVCC + 快照隔離，可以保證ETL和數據更新過程中數據的隔離性（可見性）、在壞盤出錯時可以保證數據更新原子性。
4.4 行列混存和智能索引
AnalyticDB MySQL 3.0通過自研的行列混存格式，能夠兼顧高篩選率和大吞吐掃描兩種場景，相比開源ORCFile的純列存格式在明細點查上更有優勢，而相比Parquet，AnalyticDB MySQL存儲格式具有更出色的隨機讀性能，同時對比業界行存表+列存表兩份數據冗余的模式成本更低。在AnalyticDB MySQL中，每個Table都有一個行列存儲格式文件，數據被切分成不同的RowGroup，在RowGroup內由列的Block構成，Block內對定長、非定長（Toast）數據的進行有效的編碼和壓縮，并且支持高效的隨機讀和順序讀。
在TPC-DS 測試中，通過配置合理的存儲Block大小（4KB對齊）、數據塊預取、源頭算子向量讀等大幅優化了存儲掃描性能；同時，存儲上精確的統計信息(min/max/sum/cnt等)一方面可以加速數據過濾（Smart Scan），另一方面還能夠為查詢優化器提供豐富的Statistics以幫助制定出最優的執行計劃。
AnalyticDB MySQL的特色之一是自研智能索引框架，支持五種索引類型：字符串類的Invert索引、bitmap索引、數值類的KDTree索引、JSON索引和向量索引；不同類型的索引可以實現列級索引多種條件（交、并、差）任意組合；相比較傳統數據的優勢是，無需建組合索引（不會引起空間膨脹）、且支持OR/NOT等更多條件的索引下推。為了降低用戶使用門檻，AnalyticDB在建表時可以開啟一鍵自動全列索引，查詢時通過Index CBO智能動態篩選索引下推，確定下推的索引鏈會通過謂詞計算層進行流式漸進多路歸并輸出。
5. AnalyticDB查詢技術
AnalyticDB MySQL 3.0 的查詢引擎，由自研的查詢優化器和查詢執行器兩個模塊組成。它是AnalyticDB MySQL 提供高并發、高吞吐數倉分析能力的重要一環。感知數據特征，深度結合存儲引擎的架構，同時支持Reporting、Ad-hoc、ETL數倉分析場景，是其相較于單一計算引擎的核心優勢。
作為一款分布式云原生實時數倉產品，AnalyticDB MySQL的優化器不僅僅要面臨傳統優化器所涉及的挑戰，例如復雜 Join Reorder 的 NP-hard 問題，代價估算的不確定性問題，還面臨在分布式環境下分布式并行計劃的新問題。CBO 做為AnalyticDB MySQL 3.0版本最新成果，在 TPC-DS戰役中首次開啟使用，對于整體計劃的調優，起到了非常重要的作用。
ADB 查詢執行引擎，以統一的內存池化和查詢的混合負載管理能力為基礎，使用動態代碼生成技術，創新性的混合執行模型，利用SIMD指令集的向量化算法，以及自適應的面向行、列混合存儲的查詢執行等技術，是AnalyticDB MySQL持續的在TPC-DS查詢性能上領先的關鍵因素。
5.1 CBO查詢優化框架
基于代價的優化器本質上是一個復雜的搜索問題，想要解決好這個問題，需要從四個方面入手：
搜索框架：從數據庫的發展歷程來看，基于 Cascades 的搜索框架已經成為了業界標準，包括商業數據庫 SQL Server 以及開源數據庫 GP/ORCA 都采用 Cascades 實現。AnalyticDB MySQL優化器CBO 也是基于 Cascades 論文實現的。搜索框架面臨的一個核心問題是搜索空間會急速膨脹，但是搜索時間需要維持毫秒級響應，因此需要有高效的數據結構存儲搜索空間、高效的優化規則生成搜索空間、高效的搜索算法遍歷搜索空間，高效的剪枝策略裁剪搜索空間。
分布式并行計劃：相對于傳統的單機版數據庫來說，分布式 MPP 數據庫給優化器帶來了新的挑戰。在分布式 MPP 數據庫中，數據的分布屬性變得十分的重要，它會直接影響到數據的正確性。為了滿足不同算子對數據分布的要求，數據重分布不可避免，然而數據的重分布即數據 shuffle 的代價非常昂貴，因此，在保證數據正確性的前提下，盡可能的減少數據 shuffle。作為分布式 MPP 數據庫優化器來說，需要把數據的 Partitioning 屬性，以及 Sorting、Grouping 屬性，也納入到搜索空間來綜合考慮，基于代價選擇最優的分布式并行執行計劃。
代價估算：代價估算是優化器能否尋找到最優計劃的關鍵因素。代價估算涉及到統計信息的推導和代價模型。統計信息的推導依賴于：原始表的統計信息、中間算子的推導算法、對數據的各種假設（均勻性假設、獨立性假設、包括性假設、包含性假設）以及在一些極端情況下的猜測。因此統計信息的推導存在大量的不確定性，也正是因為這些不確定性，極大的加劇了優化器尋找最優解的難度。本質上來說，只有打破對數據屬性的假設，才有可能使得統計信息的估算做到知其然知其所以然，然而打破這些假設，也要付出更多的代價。
統計信息收集：收集必要的統計信息是 CBO 工作的前提，統計信息需要做到：基本信息能夠自動化收集，自動化更新，高級統計信息可以手動收集，為 CBO 提供可靠的、多緯度的統計信息。在實際的情況下，可能存在統計信息丟失或者沒有及時收集，在這種情況下，為了避免生成災難性的計劃，可以在運行時動態采樣來獲取必要的統計信息。
5.2 混合查詢執行框架
傳統的火山執行模型不能滿足分析場景高吞吐的性能需求已經成為業界的共識。隨著各個系統的不斷發展，目前業界計算引擎有2種演化后的執行框架實現:
? Just-in-time (JIT) compilation
? Vectorization
JIT編譯方式以數據為中心，一條數據經過上一個算子處理后，還在CPU緩存中便直接進行下一個算子的計算，對CPU緩存友好，適合計算密集型任務。Vectorization中每個算子處理一批數據后，將一批結果再交給下一個算子計算。適合內存密集型任務以及向量計算，用中間結果物化的開銷換取算子的計算高內聚。
JIT編譯方式和Vectorization各有所長，如上圖所示，紅色表示JIT編譯方式，綠色表示Vectorization方式。目前AnalyticDB MySQL是唯一的同時支持這兩種查詢模式的自研分析引擎。混合執行框架，在Vectorization執行模式的基礎上，自適應的把多個計算密集特征的算子融合成一個驅動執行。實現了一個查詢執行引擎同時具備Compilation和Vectorization的優點。
5.3 統一內存管理
在內存方面，高效的內存管理是計算優化的基石。面向類型的內存模型，特指針對不同的數據類型使用不同的基礎類型存儲。這導致不同的類型無法存儲在連續的內存地址中，僅能通過按列的方式進行存儲，減少多個內存對象帶來的額外代價。另外一方面，不同內存類型間的內存無法復用，這會造成額外的內存管理代價。
ADB的查詢執行引擎，通過統一內存管理來解決上面的幾個問題
- 內存binary化： 統一內存類型，不同類型均使用相同的數據類型（byte）來存儲，同時這也是查詢執行面向行存，緩存友好算法優化的基石；
- 規范化的內存管理規格：統一內存規格，降低內存碎片帶來的額外代價，并且降低復用內存的難度；
- 分層的內存管理：統一內存管理，根據計算特點對應內存的生命周期，針對內存使用特點，實現MemoryCache， MemoryPool，并且支持內存泄漏檢測，實現面向常駐服務的主動內存管理；
5.4 DFP 和 CTE技術
在數據倉庫中，事實表和維度表 Join是典型場景，他們之間的數據量的差異可以達到千萬倍級別，這個時候，Join的計算成本更多的在于數據的掃描成本，因此我們會采用 DynamicFilterPushDown 的方式，來極大的減少左表的數據量。另外數據倉庫中會出現大量的 WITH 語句以及隱式的共享語句，這些都可以通過 Common Table Expression 的共享來避免重復計算。
DFP（DynamicFilterPushDown）對于篩選率高的 Join （命中率低）、Probe端的數據從存儲中被讀上來之后，大部分數據會被丟棄掉。因此如果評估出來 build 的數據維持在一個比較小范圍的閾值，那么我們就可以把 build 端結果值，作為左表的過濾條件，也就是 Dynamic Filter，直接下推存儲，減少掃描量。對于優化器來說，最主要的工作就是要合理評估 build 端命中 Join 條件的 NDV 值。
不同的 Join Order 直接影響可做 Dynamic Filter 的范圍和粒度，能夠進行該優化的 Join 其 Cost 與真正的 Hash Join 有巨大的差異反過來也影響了 Join Order。基于 ADB 完善且擴展性較好的 CBO 框架，我們做到了從全局考慮，基于 Cost 選擇最優的 Dynamic Filter 方案。
在執行層面，我們通過如下三個關鍵點實行有高效的DFP：
- 高效動態謂詞構建，通過進程內in-place構建動態謂詞，降低動態文詞構建代價；
- 多層過濾執行優化，結合bloomfilter，分區裁剪，感知存儲索引等方式，加速過濾效果；
- 異構數據源的下推，統一數據源接口層抽象實現，擴展異構數據源的支持；
CTE(Common table expression)，TPC-DS 30%+的sql中包含with as用法， 通過with as子查詢，在主查詢中多次引用，每一次引用帶來了額外的重復計算，導致資源浪費。基礎的CTE優化，通過復用with子句的結果給多個引用方，來減少重復計算的代價。但是對于部分場景，與主查詢的關系推導可以進一步減少with子查詢中的計算量，這時直接share完整with子句會導致額外的性能回退。那么通過inline后的最優計劃，進行common sub tree的識別，進一步減少重復計算量，達到無bad case的效果。執行器實現中，我們引入了死鎖檢測，通過分析common sub tree的多個consumer之間的依賴關系，解決死鎖問題。
6. 客戶場景和案例
AnalyticDB自2014年上云后已在全球主要Region開服，開始進入全球分析市場，2018年，成功入選了全球權威IT咨詢機構Forrester發布"The Forrester Wave?: CloudData Warehouse,Q4 2018"研究報告的Contenders象限，以及Gartner發布的分析型數據管理平臺報告 (Magic Quadrant for Data Management Solutions for Analytics)。
AnalyticDB已廣泛應用于阿里巴巴集團內部和阿里云外部客戶，具有替換Teradata、Oracle RAC的生產案例，在泛互聯網、新零售、金融、稅務、交通、氣象、物流等核心行業得到大規模應用和驗證，如在物流行業支持中國郵政首次實現全國物流查詢分析大集中等。
7. 總結和展望
AnalyticDB經過數據庫領域最頂級會議VLDB論文（AnalyticDB: Realtime OLAP Database System at Alibaba Cloud）的理論驗證（中國極其少有的大規模商用系統介紹論文，類似有Google F1[VLDB'2013]、AWS Aurora[SIGMOD'2017]等）、TPC-DS全球領先的工程驗證（TPC-DS全球性價比、性能雙雙領先）、覆蓋核心部委以及大型泛互聯網客戶的客戶驗證、阿里集團多年的超大規模驗證形成了多方面優勢，基于云計算的高效資源效率、數據庫與大數據一體化發展趨勢，正式完成重大品牌升級，由“分析型數據庫”升級為“云原生數據倉庫”。
未來以來，大數據與數據庫一體化+云原生將會重新定義云計算時代的數據倉庫，TPC-DS破世界紀錄只是起點，AnalyticDB將會持續投入致力于成為企業數字化轉型升級、數據價值在線化的基礎設施！
8. 附錄
AnalyticDB VLDB論文解讀：
VLDB論文解讀：阿里云超大規模實時分析型數據庫AnalyticDB
AnalyticDB 云棲文章
AnalyticDB for MySQL技術架構解析
更簡單易?的數據倉庫，阿?云重磅推出分析型數據庫3.0版
構建實時數據倉庫首選，云原生數據倉庫AnalyticDB for MySQL技術解密
性能為MySQL 10倍！阿里云重磅推出云原生數據倉庫AnalyticDB基礎版
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的自研云原生数据仓库AnalyticDB再破权威评测TPC-DS世界纪录的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 秒级启动万个容器，探秘阿里云容器镜像加速
- 下一篇： 彩生活云上转型 打造全球最大社区服务运营