隨(sui)著數(shu)據(ju)通訊成本(ben)(ben)的(de)(de)急劇(ju)下降，以及各種傳感技術和(he)智(zhi)能設(she)備(bei)的(de)(de)出現，從手環(huan)、共享出行(xing)(xing)、智(zhi)能電表(biao)、環(huan)境監測(ce)設(she)備(bei)到(dao)電梯、數(shu)控機(ji)(ji)床、挖掘機(ji)(ji)、工業(ye)(ye)生產線(xian)等(deng)都(dou)在源源不斷的(de)(de)產生海(hai)量的(de)(de)時(shi)間(jian)序(xu)(xu)列數(shu)據(ju)（或簡稱時(shi)序(xu)(xu)數(shu)據(ju)）并發往云端。這些(xie)海(hai)量數(shu)據(ju)是社會和(he)企業(ye)(ye)寶貴的(de)(de)財富(fu)，能夠幫助企業(ye)(ye)實時(shi)監控業(ye)(ye)務或設(she)備(bei)的(de)(de)運行(xing)(xing)情況，生成各種維度的(de)(de)報表(biao)，而且通過大(da)數(shu)據(ju)分析和(he)機(ji)(ji)器學習，對(dui)(dui)業(ye)(ye)務進行(xing)(xing)預測(ce)和(he)預警，幫助社會或企業(ye)(ye)進行(xing)(xing)科學決策、節約成本(ben)(ben)并創(chuang)造新的(de)(de)價(jia)值(zhi)。 但(dan)與(yu)現在大(da)家所(suo)熟(shu)悉的(de)(de)數(shu)據(ju)相比(bi)，時(shi)間(jian)序(xu)(xu)列數(shu)據(ju)有其(qi)顯著不同特點，本(ben)(ben)文對(dui)(dui)其(qi)特點做一分析。

• 數據是時序的，一定帶有時間戳：聯網的設備按照設定的周期，或受外部的事件觸發，源源不斷的產生數據，每一個數據點是在一時間點產生的，這個時間對于數據的計算和分析十分重要，必須要記錄。
• 數據是結構化的：網絡爬蟲的數據、微博、微信的海量數據都是非結構化的，可以是文字、圖片、視頻等。但時間序列數據往往是結構化的，而且是數值型的，比如智能電表采集的電流、電壓就可以用 4 字節的標準的浮點數來表示。
• 數據極少有更新操作：時間序列數據是機器日志數據，一般不容許而且也沒有修改的必要。很少有場景，需要對采集的原始數據進行修改。
• 數據源是唯一的：一個設備采集的數據與另外一個設備采集的數據是完全獨立的。一臺設備的數據一定是這臺設備產生的，不可能是人工或其他設備產生的，也就是說一臺設備的數據只有一個生產者，時間序列數據的數據源是唯一的。
• 相對互聯網應用，寫多讀少：對于互聯網應用，一條數據記錄，往往是一次寫，很多次讀。比如一條微博或一篇微信公共號文章，一次寫，但有可能上百萬人讀。但時間序列數據不一樣，對于產生的數據，一般是計算、分析程序自動的讀，而且計算、分析次數不多，只有分析事故等場景，人才會主動看原始數據。
• 用戶關注的是一段時間的趨勢：對于一條銀行記錄，或者一條微博、微信，對于它的用戶而言，每一條都很重要。但對于時間序列數據，每個數據點與數據點的變化并不大，一般是漸變的，大家關心的更多是一段時間，比如過去的五分鐘，過去的一個小時數據變化的趨勢，一般對某一特定時間點的數據值并不關注。
• 數據是有保留期限的：采集的數據一般都有基于時長的保留策略，比如僅僅保留一天、一周、一個月、一年甚至更長時間，為節省存儲空間，系統最好能自動刪除。
• 數據的查詢分析往往是基于時間段和某一組設備的：對于時間序列數據，做計算和分析的時候，一定是指定時間范圍的，不會只針對一個時間點或者整個歷史進行。而且往往需要根據分析的維度，對設備的一個子集采集的數據進行分析，比如某個地理區域的設備，某個型號、某個批次的設備，某個廠商的設備等。
• 除存儲查詢外，往往需要實時分析計算操作：對于大部分互聯網大數據應用，更多的是離線分析，即使有實時分析，但實時分析的要求并不高。比如用戶畫像、可以積累一定的用戶行為數據后進行，早一天晚一天畫不會怎么影響結果。但是對于物聯網應用，對時間序列數據的實時計算要求往往很高，因為需要根據計算結果進行實時報警，以避免事故的發生。
• 流量平穩、可預測：給定物聯網數量、數據采集頻次，就可以較為準確地估算出所需要的帶寬和流量，每天新生成的數據大小。而不是像電商，在“雙 11”期間，淘寶、天貓、京東等流量是幾十倍的漲幅。不像 12306 網站，春節期間，網站流量是幾十倍的增長。
• 數據處理的特殊性：與典型的互聯網相比，還有不一樣的數據處理需求。比如要檢查某個具體時間的設備采集的某個量，但傳感器實際采集的時間不是這個時間點，這時候往往需要做插值處理。還有很多場景，需要基于采集量，做復雜的數學函數計算。
• 數據量巨大：以智能電表為例，一臺智能電表每隔 15 分鐘采集一次數據，每天自動生成 96 條記錄，全國就有接近 5 億臺智能電表，每天光智能電表就生成近 500 億條記錄。一臺聯網的汽車每隔 10 到 15 秒就采集一次數據發到云端，一臺車一天就很容易產生 1000 條記錄。如果中國 2 億輛車全部聯網，每天將產生 2000 億條記錄。五年之內，物聯網設備產生的數據將占世界數據總量的 90% 以上。

