时序数据基础

什么是时序数据？

时序数据，即时间序列数据（Time-Series Data），是一组按时间先后顺序排列的序列数据。日常生活中，设备、传感器采集的数据是时序数据，证券交易记录也是时序数据。因此时序数据处理并不陌生：尤其在工业自动化与证券金融行业，专业的时序数据处理软件早已存在，例如工业领域的 PI System 以及金融行业的 KDB。

这些时序数据可能按周期、准周期产生，也可能由事件触发；采集频率有高有低。数据一般被发送至服务器汇总，并进行实时分析与处理，用于系统运行监测或预警，以及对市场行情进行预测。数据也可长期保存，用于离线分析。例如：统计某时间区间内设备的运行节奏与产出，分析如何优化配置以提升生产效率；统计一段时间内生产过程的成本分布，分析如何降低成本；统计一段时间内的设备异常值，结合业务分析潜在安全隐患，以降低故障时长等。

过去二十年，随着数据通信成本显著下降，以及传感技术与智能设备的普及——尤其是在物联网与工业 4.0 的推动下——工业与物联网企业为监测设备、环境、生产线及整个系统的运行状态，在各关键点部署传感器并采集数据。从手环、共享出行、智能电表、环境监测设备，到电梯、数控机床、挖掘机、工业生产线等，都在源源不断地产生海量实时数据，时序数据体量呈指数级增长。以智能电表为例，若每隔 15 分钟采集一次，每天可产生 96 条记录；中国已有超过 10 亿台智能电表，一天即可产生约 960 亿条时序数据。一台联网汽车往往每隔 10 到 15 秒向云端上报一次数据，一天很容易产生约 6000 条记录；若有 2 亿辆车联网，每天将产生约 1.2 万亿条乃至更多的时序数据。

由于数据量呈指数级增长，且分析与实时计算需求持续增加——尤其是在人工智能广泛应用的背景下——传统时序数据处理工具已难以满足需求。如何对每天高达 10TB 量级的海量时序数据进行实时存储、分析与计算，成为重要技术挑战。因此，过去十年间，海量时序大数据的高效处理获得了全球工业界的高度关注。

时序数据的十大特征

相对于普通互联网应用数据，时序数据具有许多明显特征。涛思数据创始人陶建辉先生早在 2017 年即对此进行了系统归纳，总结了时序数据本身及其应用的十大特征：

数据是时序的，一定带有时间戳：联网设备按设定周期，或受外部事件触发，持续产生数据；每条记录对应一个时间点，必须记录时间戳，否则记录值没有意义。
数据是结构化的：物联网、工业设备产生的数据以及证券交易数据往往是结构化的，且绝大多数为数值型。例如智能电表采集的电流、电压，可用 4 字节标准浮点数表示。
一个数据采集点就是一个数据流：一台设备采集的数据、或一支股票的交易数据，与另一台设备或另一支股票相互独立。一台设备的数据由该设备产生，数据源唯一。
数据较少有更新、删除操作：信息化或互联网应用中，记录可能经常被修改或删除；而设备或交易产生的数据，在正常情况下通常不会更新或删除。
数据不依赖事务：单条设备数据的价值相对有限，完整性和一致性要求通常不如传统关系型数据库严格；用户更关注趋势，因此一般无需引入复杂事务机制。
相对互联网应用，写多读少：互联网应用中，一条记录往往一次写入、多次读取（例如一篇文章可能被大量用户阅读）。工业与物联网设备数据则多由计算、分析程序自动读取，且次数有限；通常仅在发生异常时，人员才会主动读取原始数据。
用户关注一段时间的趋势：银行交易记录或社交媒体内容对用户往往逐条重要；而物联网、工业时序数据中，相邻数据点变化通常不大，用户更关注一段时间（如过去五分钟、一小时）的变化趋势，而不是单个时间点。
数据有保留期限：采集数据通常有基于时长的保留策略，例如保留一天、一周、一个月、一年甚至更久。数据价值往往与时间段相关，超出重要时间段的数据可按块删除。
需要实时分析计算：多数互联网大数据应用以离线分析为主；即便有实时分析，时延要求通常不高（例如用户画像可积累一定行为数据后再计算，稍晚一天对结果影响有限）。工业、物联网平台与交易系统则往往对实时计算要求很高，需基于计算结果进行实时报警与监控，以避免事故或错过决策时机。
流量平稳、可预测：给定设备数量与采集频次，即可较准确估算带宽、流量、存储需求以及每日新增数据量。这与电商大促期间数十倍流量波动，或春运期间票务网站流量激增的情况明显不同。

上述特征使时序数据处理具有独特需求与挑战；高效的时序数据处理平台也应充分利用这些特征来提升处理能力。

时序数据的典型应用场景

时序数据的细分应用场景很多，以下列举若干典型领域。

