时序数据处理、时序数据库应用于物联网、车联网、工业互联网领域的过程数据采集、过程控制，并与过程管理建立一个数据链路，属于工业数据治理的新兴领域。
企业级的时序数据处理，首先是基于数据架构和数据模型的。
数据架构决定哪些时序数据需要采集，如何处理，用于哪些业务场景，用于时序数据采集的规划与设计开发；数据模型用于解析时序数据的数据结构。
在物联网、车联网、工业互联网兴起之后，大家都想用通用的大数据平台来处理其中的数据。现在市场上流行的物联网、车联网等大数据平台几乎无一例外都是这类架构，但这套通用处理工具的效果如何？可以说有很多不足，主要表现在以下几个方面。
因为不是单一的软件，需要集成4个以上模块，很多模块都不是标准的POSIX或SQL接口，都有自己的开发工具、开发语言、配置等，需要一定的学习成本。而且由于数据会从一个模块流动到另外一个模块，数据的一致性容易受到破坏。同时，这些模块基本上都是开源软件，总会有各种漏洞，一旦被一个技术问题卡住，总要耗费工程师不少时间。总的来讲，企业需要搭建一支优秀的团队才能将这些模块顺利地组装起来，因此需要耗费较多的人力资源。
现有的这些开源软件主要用来处理互联网上的非结构化数据，但是通过物联网采集来的数据都是时序的、结构化的。用非结构化数据处理技术来处理结构化数据，无论是存储还是计算，消费的资源都大很多。
每个模块，无论是Kafka、HBase、HDFS还是Redis，都有自己的管理后台，都需要单独管理。在传统的信息系统中，数据库管理员只要学会管理MySQL或是Oracle就可以了，但现在数据库管理员需要学会管理、配置、优化很多模块，工作量大了很多。由于模块数过多，定位一个问题就变得更为复杂。比如，用户发现有一条采集的数据丢失了，至于是Kafka、HBase、Spark丢失的，还是应用程序丢失的，则无法迅速定位，往往需要花很长时间，只有将各模块的日志关联起来才能找到原因。而且模块越多，系统整体的稳定性就越低。
由于开源软件研发效率低，运维成本高，导致将产品推向市场的时间变长，让企业丧失商机。而且这些开源软件都在演化中，要同步使用最新的版本也需要耗费一定的人力。除互联网头部公司外，中小型公司在通用大数据平台上花费的人力资源成本一般都远超过专业公司的产品或服务费用。
在物联网、车联网场景中，因为涉及生产经营数据的安全，很多还是采取私有化部署。而每个私有化部署，其处理的数据量有很大的区别，从几百台联网设备到数千万台联网设备不等。对于数据量小的场景，通用的大数据解决方案就显得过于臃肿，投入与产出不成正比。因此，有的平台提供商往往有两套方案，一套针对大数据场景，使用通用的大数据平台，一套针对小数据场景，使用MySQL或其他数据库。但这样会导致研发、维护成本提高。
与通用的大数据处理工具相比，新兴时序数据处理工具具备什么样的特点呢？下面仔细分析一下。
工业互联网产生的数据量巨大，比如，全国有5亿多台智能电表，每台智能电表每隔15分钟采集一次数据，全国的智能电表一天就会产生500多亿条记录。这么大的数据量，任何一台服务器都无法处理，因此时序数据处理系统必须是分布式的、水平扩展的。为降低成本，一个节点的处理性能必须是高效的，需要支持数据的快速写入和快速查询功能。
对于互联网大数据的应用场景，大家所熟悉的都是用户画像、推荐系统、舆情分析等，这些场景并不需要数据计算具有实时性，批处理即可。但是对于工业互联网大数据的应用场景，则需要基于采集的数据做实时预警、决策，延时要控制在秒级以内。如果没有实时计算，则其商业价值就大打折扣。
工业互联网系统对接的往往是生产、经营系统，如果数据处理系统宕机，则会直接导致停产，无法对终端消费者正常提供服务。因此，时序数据处理系统必须是高可靠的，必须支持数据实时备份，必须支持异地容灾，必须支持软件、硬件在线升级，必须支持在线IDC机房迁移，否则服务一定有被中断的可能。
在绝大部分场景中，都需要能快速获取设备当前状态或其他信息，用以报警、大屏展示等。时充数据处理系统需要提供高效机制，让用户可以获取全部或符合过滤条件的部分设备的最新状态。
各种实时预警或预测已经不是简单地基于某一个阈值进行的，而是需要通过将一个或多个设备产生的数据流进行实时聚合计算（并且不只是基于一个时间点，而是基于一个时间窗口进行计算）。不仅如此，计算的需求也相当复杂，因场景而异，应容许用户自定义函数进行计算。
时序数据处理系统与通用大数据平台比较一致的地方是，同一组数据往往有很多应用都需要，因此，时序数据处理系统应该提供订阅功能：只要有新的数据更新，就应该实时提醒应用。而且这个订阅也应该是个性化的，容许应用设置过滤条件，比如只订阅某个物理量5分钟的平均值。
实时数据被存储在缓存里，历史数据被存储在持久化存储介质里，而且可能依据时长，被存储在不同的存储介质里。时序数据处理系统应该隐藏背后的存储介质，给用户和应用呈现的是同一个接口和界面。无论是访问新采集的数据还是10年前的老数据，除输入的时间参数不同外，其余都应该是一样的。
对于物联网系统，数据流量往往是平稳的，因此数据写入所需要的资源往往是可以估算的。其中变化的是查询、分析，特别是即席查询，有可能耗费很多的系统资源，不可控。因此，时序数据处理系统必须保证分配足够的资源以确保数据能够写入系统而不被丢失。准确地说，时序数据处理系统必须是一个写优先系统。
对于联网设备产生的数据，需要进行各种维度的统计分析，比如根据设备所处的地域进行分析，根据设备的型号、供应商进行分析，根据设备所使用的人员进行分析等。这些维度的分析是无法事先设计好的，而是在实际运营过程中，根据业务发展需求定下来的。因此，工业互联网大数据平台需要一个灵活的机制来增加某个维度的分析。
原始数据的采集可能频次较高，但在具体分析时，往往不需要对原始数据进行分析，而是需要对数据进行降频。时序数据处理系统需要提供高效的数据降频操作。不同设备采集数据的时间点是很难一致的，因此，分析一个特定时间点的值，往往需要插值才能解决，系统需要提供线性插值、设置固定值等多种插值策略。
为提高数据分析师的工作效率，时序数据处理系统应该提供命令行工具或容许用户通过其他工具，执行SQL查询，而不是非要通过编程接口。并且查询分析结果可以很方便地被导出，以及被制作成各种图表。
时序数据的采集一般都是通过传感器自动进行的，包括光电、热敏、气敏、力敏、磁敏、声敏、湿敏、电量等不同类别的工业传感器。就某一个具体的物理量而言，数据采集是很容易的。但就整个系统而言，数据采集是相当复杂的，具体表现在以下几个方面。
在现实场景中，往往会出现ModBus、OPC、CAN、ControlNet、Profibus、MQTT等各种类型的工业协议，而且各个自动化设备生产及集成商还会自己开发各种私有的工业协议，导致在实现工业协议的互联互通时出现极大的难度。很多开发人员在工业现场实施综合自动化等项目时，遇到的最大问题即是面对众多的工业协议，无法有效地进行解析和采集数据。
由于历史原因，采集的数据往往会通过局域网、蓝牙、Wi-Fi、2.5G、3G、4G等各种传输方式被传送到服务器中，导致各种通信方式并行存在，连接管理变得复杂。
传统的工业系统都运行在局域网中，安全问题不是考虑的重点。若需要通过云端（特别是公有云）调度工业行业中核心的生产数据，又没有充分考虑安全问题，则很有可能造成难以弥补的损失。
根据上述原因，企业在实际采集数据时，往往配有工业互联网网关盒子，该盒子支持各种物理接口、通信协议和工业标准协议，将不同协议进行转换，对数据进行安全加密，统一以MQTT（Message Queuing Telemetry Transport，ISO/IEC PRF 20922）协议或其他协议发往云端。
对于数据采集部分，因为标准性不够，就不对具体工具做介绍了。
采集后的数据一般通过网络被送往服务器或云端进行处理。相对数据采集工具而言，数据处理工具比较统一，下面对几个流行的时序数据库进行介绍。
时间序列数据库 TSDB
前往购买：时间序列数据库 TSDB
阿里云时间序列数据库 (简称 TSDB) 是一种集时序数据高效读写，压缩存储，实时计算能力为一体的数据库服务，可广泛应用于物联网和互联网领域，实现对设备及业务服务的实时监控，实时预测告警。
前往购买：InfluxDB 时序数据库
时序数据库 InfluxDB® 版是一种免运维，稳定可靠，可弹性伸缩的在线时序数据库服务。广泛应用于互联网基础资源监控，容器监控，业务运营监控分析，物联网设备远程实时监控，工业安全生产监控，生产质量评估和故障回溯。提供时序数据自动化采集，压缩存储，类SQL查询，多维聚合计算和数据可视化分析能力。
表格存储（Tablestore）是阿里云自研的面向海量结构化数据存储的Serverless NoSQL多模型数据库，被广泛用于社交、物联网、人工智能、元数据和大数据等业务场景。提供兼容HBase的WideColumn模型、消息模型Timeline以及时空模型Timestream，可提供PB级存储、千万TPS以及毫秒级延迟的服务能力。
前往购买：表格存储Tablestore