智能运维是围绕着指标、日志、追踪和告警四大数据和其转化的 AI 使能，我们认为运维场景的数据加智能技术就是智能运维 AIOps。举个例子，利用时序数据的处理方法可以对指标数据做异常检测或预测。日志是典型的半结构化数据，智能运维意味着对日志采用智能的处理方法抽象出对运维有意义的信息。通过模式识别、数据挖掘等手段对数据进行处理，可以满足多种场景多种业务需求。
面对海量运维数据，智能运维行业的企业或自研或与开源社区合作解决业务问题。Servicenow 自研了 MetricBase 数据库、NewRelic 作为 APM 厂商也研发了 NRDB。云智慧选择与 IoTDB 融合，配合自研的 DODB 提供智能运维方案。此外还有其他公司选择了 M3 和 Influxdb 等方案。
智能运维是一个大的赛道，数据在智能运维场景下是一项大挑战，每家智能运维厂商在数据层面都需要大量投入。以上是智能运维与数据的关系和当前数据对于智能运维行业的意义。
--
02
运维数据的挑战
运维场景下数据面临的挑战包括：
①体量大
运维数据体量大，对于 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 数据库不支持零值填充和线性填充。