电力能源：覆盖发电、输电、配电、用电等环节，各类电力设备会产生大量时序数据。以风力发电为例，一台风机可能有数百个采集点，日数据量很大，监控分析是保障发电环节正常运行的必要工作。在用电侧，可对智能电表实时采集的电流、电压等快速计算，掌握最新用电总量及尖、峰、平、谷用电量，并判断设备是否正常。电力系统也可能拉取历史上某一年的全量数据，借助机器学习分析用电习惯、进行负荷预测与节能方案设计，辅助电力供应规划；或拉取上月尖峰平谷用电量，按不同电价进行电费结算。这些都是时序数据在电力能源领域的典型应用。
车联网 / 轨道交通：车辆的 GPS、速度、油耗、故障信息等均为典型时序数据，合理分析可为车辆管理与优化提供支持。不同车型采集点位数从数百到数千不等；随着联网交通设备增多，海量时序数据的安全上传、存储、查询与分析成为行业痛点。对交通工具本身，可支撑轨迹追踪、辅助驾驶、故障预警等；对配套服务，也可提供支持。例如在智能地铁系统中，通过对站内传感器时序数据的采集与分析，可实时展示各车厢拥挤度、温度、舒适度等信息，便于乘客选择更合适的出行方案，也便于运营商进行客流调度。
智能制造：过去十几年，传统工业企业数字化快速发展，单个工厂的采集点从数千扩展到数十万甚至上百万；部分远程运维场景面临上万设备、千万测点的采集与存储需求，这些数据都属于典型时序数据。工业大数据系统中的时序数据处理往往很复杂。以烟草行业为例，设备工业协议多样，采集单位因设备类型而异；随着采集点增加，实时处理能力承压，同时还需兼顾高性能、高可用与可扩展等要求。若大数据平台能够满足企业时序数据存储与分析需求，将有助于实现更智能、更自动化的生产模式。
智慧油田：智慧油田（也称数字油田或智能油田）利用信息技术与装备，实现油气田层析图与动态生产数据的实时更新，以提升开发效率与经济效益。在长期建设中，钻井、录井、测井、开发生产等业务产生了来自油井、水井、气井等数十种设备的大量时序数据。为构建以油气生产指挥中心为核心的信息化智能管控模式，系统需保障数万口油气水井、阀组、加热炉等设备的实时数据处理，做到高效写入与查询、节省存储、按业务灵活水平扩展，并保持易用与数据安全。部分大型项目还会将各地油田生产数据实时同步至总部云端，通过边云协同完成数据入湖与统一管理。
IT 运维：基础设施（服务器、网络、存储等）与应用程序运行过程中会产生大量时序数据。通过对这些数据的监控，可快速了解基础设施与应用的运行状态和服务可用性（是否在线、是否正常响应等）；也可观察具体指标，如 CPU、内存、磁盘、网络带宽利用率等；还可监控错误日志与异常事件（如入侵检测、安全事件、权限控制等），并通过告警规则及时通知运维人员，从而发现问题、预防故障并优化性能，保障系统稳定运行。
金融：金融领域正在经历数据管理变革。行情数据属于典型时序数据，保留期限常达 5 至 10 年，甚至超过 30 年，且可能需要保存多地主流市场的全量交易数据，体量可达 TB 级，从而带来存储与查询压力。量化交易是凸显时序数据处理价值的典型场景之一：通过对海量行情时序数据的读取与分析，及时响应市场变化，帮助把握投资机会并控制风险。可支撑资产管理、情绪监控、股票回测、交易信号模拟、报表自动生成等能力。

处理时序数据所需要的工具

要高效处理时序数据，完整的时序数据处理平台通常需要具备以下核心模块。

数据库（Database）：提供时序数据的高效存储与读取。在工业与物联网场景中，设备产生的数据量很大。存储方面，需要将数据持久化到磁盘并尽可能压缩，以降低成本；读取方面，需要保障实时查询与历史查询效率。传统方案包括 MySQL、Oracle 等关系型数据库，以及 Hadoop 体系中的 HBase；专用时序数据库则有 InfluxDB、OpenTSDB、Prometheus 等。
数据订阅（Data Subscription）：许多应用需要第一时间获取业务所需的实时数据，以及时了解监测对象状态，并用 AI 或其他工具做实时分析。同时，出于隐私与安全，应用只能订阅其有权限访问的数据。因此，平台需要具备数据订阅能力，帮助应用获取最新数据。
ETL（Extract, Transform, Load）：在物联网与工业场景中，通常需要通过 ETL 进行提取、清洗与转换后再入库，以保证数据质量。不同采集系统标准往往不一致：例如温度单位可能是摄氏度或华氏度，时区与时间分辨率也可能不同，汇聚后的数据需要转换才能写入数据库。
流式计算（Stream Computing）：物联网、工业与金融应用需要对时序数据流进行快速计算，以满足实时业务需求。例如，根据智能电表实时电流与电压，立即计算有功功率与无功功率。平台常选用 Apache Spark、Apache Flink 等流处理框架。
缓存（Cache）：应用需要实时展示设备或标的最新状态，因此需要缓存以提供快速访问。若数据量极大且不做缓存，常规读取与筛选会导致明显延迟，难以满足实时性要求。Redis 是常用的缓存工具之一。

