Hadoop or TDengine，如何做物联网大数据平台的选型？

淡淡的烟草味﹌ 2022-09-04 06:41 258阅读 0赞

*  [Hadoop or TDengine，如何做物联网大数据平台的选型？][Hadoop or TDengine]

# 1. 大数据时代 #

![图片][b4bb7b70ca8760b50130ceb5d56f5ef5.png]

大数据时代，大家都在说什么叫大数据，强调的就是一个“大”字，人们期望对海量数据的挖掘和运用能够获取到更多有价值的东西。其来源包括：微信聊天数据，淘宝&京东等电商数据，高速收费站的数据，摩拜等共享单车产生的数据，股票交易数据，天文望远镜产生的数据等等，这些数据有的是物联网的数据，有的是时序数据，有的不是时序数据，比如微信和淘宝、京东等产生的数据就不在本次讨论范围内。

物联网的数据可以分为两类，静态数据和动态数据：

*  静态数据：通常为标签类数据，如：设备所在的地址、编号、颜色等等，这些数据不会随着设备产生新数据的过程中而发生变化。
 *  动态数据：以时间序列为基础的数据，其特点是和时间有一一对应的关系，可以按照时间顺序记录的数据列，并且这种关系在数据处理中尤为重要。充分利用这样的关系，才能把数据库做好。现在越来越多的公司意识到处理这样的时序数据应该用专门的数据库，当然，也还有相当一部分的公司仍然用Hadoop来处理，在此基础上做分析和改造，这样成本就会相对较高。

物联网大数据主要体现在采集的机器数目越来越多，频次越来越高，如：电网以前可能只采集500KV的数据，慢慢可能采集10KV的数据，最后入户的220V的数据可能都要采集。随着这种2维方式的增长，采集的数据成几何量的增加，因此，传统的方法带来越来越多的挑战。

# 2. 物联网、工业4.0的技术链 #

![图片][ccd61cc88b2a96972492b1404eac4096.png]

对物联网、工业4.0的数据进行分析，会经过如下4个步骤：

*  数据采集：通常通过传感器采集。
 *  边缘计算：通过通讯模组传输数据。
 *  存储·查询·计算：将传输的数据输入云数据引擎进行存储。
 *  系统：最后将处理好的数据接入大屏、app、web界面应用等系统。

物联网的数据平台主要集中在边缘计算和云数据引擎：

*  边缘计算。有些场景需要用到边缘计算，有的则不需要。边缘计算（或前置机模块），主要负责采集工业上的协议（因为，传感器采集的数据，通常是不规整的），同时可以在边缘计算上做降采样，把一些频率高的数据放在边缘计算部分。
 *  云数据引擎。这块是本次分享的重点，后面会详细介绍。

# ——物联网大数据选型—— #

## 1. 传统的实时数据库 ##

![图片][14ca56db9c4feff8721555484a5e99c1.png]

在物联网概念出现之前，设备数据的采集和分析也是非常重要的功能需求。为了解决流程控制领域的实时数据处理问题，从上世纪八十年代起，出现了一批实时数据库，以美国的OSISoft PI为代表，具有较高的数据处理能力，能够很好的解决传统工业生产问题。当时和实时数据库相结合的组态软件流行了很长一段时间，主要强调工控领域的实时数据采集、监视或者控制，其实现思路并不复杂，本质上是内存库，卖点在于实时响应和实时控制。这里实时控制是非常重要的，因为工控就是在强调控制，通过过来的参数，如温度高的、电流大的，能够把这些信息反馈回去，重点在于快速，能够在1s之内响应。也因为这个特点，这种实时库只能存储当前所有采集量的截面，相当于一个时间片，有些好的产品可以存储多个截面，但也比较有限，可能只能存储5分钟内的数据。

## 2. 传统的实时数据库面临的挑战 ##

![图片][c3427a9b6433dd69341333f9f1d7e4c5.png]

这样的数据处理方式是物联网吗？答案是肯定的，因为物联网的基本概念是物体和物体相联。但这只是物联网的初级阶段，解决数据采集从无到有，包括数据的实时上数和告警的问题，随着测点数暴涨，数据采集频次不断提高，传统实时数据库暴露出下列问题：

