演講的主題是 時序數(shù)據(jù)庫現(xiàn)狀及核心技術/問題，因為技術都是為解決具體問題生的。

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

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

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

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

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

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

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

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

從我的角度看，聊存儲，我喜歡從數(shù)據(jù)的角度切入。。

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

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

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

全球數(shù)據(jù)領域?qū)?019年的45ZB增長到2025年的175ZB，全球數(shù)據(jù)的近30%將需要實時處理，您的企業(yè)是否已經(jīng)做好準備？同樣帶著這個問題，我們看看實時數(shù)據(jù)庫領域是否做好了準備？

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

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

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

那么這些數(shù)據(jù)來源，有哪些是我們?nèi)粘９ぷ魃羁梢愿兄降哪兀课覀兘酉聛砗唵闻e例分析一下：

?

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

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

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

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

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

2021強調(diào)的分布式云就是強調(diào)了物聯(lián)網(wǎng)領域已經(jīng)走進云邊端一體化的進程，分布式云將取代私有云。分布式云的架構(gòu)更強調(diào)了中心云計算能力下沉的時代趨勢。

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

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

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

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

根據(jù)DB-Engines的統(tǒng)計數(shù)據(jù)，我們發(fā)現(xiàn)，在各種數(shù)據(jù)庫存儲產(chǎn)品中，時序數(shù)據(jù)庫的發(fā)展是最受歡迎，發(fā)展是最快的。

也就是說，5G和工業(yè)4.0的發(fā)展，大量時序數(shù)據(jù)的產(chǎn)生，促就了時序數(shù)據(jù)庫的快速發(fā)展。那么，目前都有哪些時序數(shù)據(jù)庫產(chǎn)品呢？

同樣這個統(tǒng)計也是來自DB-engines網(wǎng)站，目前我們已經(jīng)有幾十種時序數(shù)據(jù)庫產(chǎn)品，這些產(chǎn)品有些是開源的，有些是各個大廠研發(fā)的商業(yè)產(chǎn)品。

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

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

首先，我們從存儲架構(gòu)角度，看看時序數(shù)據(jù)庫的分類情況。

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

當然持久化角度看，還有很多優(yōu)秀的內(nèi)存時序數(shù)據(jù)庫，比如：Google的Monarch,Facebook基于Gorilla論文實現(xiàn)的產(chǎn)品。那么不論基于怎樣的架構(gòu)，這些時序數(shù)據(jù)庫都要解決的共性問題有是什么呢？

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

同時，時序數(shù)據(jù)領域還有一個很大的領域特點，或者說是領域問題，那就是弱網(wǎng)環(huán)境下，時序數(shù)據(jù)的亂序是一種常態(tài)。

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)不斷的到來，數(shù)據(jù)的節(jié)點不斷的變化，磁盤持久化也不斷發(fā)生。

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

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

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

所以基于LSM Tree結(jié)構(gòu)完美的解決了寫入的高吞吐問題。

那么，解決的寫入問題，基于LSM-Tree的時序數(shù)據(jù)庫產(chǎn)品是如何解決

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

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

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

雖然都是基于LSM-Tree的設計，但不同的產(chǎn)品有不同的優(yōu)化定制，

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

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

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

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

IoTDB為了提高查詢速度，不僅定制了 索引結(jié)構(gòu)還增加了查詢優(yōu)化器的支持。

更值得大家關注的是，IoTDB針對工業(yè)物聯(lián)網(wǎng)領域時序數(shù)據(jù)亂序問題對LSM-Tree

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

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

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

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

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

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

那么在分布式計算領域，我們按照計算延時角度已經(jīng)有了很多的技術產(chǎn)品。

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

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

好的，到了今天最后一部分。那么，時序數(shù)據(jù)庫可以應用到哪些場景呢？我們?nèi)绾尾拍芾眉夹g手段，讓數(shù)據(jù)價值最大化呢？

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

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

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

作者介紹

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