1.5 专用时序数据处理工具的必要性

1.2节提到，一个优秀的时序大数据平台需要具备处理时序数据十大特征的能力。在1.4节中，我们介绍了时序大数据平台处理时序数据所需的核心模块。结合这两节内容与实际情况，我们可以发现：处理海量时序数据的背后，实际上是一个庞大且复杂的系统。

早些年，为了应对日益增长的互联网数据，众多工具应运而生，其中Hadoop体系最受欢迎。除了使用大家熟知的Hadoop组件，如HDFS、MapReduce、HBase和Hive以外，通用的大数据平台还常常使用Kafka等消息队列工具、Redis等缓存软件、Flink等实时流式数据处理软件。在存储方面，人们也会选择MongoDB、Cassandra或其他NoSQL数据库。这样一个典型的大数据平台基本上能够很好地处理互联网行业的应用，如用户画像、舆情分析等。

因此，当工业互联网和物联网大数据兴起时，人们自然而然地想到使用这套通用的大数据平台来处理时序数据。目前市场上流行的物联网、车联网等大数据平台几乎都采用了这种架构。虽然这套方法已被证明是可行的，但仍然存在许多不足之处。

● 开发效率低：通用的大数据平台并非单一软件，至少需要集成4个模块，这些模块可能不遵循标准的POSIX或SQL接口，拥有独立的开发工具、编程语言和配置方法，学习成本较高。此外，数据在模块间传输时，一致性易受损。加之这些模块多为开源软件，常会遇到bug，即便有技术论坛和社区支持，解决技术问题仍需要耗费工程师大量时间。总的来说，搭建一个能顺利应用这些模块的团队需要投入相当多的人力资源。

● 运行效率低：现有开源软件主要针对互联网上的非结构化数据（如文本、视频、图像等），而物联网收集的数据则是时序的、结构化的。使用非结构化数据处理技术处理结构化数据，无论是存储还是计算，所需的系统资源都要多得多。

● 运维成本高：每个模块（如Kafka、HBase、HDFS、Redis）都有自己的独立管理后台。在传统信息系统中，数据库管理员只须掌握MySQL或Oracle的管理，而现在则需要学会管理、配置和优化众多模块，工作量大幅增加。模块数量过多使得定位问题变得更加复杂。例如，用户发现丢失了某条时序数据，但无法迅速判断是Kafka、HBase、Spark还是应用层的问题，通常需要花费较长时间，通过关联各模块的日志才能找到原因。模块越多，系统的整体稳定性越低。

● 产品推出慢、利润低：鉴于大数据处理平台开发应用功能的研发效率低和运维成本高，产品上市时间延长，使企业错失商机。此外，这些不断演化的开源软件需要同步更新至最新版本，同样需要投入人力资源。除了互联网领域的领头羊以外，中小型企业通常在通用大数据处理平台上的投入远超过购买专业公司产品或服务的成本。

● 对于小数据量场景，私有化部署过于笨重：在物联网和车联网领域，考虑到生产经营数据的安全性，许多系统选择私有化部署。然而，私有化部署所处理的数据量差异巨大，从数百台到数千万台设备不等。因此，对于数据量较小的场景，通用的数据处理方案显得过于庞大，投入与产出不成比例。有些平台提供商提供两套解决方案，一套用于大数据场景，采用通用大数据处理平台；另一套针对小数据量场景，使用MySQL或其他数据库来应对。但随着历史数据的积累或接入设备数量的增加，关系型数据库的性能不足、运维复杂性高、扩展性差等问题将逐渐显现，这并非长期可行的策略。

由于存在这些根本性缺陷，高速增长的时序大数据市场一直缺乏一个既简单又高效易用的工具。近年来，一些专注于时序数据处理的公司进入了这一领域，例如美国的InfluxData，其产品InfluxDB在IT运维监测领域占据相当的市场份额。开源社区的时序数据产品也非常活跃，如基于HBase开发的OpenTSDB具有广泛的影响力，阿里巴巴、百度、华为等企业也开发了基于该技术的解决方案。此外，还有一些后起之秀，如涛思数据研发的开源时序大数据平台TDengine。

由于数据量庞大且应用场景独特，时序数据处理面临着巨大的技术挑战，这就需要使用专业的大数据平台。实时高效地处理时序数据能够帮助企业实时监控生产和经营活动，而对历史时序数据的分析则有助于科学地决策资源利用和生产配置。