智能运维场景中的时序数据库选型与挑战

问题导读

1.什么是智能运维
2.运维场景下数据面临哪些挑战？
3.IoTDB 带来了什么价值？
4.如何解决运维赛道面临的问题？


1.智能运维概述

智能运维是什么行业？智能运维和传统的理解中的接网线、网管工作早已不同，这个赛道上有很多成功的企业如 SerivceNow、DataDog、Splunk、Dynatrace，他们的市值在百亿到千亿级别。云智慧是中国智能运维赛道上最大的独角兽。




物联网、工业互联网、企业服务这些领域内都有哪些可以做的事？下图是源自 ServiceNow 的一张图，其中把企业服务分为了 8 个领域，包括 IT、Sales、ERP 等等，他们认为每各领域都可以支撑千亿美金的公司，事实上 It 领域的 ServiceNow、HR 领域的 WorkDay、Sales 领域的SalesForce 等等分别在各自的领域作为佼佼者有着良好的市场口碑和影响力。




从消费互联网到产业互联网，数字化转型已经成为企业发展的必修课。数字化的进程逐渐深入，对 IT 系统的投入和维护投入会不断增多，随之便会产生海量的 IoT 数据、时序数据。

企业数字化转型下面临着巨大挑战，根据统计，41% 的组织在过去 18 个月中重新确定了 IT 运维战略，过去两年中处理的报警和事件总量平均增加 2.7 倍，68% 的组织在过去 12 个月中感受到客户期待着更好的体验和合作。IT 运维赛道在产业互联网时代被给予了很大关注。

运维数据包括指标、日志和调用链。一台机器的CPU、内存是指标，也就是我们常说的时序数据。除指标外，日志数据也记录着很多有价值的信息，但日志数据存在体量大、价值稀疏、结构化复杂等问题，处理和分析日志数据是一个难点。调用链数据服务于分布式场景下大量微服务的，用来体现复杂服务调用关系。运维的指标、日志、调用链数据的异常变化都会反应成告警。

运维又有哪些场景？云智慧通过在运维场景的积累，将运维场景分为“一元场景”、“二元场景”和“转换场景”三大类。




什么是智能运维？与人工智能、大数据、区块链等技术不同，智能运维不是一项“全新”的技术，而是以智能运维场景为基础的智能技术应用和融合。智能运维是应用创新而不是算法创新。剥离场景谈智能运维没有实际意义。智能运维核心在于探索智能技术如何适配运维行业发展，为运维行业带来新的解决问题思路。



智能运维是围绕着指标、日志、追踪和告警四大数据和其转化的 AI 使能，我们认为运维场景的数据加智能技术就是智能运维 AIOps。举个例子，利用时序数据的处理方法可以对指标数据做异常检测或预测。日志是典型的半结构化数据，智能运维意味着对日志采用智能的处理方法抽象出对运维有意义的信息。通过模式识别、数据挖掘等手段对数据进行处理，可以满足多种场景多种业务需求。



面对海量运维数据，智能运维行业的企业或自研或与开源社区合作解决业务问题。Servicenow 自研了 MetricBase 数据库、NewRelic 作为 APM 厂商也研发了 NRDB。云智慧选择与 IoTDB 融合，配合自研的 DODB 提供智能运维方案。此外还有其他公司选择了 M3 和 Influxdb 等方案。

智能运维是一个大的赛道，数据在智能运维场景下是一项大挑战，每家智能运维厂商在数据层面都需要大量投入。以上是智能运维与数据的关系和当前数据对于智能运维行业的意义。


2.运维数据的挑战
运维场景下数据面临的挑战包括：

①体量大

运维数据体量大，对于 IT、OT 行业，随着技术进步业务发展，企业中需要检测的指标数量可能达到上千个，对于数据指标的存取是一项大挑战。

② 缺失补全

运维场景下，由于运维数据与业务数据相比优先级往往更低，因此经常出现数据质量不高的问题，此时需要对数据进行补全。数据补全在不同场景下采用差值填充还是零值补全？IoTDB 对此有很好的解决方案。

③ 峰谷潮

为了不让运维数据的计算与业务抢资源，存在业务繁忙时需要运维数据的采集不能影响业务，例如，我们限制了采集数据的探针 CPU 利用率在 2%，此时数据会峰谷潮式地到来：业务忙时没有数据、业务闲时数据大量涌入。

④ 乱序容忍

此外，受到采集设备和网络传输的影响，在真实运维场景下，6 个小时内的数据常常存在数据乱序问题。

⑤ 粒度齐整

采集器采集到的时序数据是依赖于 CPU 时钟或计算时钟的，采集到的数据常常不能严格按采集时间间隔卡齐，这对运维数据也是一大挑战。

⑥ 单点爆炸

如果设备有问题，一个采集器发了很多数据要如何解决。


03.IoTDB 的价值
IoTDB 带来了什么价值？如何解决运维赛道面临的问题？

我们用真实数据、真实用户场景进行了对比测试，对比了 ClickHouse(22.1.3.7)、IoTDB(0.12.4) 和 TDengine(2.2.0.2)。ClickHouse 是一个分布式存储系统，IoTDB 和 TDengine 是专业的时序数据库存储系统，企业在分析时序数据时既可以选择专业的时序数据库也可以选择 OLAP。测试机器配置如下：

