引言

企業(yè)數(shù)字化的進(jìn)程，由數(shù)據(jù)庫的發(fā)展軌跡主導(dǎo)，而數(shù)據(jù)庫本身的演進(jìn)又受制于硬件的技術(shù)瓶頸。簡單來說，數(shù)據(jù)庫需要一個強大的計算機(jī)來支撐，但單塊CPU顯然沒有這個能力，因此通過網(wǎng)絡(luò)連接多塊CPU、磁盤的分布式技術(shù)成為數(shù)據(jù)庫發(fā)展的主要推動力，但相關(guān)硬件技術(shù)的發(fā)展速度有所差異，“在多年以前，數(shù)據(jù)庫的硬件瓶頸主要在于磁盤和網(wǎng)絡(luò)帶寬，隨著磁盤讀寫速度和網(wǎng)絡(luò)帶寬的提升，也就是IO不會成為數(shù)據(jù)庫的明顯瓶頸?！毖谆藬?shù)據(jù)研發(fā)工程師吳立表示，“如今，CPU成為了數(shù)據(jù)庫執(zhí)行效率上的新的瓶頸。”

炎凰數(shù)據(jù)在數(shù)據(jù)庫開發(fā)過程中，最重要的原則就是順應(yīng)新的場景需求，以及具體的硬件發(fā)展現(xiàn)狀，進(jìn)行技術(shù)演進(jìn)決策。

一、列存儲：數(shù)以類聚

炎凰數(shù)據(jù)在數(shù)據(jù)庫技術(shù)演進(jìn)中有幾個關(guān)鍵節(jié)點，列存儲技術(shù)的引入在早期非常關(guān)鍵。

炎凰數(shù)據(jù)的核心創(chuàng)始團(tuán)隊均來源于全球大數(shù)據(jù)分析引擎領(lǐng)軍企業(yè)Splunk，吳立也不例外，“Splunk成立的時間比較早，在大約二十年前，Splunk的產(chǎn)品在業(yè)內(nèi)是非常先進(jìn)的，但他們實際上采用了行存的存儲形式，在當(dāng)時還是可以解決用戶問題的，比如日志索引、搜索等?！?/span>

比如在做數(shù)據(jù)聚合搜索的時候，對于行存，就是同一行數(shù)據(jù)存在一個數(shù)據(jù)塊或者一個連續(xù)的存儲空間里面，而列存就是同一列數(shù)據(jù)存在一個連續(xù)的存儲空間里面。聚合操作一般只針對某一列數(shù)據(jù)，也就是某一個字段，比如計算某一列數(shù)值的和。數(shù)據(jù)計算通常是針對同一個字段的數(shù)據(jù)。有了列存之后，可以一次性把所需數(shù)據(jù)提取出來，相比之下，如果是行存，則需要不斷進(jìn)行尋址才能找到對應(yīng)的某列數(shù)據(jù)，因為它們分散在不同的數(shù)據(jù)塊里面。

行存的邏輯是存儲每個實體的多維度信息，而列存則是存儲每個維度包含的所有實體的信息。在大數(shù)據(jù)場景下，列存相比行存有很明顯的優(yōu)勢?！按送?，列存儲的另外一個優(yōu)勢是，由于數(shù)據(jù)性質(zhì)相同，列式數(shù)據(jù)可以很好地做數(shù)據(jù)壓縮，進(jìn)一步提升效率。”

在具體落地中，通過調(diào)研很多產(chǎn)品的優(yōu)缺點，炎凰數(shù)據(jù)進(jìn)一步確認(rèn)了列式存儲的數(shù)據(jù)格式，“我們調(diào)研了很多列存的數(shù)據(jù)格式，比如Parquet、Avro等，最終，基于內(nèi)存設(shè)計、標(biāo)準(zhǔn)化、語言無關(guān)、平鋪和層級數(shù)據(jù)結(jié)構(gòu)支持、硬件感知等方面的優(yōu)秀特性，認(rèn)為Arrow是一個非常通用并且可被廣泛接受的數(shù)據(jù)格式。我們在應(yīng)用中，結(jié)合具體的使用場景使數(shù)據(jù)的處理和交換更加高效。”

這項技術(shù)可以給OLAP應(yīng)用帶來很大的體驗提升，但吳立在親身經(jīng)歷中體會到，雖然技術(shù)是為產(chǎn)品服務(wù)的，但是技術(shù)演進(jìn)隨時可能面臨風(fēng)險。因為技術(shù)改造終究是很漫長的過程，工程量極大，在真正落地之前并不能100%確定能夠應(yīng)對未來兩三年的技術(shù)發(fā)展要求。“除了列存儲，還有比如實時搜索這樣的功能，具體落地時，都存在各種各樣的難題，包括學(xué)習(xí)曲線、框架支撐等等。”