*  水平扩展：没有水平扩展的能力，数据量增加，只能依靠硬件scale up（增加单个硬件性能，如把16G内存的机器换成256G内存的，但是这样的扩展能力还是有限的）。所以水平扩展，在选型过程中如果解决，也是一个重要的问题。
 *  技术架构：技术架构陈旧，使用磁盘阵列（价格比较昂贵），还运行在Windows环境下。
 *  数据分析：数据分析能力偏弱（还需要历史数据，否则只能根据当前数据进行分析，看看有没有超过阈值，或发出报警，这其实不能算作数据分析），不支持现在流行的各种大数据分析接口。
 *  云服务：不支持云端部署，更无法支持PaaS。

现在做物联网，在实时数据的基础上，还要进行扩充，做历史数据。通过历史的查询，归类的统计，或者机器学习的方法把历史数据增值，获得两类信息：

1.  整体情况的统计，如有10W个设备，统计这10W个设备的总体情况，也就是常说的报表。
2.  单个设备的分析，如有一台设备经常坏，为什么经常坏呢？我们可以看下这台设备采集的数据是什么样的，是不是电流经常发生突变等信息。通过对单个设备进行分析，把这块的数据模式收集起来，扩展到其它设备中，能够提高整个系统运维的安全性。同时，把单个设备进一步扩展，扩展到每个人用的手机或者手环等，能把这些大数据做好，那么我们除了To B业务外，也能在To C业务上给公司产生增值。

如果不需要历史数据，可以只做redis，因为只看当前数据，redis会比一些实时数据库的架构稳定性更好。

## 3.通用的互联网大数据解决方案 ##

![图片][d0ec030987e89f53a4fe408dee130d49.png]

目前的Hadoop方案，是一些大型的互联网企业最先使用的。在处理大数据时，将多个开源软件，如现在比较流行的kafka，然后把实时数据引入到redis，把历史数据存到Hadoop，中间可能结合Spark和Flink的计算，利用集群来处理海量数据。这是一种非常好的，通用的处理大数据的解决方案，可以处理百亿、千亿、甚至万亿级别的数据，只需保证它的服务器足够。如果有特殊需求，可以写一些代码来实现，比如做实时监控，就可以在kafka后面挂一个Flink做实时分析，做实时的流计算，把当前的QBS、健康状态做实时统计；在比如看历史数据，可以在Hadoop上挂一个MapReduce，这样我们可以通过写程序把所有的需求都实现。

那么对于物联网，为什么不用这一套解决方案来做呢？是不是不需要做物联网大数据平台的选型呢？答案显然是否定的。

## 4. 通用互联网方案面临的挑战 ##

![图片][5df370e4da94e7d50c49f31600f875c0.png]

对于一些规模较小的公司，做软件开发所关注的点，Hadoop系统并没有很好的解决，因为它比较低效，也比较复杂，成本比较高。逐一分析下：

1.  开发效率低：因牵涉到多种系统，每种系统有自己的开发语言和工具，开发精力花在了系统联调上，而且数据的一致性难以保证。如果你的公司从头开始做这件事，投入成本更大。
2.  开发成本高：这套架构需要的开发人员，市场比较稀缺，可以把这套系统搭建起来的比较有经验的研发经理，年薪没有50W是找不到的，一般的开发人员也比较难找，如果从新培养，但是待遇低的话，也很难留住人才。
3.  运维复杂：每个系统都有自己的运维后台，带来更高的运维代价，出问题后难以跟踪解决，系统的不稳定性大幅上升。
4.  运行效率差：非结构化数据技术来处理结构化数据，整体性能不够，系统资源消耗大。因为多套系统，数据需要在各系统之间传输，造成额外的运行代价。
5.  应用推向市场慢：集成复杂，得不到专业服务，项目实施周期长，导致人力攀升，利润缩水。

综上所述，该如何解决这些问题，如果你的公司做这样的项目能够投入的人比较少，不足10人，那么投入的硬件可能就是10个服务器，在这样的规模内，用Hadoop显然是不合适的，否则1~2年也不会做出好的产品。