CPU：Intel Core i7 16C

内存：32G

操作系统：CentOS 7.4

硬盘：机械硬盘

用低配置的机器进行测试，目的是为了适应工业互联网和 TOB 场景下，无法选择运行机器配置的情况，如实地反应数据库在低配置机器上的运行性能。

① 体量大

我们测试了单机 1 万条指标、100 亿个点、5 个并发写入数据的写入速度和压缩比。写入速率影响整个系统的响应时间，压缩比会影响运维整体资源的使用开销。

智能运维系统占用了大量机器资源的情况通常不能被企业客户接受。IoTDB 在该场景下 1.2 小时可以跑完测试，IoTDB 写入数据速率在 233.2 万条每秒，压缩比 81%，我们认为 IoTDB 数据库从压测数据看来整体具有优势。





② 乱序容忍

运维行业中经常遇到 10% 的乱序数据的情况，特点是乱序数据基本在 6 小时之内，较少见到今天受到前一天的数据。使用 ClickHouse，第一种方案可以选择将数据保存在内存中，6 小时后写入数据库；第二种方案是在读取时进行排序。使用 IoTDB 和 TDengine 可以直接存取数据，不用考虑数据顺序问题。我们运行了时间区间查询和时间区间加聚合函数两个查询进行测试。整体上看 IoTDB 的查询和聚合加查询效率都非常好，采用时序数据库也减少了数据交互的复杂度。




③ 缺失值补全

缺失值补全指的是对数据缺失进行线性/均值/特定值填充等方式补全数据。日志异常检测、把日志转换成指标，用指标进行异常检测，这类场景下往往需要零值填充数据。我们测试了零值填充和线性填充场景下的 IoTDB 和 TDengine 的效率。Clickhouse 数据库不支持零值填充和线性填充。




在运维场景下，会对日志进行分类后，对数据发生的数量进行指标化后进行异常检测。下图中是一个日志异常检测的真实案例，在智能运维场景中，把日志转换成指标是常见的运维日志处理手段。日志转换成指标后，大部分时间可能都是空值，只有少量场景下会出现日志量暴增的情况。因此零值填充是运维日志场景下需要应对的挑战。



④ 峰谷潮

通过引入消息队列可以应对峰谷潮给系统带来的影响。




⑤ 数据齐整

假设采集器第一个采集到的时间是 23:00:00.000，若以一分钟为粒度，下一个点理论上应为 23:01:00.000。但如果采集器的计算机时钟发生异常，在 23:00:00.012 多上报了一次数据，在运维场景中随着这种毫秒级的差异不断的累加，可能会导致一天内的点比前一天多一个点的问题出现，这时会引起同比环比计算产生误差，导致异常检测点错位。因此要做数据的粒度齐整和粒度卡齐。

Clickhouse 需要依赖外部系统进行先读取再卡齐，IoTDB 和 TDengine 支持了区间数据采样。  




图中是一个指标异常检测的真实案例，其中的数据是银行脱敏后的真实的日常交易数据，标红的点是异常点，即交易突增和突降。如果没有数据齐整化的处理过程，异常检测的同环比检测会不准确，进而产生误报、产生较大业务问题、影响业务连续性，导致平台产品质量被质疑。



① 单点爆炸问题

单点爆炸需要对数据进行去重。Clickhouse 对数据去重不友好，需要在内存中缓存数据后进行存储；也可以利用 replaceMergeTree 引擎，每次去重需要执行 OPTIMIZE TABLE visits PARTITION xx 操作；使用 MergeTree 引擎，需要用 distinct 去重，但导致数据库存储的数据量增多，磁盘存储空间消耗大。IoTDB 和 TDengine 则原生地支持了根据时间戳写入去重。

云智慧的智能运维平台架构如图，平台可以处理 IT 和 OT 设备产生的数据。数据上报后，经过 Kafka 消息队列写入智能运维算法平台。元数据存储在 MySQL 中，时序数据存储到 IoTDB 和云智慧自研的 DODB 内。上层应用包含指标管理、指标问题发现、异常检测和单指标预测和分析及日志分析、事件分析等引擎，云智慧也提供了基于 Tensorflow 的智能分析引擎。




云智慧的很多成员是 IoTDB 的 Commiter，我们对社区进行了回馈。我们向IoTDB 社区贡献了 Prometheus 的分布式、长时间跨度的持久化存储方案，使用 IoTDB 作为 Prometheus 的外存，代码已经合并到 IoTDB 主干分支。



Prometheus 内部主要分为三大块， Retrieval 是负责采样指标数据，TSDB（内置的本地存储时间序列数据库）是负责存储采样数据，PromQL 是 Prometheus 提供的查询语言模块。同时为了解决数据持久化的问题和更好的进行弹性扩展，Prometheus 提供了 http 接口：remote_write 和 remote_read，来实现数据的远程的读、写操作达到监控与数据分离的目的。

