多点干油泵
今天的介绍会围绕下面四点展开：
∙智能运维概述
∙IoTDB 的价值
∙运维的数据挑战
∙案例分享
分享嘉宾｜张博 云智慧 CTO
编辑整理｜张德通 DataFun志愿者
出品平台｜DataFunSummit
01
智能运维概述
智能运维是什么行业？智能运维和传统的理解中的接网线、网管工作早已不同，这个赛道上有很多成功的企业如 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 等方案。
智能运维是一个大的赛道，数据在智能运维场景下是一项大挑战，每家智能运维厂商在数据层面都需要大量投入。以上是智能运维与数据的关系和当前数据对于智能运维行业的意义。
--
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。测试机器配置如下：
金属丝的杨氏模量
oCPU：Intel Core i7 16C
o内存：32G
o操作系统：CentOS 7.4
o硬盘：机械硬盘
用低配置的机器进行测试，目的是为了适应工业互联网和 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 支持了区间数据采样。
