為處理日益增長的互聯(lián)網(wǎng)數(shù)據(jù)，眾多的工具開始出現(xiàn)，最流行的應(yīng)該是Hadoop體系。除使用大家所熟悉的Hadoop組件如HDFS、MapReduce、HBase和Hive外，通用的大數(shù)據(jù)處理平臺往往還使用Kafka或其他消息隊列工具，Redis或其他緩存軟件，F(xiàn)link或其他實時流式數(shù)據(jù)處理軟件。存儲上也有人選用MongoDB，Cassandra或其他NoSQL數(shù)據(jù)庫。這樣一個典型的大數(shù)據(jù)處理平臺基本上能很好的處理互聯(lián)網(wǎng)行業(yè)的引用，比如典型的用戶畫像、輿情分析等等。

很自然，在物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)起來后，大家都想到的是用通用的大數(shù)據(jù)處理平臺來處理它們的數(shù)據(jù)?，F(xiàn)在市場上流行的物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等大數(shù)據(jù)平臺幾乎無一例外是這類架構(gòu)，這套方法證明完全工作。但這套通用方法效果如何？可以說有很多不足，主要表現(xiàn)在幾個方面。

• 開發(fā)效率低：因為不是單一軟件，需要集成至少4個以上模塊，而且很多模塊都不是標準的POSIX或SQL接口，都有自己的開發(fā)工具、開發(fā)語言、配置等等，需要一定的學(xué)習(xí)成本。而且由于數(shù)據(jù)從一個模塊流動到另外一個模塊，數(shù)據(jù)一致性容易受到破壞。同時，這些模塊基本上都是開源軟件，總會有各種BUG，即使有技術(shù)論壇、社區(qū)的支持，一旦被一技術(shù)問題卡住，總要耗費工程師不少時間?？偟膩碇v，需要搭建一個還不錯的團隊才能將這些模塊順利的組裝起來，因此需要耗費較大的人力資源。
• 運行效率低：現(xiàn)有的這些開源軟件主要是用來處理互聯(lián)網(wǎng)上非結(jié)構(gòu)化的數(shù)據(jù)，但是物聯(lián)網(wǎng)采集的數(shù)據(jù)都是時序的、結(jié)構(gòu)化的。用非結(jié)構(gòu)化數(shù)據(jù)處理技術(shù)來處理結(jié)構(gòu)化數(shù)據(jù)，無論是存儲還是計算，消費的資源都大很多。舉個例子，智能電表采集電流、電壓兩個量，用HBase或其他KV型數(shù)據(jù)庫存儲的話，其中的Row Key往往是智能電表的ID，加上其他靜態(tài)標簽值。每個采集量的key由Row Key，Column Family, Column Qualifier, 時間戳，鍵值類型等組成，然后緊跟具體的采集量的值。這樣存儲數(shù)據(jù)，overhead很大，浪費存儲空間。而且如果要做計算的話，需要將具體采集量先解析出來。比如計算一段時間電壓的平均值，就需要先將電壓值從KV的存儲里解析出來，放入一個數(shù)組，然后再進行計算。解析KV結(jié)構(gòu)的overhead很大，導(dǎo)致計算的效率大幅降低。KV型存儲的最大好處是schemaless, 寫數(shù)據(jù)前不用定義數(shù)據(jù)結(jié)構(gòu)，想怎么記錄就可以怎么記錄，這對于幾乎每天都會更新的互聯(lián)網(wǎng)應(yīng)用而言，是個很誘人的設(shè)計。但是對于物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等應(yīng)用而言，沒多少引人之處，因為物聯(lián)網(wǎng)設(shè)備產(chǎn)生的數(shù)據(jù)的schema一般是不變的，即使改變，頻次很低，因為相應(yīng)的配置或固件需要更新才行。
• 運維成本高：每個模塊，無論是Kafka, HBase, HDFS還是Redis，都有自己的管理后臺，都需要單獨管理。在傳統(tǒng)的信息系統(tǒng)中，一個DBA只要學(xué)會管理MySQL或是Oracle就可以了，但現(xiàn)在一個DBA需要學(xué)會管理、配置、優(yōu)化很多模塊，工作量大了很多。而且由于模塊數(shù)過多，定位一個問題變的更為復(fù)雜。比如用戶發(fā)現(xiàn)有條采集的數(shù)據(jù)丟失，這丟失是Kafka、HBase、Spark，還是應(yīng)用程序丟失？無法迅速定位，往往需要花很長時間，找到方法將各模塊的日志關(guān)聯(lián)起來才能找到原因。而且模塊越多，系統(tǒng)整體的穩(wěn)定性就越低。
• 應(yīng)用推出慢、利潤低：由于研發(fā)效率低，運維成本高，導(dǎo)致產(chǎn)品推向市場的時間變長，讓企業(yè)喪失商機。而且這些開源軟件都在演化中，要同步使用最新的版本也需要耗費一定的人力。除互聯(lián)網(wǎng)頭部公司外，中小型公司在大數(shù)據(jù)平臺的人力資源成本一般都遠超過專業(yè)公司的產(chǎn)品或服務(wù)費用。
• 對于小數(shù)據(jù)量場景，私有化部署太重：在物聯(lián)網(wǎng)、車聯(lián)網(wǎng)場景中，因為涉及到生產(chǎn)經(jīng)營數(shù)據(jù)的安全，很多還是采取私有化部署。而每個私有化部署，處理的數(shù)據(jù)量有很大的區(qū)別，從幾百臺聯(lián)網(wǎng)設(shè)備到數(shù)千萬臺設(shè)備不等。對于數(shù)據(jù)量小的場景，通用的大數(shù)據(jù)解決方案就顯得過于臃腫，投入產(chǎn)出不成正比。因此有的平臺提供商往往有兩套方案，一套針對大數(shù)據(jù)場景，使用通用的大數(shù)據(jù)平臺，一套針對小數(shù)據(jù)規(guī)模場景，就使用MySQL或其他DB來搞定一切。但這樣導(dǎo)致研發(fā)、維護成本提高。

