2021-01-29

為什麼預計算技術代表大資料行業的未來，一文讀懂

作者簡介 ：李揚，Kyligence 聯合創始人兼 CTO

Apache Kylin 聯合建立者及項目管理委員會成員 (PMC)，曾任 eBay 全球分析基礎架構部大資料資深架構師、IBM InfoSphere BigInsights 技術負責人和摩根士丹利副總裁，IBM“傑出技術貢獻獎”獲獎者，具有大資料分析領域 10 多年實戰經驗。

專注于大資料分析、并行計算、資料索引、關系數學、近似算法和壓縮算法等前沿技術。在過去 15 年的工作經曆中，見證并直接參與了 OLAP 技術的發展 。

正文：

了解 Kylin 的技術同仁，一定對預計算這個概念不陌生。業内對于預計算的價值一直褒貶不一，今天筆者将結合自己的十多年的工作經驗，從預計算的曆史、原理到企業的應用，以及未來的發展來為大家帶來更為全面的解讀。

預計算的早期形式

預計算是一種用于資訊檢索和分析的常用技術，其基本含義是提前計算和存儲中間結果，再使用這些預先計算的結果加快進一步的查詢。

其實在我們不知道預計算的時候，我們就已經使用過預計算了。預計算的曆史大概可以追溯到 4000 年前古巴比倫人最早使用的乘法表。你回想國小背過的乘法表（如下圖所示）， 記住了乘法口訣，我們就可以通過心算來進行一些簡單的乘法運算，這個過程其實就是一種簡單的預計算。

乘法圖表來源： https://en.wikipedia.org/wiki/Multiplication_table

資料庫中的預計算

預計算也廣泛應用于資料庫技術中。比如，關系資料庫中的索引其實就是一種預計算。為了快速地檢索資料，資料庫會主動維護一個資料索引的結構，用來描述表格中一列或者多列資料的縮影。一旦索引的預計算完成，資料庫不用每次都重新查找表格的每一行，就能快速地定位資料。假設N是表格的行數，有了索引的預計算，資料檢索的時間可以從O(N)減少至O(log(N)) 甚至到 O(1)。

索引作為一種預計算，帶來便利的同時也存在一些弊端。當表格中插入新的行數時，就需要重新進行的計算和儲存。當索引越多，查詢響應越快時，那其實也意味着要進行更多的預計算，這當然也會顯著減緩資料更新的速度。下列圖表展示了索引數量增加後，表格插入行的性能也相應降低 。

索引數量對插入行性能的影響圖表來源：https://use-the-index-luke.com/sql/dml/insert

彙總表，通常由物化視圖實作，也是資料庫中預計算應用的另一種形式。彙總表本質上是對于原始表格的彙總。一個十億行的交易表按照日期進行聚合以後，可能就隻剩幾千行了。對資料的分析就可以通過彙總表而不是原始表來完成。受益于彙總表中資料量的大幅縮小，互動式的資料探索在彙總表上能提速數百倍甚至數千倍。而想在原始表格中完成這樣的互動式分析幾乎是不可能的。建構一個交易表的成本并不低，而且如果需要與初始表格保持同步更新的話，那成本就更高了。不過，考慮到分析速度的大幅提升及其所帶來的價值，彙總表仍然是現代資料分析中廣泛使用的一種工具。

OLAP 和 Cube 中的預計算

随着資料庫技術的演進，資料庫根據用途也出現了專精和分工。1993年，關系資料庫之父埃德加·科德（Edgar F. Codd）創造了 OLAP（On-Line Analytical Processing）這一術語來表示聯機分析處理。由此，資料庫被分為專精于線上事務處理的 OLTP 資料庫，和專精于線上分析的 OLAP 資料庫。就同你推測的一樣，OLAP 資料庫将預計算技術的運用提升到了更高的層次。

