演講的主題是 時序數據庫現狀及核心技術/問題，因為技術都是為解決具體問題生的。

我們將從如下3個視角的分享，分別從：

• 領域趨勢方面和大家聊聊時序數據庫的現狀和未來發展空間。
• 核心技術角度和大家聊聊時序數據庫面臨怎樣的實際問題，將會以怎樣的技術手段來解決。
• 從應用場景和價值締造角度我們簡單聊聊如何才能讓時序數據庫在具體應用場景中產生業務價值。

那么，在開始今天的分享之前，先簡單的介紹一下我的個人信息：

我是 孫金城，阿里花名 “金竹”。

目前在阿里工作已經接近10年，以ApacheFlink為切入點，在流計算領域貢獻了5年，目前以阿里巴巴物聯網分析團隊負責人的角色，基于ApacheIoTDB對時序數據存儲領域進行探索。

在開源領域，目前是兩個Apache頂級項目的PMC成員，也是ApacheMember，同時也在支持Apache本土社區的發展，是ALCBeijing的成員，Apache孵化器的IPMC 成員，以及開放原子開源基金會的孵化器導師。

那么，在眾多的開源 參與和貢獻 的同時，我個人也非常喜歡做一些技術類的博客和視頻分享，也歡迎大家關注我的個人公眾號，大家可以保持線下的持續交流。

好的，我們開始今天的第一部分，我們看看時序數據庫目前處在一個怎樣的趨勢，是什么造就了時序數據庫的快速發展？

從我的角度看，聊存儲，我喜歡從數據的角度切入。。

目前不僅僅是數據時代，而且數據的規模是驚人的，我們處在一個大數據時代。那么我們所說的大數據時代的數據規模到底是怎樣的呢？

根據某研究院發布的統計數據，近年，隨著人工智能、5G，AIoT等技術的推動，全球數據量正在無限地增加。2018年全球數據總量為33ZB，在2019年約達到45ZB。按照這樣的增長趨勢，到2025年，全年將會有175ZB的數據產生。

在希捷的首頁，有一句話，這里分享給大家：

全球數據領域將從2019年的45ZB增長到2025年的175ZB，全球數據的近30%將需要實時處理，您的企業是否已經做好準備？同樣帶著這個問題，我們看看實時數據庫領域是否做好了準備？

那么，到2025年每年175ZB的數據從哪里來的呢？我們從云/邊/端三個角度看數據的創建和存儲。