列式存儲相當(dāng)于在空間上將查詢、分析與計算所需的重要元素進(jìn)行匯集或提前過濾，這是加速的重要原則。而這些元素的同質(zhì)性自然能帶來另一項計算加速優(yōu)勢，也就是SIMD并行計算，其對列式數(shù)據(jù)的每一項同時進(jìn)行相同的運算。

“如果對性能要求很高，SIMD是很自然的選擇。我們希望在產(chǎn)品特別是內(nèi)核執(zhí)行的各個階段都能進(jìn)行優(yōu)化，并利用好硬件帶來的優(yōu)勢。在落地過程中，有一個關(guān)鍵問題是，SIMD對CPU架構(gòu)的適配性要求很高，每次適應(yīng)新的CPU架構(gòu)，都可能面臨不支持SIMD指令的情況。我們會選擇對SIMD支持更友好的library來對數(shù)據(jù)結(jié)構(gòu)進(jìn)行解析，從而實現(xiàn)CPU的適配。比如為了適配ARM的CPU架構(gòu)，有一些功能組件會采用架構(gòu)支持的指令集進(jìn)行編譯，使產(chǎn)品在新的架構(gòu)上能高效運行。

二、JIT即時編譯：開源的力量

即時編譯是一種通用技術(shù)，與任何具體執(zhí)行策略都不關(guān)聯(lián)，從而在編譯層面的優(yōu)化將有很大的自由度。編譯優(yōu)化也是相對于向量化計算的一種典型加速方式，兩者各有優(yōu)劣。

“我們在搜索的過程中發(fā)現(xiàn)，在簡單的表達(dá)式求值場景中，性能沒有完全達(dá)到期望值。因為炎凰數(shù)據(jù)打造的是Schema on Read（讀時建模）產(chǎn)品，應(yīng)用中會涉及到大量的數(shù)據(jù)讀取之后在計算層面的過濾?！?/span>

Schema on Read也就是讀時建模是炎凰數(shù)據(jù)的產(chǎn)品核心關(guān)注點，主要是為了適應(yīng)當(dāng)下大數(shù)據(jù)場景中常見的異構(gòu)數(shù)據(jù)分析面臨的挑戰(zhàn)。

“在搜索過程中還涉及到投影計算，過濾和投影是計算非常重的，如果這兩個計算的性能不好，就會影響整個SQL語句執(zhí)行的效率。“

為此，炎凰數(shù)據(jù)決定在編譯優(yōu)化層面應(yīng)用JIT即時編譯技術(shù)，JIT的主要思想是程序在運行時被編譯成代碼，不需要提前編譯，雖然會犧牲一定的編譯速度，但也降低了鏈接的額外開銷。

在SQL查詢執(zhí)行的不同步驟中，執(zhí)行引擎需要計算表達(dá)式，表達(dá)式以DAG的形式表示，而JIT編譯可以提高表達(dá)式在計算時的效率。

在經(jīng)過調(diào)研和選型之后，炎凰數(shù)據(jù)發(fā)現(xiàn)，正好Arrow也提供了表達(dá)式優(yōu)化的工具——Gandiva，“一方面，Gandiva提供了很多內(nèi)置的表達(dá)式庫，同時對投影和過濾計算過程都有良好的支持；另外一方面Gandiva在編譯優(yōu)化表達(dá)式的時候有優(yōu)化，進(jìn)一步計算的效率?！?/span>

但Gandiva并不是一個很完美的產(chǎn)品，為此，炎凰數(shù)據(jù)在這個工具的基礎(chǔ)上，對于不滿足特定場景的需求進(jìn)一步進(jìn)行完善和補全。“比如想在這個library里面添加一個自定義函數(shù)接口的時候，相關(guān)的注冊機(jī)制沒有完善，就會遇到問題。通常的做法是把這一部分代碼建立一個分支，完善后patch到我們的產(chǎn)品里面。但這種做法帶來的后果是，經(jīng)常會隨著項目往前發(fā)展，帶來一些沖突?！?/span>

炎凰數(shù)據(jù)借用了開源的力量，把這部分代碼貢獻(xiàn)給Arrow開源項目，再從項目的上流分支做一些改進(jìn)增強，從而解決了這個問題。

JIT即時編譯帶來的優(yōu)勢非常明顯，大大減少了表達(dá)式計算在過濾和投影階段的時間，使得用戶查詢特別是在涉及大量表達(dá)式的時候變得更快。