Cube 系統是一種特殊的 OLAP 資料庫，它将預計算發揮到了極緻。分析時資料可以具有任意數量的次元，而 Cube 就一個資料的多元度數組。将關系型資料載入到 Cube 的過程就是一種預計算，其中包括了對表格的關聯和聚合。一個滿載的 Cube 約等于 2n 個彙總表，其中 n 是次元的數量。這種巨量的預計算可能需要數小時才能完成！

Cube 的優勢和劣勢都十分明顯。一方面來說，一旦 Cube 建構完成，就能帶來最快的分析體驗，因為所有的計算都已經預先完成了。無論你想檢視資料哪個次元，結果其實都早已計算好了。除了從 Cube 擷取查詢結果和進行可視化操作之外，幾乎不需要再進行聯機計算，這完美實作了低延遲和高并發。

另一方面，Cube 不夠靈活，而且維護成本較高。這不僅僅是因為預計算和存儲本身消耗資源，更多是因為将資料從關系資料庫中載入 Cube 通常需要人工建設資料管道。每次業務需求變更時，都需要一個新的開發周期來更新資料管道和 Cube。這既需要投入時間，也需要投入金錢。

盡管投入不菲，在追求極緻的低延遲高并發的大資料多元分析場景下，Cube 技術一直是不可或缺的一個選項。

Cube 圖源：https://en.wikipedia.org/wiki/OLAP_cube

大資料時代的挑戰與機遇

展望未來，預計算在大資料時代又會面臨什麼挑戰和機遇呢？

先說結論，随着資料總量和資料使用者的持續增加，預計算将成為資料服務層中必不可少的基石。為了更好地解釋這一點，我們先要了解數字化轉型時代的大背景和預計算的技術特征。

先來看看當下企業數字化轉型的一些大背景。

• 資料量在持續增長(如下圖所示)。未來，将有更多的資料需要分析，這也就是說，企業将每年投入更多的算力來處理每年新增的資料。

資料增長圖來源：https://www.statista.com/statistics/871513/worldwide-data-created/

• 摩爾定律已經走到盡頭。德克薩斯大學的研究表明，從晶片制造的角度來看，過去十年中摩爾定律的影響已大不如前。與此同時，雲計算的價格近年來基本保持平穩。這意味着，企業的計算成本會與資料量的增長保持同步。

雲計算價格圖源：https://redmonk.com/rstephens/2020/07/10/iaas-pricing-patterns-and-trends-2020/

• 資料使用者的數量會顯著增加。隻有當資料被用于決策時，資料才有價值。為了讓資料這個“新石油”更好地驅動業務發展，理想狀态是公司中的每位員工都會使用資料。這也就是說，未來分析系統上的使用者可能将會是現在的數十倍甚至數百倍。平民資料分析師的時代要來了。

再來總結一下預計算的技術特征：

• 預計算其實是以空間換回了時間。如果追求響應速度，那麼當然優先考慮預計算。
• 預計算增加了資料準備的時間與成本，但同時減少了資料服務的時間與成本。如果追求高并發和服務更多的消費者，那也優先考慮預計算。
• 預計算會導緻資料管道邊長并增加端到端的資料延遲。這是需要改進的部分，這點我們也将在後文詳細介紹。

在以上的大背景下，讓我們一起來看看，預計算将會如何幫助我們解決一些基本的分析需求。

如何在資料增長的同時依舊保持快速查詢響應？

• 當我們使用聯機計算（通常是 MPP 資料庫）進行查詢時，查詢時間複雜度最小為O(N)，這意味着其所需的計算勢必與資料成線性增長的關系。假設，今天一條查詢運作時間是 3 秒，當資料量翻倍時，同樣的查詢運作時間就會變為 6 秒。要想資料分析師不抱怨，讓查詢響應時間保持在 3 秒之内，你隻能向 MPP 供應商付雙倍錢，讓 MPP 系統資源增加一倍。與聯機計算不同，當通過預計算進行查詢時，你會覺得它好像不受資料增長的影響。因為大多數結果都被預計算了，是以查詢時間複雜度接近 O(1)。即使資料量加倍，查詢傳回結果的耗時也與之前相差不大，查詢的響應時間仍将為 3 秒。