另外，在国内人力成本越来越高的情况下，很多的公司都期望能够选择一个数据库。不光解决各种效率问题，更重要的是出了问题能够及时有人处理，比如用俄罗斯的ClickHouse或者美国的InfluxDB，如果出现问题，花钱也很难找到人维护，所以国家搞国产化，也有这样的因素在里面。

## 5. 物联网、工业4.0数据特征：时序空间数据 ##

![图片][dae7c7935e22a4284b6d839e08279bd1.png]

那么对于物联网大数据平台，什么样的选型方案才是专业的、正确的？我们首先要对网联网数据的模式进行分析，总结物联网数据的特征，并加以充分利用，这样我们选择的数据库才是一个真正能够利用软硬件资源，发挥最大效用的网联网数据库。大家在做自己的app时也要考虑你的数据是否满足这样的特征，是否适合用时序数据库来做。其典型特征有：

1.  所有采集的数据都是时序的。在数据索引的基础上，把内存块、磁盘文件按照这样的时序的假设进行拆分，就不需要再做额外的索引，来节约时间，提升效率。
2.  数据都是结构化的。计算机的编程语言更擅长处理结构化的数据，比如一个Json格式的数据过来，虽然有很多的库直接就把它解析掉了，形成我们需要的数据，但是这个过程也是比较耗时的，因为传入的时候需要进行正向的序列化，传出的时候需要进行反向的序列化，这俩次的序列化会产生很大的CPU消耗。并且结构化的数据，可以采用列式存储，虽然物联网的数据量比较大，但是变化通常都比较有规律，如果采用行式存储，压缩比率不会太高，如果采用列式存储，如001100这种数据，我们只需要记住0出现几次，1出现几次，而不需要把所有的数据都记录下来。因此，不是列式存储的数据，建议大家都不要选用。
3.  一个采集点的数据源是唯一。因为时序数据最重要的特点就是每台机器产生的数据跟其它机器产生的数据在逻辑上一定是分离的，因此，可以按照分离的操作进行分表，Prometheus（普罗米修斯）和涛思数据库都是这样做的，逻辑上进行分离之后，就不需要把大量的数据混合在一起进行查询，大大提高了查询效率。
4.  数据很少有更新或删除操作。可以在数据写入磁盘的时候进行优化，当数据量增大的时候（几十上百M/s的写入速度），能够达到单块磁盘极限的量，这时，一定要减小落盘后的修改，否则在修改的时候，某些数据是没有办法写入磁盘的，这时系统整体的吞吐量是不够的。
5.  数据一般是按到期日期来删除的。在选型初期，很多公司不太注意压缩比，运行一段时间之后，数据越来越大，就不得不考虑数据的保存时长，如何快速的删除过期数据，这是需要考虑的问题。
6.  数据以写操作为主，读操作为辅。在设计过程中要有一个优先级，需要优先满足写的操作。
7.  数据流量平稳，可以较为准确的计算。有些互联网公司可能双十一的时候数据流量非常大，平时数据量相对较小，那么就不太容易估算机器的容量。
8.  数据都有统计、聚合等实时计算操作。这些操作可以在数据库中进行预先计算，可以在数据库内部做，也可以在接收的时候将数据库的结果保存在一些关键步骤，这也是之前Hadoop等数据库通用的方法。
9.  数据一定是指定时间段和指定区域查找的。可以把查询遍历的磁盘缩小到非常小的一部分，这是提升数据库速度的一个关键。
10. 数据量巨大，一天的数据量就超过100亿条。数据库能不能支撑分离存储，新的、热的数据放在SSD中，老的数据放在HD上，或者其它更老的数据放在网络存储中。

这就是物联网大数据平台在选型中需要注意的问题。

# ——实际应用场景分析—— #

接下来通过分析一些系统的现状，来看看出现了哪些问题：

## 1. 某智能园区配电监控系统 ##

![图片][d300745b08c33716b2f0fc73c545f319.png]