在具體開發(fā)中，炎凰數(shù)據(jù)實現(xiàn)了很多改造，包括數(shù)據(jù)類型、高階函數(shù)等方面的支持，以及緩存復(fù)用、外部函數(shù)注冊等機(jī)制，這些成果全部貢獻(xiàn)給了Arrow項目。

三、push mode：改頭換面

數(shù)據(jù)庫的性能優(yōu)化點不僅在于硬件層面的適配，也在于軟件架構(gòu)中的參與方，也就是數(shù)據(jù)何時被消費。如果是用戶主動，則在用戶有消費需求的時候從系統(tǒng)拉取數(shù)據(jù)進(jìn)行處理，這被稱為pull mode；如果是供應(yīng)方主動，則不需要關(guān)心用戶消費時間點，可以提前提取數(shù)據(jù)、處理數(shù)據(jù)，把數(shù)據(jù)以推送的形式提供給用戶，這被稱為push mode。

pull mode和push mode之間沒有說哪個更好，需要結(jié)合具體場景來比較。pull mode在查詢引擎中是一個很經(jīng)典的模式，接口簡單，從而可以很容易地擴(kuò)展新功能。但是對于push mode，其技術(shù)復(fù)雜性更高，不過在新場景支持和效率提升特別是流式數(shù)據(jù)處理、緩存效率等方面，push mode更加有優(yōu)勢。

”為了實現(xiàn)技術(shù)改造，炎凰數(shù)據(jù)把pull mode相關(guān)的所有執(zhí)行引擎的算子都替換成了push mode的算子，在整個項目中做了大量的臟活累活?！皃ush mode帶來了進(jìn)一步的查詢性能提升，“收益非常明顯，雖然程度不一，但對查詢的提升基本是全面的。”

全方位提升的結(jié)果凝聚炎凰數(shù)據(jù)整個團(tuán)隊的努力，團(tuán)隊也踩了不少坑，“整體模式切換是比較痛苦的過程，因為要去協(xié)調(diào)整個整個團(tuán)隊的資源，不能影響正常產(chǎn)品功能的發(fā)布，也要考慮用戶的新需求，同時讓用戶在老的引擎和新的引擎里面都能夠工作。比如有些issue是在產(chǎn)品發(fā)布之后才發(fā)現(xiàn)的，這就提醒我們在工程排期上多留一些buffer，從而提高容錯率?！?/span>

四、產(chǎn)品追求：始終如一

列式存儲、JIT即時編譯以及push mode，一系列的技術(shù)優(yōu)化，最終都是為了用戶查詢體驗的提升，極致的產(chǎn)品追求，反映的是炎凰數(shù)據(jù)成熟的產(chǎn)品思維，“從終端用戶的角度來看，他們不會關(guān)心技術(shù)具體是怎么做的，只關(guān)心查詢結(jié)果是否能夠盡快提供，特別是在大數(shù)據(jù)量的情況下，這是我們所有產(chǎn)品的落腳點。”

炎凰數(shù)據(jù)的核心優(yōu)勢在于異構(gòu)數(shù)據(jù)的處理，從數(shù)據(jù)的采集到存儲、搜索、可視化都能夠有非常好的體驗。在產(chǎn)品開發(fā)的關(guān)鍵節(jié)點也就是核心引擎研發(fā)中，炎凰數(shù)據(jù)始終關(guān)注技術(shù)發(fā)展趨勢以及技術(shù)生態(tài)的支持，并堅持一個原則，“我們在開發(fā)的過程中，不同的階段要給到用戶一個相對完整的產(chǎn)品體驗，同時也不損耗我們對產(chǎn)品的長遠(yuǎn)規(guī)劃?！?/span>

炎凰數(shù)據(jù)當(dāng)下的技術(shù)演進(jìn)和產(chǎn)品更新的選擇，順應(yīng)了OLAP技術(shù)不斷趨同、走向標(biāo)準(zhǔn)化，以及數(shù)據(jù)平臺一體化的趨勢。在這個背景下，炎凰數(shù)據(jù)對競爭優(yōu)勢的理解有著自己的執(zhí)著，“我們始終如一的追求，都在于對異構(gòu)化的數(shù)據(jù)更高效的處理，以及為用戶在從采集到可視化的各個層面提供給更好的體驗，存儲要保證安全，分析要保證快速，可視化要滿足分析的需求。只要在各個層面都做的足夠優(yōu)秀，當(dāng)作為一個一體化產(chǎn)品呈現(xiàn)給用戶的時候，它才能夠在業(yè)內(nèi)占據(jù)一席之地。”