物(wu)聯(lian)網(wang)、工業互聯(lian)網(wang)的(de)(de)(de)數(shu)(shu)(shu)(shu)據(ju)(ju)是流式(shi)數(shu)(shu)(shu)(shu)據(ju)(ju)，像視頻流，而且單個數(shu)(shu)(shu)(shu)據(ju)(ju)點(dian)的(de)(de)(de)價(jia)值(zhi)很低(di)，甚至丟失一小段時(shi)間(jian)的(de)(de)(de)數(shu)(shu)(shu)(shu)據(ju)(ju)也不(bu)影響分(fen)析(xi)的(de)(de)(de)結論，也不(bu)影響系(xi)統的(de)(de)(de)正(zheng)常運行(xing)。但看似(si)簡單的(de)(de)(de)事情，由于數(shu)(shu)(shu)(shu)據(ju)(ju)記錄條數(shu)(shu)(shu)(shu)巨大，導(dao)致數(shu)(shu)(shu)(shu)據(ju)(ju)的(de)(de)(de)實時(shi)寫入成為(wei)(wei)瓶頸，查詢分(fen)析(xi)極為(wei)(wei) 緩慢，成為(wei)(wei)新的(de)(de)(de)技(ji)術挑戰。傳(chuan)統的(de)(de)(de)關系(xi)型數(shu)(shu)(shu)(shu)據(ju)(ju)庫、NoSQL 數(shu)(shu)(shu)(shu)據(ju)(ju)庫以及(ji)流式(shi)計算(suan)引擎(qing)由于沒(mei)有充(chong)分(fen)利用時(shi)間(jian)序列數(shu)(shu)(shu)(shu)據(ju)(ju)的(de)(de)(de)特點(dian)，性能(neng)提升極為(wei)(wei)有限(xian)，只能(neng)依(yi)靠集群技(ji)術，投入更多的(de)(de)(de)計算(suan)資源和(he)存儲(chu)資源來處理，系(xi)統的(de)(de)(de)運營(ying)維護成本急劇上升。

面對這一高(gao)速增長的(de)(de)(de)物聯網(wang)(wang)數據(ju)市(shi)場，近幾(ji)年出(chu)現一批(pi)專(zhuan)注時(shi)間(jian)序列數據(ju)處理的(de)(de)(de)公(gong)司，比如美國的(de)(de)(de)InfluxData，其(qi)產(chan)品InfluxDB在(zai)IT運維(wei)監測(ce)方面有相當的(de)(de)(de)市(shi)場占有率。在(zai)工業控制領(ling)(ling)域(yu)(yu)老牌實時(shi)數據(ju)庫(ku)公(gong)司OSIsoft在(zai)2017年5月獲(huo)得(de)軟銀12億美元(yuan)的(de)(de)(de)投資(zi)，期望成(cheng)為(wei)新興的(de)(de)(de)物聯網(wang)(wang)領(ling)(ling)域(yu)(yu)的(de)(de)(de)數據(ju)庫(ku)的(de)(de)(de)領(ling)(ling)頭(tou)羊。開源社區也(ye)十分活躍，比如基于(yu)HBase開發的(de)(de)(de)OpenTSDB。中國國內，阿里、百度、華為(wei)都有基于(yu)OpenTSDB的(de)(de)(de)產(chan)品。

TDengine 是一款高性能、分布式、支持 SQL 的時序數據庫（Time Series Database，TSDB），其(qi)時序數據庫核心代(dai)碼包括集群功能(neng)(neng)全部(bu)開源，同(tong)時 TDengine 還帶有內(nei)建(jian)的緩存(cun)、流式(shi)計算、數據訂閱等系統功能(neng)(neng)，能(neng)(neng)大幅減少研發和運(yun)維的復(fu)雜度，可廣泛應用于(yu)物(wu)聯網、車聯網、工業互聯網、IT 運(yun)維、金(jin)融等領域。