时序数据处理需要多模块协同，覆盖采集、存储、计算、分析与可视化，以及专用算法库等环节。工具选择取决于业务需求与数据特点；合理组合才能高效处理各类时序数据并挖掘其价值。

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

在「时序数据的十大特征」一节中提到，优秀的时序大数据处理平台需要具备应对这些特征的能力；在「处理时序数据所需要的工具」一节中，介绍了主要模块与组件。结合实际可以看到：处理海量时序数据往往是一个庞大而复杂的系统。

早些年，为处理快速增长的互联网数据，出现了大量工具，其中 Hadoop 体系最为流行。除 HDFS、MapReduce、HBase、Hive 等组件外，通用大数据平台还常使用 Kafka 等消息队列、Redis 等缓存，以及 Flink 等实时流处理软件；存储上也有人选用 MongoDB、Cassandra 等 NoSQL 数据库。这类平台能够较好支撑互联网场景（如用户画像、舆情分析等）。

因此，在工业与物联网大数据兴起后，业界自然仍倾向用这套通用平台处理时序数据。目前市场上的物联网、车联网等大数据平台大多采用类似架构。该路径已被证明可行，但仍存在不足：

开发效率低：并非单一软件，通常需要集成至少四个以上模块；许多模块并非标准 POSIX 或 SQL 接口，各有工具链、语言与配置，学习成本高。数据在模块间流转时，一致性也容易受损。开源组件难免存在缺陷；即便有社区支持，一旦卡住仍会消耗大量时间。总体而言，需要较强团队才能把模块组装起来，人力成本较高。
运行效率低：许多开源组件主要面向互联网非结构化数据（文本、视频、图片等），而物联网采集数据多为时序、结构化数据。用非结构化处理技术处理结构化数据，在存储与计算上都会消耗更多资源。
运维成本高：Kafka、HBase、HDFS、Redis 等各有管理界面，需要单独运维。传统系统中 DBA 主要管理 MySQL 或 Oracle 即可；现在则要学习管理、配置与优化多个模块，工作量显著增加。模块越多，问题定位越复杂：例如发现一条采集数据丢失时，难以迅速判断是 Kafka、HBase、Spark 还是应用侧导致，往往需要关联各模块日志才能定位。模块越多，系统整体稳定性也越难保障。
产品推出慢、利润承压：研发效率低、运维成本高，会拉长产品上市周期，影响商业机会。开源组件持续演进，跟进新版本也需要人力。除互联网头部企业外，中小企业在通用大数据平台上的人力投入，往往高于采购专业产品或服务的费用。
小数据量场景下私有化部署过重：物联网、车联网因数据安全等因素，常采用私有化部署；单套部署的规模差异很大，从数百台到数千万台设备不等。对小规模场景，通用大数据方案往往过重，投入产出不成正比。于是有的厂商准备两套方案：大数据场景用通用大数据平台，小规模场景用 MySQL 等关系库。但随着历史数据累积或接入设备增长，关系库在性能、运维与扩展性上的不足会逐渐暴露，难以长期支撑。

正因存在这些结构性不足，高速增长的时序大数据市场长期缺乏既简单好用又高效的工具。近些年，一批专注时序数据处理的企业进入该领域，例如美国 InfluxData，其 InfluxDB 在 IT 运维监测方面有较高市场占有率。开源社区同样活跃，例如基于 HBase 的 OpenTSDB；在中国，阿里、百度、华为等均有基于 OpenTSDB 的相关产品。涛思数据不依赖第三方组件，推出了自主研发并开源的 TDengine。

由于数据量巨大且应用方式特殊，时序数据处理具有较高技术挑战，需要专业平台支撑。对实时时序数据的高效处理，有助于企业实时监控生产经营过程；对历史时序数据的分析，有助于对资源使用与生产配置做出更科学的决策。

选择时序数据处理工具的标准

企业需要合适的时序大数据平台来处理设备与交易产生的海量数据。那么，这类平台应具备哪些能力？与通用大数据平台相比，又应具备哪些特征？