通用大數(shù)據(jù)平臺有上述的問題，是否有好的辦法解決？那么我們需要針對物聯(lián)網(wǎng)的場景做細致的分析。仔細研究會發(fā)現(xiàn)，所有機器、設(shè)備、傳感器產(chǎn)生的數(shù)據(jù)都是時序的，而且很多還帶有位置信息。這些數(shù)據(jù)具有明顯的特征，1: 數(shù)據(jù)是時序的，一定帶有時間戳；2：數(shù)據(jù)是結(jié)構(gòu)化的；3: 數(shù)據(jù)極少有更新或刪除操作；4：數(shù)據(jù)源是唯一的；5：相對互聯(lián)網(wǎng)應(yīng)用，寫多讀少；6：用戶關(guān)注的是一段時間的趨勢，而不是某一特定時間點的值；7: 數(shù)據(jù)是有保留期限的；8：數(shù)據(jù)的查詢分析一定是基于時間段和地理區(qū)域的；9：除存儲查詢外，還往往需要各種統(tǒng)計和實時計算操作；10：流量平穩(wěn)，可以預(yù)測；11：往往需要有插值等一些特殊的計算；12：數(shù)據(jù)量巨大，一天采集的數(shù)據(jù)就可以超過100億條。

如果我們充分利用上述特征，完全可以開發(fā)出一個特殊的針對物聯(lián)網(wǎng)場景進行優(yōu)化的大數(shù)據(jù)平臺。這個平臺將具有如下特征，1：充分利用物聯(lián)網(wǎng)的數(shù)據(jù)特點，在技術(shù)上做各種優(yōu)化，大幅度提高數(shù)據(jù)插入、查詢的性能，降低硬件或云服務(wù)成本；2：必須是水平擴展的，隨著數(shù)據(jù)量的增加，只需要增加服務(wù)器擴容即可；3：必須有單一的管理后臺，是易于維護的，盡量做到零管理；4：必須是開放的，有業(yè)界流行的標準SQL接口，提供Python、R或其他開發(fā)接口，方便集成各種機器學(xué)習(xí)、人工智能算法或其他應(yīng)用。

濤思數(shù)據(jù)的TDengine Database就是充分利用物聯(lián)網(wǎng)數(shù)據(jù)的12大特點而開發(fā)的全棧式的大數(shù)據(jù)處理引擎，具備上面所說的幾大特征，有望解決通用大數(shù)據(jù)平臺在處理物聯(lián)網(wǎng)數(shù)據(jù)時的不足。按照濤思數(shù)據(jù)的設(shè)計思路，使用TDengine Database，應(yīng)可以大幅簡化物聯(lián)網(wǎng)大數(shù)據(jù)平臺的架構(gòu)，縮短研發(fā)周期，降低平臺運營費用。