这是某智能园区配电监控系统，采用的还是10年前的架构，实时数据库是这个架构的最核心部分，数据从采集设备过来之后，经过数据采集服务器（前置机）进入到实时数据库和历史数据库中（实时数据库以内存库为基础，随着技术的进步，也进行了扩展，开发了历史数据库，并且把数据分为三层，分别为热层、稳层和冷层。热层是指数据在内存中，稳层是指数据在硬盘中，冷层是指对硬盘中的文件进行了压缩或者二次归档。这种冷温热层的区分，已经和现在的时序数据库系统比较接近了，但是使用上并不是很方便。），采集的数据通过采集服务器进入到了内存库进行了实时计算，同时历史数据采用Oracle进行存储，并且这种方式也采用了行转列的方式，在时间维度上对数据进行拆分，按天分表，5分钟一条历史数据，每表288字段。

这个系统的卖点在于实时数据处理，包括告警、失电设备分析、故障快速恢复方案，可以通过大屏展示一些数据指标。

其问题在于：

1.  历史数据分析较少
2.  难以升级改造，提高数据采集频率和性能需要推翻重做

这时可以采用InfluxDB或者TDengine时序数据库替换实时数据库和历史数据库，不过InfluxDB达到同样的效果，可能会需要比较高的硬件成本，这也是需要考虑的因素。

## 2. 某车联网数据仓库 ##

![图片][a72b0cd80434a075b947e7f2e82bea6c.png]

第二个是某车联网数据仓库，采用的是Hadoop系统的解决方案：

*  记录了百万级别车的历史数据，分钟级别的采集频率
 *  每天数据增量在2TB左右，需要保存10年
 *  作为数据仓库，无实时查询要求
 *  历史查询仅仅在发生事故时使用

存在的问题：

*  采用百台级别的硬件服务器，硬件扩容成本和软件维护成本很大
 *  因为存储在Hadoop系统中的数据采用的是lzo的压缩格式，综合压缩比只能达到45%
 *  有强烈的改造需求，希望提供一些增值服务，比如每台车的车主想要查看自己车辆的信息，都去过哪些地方，停留了多久等，这时对系统的查询需求就会比较大，但是Hadoop是没法做到实时查询的，做到10s级别的查询都非常困难。随着记录的车辆越来越多，国家要求更多的车辆的数据要保存的车联网中，那可能就不是百万级别的车，可能300W、500W甚至更多，服务器就得相应增加到300台或者500台，虽然能够处理，但是盈利空间并不是很大，没有动力来支持做这样的扩容。

这时，我们就建议更换它的数据库，这里比较适合的有：TDengine、ClickHouse，ClickHouse适合做一些数据仓库，但是实时写入的能力相对差一些，TDengine在实时查询上会更好，压缩比可以做到更高，当时测试的时候，压缩比可以做到4%，比原来提升了10倍。

## 3. 某大型机械制造商的设备管理系统 ##

![图片][7c175d577111982569e1b23711e131b1.png]

第三个是大型机械制造商提供给客户的设备管理系统，每套设大概卖到50万或者100万，已经销售了几十万级别的设备。数据进来之后，首先进入kafka中，通过kafka将实时的压力分摊出去，实时数据会进入redis中，通过统计进入关系库中，然后给到App做最新状态的显示，历史输入会进入Cassendra中，Cassendra的特点是写入速度非常快，但是查询非常耗时。这样的系统其实是需要更新的，但是动力并不高，因为它还是能基本满足用户的需求，这时就需要挖掘出用户新的需求，提供增值服务。

从这个例子和上一个例子我们可以看到，如果只是偶尔的查询，一般的数据库都能满足要求。但是物联网不只是物体和物体的联接，还包括用户和物体的交互，不止能够看报表，还要能够走到C端的用户中，这时物联网平台才能有影响力，才能产生更多的增值服务。所以当我们的客户不再是公司、管理人员、运维人员，而是真正的用户，那这套系统将非常具有价值。在这种需求下，如何去选型是我们需要考虑，也就是谁的实时数据处理的好，谁的历史数据处理的好，能够满足这样的需求。

## 4. 某智能工厂的高频数据采集系统 ##

![图片][da54bfdf86321e48d3d4805eaf716adf.png]

这是某智能工厂的高频数据采集系统：

*  采集设备100，采集点7000
 *  采集频率5s，但是历史数据只能存储60s

目前的诉求：

现在希望将采集频率提升到20ms，每秒数据量达到50hz*7000*16B=5.6MB，并且采集规模扩大到所有产品线，以期更好的提高生产效能。

