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

为处理日益增长的互联网数据，众多的工具开始出现，最流行的应该是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, 应可以大幅简化物联网大数据平台的架构，缩短研发周期，降低平台运营费用。

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

从数据架构看生鲜电商的数据价值
目前数据的价值已经从单纯的啤酒尿不湿数据挖掘.决策分析与决策支持.商业分析,往数据资产.生产力资料方向发展. 作为电商垂直领域的生鲜电商则更是数据战场,凭借推荐算法和大数据杀熟等策略,收集完整的定价轨 ...
【数据架构系列-02】从《数据中台能力成熟度模型》的发布，聊聊火了的中台
热点之所以会"热起来",是由于万众瞩目的那份炽烈,也是因为无数双"手"的奋力炒作.所以,要穿过那"缭绕烟雾"看到本质,便需要冷静的头脑. 2 ...
【数据架构系列-04】趁着国家数据局来了，一起聊聊政府数据开放，未来道阻且长
这几天朋友圈.订阅号.新闻推送频繁出来的消息是国家要成立数据局,"3月7日下午,根据国务院关于提请审议国务院机构改革方案的议案,组建国家数据局,一个全新的机构即将诞生".可见国家是 ...
【企业架构设计实战】5 大数据架构设计
数据架构概述什么是数据? 一个企业的数字化核心是数据,数据化的价值依赖于数据的标准和质量,数据对一个企业来说至关重要,它也是整个信息化建设及企业架构的核心.数据具有多样性,有结构化的.非结构化的,与 ...
阿里前大数据架构师：如何快速的成长为一名优秀大数据架构师
什么是大数据架构师: 围绕大数据系平台系统级的研发人员, 熟练Hadoop.Spark.Storm等主流大数据平台的核心框架.深入掌握如何编写MapReduce的作业及作业流的管理完成对数据的计算,并 ...
瓜子大数据架构首曝光：掩藏在“二手车”背后的技术思考
提起车好多集团,可能有些人会感到陌生,但提起瓜子二手车.毛豆新车,想必都十分熟悉,脍炙人口的广告语使得大家忽视了这家公司的技术能力.车好多集团旗下拥有瓜子二手车.毛豆新车.车速拍与瓜子养车四大品牌, ...
看看华为、阿里大数据架构师的必备技能！
嘘,我们只偷偷地告诉你一个人! 这个秘密职业就是数据架构师在国内大数据行业大概有以下几种岗位:数据架构师.数据分析师.数据挖掘工程师.数据算法工程师和数据产品经理. 接下来我们介绍第二种岗位让我 ...
招聘岗位：大数据架构师年薪：25-48W 工作地点：北京
岗位职责: 1.负责军工行业大数据项目技术方案与演进规划,负责企业级大数据的架构设计.技术规划与选型.方案设计,使大数据架构具有良好的性能.安全性.可靠性.可扩展性. 2.参与大数据对外项目交付,控制 ...
SDCC 2016大数据架构峰会·杭州站启航，首批过半讲师和议题公布
2016年9月22日-23日,由CSDN重磅打造的大数据核心技术与实战峰会.互联网应用架构实战峰会将在杭州举行. SDCC 2016大数据技术&架构实战峰会(杭州站)是由CSDN主办的顶级技术 ...

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

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

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

最新文章

热门文章