摘要：本文整理自 SelectDB 資深大資料研發專家王磊，在 FFA 2022 實時湖倉專場的分享。本篇內容主要分為四個部分：實時數倉需求和挑戰
基於 Apache Doris 和 Apache Flink 構建實時數倉
使用者案例與最佳實踐分享
新版本特性
在資料流的角度上，分析一下傳統的資料架構。從圖中可以看到，資料分為實時資料流和離線資料流。在實時資料部分，透過 Binlog 的方式，將業務資料庫中的資料變更，採集到實時數倉。同時，透過 Flume-Kafka-Sink 對日誌資料進行實時採集。當資料來源上不同來源的資料都採集到實時數倉後，便可以構建實時數倉。在實時數倉構建的內部，我們仍然會遵守數倉分層理論，將資料分為 ODS 層、DWD 層、DWS 層、ADS 層。在離線資料流部分，透過 DataX 定時同步的方式，採集業務庫 RDS 中的一些資料。當不同來源的資料，進入到離線數倉後，便可以在離線數倉內部，依賴 Spark SQL 或 Hive SQL，對資料進行定時處理。然後，分離出不同維度（ODS、DWD、ADS 等）的資料，並將這些資料存在一個儲存介質上。我們一般會存在 HDFS 或 S3 的物件儲存上。透過這樣的方式，我們的離線數倉便構建起來了。與此同時，為了保障資料的一致性。我們需要一個資料清洗任務。使用離線資料對實時資料進行清洗，保障資料最終的一致性。
如上圖所示，我們在技術架構的角度，對傳統資料架構進行分析。從圖中可以看到，不同應用採取不同技術棧。比如在湖倉部分是 Hive、Iceberg、Hudi 等元件。在湖倉之上的 Ad-hoc，我們選擇 Impala 或 Kudu。對於 OLAP 的高併發，我們會使用 Druid 或 Kylin 元件。除此之外，業務還有半結構化的需求。我們會使用 ES 對日誌進行檢索和分析；使用 HBase 構建高效的點查服務。在部分情況下，業務需要對外提供統一的資料服務。這時，部分業務會使用 Presto 或 Trino 的查詢閘道器，統一對使用者提供服務。這個架構有什麼問題呢？首先，架構元件多，維護複雜。其次，它的計算、儲存和研發成本都比較高。主要因為我們同時維護兩套資料和兩套計算，即實時資料流和實時計算任務。最後，我們無法保障實時流的資料和離線資料的一致性。此時，只能透過離線資料定時清洗，保證資料的一致性。
基於以上痛點，一個“統一的實時”架構呼之欲出。“統一”是指資料結構的統一，我們希望半結構化和結構化資料能夠統一儲存在一起。同時也指的是在一個平臺中能完成多種分析和計算場合（實時查詢，互動式分析，批次處理等）“實時”指的是我們希望資料的接入和資料分析都能實時的進行。基於 Apache Doris 和
Apache Flink 構建實時數倉
基於以上需求，如何透過 Apache Doris 和 Apache Flink 構建實時數倉？滿足使用者對實時應用和統一架構的需求。首先，介紹一下什麼是 Apache Doris？Apache Doris 是基於 MPP 架構的高效能的實時分析型資料庫。它以極速易用的特點被人們所熟知，Doris 只需亞秒就能完成海量資料（TB 級別或者百億級別資料）的查詢。不僅支援高併發（點查、ad-hoc）的查場景，也支援高吞吐量（ETL 任務）的查詢場景。因此，Apache Doris 能較好的滿足高併發報表、即席查詢、統一數倉服務、以及湖倉和聯邦查詢等功能。使用者在此之上，可以構建使用者行為分析、AB 實驗、日誌檢索分析、使用者畫像分析等應用。從下圖中我們可以看到，資料來源經過各種資料整合和加工後，通常會入庫到實時數倉 Doris 之中。同時，部分資料會入到湖倉架構的 Hive 或 Iceberg 中。然後，基於 Doris 構建一個統一的數倉，對外提供服務。
接下來，看一下如何基於 Apache Doris 構建極速易用的實時數倉的架構？因為 Doris 既可以承載資料倉儲的服務，也可以承載 OLAP 等多種應用場景。因此，它的實時數倉架構變得非常簡單。我們只需要透過 Flink CDC 將 RDS 的資料，實時同步到 Doris。透過 routine load 將 Kafka 等訊息系統中的資料，實時同步到 Doris。在 Doris 內部，基於 Doris 不同的表模型、Rollup、以及物化檢視的能力，構建實時數倉。Doris 的表模型分為明細模型、主鍵模型和統計模型。在 Doris 內部構建實時數倉時，ODS 層通常會使用明細模型構建。DWD 層透過 SQL 排程任務，對 ODS 資料抽取並獲取。DWS 和 ADS 層則可以透過 Rollup 和物化檢視的技術手段構建。除此之外，Doris 還支援基於 Iceberg、Delta Lake 和 Hudi 的資料湖服務，提供一些聯邦分析和湖倉加速的能力。這樣我們便完成了基於 Doris 構建一個實時數倉。在實時數倉之上，我們可以構建 BI 服務、Adhoc 查詢、多維分析等應用。
架構明確之後，我們看一下在實踐過程中會有哪些挑戰？首先，大家最關心的問題就是資料的一致性保證。資料一致性一般分為“最多一次”、“至少一次”和“精確一次”。1. 最多一次是指，傳送方僅傳送訊息，而不期待任何回覆。在這種模型中，資料的生產和消費過程，都可能出現資料丟失。
2. 至少一次是指，傳送方不斷重試，直到對方收到為止。在這個模型中，生產和消費過程都可能出現資料重複。
3. 精確一次能夠保證訊息，只被嚴格傳送一次，並且只被嚴格處理一次。這種資料模型，能夠嚴格保證資料生產和消費過程中的準確一致性。Doris 基於兩階段提交，實現準確的資料一致性。
Flink CDC 透過 Flink Checkpoint 機制結合 Doris 兩階段提交，實現端到端的資料寫入一致性。具體過程分為四步。第一步，事務開啟（Flink Job 啟動和 Doris 事務開啟）：當 Flink 任務啟動後，Doris 的 sink 會發起一個 precommit 請求，開啟一個寫入事務。第二步，資料傳輸（Flink Job 的執行和資料的傳輸）：在 Flink Job 執行過程中，Doris sink 會不斷從上游運算元獲取資料，並透過 httpchunked 的方式，持續將資料傳輸到 Doris。第三步，事務預提交：當 Flink 開始進行 Checkpoint 時，Flink 會發起一個 Checkpoint 請求。此時，Flink 的各個運算元會進行 Barrier 對齊和快照儲存。Doris Sink 會發出停止 Stream Load 寫入的請求，併發起一個事務提交請求到 Doris。此時，這批資料已經完全寫入 Doris BE 中，BE 還沒有進行資料釋出。因此，寫入 BE 的資料對使用者來說是不可見的。第四步，事務提交。當 Flink 的 Checkpoint 完成之後，它會通知各個運算元。此時，Doris 會發起一次事務提交到 Doris BE。BE 會對此次寫入的資料，進行釋出。最終完成資料流的寫入。綜上所述，是 Flink CDC 結合 Doris 兩階段事務，完成資料一致性提交的過程。這裡有一個問題是，當預提交成功，但 Flink Checkpoint 失敗時，該怎麼辦？這時 Doris 並沒有收到事務最終的提交請求，Doris 內部會對寫入資料進行回滾（rollback），從而保證資料最終的一致性。
下面來看一下資料增量和全量的同步。如何基於 Flink CDC 實現全量和增量的資料同步？這個原理很簡單，因為 Flink CDC 實現了基於 Snapshot 的全量資料同步，以及基於 BinLog 實時增量的資料同步。與此同時全量資料同步和增量資料同步可以自動切換。因此。在資料遷移的過程中，使用者只需要配置好同步的表即可。當 Flink 任務啟動時，首先會進行歷史表的資料同步。同步完成之後，它會自動切換成實時同步。
完成實時資料同步之後，使用者又產生了 RDS Schema 的變更需求。因為隨著業務的發展，RDS 表結構會產生變更，使用者希望 Flink CDC 不但能夠將資料變化同步到 Doris，也希望將 RDS 表結構的變更也同步到 Doris。這樣的話，使用者不用擔心 RDS 的表結構和 Doris 表結構不一致的問題。要滿足這種 DDL 同步的需求，前提是 Doris 能夠快速支援這種 Schema 的變更。當很多 Schema Change 請求到來後 Doris 能夠快速處理。由於 Doris 處理 Schema Change 時，相對比較耗時，所以我們引入了 Light Schema Change。Light Schema Change 的實現原理非常簡單，我們只需要在加減列時，對 FE 中的後設資料進行修改，將修改後的資料持久化。Schema Change 只需要更新 FE 中的後設資料即可，因此 Schema Change 的效率就非常高。與此同時，這個響應過程是同步的過程。由於 Light Schema Change 只修改了 FE 的後設資料，並沒有同步給 BE。因此，會產生 BE 和 FE Schema 不一致的問題。
為了解決這種問題，我們對 BE 的寫出流程進行了修改，具體包含三個方面。1. 資料寫入：對於資料寫入而言，FE 會將 Schema 持久化到後設資料中。當 FE 發起匯入任務時，會把最新的 Schema 一起發給 Doris BE，BE 會根據最新的 Schema 對資料進行寫入，並與 RowSet 進行繫結。將該 Schema 持久化到 RowSet 的後設資料中，實現了資料的各自解析。解決了寫入過程中 Schema 不一致的問題。2. 資料讀取：對於資料讀取而言，FE 生成查詢計劃時，會把最新的 Schema 附在其中，並一起傳送給 BE。BE 會拿到最新的 Schema，對資料進行讀取，來解決讀取過程中 Schema 發生不一致的問題。3. 資料 Compaction：對於資料的 Compaction 而言，當資料進行 Compaction 時，我們選取需要進行 Compaction 的 RowSet 中最新的 Schema，作為之後 RowSet 對應的 Schema。以此解決不同 Schema 上，RowSet 的合併問題。經過 Light Schema Change 最佳化之後，Doris Schema Change 的效能，從之前一個 Schema 變化 310 毫秒，降低到了 7 毫秒。整體效能有近百倍的提升。徹底的解決了，海量資料的 Schema Change 變化難的問題。
有了 Light Schema Change 的保證，Flink CDC 能夠同時支援 DML 和 DDL 的資料同步。那麼在 Flink CDC 中，我們是如何實現的呢？1. 首先，我們要在 Flink CDC 的 MySQL Source 側開啟同步 MySQL DDL 的變更配置。然後，我們需要在 Doris 側識別 DDL 的資料變更，並對其進行解析。2. 當 Doris Sink 發現 DDL 語句後，Doris Sink 會對這種表結構進行驗證，驗證表結構是否支援 Light Schema Change。當表結構驗證透過後，Doris Sink 會發起 Schema Change 請求到 Doris，從而完成此次 Schema Change 的變化。3. 在具體使用過程中，Doris 如何開啟 Light Schema Change 呢？我們只需要在表裡新增，"light_schema_change" = "true"即可。當我們解決了基於 Flink 和 Doris 資料同步過程中，源資料的一致性、全量資料和增量資料的同步、以及 DDL 資料的變更後，一個完整的資料同步方案就完成了。
站在資料模型的角度，看一下如何基於 Flink 和 Doris，構建不同的資料模型。第一種資料模型，也是最簡單的資料模型。我們將一個 RDS 的表，同步到一個 Doris 的表中。透過 MySQL-Source 加 Doris-Sink，實現表結構和資料的變更。第二種資料模型，我們可以將 MySQL 中兩個表的資料同步到 Flink 後，在 Flink 內部進行多流 Join，完成資料打寬，生成一個大寬表資料，同步到 Doris 之上。第三種資料模型，我們可以對上游的 Kafka 資料進行清洗，清洗後透過 Doris-Sink 寫入 Doris 表中。第四種資料模型，我們還可以將 MySQL 資料和 Kafka 資料，進行多流的 Join，然後寫入 Doris。
第五種資料模型，我們在 Doris 側建一個基於 Unique Key 模型的寬表。然後，將上游 RDS 中的資料，根據 Key 使用 Doris 的多列更新模式，將多列資料分佈寫入到 Doris 的大寬表中。例如，我們首先將 MySQL 第一個表中的 status，同步到 Doris 中。其次，我們將 MySQL 第二個表中的，amount 欄位同步到 Doris 的同一個大寬表模型中。除此之外，我們還可以將多源的 RDS（MySQL、Oracle 等）資料同步到 Doris 後，在 Doris 內部使用寬表抽取的方式，構建一個大寬表。
對於大資料來說，高併發寫入並不難，難點在於高併發更新。如何在上億資料中快速找到需要更新的資料，並對其進行更新？這一直是大資料領域比較難的問題。為了解決這個問題，Doris 透過 MVCC 多版本併發機制來實現。特別是在 Unique Key 模型中，當我們寫入一個資料時，如果資料庫中不存在資料，會寫入一個版本。當我們再次對該資料進行更新時，會再次寫入一個版本。此時，資料變更在 Doris 以多個版本的形式存在。當使用者在查詢時，Doris 會將最新版本對應的資料返回給使用者。並在 compaction 時，對歷史變更的資料進行清理。這種設計解決了海量資料的更新問題。同時，Doris 支援 Merge On Read 和 Merge On Write 兩種方式。
首先，講一講 Merge On Read，它的特點是寫入速度非常快。無論是 insert 語句，還是 update 語句，對於 Doris 來說，都是以多版本的方式寫入 Doris。因此，它的寫入效能很高。其次，它的查詢效能不是很高。因為在查詢過程中，需要對 Key 進行聚合去重，然後再執行查詢。因此，它的效能不是很高。舉例：
1. 我們在資料裡面寫入三條訂單資料，資料是以 append 的形式寫入 Doris 表中。2. 然後，我們對訂單 1 的 cost 進行更新，寫入一個新的版本的資料。當我們將訂單 1 的 cost 修改為 30 時，資料透過 append 的形式，以新版本寫入 Doris。3. 當我們對訂單 2 的資料進行刪除時，仍然透過 append 方式，將資料多版本的寫入 Doris 並將_DORIS_DELETE_SIGN欄位變為 1，此時，表示這條資料被刪除了。當 Doris 讀取資料時，發現最新版本的資料被標記刪除，就會將該資料從查詢結果中進行過濾。除此之外，Doris 還有一個DORIS_SEQUENCE_COL列，保證在高併發更新的情況下，更新資料的一致性和順序性。
下面看一下查詢效果。當使用者進行查詢時，會進行兩次聚合操作。第一次，使用多路歸併排序，將重複的資料排列在一起，並使用高版本資料覆蓋低版本資料的方式，對資料進行合併。
第二次，按照查詢的聚合條件，對資料進行聚合。這樣帶來兩個比較嚴重的查詢性問題。第一，在多路歸併的時候，它的代價較高，對 Key 進行比較，非常消耗 CPU。第二，在資料讀取的過程中，我們無法進行有效的資料裁剪，會引入大量的 IO 操作。
下面來看一下 Merge On Write 如何實現高併發寫入以及查詢的效能問題。Merge On Write 相容查詢效能和寫入效能。Merge On Write 在寫入的過程中，引入了 Delete Bitmap 資料結構，Doris 使用 Delete Bitmap 標記 RowSet 中某一行是否被刪除。這裡使用了兼顧效能和儲存空間的 Row Bitmap，將 Bitmap 中的 Mem Table 一起儲存在 BE 中，每個 segment 會對應一個 Bitmap。為了保持 Unique Key 原有的語義，Delete Bitmap 也支援多版本。每次匯入會產生該版本增量的 Bitmap。在查詢時需要合併此前所有版本的 Delete Bitmap。接下來，看一下基於 Delete Bitmap 的 Merge On Write 的寫入流程。首先，DeltaWriter 會先將資料 flush 到磁碟。第二步，我們會批次檢查所有 Key。在點查過程中，會經過一個區間樹，查詢到對應的 RowSet。然後，在 RowSet 內部透過 BloomFilter 和 index 高效查詢。當查詢到 Key 對應的 RowSet 後，便會覆蓋 RowSet Key 對應的 Bitmap。然後在 publish 階段更新 Bitmap，從而保證批次點查 Key 和更新 Bitmap 期間不會有新的可見 RowSet，保證 Bitmap 在更新過程中資料的正確性。除此之外，如果某個 segment 沒有被修改，則不會有對應版本的 Bitmap 記錄。
下面看一下 Merge On Write 的查詢流程。首先，當我們查詢某一版本資料時，Doris 會從 LRU Cache Delete Bitmap 中，查詢該版本對應的快取。如果快取不存在，我們再去 RowSet 中讀取對應的 Bitmap。最後，我們使用 Delete Bitmap，對 RowSet 中的資料進行過濾，將結果返回。同時在這個階段我們還可以透過 Bloomfilter 和 Bitmap 的二級索引來提高查詢的效率，查詢過程中 Doris 會進行有效的謂詞下推。因此，在 Merge On Write 中，大幅提升了資料寫入的查詢的效率。
Doris 針對不同場景，提供了不同的資料模型，分別有明細資料模型、主鍵資料模型、聚合資料模型。其中，明細資料模型主要用來儲存日誌，資料來一條就存一條。主鍵資料模型指相同的 Key 會進行覆蓋，比如根據訂單 ID，對訂單狀態進行更新。在統計模型方面，我們會將相同 Key 的 Value 列進行統計合併計算。比較典型的應用場景是報表統計和指標計算。比如根據門店 ID 和門店時間，對銷售額進行統計計算。對於統計模型來說，資料會邊入庫邊統計。對於使用者查詢來說，直接查詢統計後的資料，讓查詢過程更高效。
物化檢視的概念。物化檢視指，根據預定義的 SQL 分析語句執行預計算，並將計算結果物化，從而加速查詢的一種手段。對於 Doris 來說，物化檢視主要用於聚合場景。除此之外，還可以用於聚合資料和明細資料的同時查詢；以及匹配不同的字首索引場景。在物化檢視使用方面，首先建立一個表，然後再建立一個物化檢視。基於一張 Base 表，可以構建不同的物化檢視基於不同的維度進行統計。當使用者查詢時，如果能夠命中化識圖，都會走物化檢視；如果沒有命中物化檢視，會走 Base 表，從而完成高效查詢。對於資料更新來說，首先會更新 Base 表，然後更新物化檢視。從而讓 Doris 保證物化檢視和 Base 表資料的完全一致性。
接下來，看一下物化檢視的智慧路由選擇。Doris 透過物化檢視加速查詢，並且在查詢過程中，自動進行路由選擇。在查詢資料的過程中，如果資料在物化檢視中存在，會直接走物化檢視；如果在物化檢視中不存在，才會走 Base 表。與此同時，Doris 的智慧儲存和現代化計算能力，也能快速完成資料查詢。物化檢視在智慧路由的過程中，遵循最小匹配原則。只有查詢的資料集比物化檢視集合小時，才可能走物化檢視。它的智慧選擇過程包括最優選擇和查詢改寫兩個部分。首先，我們來看一下最優選擇。最優選擇包括兩個部分，即過濾候選集和選擇最優。在過濾候選集過程中，當一個 SQL 語句過來，透過 Where 條件進行判斷。Where 條件裡查詢的是 advertiser=1。由此可見，物化檢視和 Base 表都有這個欄位，這時的候選集是物化檢視和 Base 表。我們會判斷 Group By 計算。Group By 欄位是 advertiser 和 channel。這兩個欄位同時在物化檢視和表中 Base。這時過濾的候選集仍然是物化檢視和 Base 表。接下來，我們會過濾計算函式。比如在這裡會執行 count(distinct user_id)，然後對資料進行計算。由於 Count Distinct 的欄位 user_id 在物化檢視和 Base 表中都存在。因此過濾結果仍是物化檢視加 Base 表。最後，進行最優選擇。透過一系列計算，我們發現查詢條件無論是 Where、Group By 還是 Agg function 關聯的欄位，在 Base 表和物化檢視都存在。這時，我們需要進行最優選擇。然後，Doris 經過計算發現 Base 表的資料遠大於物化檢視，即物化檢視的資料更小。由此可見，如果查詢走物化檢視，它的效率更高。最優的查詢計劃是物化檢視。當我們找到最優的查詢計劃，會進行子查詢改寫，將我們的 Count Distinct 改寫成 Bitmap。從而完成了物化檢視的智慧路由。完成智慧路由之後，我們會將 Doris 生成的查詢 SQL 傳送到 BE 進行分散式查詢計算。
Doris 資料分為兩級儲存。第一個是分割槽，第二個是分桶。我們可以按照天對資料在 Partition 級別進行分割槽。接下來，我們按照 set 級別進行分桶。將一個分割槽的資料，分到不同的桶裡。當我們在查詢 set ID 時，就可以透過分割槽裁剪，快速定位資料，實現高併發的查詢。除此之外，Doris 還有很多最佳化查詢的手段。比如一些索引能夠加速查詢，前 36 位會走字首索引。Zone Map 索引、Bloom Filter 索引都能能快速完成資料的過濾計算。最後，Doris 內部在查詢過程中，還做了各種各樣的最佳化。比如智慧運算元下推，選擇更合適的資料模型。與此同時，Doris 在 Join 方面也有很大的優勢，比如 Broadcast Join、Bucket Shuffle Join、Colocate、Shuffle Join，能夠儘量減少 Join 過程中的資料 Shuffle。
Doris 的應用場景主要應用在即時分析/互動分析、多維報表分析，實時數倉、湖倉加速&聯邦分析的四大場景。在這四大場景上，我們可以構建一些指標監控、高頻發報表、自助 BI、行為分析、AB Test 等各豐富的資料應用。
這是一個典型的基於 Doris 構建實時數倉的案例。下層的資料來源是 RDS 業務庫，檔案系統資料、埋點資料。當資料實時接入 Doris 後，它基於 Doris 構建了一個實時數倉。在資料接入過程中透過 DataX 進行離線資料同步；透過 Flink CDC 進行實時資料同步。然後，在 Doris 內部構建不同的資料分層，比如 ODS 層、DWS 層、DWD 層的資料。最後，在上層構建不同的資料應用，比如自助報表、自助資料抽取、資料大屏。除此之外，它結合了自己的應用平臺，構建了資料開發與治理平臺，完成了源資料管理、資料分析等操作。使用者在使用 Doris 後，又帶來什麼好處呢？首先，它的業務計算從之前的兩小時，減少到三分鐘。全鏈路的更新報表從周級別，更新到十分鐘級別。同時，Doris 基於高度相容 MySQL，它的學習成本非常低。因此，報表簽約工作是非常順利的。由於 Doris 的開發非常簡單。開發週期從從周下降至天級。業務人員能快速滿足業務需求的變化。
某運營商的服務的架構是透過 Flink CDC 將 RDS 的資料同步到 Doris 中。然後，透過 routine load 將上層日誌中的資料接入到 Kafka 之後，將 Kafka 資料同步到 Doris 之中。然後，在 Doris 內部構建實時數倉。在資料排程時，它透過開源 Doris，完成資料排程。使用 Prometheus+Grafana 進行資料監控。它採用 Flink+Doris 架構體系後，帶來的好處是元件減少，解決了多架構下的資料的冗餘儲存，伺服器資源節省了 30%，資料儲存磁碟佔用節省了 60%，運營成本大幅降低。該案例每天在使用者的業務場景上，支援數萬次的使用者的線上查詢和分析。
如上圖所示，之前的架構是 Hadoop 數倉架構。因此它的元件比較豐富，有 RDS、HBase、Hive。除此之外，還有 Kafka 等技術棧。由此可見，它的技術棧非常複雜。在使用 Doris 之後，它將 RDS 裡的資料透過 Flink CDC，實時同步到 Doris 裡，伺服器資源成本得到了很大的降低。同時，也將資料的查詢時間從 Spark 的 2~5 小時，縮短到十分鐘，查詢效率也大大提升。在資料的同步過程中，它使用了 Flink CDC+MySQL，全量加增量的資料同步方式。與此同時，它還利用 Doris 的 Light Schema Change 特性，實時同步 Binlog 裡的 DDL 表結構變更到 Doris，實現資料接入數倉零開發成本。
1.2 版本第一個新特性是增加了 Multi Catalog，使用者可以無縫對接多種資料來源。Doris 會自動進行 Schema 同步，它的效能是 Trino 的三倍。除此之外，我們在主鍵模型可實時更新，實時更新場景下查詢效能 10 倍以上提升。Light Schema Change 能將 DDL 資料更新，並將資料表結構的變更，拉近毫秒級別。在外表上，我們開始支援 JDBC 外表，以及 Array 型別資料型別，New Decimal 等各種情況。重點介紹一下，之前我們支援 native UDF，大家的使用成本較高。現在，我們會支援 Java UDF，使用者可以快速寫一個 Java 類，就可以完成 Java UDF 的使用。
新版本相比在 1.1 之前的版本，有 3~5 倍的效能提升。同時，我們的效能也領先某業界標杆競品兩倍以上。上圖是我們在 SSB-FLAT 的效能測試結果。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2940031/，如需轉載，請註明出處，否則將追究法律責任。