这里可以采用TDengine和Prometheus，它们各有优缺点，大家可以在选型的时候考虑下。

## 5. 某电动车制造商的车辆实时检测系统 ##

![图片][de105349829173c6803d3b401797b13f.png]

最后一个案例是某电动车制造商的车辆实时检测系统，目标比较火，是面向终端用户的。用户在购买电动车之后可以选择是否购买车辆实时检测系统，实际就是在车辆上安装这样的采集盒，定期的将车辆的轨迹、电池等参数上传到云端，成批次的写入MySQL数据库，之后车主就可以随时查询车辆的轨迹。这套系统，在最初是非常OK的，但是随着车辆的增加达到1000辆时，写入压力就非常大了，CPU占有率非常高，导致没有办法处理实时查询的请求，最终只能降低入库的频率，但这样大大降低了用户体验。

这时它需要：

*  提高实时的写入能力
 *  写入的数据可以快速查询
 *  可以水平和动态的扩容

明确了这样的业务需求之后，它做了技术选项，当时竞争的数据库也比较多，最终选择了TDengine，说明TDengine在这样的业务需求下，是非常出色的。

# ——时序数据库选型问题总结—— #

![图片][3fffc94a5e19dab7aea63d4b5435a8d3.png]

最后，总结下时序数据库选型时需要注意的问题，时序数据库的基本功能就是提供高效可靠的数据采集、数据插入、数据查询和计算等通用的功能，判断一款时序数据库是否好用，主要是看能否在你的业务需求上产生亮点，对业务产生增值：

*  性能提升：提高实时写入（用点/s的指标进行衡量，10W点/s只是起点）、实时查询、聚合计算、历史查询性能，更多更快。
 *  业务提升：带来新的业务需求，离线功能转在线功能。
 *  总拥有成本：

1.  硬件成本：磁盘空间、计算资源、机房费用。2. 运维成本：备份、迁移、DBA工具、人员成本、运维工具。

*  研发成本：丰富的API接口、低学习成本、低人员成本。

总之，在物联网的选型上，如何找到自己痛点，在单位硬件的条件下，测试这几个痛点的主要性能，才能更好的做物联网大数据平台的选型。

[Hadoop or TDengine]: https://blog.51cto.com/u_15060460/2676856?xiangguantuijian&01
[b4bb7b70ca8760b50130ceb5d56f5ef5.png]: /images/20220829/c621d6cdb8304564adbc47ed6800cf2d.png
[ccd61cc88b2a96972492b1404eac4096.png]: /images/20220829/facbee5a4b8a4308b6629151cd9371d6.png
[14ca56db9c4feff8721555484a5e99c1.png]: /images/20220829/2da5fde426a5451a88a0fc8848fc461f.png
[c3427a9b6433dd69341333f9f1d7e4c5.png]: /images/20220829/e29c82b8f0054b19880e397a398ecdb5.png
[d0ec030987e89f53a4fe408dee130d49.png]: /images/20220829/49dc0132f9e147d5a833b137149c609c.png
[5df370e4da94e7d50c49f31600f875c0.png]: /images/20220829/7e29e299e21f4c589bf019b503822d0b.png
[dae7c7935e22a4284b6d839e08279bd1.png]: /images/20220829/27c1f72d092047daafcf47cf5a482feb.png
[d300745b08c33716b2f0fc73c545f319.png]: /images/20220829/c99d6c80b16b49048141a8a09dbb6692.png
[a72b0cd80434a075b947e7f2e82bea6c.png]: /images/20220829/915d8b5afed3486e98d31f3551cd30e7.png
[7c175d577111982569e1b23711e131b1.png]: /images/20220829/024b0bfb226f4733bd70657e261fe02e.png
[da54bfdf86321e48d3d4805eaf716adf.png]: /images/20220829/6c0dc10f767648baa1c1a1426d7e713e.png
[de105349829173c6803d3b401797b13f.png]: /images/20220829/8d1c90e3286f44f2ab3ff9d576d2e1fe.png
[3fffc94a5e19dab7aea63d4b5435a8d3.png]: /images/20220829/50cf0f60f52d46efa1ae2dcf761e8202.png