TDengine是怎么解决物联网大数据处理问题的

物联网平台里模块很多，但其中很重要的一块就是数据处理，包括采集、存储、查询、分析和计算，是整个物联网行业里面比较共性的部分，个性化程度不高。

再仔细一看，大部分物联网平台，尤其是国内的，几乎无一例外的用的是Hadoop生态搭建的，用的是互联网行业流行的大数据架构。

采集进来的数据先进Kafka, 然后分流进HBase/Cassandra/MongoDB等做持久化存储，进Redis做缓存。

进Spark/Flink等做流式计算，后面再接应用、大屏展示等等。

了解这些通用的大数据框架后，TDengine的第一反应就是，Hadoop这套体系太重，至少对于物联网大数据而言如此。

搭建一个平台，居然要好多款开源软件拼接在一起，研发、运维效率会很低，数据一致性很难保证，定位一个问题牵涉的环节太多，很不适合私有化部署。

将各种物联网场景抽象出来，TDengine总结出了物联网数据的十三大特点：

1.数据是时序的，一定带有时间戳；

2.数据是结构化的；

3.数据极少有更新或删除操作；

4.数据源是唯一的；

5.相对互联网应用，写多读少；

7.用户关注的是一段时间的趋势，而不是某一特点时间点的值；

8.数据是有保留期限的；

9.数据的查询分析一定是基于时间段和地理区域的；

10.除存储查询外，还往往需要各种统计和实时计算操作；

11.流量平稳，可以预测；

12.往往需要有插值等一些特殊的计算；

13.数据量巨大，一天采集的数据就可以超过100亿条。

总结出这些特点后，一下豁然开朗，觉得采用Hadoop这些开源软件来处理物联网数据完全是大错特错。

物联网数据像日志数据，几乎没有更新操作的可能，那数据库中的事务处理的实现就完全多余；

数据是时序的，时间戳自然可以作为主键，根本不需要复杂的索引结构；

物联网数据是结构化的，像HBase、Cassandra那样用Key-Value来存储，计算效率和存储效率大打折扣，应该采用结构化存储才行；

物联网数据的冷热程度是时间决定的，刚采集的数据是最热的，而不是用户点击决定。因此用简单的先进先出的内存管理就能很好的实现高效的缓存，根本就不需要Redis；

物联网数据从一个设备来看，就是一个数据流，实现滑动窗口的流计算那不是一个最顺其自然的事情，哪用得上Spark这么复杂的引擎；

对于数据分区，简单的按设备分区按时间段分区，就轻松解决，根本就不需要复杂的分区机制；

物联网数据流是相对平稳的，而且物联网设备本身一定有缓存能力，完全可以抛弃Kafka这些套件，实现一个简单的消息队列和数据订阅来满足需求。

随后又发现有时序数据库，马上看他们文档和代码，发现他们利用了时序数据一些特点，但还是没有充分利用，而且只是定位为一个数据库。

后面又了解到工业界有实时数据库，发现这些实时数据库都是老古董产品了，基本上都还是Windows上研发，价格贵，而且没有标准SQL，水平扩展几乎没有，大数据分析能力几乎没有，完全没有能力应对日益增长的大数据量和大数据分析需求，迟早会被淘汰。

一个分布式高可靠、持久化存储的消息队列，每台手机需要推送的消息就放在一个队列里。消息队列与物联网的时序数据有区别吗？本质上没有。

一个是非结构化的，一个是结构化的；

一个是简单的进和出，但另外一个是需要有分析和计算的；

两者在系统的架构设计上没有大的不同。

因此TDengine迅速定位了自己要做的产品，那就是物联网大数据平台，要把时序数据库、缓存、消息订阅、流式计算等系列功能融合在一起，一站式的解决物联网大数据问题，这样才能将系统研发、维护的复杂度与成本大幅降低。

追求简单极致的习惯，TDengine马上又定下采用SQL接口，能通过JDBC接口与众多第三方工具无缝集成，安装部署要一键搞定的策略，目的是要让开发者用起来轻松，完全没有学习成本。

研究物联网数据的特点后，TDengine想到了两个技术创新点，

一是“一台设备一张表”的数据模型来极大提高单台设备的数据插入和查询效率,  

二是给每张表打静态标签，将静态标签数据与采集的动态数据完全分开存储，来解决多表聚合查询问题。