隨著網絡的高速發展，尤其是5G時代的到來，數據越來越多的進入云端。那么我們所說的Core/Edge/Endpoint(云/邊/端）分別指的是什么呢？

• 云(Core) - 這包括企業中指定的計算數據中心和云提供商。它包括各種云計算，公共云、私有云云和混合云。
• 邊(Edge) - 邊緣是指不在核心數據中心的企業級服務器和設備。這包括服務器機房、現場服務器、還有一些較小的數據中心，這些數據中心位于距離設備較近的區域，以加快響應。
• 端(Endpoint) - 端包括網絡邊緣的所有設備，包括個人電腦、電話、聯網汽車、可穿戴備以及工業傳感器等。

那么這些數據來源，有哪些是我們日常工作生活可以感知到的呢？我們接下來簡單舉例分析一下：

?

作為在阿里工作近10年的我，對我來說感覺最近的數據是一年一度的雙11全球狂歡。我們發現自2009年以來，雙11每年的成交額飛速增長，到2020年竟然高達4982億。這個數字背后，說明了大量數據的產生。但是相對于175ZB的數據來說，這些交易數據，監控數據，只是冰山一角。為什么這樣說呢？我們繼續往下看。。。

這里同樣又一份關于全球設備連接的統計數據，到2020年全球有500億的設備數據上云，這些設備覆蓋了很多實際場景，比如：智能生活，智能城市，智能農業，

更值得大家關注的是智能制造，也即是工業物聯網領域。在5G和工業4.0的的大背景下，工業物聯網也將會是下一個技術趨勢所在。。。

我們說到技術發展趨勢，Gartner的數據是大家非常信任的，在2021年Gartner又指明了9大技術趨勢，如果大家關注Gartner的報告，我們發現這9大戰略技術趨勢和前三年有了一些變化。

2018強調云向邊緣挺進，2019主張賦權邊緣，2020更加強調流量的處理要靠近設備本地，其實也就是端和邊的計算技術。這連續三年都明確提到了端/邊，也就是物聯網領域，那么2021的戰略趨勢和物聯網有怎樣的關系呢？

2021強調的分布式云就是強調了物聯網領域已經走進云邊端一體化的進程，分布式云將取代私有云。分布式云的架構更強調了中心云計算能力下沉的時代趨勢。

分布式云的多樣性也囊括了物聯網領和邊緣計算的技術方向。那么在這樣一個大的技術趨勢下，時序數據庫當前處在一個怎樣的階段呢？

國家對物聯網領域，尤其是工業物聯網領域是高度重視的，早在2017年就提出了指導意見，明確了三個階段性的發展目標：在2025年之前重點在基礎設施的建設，到2035年具備平臺化能力，最終達到應有層面的落地。那么實際上各個大廠的發展都是超前于這份指導性建議的發展目標額，目前各個云廠商已經基本形成了各自的工業物聯網平臺的搭建，后續的重點是平臺的增強和實際應用的創新發展。那么在這樣一個高速發展的階段，各個大廠都在解決這這樣的問題呢？

其實，物聯網領域的數據產生，大部分來自于 工業物聯網，剛才大家看到，物聯網領域設備連接在2020年已經超過500億，我們以一個挖掘機工礦信息來說，一個設備就有5000多的工況指標要采集，數據每秒都在不停的采集，數據量可畏是驚人的，那么在千億的工礦數據和ZB級別的時序數據面前，我們面臨怎樣的難題呢？

大家會想到的是數據上云的帶寬流量成本問題，但幸運的是，在過去的20年中，有線寬帶服務每兆比特的費用下降了98％，從2000年的平均28.13美元下降到2020年的0.64美元。所以低流量成本的情況下，ZB級別的存儲成本問題就更為顯著。技術都是為領域問題而生，面對這樣的領域問題，存儲領域又有這樣的技術變化呢？

根據DB-Engines的統計數據，我們發現，在各種數據庫存儲產品中，時序數據庫的發展是最受歡迎，發展是最快的。

也就是說，5G和工業4.0的發展，大量時序數據的產生，促就了時序數據庫的快速發展。那么，目前都有哪些時序數據庫產品呢？

同樣這個統計也是來自DB-engines網站，目前我們已經有幾十種時序數據庫產品，這些產品有些是開源的，有些是各個大廠研發的商業產品。

目前來看，大概有20%+的商業產品，近80%來自開源社區，這里也多說一句，擁抱開源同樣也是大勢所趨。

好的，趨勢方面我們就了解到這里，接下來我們細致的看看現在的時序數據庫有哪些特點，如何分類，時序數據庫又???哪些核心技術。

首先，我們從存儲架構角度，看看時序數據庫的分類情況。

• 第一類就是是基于關系數據庫的時序數據庫，比如timescale。
• 第二類就是基于KV的時序數據庫，比如OpenTSDB。
• 第三類就是專門面向時序數據場景的原生時序數據庫，比如InfluxDB,IoTDB和TDengine等。

當然持久化角度看，還有很多優秀的內存時序數據庫，比如：Google的Monarch,Facebook基于Gorilla論文實現的產品。那么不論基于怎樣的架構，這些時序數據庫都要解決的共性問題有是什么呢？

我們前面說最大的數據來源是工業領域的各種設備傳感器數據，這些設備的工況數據收集和處理將給存儲和計算帶來巨大的挑戰。我們還是以一個具體的案例來說，這是GoldWind發電數據采集，GoldWind有超過2w個風機，一個風機有120-510個傳感器，采集頻率高達50Hz，就是每個傳感器1秒50個數據點采集峰值。這要算下來就是每秒5億個時序指標點的數據。這個數據量讓數據采集/存儲/計算面臨很大的挑戰。同時還有我們業務中的一些非常常見的查詢需求。所以時序數據的存儲將要解決寫入吞吐問題，還有數據查詢分析的性能問題。

同時，時序數據領域還有一個很大的領域特點，或者說是領域問題，那就是弱網環境下，時序數據的亂序是一種常態。

亂序問題問什么是時序數據場景的核心問題呢，我看一個具體的智能制造的案例，如圖。是一個工業冶煉能耗控制的例子。核心需求是，在云端進行大量的實時模型訓練，然后模型下推到邊緣端，在邊緣端利用時序數據庫進行數據的本地存儲和局部數據數據預測，進而控制本地的熔爐燃料投放。比如，5秒鐘一個計算窗口，那么亂序造成的計算不精準，將會對能源消耗和冶煉質量帶來很大的影響。所以說，亂序問題的解決也是時序數據價值最大化的核心問題所在。

那么從存儲架構的維度看，基于關系/基于KV和原生時序數據庫的寫入速度有怎樣的排布？

宏觀來看，基于關系數據庫的時序數據庫寫入速度遠遠慢于，基于KV和原生的時序數據庫。為什么會有這樣的判斷呢？這個結論還是從底層存儲架構設計角度得出的。

關系數據庫的存儲寫入架構是基于B-Tree或者B+Tree，而KV和原生的時序數據庫都是基于LSM-Tree進行數據寫入設計的。不同的數據結構對寫入性能產生巨大的影響。我們進一步細聊一下其中的原因。。。

聊到存儲寫入，我們立即會想到磁盤，我們應用數據寫到磁盤會經過內存，然后持久化到磁盤。那么這個過程中，寫入的核心耗時是在什么階段呢？

就是大家熟知的磁盤IO部分。那我們看看怎樣的磁盤IO才是高性能的？而怎樣的磁盤IO又是低效的呢？

我們知道 扇區 是磁盤的最小組成單元，通常是512字節,文件系統/數據庫不是一個扇區一個扇區的來讀數據，因為太慢了，所以有了block（塊）的概念，它是一個塊一個塊的讀取的，block才是文件存取的最小單位。每個塊的大小是 4~64KB，但是這個數值是可配置。一般來說磁盤訪問一個磁盤塊平均要用10ms左右，因此，我們有必要做一些事情來減少磁盤的平均訪問時間來提高寫入性能。大家都知道，順序IO性能遠高于隨機IO，隨機I/O可能是因為磁盤碎片導致磁盤空間不連續，或者當前block空間小于文件大小導致的。連續 I/O 比隨機 I/O 效率高的原因是：在做連續 I/O 的時候，磁頭幾乎不用換道，或者換道的時間很短；而對于隨機 I/O，很多的話，會導致磁頭不停地換道，造成效率的極大降低。那么剛才說的B+Tree和 LSM-Tree的數據結構，與磁盤IO有怎樣的關系呢？

我們先來看看Btree和B+Tree的的寫入復雜度，這里我們核心看對磁盤的訪問，

所以我以DAM的維度看兩種數據結果的復雜度，我們會發現不論是BTree和B+Tree寫入和查詢復雜度都是LogBN，B是階數，N是節點數。感興趣算法復雜度的推導的朋友可以掃描左下角二維碼查看推導過程。那么，既然算法復雜度一樣，在實際的存儲產品中這兩種設計有怎樣的區別呢，我們先看看BTree和B+Tree的數據結構設計的區別：

核心區別就是：是否在非葉子節點存儲數據以及在葉子節點是否以指針連接相鄰節點。那么問題來了，在存儲對磁盤訪問的角度考慮，我們是選擇BTree還是選擇B+Tree呢？這里面我們就要加入另一個變量因素，就是存儲產品一次讀取磁盤的block因素和每個節點數據和指針大小因素。根據BTree和B+Tree的數據結構特點，在一次讀取磁盤的Block大小一定的情況下，一個Block的磁盤讀取所包含節點越多那么在數據量一定的情況下，樹的階數越大，也就是LogBN的B越大，進而讀取磁盤次數越少性能越好。這句話的信息點有點多，相信如果不是存儲領域的朋友可能會有若干個“為什么”，那么如果除了對這個結論感興趣，對細節推到部分也感興趣的話，我的公眾號里面有一個近2小時的細致剖析，大家可以關注我的公眾號，在會后進行選擇性觀看。

好的，那么我們再回到，為什么BTree/B+Tree的寫入會設涉及到隨機IO問題。

假設我們有如上數據按順序進入存儲系統，如果存儲系統采用的是BTree進行設計的，我們簡單分析一下寫入過程。

首先數據陸陸續續的到來，35，3，90這個小樹是如何變化的。。先來3，再來 35，再來 90，我們構建數據結構，如圖，35左右是3和90，數據再陸續到來，當17到來的是，數據如何變化？17比35小，所以17再左子樹。假設這時候我進行了一次持久化操作，然后，后續數據陸續到來。。。當26到來的時候，26比35小，在35的左子樹，但是35左邊已經有2個data了，做3階Btree，節點超了。因為節點超了，所以我們需要進行節點分裂，如圖，17上提與35同一層級。這時候我們假設再次磁盤持久化處理，我們發現3和17已經不在一個數據塊了，17和35又重新寫到了磁盤上的一個數據塊。

數據不斷的到來，數據的節點不斷的變化，磁盤持久化也不斷發生。

這個變化過程中大家發現機遇BTree和B+Bree的設計，寫入磁盤的數據是有更新操作的，進而造成了大量隨機IO。

那么我們再來看看LSM-Tree的為什么是順序IO？其實，LSM核心思想是放棄部分讀能力，換取寫入的最大化能力。我們看到LSM-Tree的寫入復雜度是O（1）。具體的插入流程如下：

• 來請求之后 首先寫入write ahead文件，然后進行內存的更新，
• 更新完成之后，就返回成功。那么數據是如何持久化的呢？
• 當內存到一定大小后，就將內存變成immutable，進行持久化操作。
• 最后刷盤進行持久化成功之后，會有后續的 Merging Compaction在后臺進行。

所以基于LSM Tree結構完美的解決了寫入的高吞吐問題。

那么，解決的寫入問題，基于LSM-Tree的時序數據庫產品是如何解決

查詢性能問題的呢？我看OpenTSDB查詢邏輯是怎樣的？

• 查詢請求來了，會對各種索引進行查詢。。。
• 首先是以二分法查詢MemTable，
• 然后查詢immutableMem-table，
• 如果都沒有查到，就查詢磁盤文件
  ?

當然在查詢過程中還伴隨各種優化，比如BloomFilter的應用。

雖然都是基于LSM-Tree的設計，但不同的產品有不同的優化定制，

比如我們再來看看InfluxDB的設計。。

• 同樣數據來了也是第一寫入到WAL文件。
• 接下來再更新內存Mem-Table之前，InfluxDB出于查詢性能的考慮，在這個環節增加了內存索引構建。
• 然后才是內存更新，
• 最后返回客戶端成功信息。

當然，在Mem-Table部分，InfluxDB也做了局部優化，利用hash進行分布優化。同時在持久化時機上面也考慮了內存大小和刷盤時間周期。其實，InfluxDB設計了自己的TSMFile格式，文件增加了索引建立。這里和大家提一句就是，InfluxDB的設計充分考慮時序數據的時間特點，在Mem-Table中的Map中采用timestamp作為key的組成部分。從1.8版本看，InfluxDB代碼里面沒有看到將內存變成immutable的部分。在InfluxDB的Compaction時候也考慮若干優化因素。比如壓縮算法的選擇等。最后，InfluxDB還設計了自己的索引結構，TSI極大的加速了數據查詢性能。

好的，看完OpenTSDB和InfluxDB，我們再來看看Apache頂級項目 IoTDB。

IoTDB為了提高查詢速度，不僅定制了 索引結構還增加了查詢優化器的支持。

更值得大家關注的是，IoTDB針對工業物聯網領域時序數據亂序問題對LSM-Tree

進行了優化改造，在內存和文件上面都考慮亂序的處理。出于今天接下來還有

黃老師對ApacheIoTDB進行細節分享，我這里先對IoTDB簡單說這么多。

OK，那么我們想想，在時序數據庫領域到底涉及里哪些問題和哪些解決這些領域問題的核心技術呢？

• 第一個就是存儲數據結構的設計，利用xLSM-Tree的架構解決寫入高吞吐問題。
• 第二個在高性能查詢上面，各個產品都有自己的索引定制和查詢優化器的引入。
• 第三個在存儲成本上面，各個時序數據庫產品以列式存儲和具體類型的針對性壓縮算法選取解決存儲成本問題。當然在云上存儲成本上面我，們還可以在邊緣端做更多的優化處理，在云上有冷熱數據的處理，這也是分布式云的技術戰略趨勢所導向的。
• 第四個也是非常重要的領域問題，就是亂序的解決，利用寫前保序和寫后重排多種手段在存儲層面解決亂序問題。進而在后續的計算分析部分發揮最大的價值。那么大家想想除了上面核心的四個方面還有其他關鍵問題和技術需要關注嗎？
• 當然還有，那就是在分布式云的架構下，邊緣端的部署也是需要高可靠的，各個時序數據庫產品都需要提供多副本的集群版支持。
• 最后還有一個，如果最大限度讓時序數據庫產生最大價值，邊緣端的實時計算也是必不可少的，那么，時序數據庫對實時計算的支持也有很大的技術挑戰。

那么在上面提到的6大領域問題和技術挑戰中，實時計算看起來和數據庫關系不大，為什么我這里還要重點提出呢？

這里和大家分享的思考是，在分布式云的大技術方向下，計算不僅僅是集中云上的需求，也是在邊緣端的計算能力也是一種強需求，我們還以前面提到的案例來說在邊緣上面同樣需要實時計算和實時預測，那么出于邊緣端硬件資源有限，現有云上實時計算產品大多是部署很重的，很難在實際的工業領域邊緣節點進行部署，邊緣端需要更輕量的、針對時序數據進行的實時計算支持。所以在邊緣端的時序數據庫同樣需要接受 支持實時計算 的 技術挑戰。

那么在分布式計算領域，我們按照計算延時角度已經有了很多的技術產品。

從計算延時以天為單位，到計算延時達到毫秒，大家熟知的產品如圖。Hadoop/Hive/Spark/Kafka/Flink等產品，但這些產品的定位都是云上硬件資源豐富的大規模分布式計算場景，那么在邊緣端的時序數據分析場景，我們需要具備怎樣的實時能力呢？邊緣的實時計算能力我們重點放到分鐘到毫秒的實時性。

在這部分的實時計算設計架構中，我們也有兩種典型的設計架構，一個是NativeStreaming的設計模式，認為批是流的特例，另一個是Micro-Batching的設計模式，認為流是批的特例。在目前的很多時序數據庫產品已經考慮對實時計算的支持，比如InfluxDB1.x版本的CQ功能，和2.x版本的Task設計。還有ApacheIoTDB正在設計的實時計算功能。當然今天下午也給大家準備了專門面向IoT領域的時序數據流計算分析產品HStreamDB的分享。

好的，到了今天最后一部分。那么，時序數據庫可以應用到哪些場景呢？我們如何才能利用技術手段，讓數據價值最大化呢？

時序數據庫可以應用到各種場景中包括前面提各種監控領域，以及前面提到的智能制造，智能生活，智能城市等場景中，那么要想這些場景中的價值最大化，我們需要考慮從采集到數據分析和數據可視化的各個環節的不同挑戰性問題。

這里想稍加強調的是云邊端的數據閉環的建立，才是數據最大化的最佳途徑。我們不僅僅是采集數據和數據的監控，數據的可視化，最大的數據業務價值需要在采集的數據上面進行數據分析，分析之后的數據再反向控制終端，達成數據閉環。

那么，不同的大廠，不同的時序數據產品在數據閉環的締造中采用的技術手段可能個各不相同。今天非常有興邀請到業界知名的時序產品負責人/大神為大家針對性的對具體時序數據庫產品進行細致分享，我們接下來把時間交給 后續的老師。

作者介紹

孫金城，51CTO社區編輯，Apache Flink PMC 成員，Apache Beam Committer，Apache IoTDB PMC 成員，ALC Beijing 成員，Apache ShenYu 導師，Apache 軟件基金會成員。關注技術領域流計算和時序數據存儲。