随着資料量增長，對比線上計算和預計算完成查詢的時間複雜度

如何更好地滿足“平民分析師”的并發需求？

• 對于聯機計算而言，使用者增長的影響類似于資料增長的影響。所需的計算量随并發使用者的增長而線性增長。MPP 供應商可能會勸說你将叢集規模增加一倍，來支援數量翻倍的分析師，不過公司的IT預算可能不允許，因為價格也翻倍了。另一方面，由于預計算将單條查詢所需的資源最小化，新增使用者所需的額外資源也能實作最小化。

當資料量和使用者數量同時增長，如何管理 TCO（總擁有成本）？

• 雲的優勢在于，在雲上所有資源消耗都可以通過成本進行量化。下圖展示了在 AWS 中 MPP 資料服務和預計算資料服務之間的實際成本比較。實際成本包含資料準備成本和查詢服務成本。其中，測評使用的工作負載是具有 1 TB 資料的 TPC-H（決策支援基準測試）。假設我們今天有 40 位分析師，每位分析師每天運作 100 個查詢語句，那麼問題來了，如果資料量增長 25％，使用者增長 5 倍，一年後的總成本将是多少？

預計算資料服務和 MPP 服務總體擁有成本對比

• 實驗表明，當查詢或使用者數量增長時，預計算的 TCO 優勢明顯。尤其是當每天查詢數量達到 20000 之後，預計算資料服務的 TCO 僅為 MPP 服務的1/3。資料量增長越大，預計算的優勢就越明顯。

總而言之，在數字化轉型的時代，預計算将會是大規模資料變現的關鍵技術。資料服務系統在預計算加持下，能夠同時實作快速響應時間，高并發和低 TCO。當然，就額外的資料準備而言，預計算也有它缺，這一點我們也會在下文展開讨論。

舉例：将OLAP查詢提速200倍

下面我們近距離觀察一個執行個體，看看 Apache Kylin 如何使用預計算，将一個 TPC-H 查詢加速200倍。TPC-H是一個資料庫研究領域常用的決策分析測試基準。

在100 GB 資料量下，TPC-H 基準裡的7号查詢在 Hive+Tez 的 MPP 引擎下需要執行35.23秒。從下圖可以看到，這個查詢并不簡單，包括了一個子查詢。執行計劃顯示，這個查詢的包含了多個Join運算和一個 Aggregate 運算。這兩種計算也是整體執行中最大的瓶頸。

TPC-H 基準裡的7号查詢在 MPP 引擎下的執行計劃

從預計算視角，我們容易想到使用一個物化視圖，可以将 Join 運算提前算好，進而節省查詢時的開銷。如果人工來做，方法大緻如下。

TPC-H 基準裡的7号查詢人工處理物化視圖

注意到新的執行計劃由于 Join 運算被替換為物化視圖而大大簡化了。但這個方法的缺點在于物化視圖需要人程式設計工來建立和維護，并且應用層需要改寫 SQL 來查詢新的物化視圖，而不是原始表。這種改寫在實際工程中代價很大，因為涉及大面積的應用層重構，通常需要一個完整的開發周期，并需要全回歸的應用測試。最後，Aggregate 運算仍然線上計算，預計算還有較大的提升空間。

為了做到更完美的預計算，Apache Kylin 做了一下設計：

• 引入了多元立方體概念。一個 Cuboid 簡單來說，就是一個包含了 Join 和 Aggregate 預計算結果的物化視圖
• 幫助使用者通過 GUI 配置方式，自動建立和維護Cuboid
• 能自動優化查詢的執行計劃，動态選擇最合适的Cuboid 執行查詢，而使用者無需修改 SQL

TPC-H 基準裡的7号查詢在 Apache Kylin 環境下的執行計劃

