導讀 本文将分享 SelectDB 公司對于現代資料分析棧的一些認識，以及SelectDB 公司圍繞 Apache Doris 建構現代資料分析棧的一些工作。
今天的介紹會圍繞下面四點展開：
1. 目前資料分析棧的現狀與挑戰
2. 基于 Apache Doris 建構實時統一的資料底座
3. Apache Doris 最新特性解讀
4. 關于 SelectDB
分享嘉賓｜衣國壘 SelectDB CTO &ApacheDoris Committer
編輯整理｜朱佳佳 北京航空航天大學
出品社群｜DataFun
01
目前資料分析棧的現狀與挑戰
1. 目前資料分析棧
目前資料分析棧可以分為兩大類。
第一類是以 Oracle 為代表的關系型資料庫作為資料分析的資料源，通過資料同步工具同步到資料倉庫中，在資料倉庫中做進一步的資料處理，如 ETL（抽取、轉換、加載）或 ELT（抽取、加載、轉換）。資料最後通過 BI 工具（Tableau、Quick BI 等）以報表的形式呈現給業務管理者。也有很多企業采用 Clickhouse 或 Apache Doris 這類的 OLAP 技術對處理進行加速。
第二類是以日志或者第三方資料的 API 作為資料分析的資料源，通過Kafka 或 Flink 流式處理系統把資料同步到 S3 或 HDFS 上，通過 DeltaLake、Hudi、Iceberg 這類湖倉方案對資料進行管理。然後通過批處理系統（Spark、MapReduce 等）、流式處理系統（Flink）、互動式分析系統（Impala、Presto）對資料進行處理，最終将資料存儲到 OLAP 系統中。資料呈現方式也是多種多樣的，如使用者行為分析、ABTest 實驗、基于日志的 Tracing 系統等。
2. 架構演進
從 2006 年 Hadoop 誕生開始，資料分析棧的演進可分為三個階段。
① 第一階段是以誕生 Hadoop 為界，它解決了移動網際網路時代海量資料計算和分析的問題，資料處理不再受傳統一體化架構的限制，可分析的資料量也從過去的 TB 級資料更新到 PB 級。
② 第二階段大資料技術棧百花齊放，誕生了消息處理引擎 Spark，它超越了 Hadoop 的 Mapreduce 的分析速度；誕生了流式處理系統 Flink，加速了流式處理性能；同時也誕生了很多 OLAP 技術，如 Impala，Presto 這樣的互動式分析引擎，可以直接對 HDFS 或 S3 上的資料進行分析；也有像 Doris、Kylin、Druid、Clickhouse 這樣的系統，它要求把使用者的資料灌入到自己的存儲中，更高效地對資料進行分析。
③ 第三階段結合雲基礎設施，大資料技術棧逐漸趨于統一。以 Snowflake 資料倉庫技術為代表，使用者隻需要提供資料源，加工過程由 Snowflake 這樣的 SaaS 技術解決，使用者不需要感覺各種大資料元件。
資料倉庫技術和大資料技術越來越趨于融合，結合雲的基礎設施，在提升資料分析效率的同時，對資源的管理也會更加高效。
3. 現代資料分析需求，有哪些變與不變？
現代資料分析需求不變的方面：
- 性能，性能越好意味着機關成本下處理的資料量越多。
- 時效性，資料的價值會随着時間的推移而降低，實時資料的重要性已在越來越多的業務場景中得到驗證。
現代資料分析需求的變化：
- 靈活，縮短需求傳遞周期，讓使用者盡快看到資料應用的效果。
- 全民化，企業中的任何一個人都可以無障礙地通路所需要的資料，并可以對資料進行探索，建構自己的業務認知。
4. 現代資料分析需求的挑戰？
現代資料分析在以下四個場景面臨的挑戰如下：
① 多元報表：高并發，且查詢需要響應毫秒級低延時。現在很多報表是面向 B 端的商戶或終端消費者，它對通路量、并發度、系統的可用性的要求越來越高。
② 即席查詢：這種查詢模式相對靈活，沒有辦法預知，常常需要對資料進行大量掃描，然後再做出複雜計算，最後将結果呈現，是以它不論對于 IO 的壓力還是對于 CPU 的壓力都非常大的。
③ 統一數倉：為了減少業務運作維護代價，越來越多的企業将資料的加工糅合到一套系統中，該系統能同時具備線上查詢和離線 ETL 能力，同時保證離線計算和線上服務的資源不搶占。
④ 湖倉加速：支援加載多種資料源，打破資料孤島，呈現出統一的業務視圖。
--
02
基于 Apache Doris 建構實時統一的資料底座
接下來介紹一下 Apache Doris 如何解決目前面臨的資料分析棧的問題。
1. Apache Doris 是什麼？
Apache Doris 在 2022 年 6 月正式從 Apache 社群孵化畢業，成為Apache 頂級項目。Apache Doris 是一個 MPP 架構的高性能實時分析型資料庫，它主要應用在多元報表、即席查詢、使用者畫像，實時大屏、日志分析、資料湖加速等業務場景。目前全球超過 700 多家企業在生産環境中使用 Doris，它的穩定性及服務品質都是非常有保證的。
2. Apache Doris 典型應用場景
第一類業務場景是把關系型資料庫的資料源通過資料內建處理工具灌入到Apache Doris 中，它能支援 OLTP 這種頻繁的交易型資料分析。第二類業務場景是把日志資料通過資料內建的工具灌入到 Doris 中，進而生成 PV、UV 等使用者行為報表，此外還支援 IoT 的時序資料。
Doris 中的資料可以做很多場景的分析，如使用者行為分析、AB test 實驗、日志檢索分析、訂單分析、大屏駕駛艙等。此外，Doris 通過湖倉一體的查詢引擎對 Hive、Iceberg、Hudi 等外部資料源進行分析。Doris 在 OLAP 領域已經做得相當好了，一些小規模資料量的 ETL 的問題是目前 Doris 努力的一個方向。
3. 場景案例一：網際網路使用者增長分析平台
在過去網際網路使用者增長分析平台的分析架構包含了 Kudu、Spark、YARN等架構，Doris 把這種複雜的多元件的架構統一到一個分析架構上，提供即席分析和多元報表等應用場景，在性能上也比過去提升 2-10 倍。Doris 的平均查詢延時在 10 秒左右，95 分位的查詢延時在 30 秒以内，每天可運作數萬條 SQL 處理，叢集規模可達數百台。
--
03
Apache Doris 最新特性解讀
下面介紹 Doris 的一些最新特性。
1. Apache Doris 1.2 版本特性——主鍵模型優化
過去 Doris的Unique key 模型是一種 Merge on Read 模型，它的原理是把資料存儲成 Segment，每個 Segment 都有一個版本号，在查詢的時候通過 Merge 多個 Segment 資料，取版本号最大的資料做傳回。在查詢的時候，大規模資料的歸并排序和比較是非常耗 CPU 的，同時不支援謂詞下推，無法做 where 語句的提前過濾，導緻掃描的資料量更多，查詢過程會更慢，實時更新能力也會受限。Doris 1.2 版本中引入基于主鍵索引+Delete Bitmap 的方式來實作 Unique key 模型，在資料導入過程中，生成資料删除标記 Delete Bitmap，在查詢時通過 Delete Bitmap 做資料過濾。
經過測試，在實時更新的場景下，新版本的Unique key模型比舊版本的性能提升了10倍以上。
2. Apache Doris 1.2版本特性——Light Schema Change
當把關系型資料庫據同步 Doris 中時，可能由于 Schema 的變化導緻資料流的中斷，過去的 Doris Schema Change 把資料重新讀一遍，再重新寫一遍，整個過程是分鐘級甚至小時級的，當資料特别大，有可能導緻資料流中斷的。在 Doris 1.2 版本中，引入了 Light Schema Change 新技術，對于加列、減列及變更列類型的資料處理，隻需修改FE節點存儲的中繼資料來實作，整個過程在毫秒級就可以完成。
3. Apache Doris 1.2 版本特性——Multi Catalog
在舊版本中，Doris 通過建立一張外表來實作 MySQL 或 Hive 中的資料源同步，如果有幾萬張表，在 Doris 中也需要建立幾萬張外表，而且一旦發生變更，就需要重新操作一次，同步的代價是非常大的。在 Doris 1.2 版本中，SelectDB 為 Doris 引入了 Multi Catalog 技術，使用者可以把整個 Hive Metastore 映射到 Doris 中，Doris 自動将 Hive 中的 Schema 同步到 Doris 中，且會自動同步 Schema 的變更，整個同步過程是秒級或者分鐘級的。同時也支援了新的資料庫引擎，如 Iceberg、Hudi。
4. Apache Doris 1.2 版本特性——JDBC資料源
在舊版本中，Doris 通過 ODBC 的方式連接配接 MySQL、Oracle、PostgreSql等資料源，但在使用過程中經常因為驅動版本的不一緻導緻程序崩潰。在新版本中引入 JDBC 的方式，它對版本的相容性更好，使得 Doris 更加穩定。
5. Apache Doris 1.2 版本特性——冷熱資料分離
使用者希望在有限的成本下存儲更多的資料，是以 Doris 1.2 版本中引入了冷熱資料分離的技術，把一段時間内通路較多的資料存儲到本地磁盤上，把一段時間内通路較少的資料以對象存儲的方式放到雲端 S3 這種低成本的存儲方式中，這種方式能将使用者的存儲成本降低 70%。
冷熱資料分離支援的最細粒度為 Rowset 級别，将冷資料放到 S3 中，将熱資料放到本地磁盤中，Doris 自動感覺哪些 Rowset 是冷資料，哪些 Rowset 是熱資料。冷資料全功能支援導入、查詢、Schema Change。
當把資料搬遷到 S3 後，S3 是沒有硬鍊機制的，如果 Schema Change還基于硬鍊實作的話，那冷熱分離就實作不了了，這也是我們要實作 Light Schema Change 的一個原因。
後續還會繼續對冷熱分離技術做一些優化，如單副本存儲，本地 File Cache。
6. Apache Doris 1.2 版本特性——New MemTracker
Doris 1.2 版本引入了 New MemTracter，因為 Doris 具備線上計算、離線 ETL 等能力，查詢存在并發，如果對記憶體不加以限制，有可能一個查詢把所有資源占滿。New MemTracter 對記憶體進行三個粒度的限制，對程序級記憶體進行限制，對單查詢記憶體限制，如果超過限制，會自動 Cancel 掉，保證查詢不會把所有的資源占滿，引入了算子粒度的記憶體統計，統計每一個算子分别使用多少記憶體，提供更好的可觀測性。
7. Apache Doris 1.2 版本特性——其他重要新功能
此外 Doris 1.2 版本還有一些其他的功能，支援 Array 類型，支援嵌套、行列轉換，支援 JSON 格式資料存儲。同時引入了 New Decimal 資料類型，它支援更大的精度和更高的計算效率，開發了新的 Date 和 Datetime 類型資料。此外引入了 Java UDF，使用者能夠把已有的技術資産非常友善的引入到 Doris 中，1.2 版本目前已釋出。
8. Apache Doris 1.2版本性能表現——持續優化中
我們對 Doris 做了 100 多處的性能優化，整體性能相較于 1.1 版本提升了近 4 倍，是業内标杆競品的三倍以上。
近期，在 ClickHouse 發起的分析型資料庫性能測試排行榜 ClickBench 中，基于 Apache Doris 的新一代雲原生實時數倉 SelectDB 強勢登頂，性能表現超越一衆國内外産品，多項名額排行前列，并在業界最為通用的 c6a.4xlarge, 500gb gp2 機型下排行全球第一！
--
04
關于 SelectDB
SelectDB 公司的定位是 Apache Doris 背後的一個商業化公司，我們将大力投入研發力量，加強 Apache Doris 在資料分析技術上的創新力，使 Apache Doris 能成為世界領先的開源的分析型的資料庫。
--
05
問答環節
Q1：Doris 冷熱分離技術中，遠端 S3 上的路徑是存在 BE 節點中還是存在 FE 節點？
A1：是存在 BE 節點中的。
Q2：Doris 在 SaaS 多租戶資料存儲上面有什麼演進嗎？
A2：目前沒有，但是在 SelectDB Cloud 上會有這部分功能。
Q3：冷熱分離技術中，Rowset 分級會不會使得小檔案變多？
A3：小檔案問題并不會太多，因為冷資料使用者通路的頻率是比較低的，我們也會做本地 cache 的淘汰。
Q4：Doris 是否有一些雲原生特性的規劃？
在容器化方面，1.3 版本中，會對 K8S 做技術支援。在多租戶問題上，因為考慮到現在很多雲原生的技術的部署是比較複雜的，是以我們會把相應的接口放到 Doris 的代碼中，大家可以參考實作。
Q5：在技術選型上如 Clickhouse、Doris、StarRocks 有什麼建議？
A5：從我的角度來看，Doris 還是比較好。Doris 很多代碼借鑒了Clickhouse，但是在代碼基礎上也做了很多改進，如 Group by 算子的性能、join 的能力，都是支援的非常好。我覺得 Doris 在整個 OLAP 領域還是比較領先的。
Q6：Doris 新版本的存儲效率如何？
A6：在存儲效率方面，我們引入了新的特性，對于 String 字元串，引入了 ZSTD 壓縮技術，在 String 類型上資料存儲效率是有提升的，但整數類型提升不大。
Q7：Doris 新版本能否解決記憶體管理上的一些問題嗎？
A7：一方面，我們引入了 New MemTracter 限制記憶體，在 1.3 版本中還會繼續對記憶體限制進行優化，當沒有并發的時候，可以把所有記憶體用起來，當并發的時候，會按照使用者設定的比例來 kill 掉一些比較大的查詢，來保證就剩下的查詢能夠按照使用者設定的比例這樣來跑下來。
另一方面，在Doris 下一個版本中，我們會去把所有代碼改造成異常安全代碼，保證即使有任何錯誤，整個系統也可以繼續穩定地運作。
Q8：新版 Unique key 模型是否會影響 Segment V2 資料存儲？1.1 版本是否可以直接更新到 1.2 版本？
A8：新版 Unique key 模型不會影響 Segment V2 資料存儲，因為新版Unique key 模型資料存儲還是基于 Segment V2 的，隻是增加了 Delete Bitmap 的實作，是以不會影響 Segment V2 的存儲。
新版 Unique key 模型能夠相容老版 Unique key 模型，更新後，老版Unique key 模型仍可以繼正常運作，這也是 Doris 每個版本的要求，保證更新過程是滾動更新，是以 Doris 連續兩個版本之間更新是可以保證的。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
衣國壘
SelectDB CTO &ApacheDoris Committer
先後在百度、騰訊從事Doris，Elasticsearch，Clickhouse 相關的研發工作，Apache Doris Committer，負責研發了兩階段事務、并行導入、分布式叢集管理、聯邦查詢等多個核心機制。現任 SelectDB 公司 CTO。