通用大数据架构为什么不适合处理物联网数据？

为处理日益增长的互联网数据，众多的工具开始出现，最流行的应该是 Hadoop 体系。除使用大家所熟悉的 Hadoop 组件如 HDFS，MapReduce, HBase, Hive 外，通用的大数据处理平台往往还使用 Kafka 或其他消息队列工具，Redis 或其他缓存软件，Flink 或其他实时流式数据处理软件。存储上也有人选用 MongoDB，Cassandra 或其他 NoSQL 数据库。这样一个典型的大数据处理平台基本上能很好的处理互联网行业的引用，比如典型的用户画像、舆情分析等等。

很自然，在物联网、车联网、工业互联网起来后，大家都想到的是用通用的大数据处理平台来处理它们的数据。现在市场上流行的物联网、车联网等大数据平台几乎无一例外是这类架构，这套方法证明完全工作。但这套通用方法效果如何？可以说有很多不足，主要表现在几个方面。

• 开发效率低：因为不是单一软件，需要集成至少 4 个以上模块，而且很多模块都不是标准的 POSIX 或 SQL 接口，都有自己的开发工具、开发语言、配置等等，需要一定的学习成本。而且由于数据从一个模块流动到另外一个模块，数据一致性容易受到破坏。同时，这些模块基本上都是开源软件，总会有各种 BUG，即使有技术论坛、社区的支持，一旦被一技术问题卡住，总要耗费工程师不少时间。总的来讲，需要搭建一个还不错的团队才能将这些模块顺利的组装起来，因此需要耗费较大的人力资源。
• 运行效率低：现有的这些开源软件主要是用来处理互联网上非结构化的数据，但是物联网采集的数据都是时序的、结构化的。用非结构化数据处理技术来处理结构化数据，无论是存储还是计算，消费的资源都大很多。举个例子，智能电表采集电流、电压两个量，用 HBase 或其他 KV 型数据库存储的话，其中的 Row Key 往往是智能电表的 ID，加上其他静态标签值。每个采集量的 key 由 Row Key，Column Family, Column Qualifier, 时间戳，键值类型等组成，然后紧跟具体的采集量的值。这样存储数据，overhead 很大，浪费存储空间。而且如果要做计算的话，需要将具体采集量先解析出来。比如计算一段时间电压的平均值，就需要先将电压值从 KV 的存储里解析出来，放入一个数组，然后再进行计算。解析 KV 结构的 overhead 很大，导致计算的效率大幅降低。KV 型存储的最大好处是 schemaless, 写数据前不用定义数据结构，想怎么记录就可以怎么记录，这对于几乎每天都会更新的互联网应用而言，是个很诱人的设计。但是对于物联网、车联网等应用而言，没多少引人之处，因为物联网设备产生的数据的 schema 一般是不变的，即使改变，频次很低，因为相应的配置或固件需要更新才行。
• 运维成本高：每个模块，无论是 Kafka, HBase, HDFS 还是 Redis，都有自己的管理后台，都需要单独管理。在传统的信息系统中，一个 DBA 只要学会管理 MySQL 或是 Oracle 就可以了，但现在一个DBA需要学会管理、配置、优化很多模块，工作量大了很多。而且由于模块数过多，定位一个问题变的更为复杂。比如用户发现有条采集的数据丢失，这丢失是 Kafka, HBase，Spark,还是应用程序丢失？无法迅速定位，往往需要花很长时间，找到方法将各模块的日志关联起来才能找到原因。而且模块越多，系统整体的稳定性就越低。
• 应用推出慢、利润低：由于研发效率低，运维成本高，导致产品推向市场的时间变长，让企业丧失商机。而且这些开源软件都在演化中，要同步使用最新的版本也需要耗费一定的人力。除互联网头部公司外，中小型公司在大数据平台的人力资源成本一般都远超过专业公司的产品或服务费用。
• 对于小数据量场景，私有化部署太重：在物联网、车联网场景中，因为涉及到生产经营数据的安全，很多还是采取私有化部署。而每个私有化部署，处理的数据量有很大的区别，从几百台联网设备到数千万台设备不等。对于数据量小的场景，通用的大数据解决方案就显得过于臃肿，投入产出不成正比。因此有的平台提供商往往有两套方案，一套针对大数据场景，使用通用的大数据平台，一套针对小数据规模场景，就使用 MySQL 或其他 DB 来搞定一切。但这样导致研发、维护成本提高。

通用大数据平台有上述的问题，是否有好的办法解决？那么我们需要针对物联网的场景做细致的分析。仔细研究会发现，所有机器、设备、传感器产生的数据都是时序的，而且很多还带有位置信息。这些数据具有明显的特征，1: 数据是时序的，一定带有时间戳；2：数据是结构化的；3: 数据极少有更新或删除操作；4：数据源是唯一的；5：相对互联网应用，写多读少；6：用户关注的是一段时间的趋势，而不是某一特点时间点的值；7: 数据是有保留期限的；8：数据的查询分析一定是基于时间段和地理区域的；9：除存储查询外，还往往需要各种统计和实时计算操作；10：流量平稳，可以预测；11：往往需要有插值等一些特殊的计算；12：数据量巨大，一天采集的数据就可以超过 100 亿条。

如果我们充分利用上述特征，完全可以开发出一个特殊的针对物联网场景进行优化的大数据平台。这个平台将具有如下特征，1：充分利用物联网的数据特点，在技术上做各种优化，大幅度提高数据插入、查询的性能，降低硬件或云服务成本；2：必须是水平扩展的，随着数据量的增加，只需要增加服务器扩容即可；3：必须有单一的管理后台，是易于维护的，尽量做到零管理；4：必须是开放的，有业界流行的标准 SQL 接口，提供 Python、R 或其他开发接口，方便集成各种机器学习、人工智能算法或其他应用。

涛思数据的 TDengine 就是充分利用物联网数据的 12 大特点而开发的全栈式的大数据处理引擎，具备上面所说的几大特征，有望解决通用大数据平台在处理物联网数据时的不足。按照涛思数据的设计思路，使用 TDengine,应可以大幅简化物联网大数据平台的架构，缩短研发周期，降低平台运营费用。

---

目前，TDengine 已经在 GitHub 上开源，欢迎大家下载体验，如有任何问题，都可以在 GitHub 上提出，我们有专门的研发人员进行解答。