我们把 Prometheus labels 的 key 和 value 作为 IoTDB 的 tags，同时lables 中的 value 作为路径 Mertic name 当作 measurement 存储，通过这一的方式完成了 Prometheus 原始采样数据转换为 IoTDB 数据模型进行存储的操作。




该方案让 Prometheus 可以存储更长时间跨度的数据，效果如图。




04.案例分享
接下来将介绍一些云智慧在实际用户场景中针对时序数据的解决方案。

Case1：智能运维算法平台助力某银行客户海量指标实时异常发现

作为全国性的银行，各省、市的分行和支行指标，包括交易成功率、访问失败率等指标产生了海量数据，这些数据的采集和存储是极大的挑战。真实场景下，需要分析的实时数据指标量在百万级。

图中是网卡流入数据的实时异常检测，可以看到网卡数据具有规律的、周期性的数据特点，数据上流量的突增被认为是异常点。





云智慧在银行客户海量指标实时异常检测的实现方面，支持了如下功能：

① 变更自学习：业务变更时除变更点报异常外，能快速学习变更情况。

② 趋势自适应：能够学习到数据内在趋势，不会误报符合趋势变化的数据。




① 趋势+变更自学习：趋势叠加变更能自学习

② 跑批自适应：能够适应客户特定的跑批、周期性业务




① 周期自学习：能够学习数据内在周期

② 周期+趋势自适应：能够适应周期趋势叠加




① 忙闲时自学习：对于定时任务，其分为忙时和闲时，需要算法自学习

② 扩展至物理世界指标：对物理世界指标如温度、压强等也具备处理能力




Case2：智能运维算法平台助力某运营商携号转网业务异常发现

将日志转移成指标后对指标进行分析，在行业内是最常见的日志异常检测方法。左上角是真实运营商客户案例，在人面对打印出来的海量异常数据时很难直观地感知到异常存在。




云智慧会对日志进行模式识别后分类，右下角展示了日志分类后日志转换成的指标展现的情况。对指标进行异常检测会更加有效，如在某个点跑批业务失败导致日志没有打印，此时打印了其他错误日志，依照这些信息可对系统健康度进行检查，有很大价值。




根因分析是银行客户和其他行业大客户非常关心的功能。左上角是重点业务出现异常后智能运维平台提供异常点报告，分析入口侧异常是由于数据库还是缓存导致的异常；右下角是海量结构化数据的异常检测和分析，时序数据和数据库对根因分析有很大帮助。




云智慧智能研究院致力于 AIOps 前沿技术的研究，团队拥有 50 多名成员，大部分来自清华、北大、北航等国内外顶尖顶级高校，曾就职于微软亚洲研究院、快手、字节跳动等知名企业，研究团队 95% 以上拥有硕士、博士学历。团队自主研发了首款智能运维领域算法 SDK-Hours，其作为核心模块有效支撑了云智慧智能运维产品。团队积极与知名研究机构展开合作，联合清华大学软件学院成立了首个“智能运维研究中心”，与中科院软件所在根因分析形式建模达成深度合作，携手推进根因分析在工业智能运维场景中的落地。团队积极参与开源社区，成为 Apache 时序数据库 Apache-IoTDB Commiter，开源自主研发的运维可视化系统 FlyFish并获得中国开源云联盟优秀开源项目奖及 Gitee GVP-最有价值开源项目。团队发布并维护智能运维领域公开数据集-GAIA(Generic AIOps Atlas)。




05.Q&A环节
Q1：IoTDB 可以替代 Prometheus 吗？

A1：IoTDB 不是直接替换 Prometheus 的，Prometheus 具有自身的数据分发和数据收集的模块，使用 IoTDB 作为外存目的是解决 Prometheus 的长时间数据持久化存储的问题。Prometheus 使用了 sstable 到 memoryTable 的一套理论实现了数据持久化存储，Prometheus 官方建议存储 7-14 天的数据。云智慧将 Prometheus 和 IoTDB 的结合使 Prometheus 可以稳定地存储时间跨度更长的数据，也更加提升了数据压缩比。存储进 IoTDB 的数据可以直接进行数据挖掘和分析处理，对数据的二次利用有很高价值。

Q2：智能检测和归因的算法是什么？

A2：时序数据异常检测，主要分为三个流派：第一种机器学习或深度学习流派，提取大量特征，sigma 特征、周期特征、同款比特征等，进行分类；第二种是基于 STL 的分解，将时间序列拆解成周期型、趋势型等，按类型划分进行异常检测；最后一种是基于统计学的预测，例如可以用极值分布进行分析。在行业内，最常用和效果较好的方法是基于统计的方法，尤其在数据量大的情况下，机器学习方法很难落地，但机器学习和深度学习方法可能对其他场景下的异常检测更加适用。基于 STL 的分解方法对周期性数据效果非常好，但对非周期性数据不友好。当然我们适用了多种算法进行异常检测，满足不同场景。

Q3：IoTDB 用的是分布式版本吗？

A3：我们的实践是采用一个前置网关，分发数据到各个单节点 IoTDB 上。

最新经典文章，欢迎关注公众号

原文连接：
https://mp.weixin.qq.com/s/8Rg4ntmj2-fcBfXEwGi9_w