在 Apache Kylin 上執行同樣的查詢，在相當的硬體條件下，隻需要0.17秒。充分的預計算消除了 Join 和 Aggregate 兩個最大運算瓶頸。在執行計劃優化過程中，系統會自動挑選最合适的 Cuboid 并替換到執行計劃裡。應用層的 SQL 不需要修改，就能獲得透明加速200倍的分析體驗。

預計算未來可期

盡管預計算在大資料領域表現優異，但也确實存在一些缺點，例如，預計算可能會加劇資料管道的延遲，還需要額外的人工運維。不過好消息是，Gartner 預測：“到 2022 年，通過機器學習的增加和自動服務級别管理的壯大，資料管理手動任務将減少 45％”。我們将會在接下來的兩年内，看到新一代智能資料庫系統緩解甚至徹底消除這些問題。

在不久的将來，新一代資料庫将以智能化和自動化的方式融入預計算技術。下面是我們對未來一些預測：

• 為了支援更大的資料量和服務更多的平民分析師，預計算将會被會在資料服務層廣泛使用。
• 借助人工智能和自動化技術，預計算的資料準備工作将會實作全面的自動化。例如，炙手可熱的雲上數倉 Snowflake 就在底層資料塊上自動作小量聚合預計算并加以物化（small materialized aggregates [Moerkotte98]），過程對使用者完全透明，完全自動化。大資料 OLAP 引擎 Apache Kylin 也能根據使用者配置的次元組合，自動化的完成将關系資料加載到 Cube 中預計算。整體配置過程在 GUI 中完成，不需要程式設計或大資料技能就可以實作，達到了半自動化的水準。
• OLAP 資料庫開始配備智能或透明的預計算功能。這樣的資料庫将能夠在聯機計算和預計算之間透明地切換。當需要查詢最新資料時，就可以直接從MPP 引擎查詢最新資料，不會受困于資料管道的延遲。當查詢能擊中某些預計算時，那麼已經計算好的結果将會在最大程度上減少查詢成本，同時系統吞吐量也會提高。新型資料庫将能夠實作自動決定何時預計算，作哪些預計算，并智能地運用預計算來實作各種運維目标，比如快速響應時間，高并發性和低 TCO。而以上這些對終端使用者都是透明的，徹底解放資料庫管理者。

點選這裡，了解預計算技術和Kyligence詳情。

參考文獻

• Multiplication table https://en.wikipedia.org/wiki/Multiplication_table
• Database index https://en.wikipedia.org/wiki/Database_index
• More indexes, slower INSERT https://use-the-index-luke.com/sql/dml/insert
• OLAP cube https://en.wikipedia.org/wiki/OLAP_cube
• The Rise and Fall of the OLAP Cube https://www.holistics.io/blog/the-rise-and-fall-of-the-olap-cube/
• Worldwide data volume https://www.statista.com/statistics/871513/worldwide-data-created/
• Measuring Moore’s Law 2020 https://www.nber.org/system/files/chapters/c13897/c13897.pdf
• IaaS Pricing Patterns and Trends 2020 https://redmonk.com/rstephens/2020/07/10/iaas-pricing-patterns-and-trends-2020/
• TPC-H decision support benchmark http://www.tpc.org/tpch/
• Augmented Data Management https://www.gartner.com/en/conferences/apac/data-analytics-india/gartner-insights/rn-top-10-data-analytics-trends/augmented-data-management

關于 Kyligence

Apache Kylin 在 PB 級别資料上帶來了開創性的即時分析能力，并被全球超過1000多家企業所使用。由 Apache Kylin 核心團隊創立的 Kyligence 公司的使命以自動化資料管理、發現、互動及洞察來為其客戶提升生産效率。

Kyligence 獲得了來自紅點、思科、寬帶資本、順為資本、斯道資本（富達國際自有投資機構）及 Coatue Management 等投資機構的多輪投資，其全球客戶包括歐萊雅、Xactly、及華為等。公司以雙總部營運，中國總部位于上海，美國總部位于美國加利福尼亞矽谷聖何塞。

聯系我們網站：http://cn.kyligence.io 郵件：[email protected]電話： [phone]