必须是分布式系统：工业与物联网设备产生的海量数据，单机无法处理，因此系统必须可分布式、可水平扩展，并能够高效应对高基数问题。以智能电表为例，设备常带有设备 ID、城市 ID、厂商 ID、型号 ID 等标签；数百个城市、百万级设备，再叠加厂商与型号，基数可轻松超过百亿。要在百亿级基数中筛选某一设备的数据，难度很大，这就是时序领域经典的「高基数」问题。即便中小型项目，过亿基数也很常见。因此选型时需关注架构能否支撑业务基数；能够通过分布式架构处理高基数问题，才足以支撑业务增长，称得上真正的时序大数据平台。
必须是高性能：「高性能」是相对概念，描述相对其他产品的表现。不同平台的硬件规模与需求不同，但好的平台不应依赖「堆硬件」，而应具备出色的单点能力，以更少资源获得更好性能，从而实现降本增效。若专用时序平台在存储、读取、分析等方面无法做到高性能，就难以体现相对通用大数据平台的优势。
必须满足实时计算：互联网大数据常见场景包括用户画像、推荐、舆情分析等，对实时性要求不高，批处理往往即可。物联网场景则常需基于采集数据做实时预警与决策，延迟通常要求控制在秒级以内。若计算不具备实时性，业务价值会大打折扣。
必须具备运营商级高可靠能力：工业与物联网系统常直接对接生产经营；若数据处理系统宕机，可能导致停产、经济损失，或影响对终端用户的服务。例如智能电表系统故障，可能影响大量用户用电。因此系统必须高可靠，支持实时备份、异地容灾，以及软硬件在线升级与机房迁移，否则服务中断风险难以接受。
必须具备高效缓存：多数场景需要快速获取设备当前状态等信息，用于告警、大屏展示等。系统应提供高效机制，支持获取全部或按条件过滤后的设备最新状态。
必须支持实时流式计算：实时预警或预测往往不再基于单一阈值，而需要对一个或多个设备数据流做实时聚合，并基于时间窗口而非单点计算。计算需求因场景而异，还应允许用户自定义函数。
必须支持数据订阅：与通用大数据平台类似，同一组数据常被多个应用使用，系统应提供订阅能力，在有新数据时及时通知应用。出于隐私与安全，订阅还应可控：应用只能订阅有权查看的数据，例如仅能订阅每小时平均功率，而不能订阅原始电流、电压。
必须保证数据可持续稳定写入：联网设备数据流量通常较平稳，写入资源可以估算；变化更大的是查询与分析，尤其是即席查询，可能占用大量不可控资源。因此系统必须预留足够资源，确保写入不被查询拖垮，数据不丢失。准确地说，系统应是写优先系统。
必须统一实时数据与历史数据处理：实时数据在缓存中，历史数据在持久化介质中，并可能按时长分布在不同介质上。系统应隐藏底层存储差异，向用户与应用提供统一接口：访问新采集数据与多年前历史数据时，除时间参数外，其余应保持一致。
必须支持灵活的多维分析：联网设备数据需要从地域、型号、供应商、使用人员等多个维度统计分析，且维度往往随业务发展动态增加，难以事先穷尽。因此系统需要灵活机制，支持按需增加分析维度。
需要支持即席分析与查询：为提高分析效率，系统应提供命令行工具，或允许通过其他工具执行 SQL，而不必事事编程。查询结果应便于导出，并制作成图表。
必须支持降频、插值与专用函数等操作：原始采集频次可能很高，分析往往基于降频后的数据，系统需提供高效降频能力。设备难以严格同步，不同设备采集时间点不易对齐，特定时刻取值常需插值；系统应提供线性插值、固定值等多种策略。工业互联网除通用统计外，还常需时间加权平均、累计求和、差值等专用函数。
必须提供灵活的数据管理策略：大型系统中，采集数据类型多，除原始数据外还有大量衍生数据。它们特点各异：有的频次高，有的保留时间长，有的需要多副本，有的需要快速访问。平台应提供多种策略供配置，并支持策略并存。
必须开放：系统应支持业界常用的标准 SQL，提供 C/C++、Java、Go、Python、RESTful 等开发接口，并支持 Spark、R、Matlab 等工具，便于集成机器学习、人工智能算法或其他应用，使平台可持续扩展，而不是封闭孤岛。
必须支持异构环境：大数据平台建设周期长，不同批次采购的服务器与存储往往不同，系统应支持多种档次与配置的设备共存。
必须支持边云协同：应有灵活机制将边缘节点数据上传云端，可按需同步原始数据、加工后数据或仅符合过滤条件的数据，并可随时取消或调整策略，以便更好地汇聚数据、统筹业务并支持决策。
需要统一的后台管理：便于查看运行状态，管理集群、用户与系统资源，并与第三方 IT 运维监测平台无缝集成。
需要支持私有化部署：许多企业出于安全等因素希望私有化部署，而传统企业 IT 运维力量有限，因此安装、部署与运维应尽量简单、快捷、可维护。