MatrixDB：超融合时序数据库在泵车智能运维中的实践
分享嘉宾：于成铭 四维纵横 架构方案总监
出品平台：DataFunTalk
导读：今天分享的主题和?程?辆的全周期智能运维解决?案有关，首先对基于传统的全周期智能运维方案进行一个概述，并基于传统架构的一些痛点提出我司研发的新产品——MatrixDB超融合时序数据库的一些技术特点；最后简单介绍我司的MatrixDB生态。
今天的介绍会围绕下面三点展开：
--
01
工程车辆全周期智能运维传统架构
1. ?程?辆简介
混凝?搅拌?、?卸?、压路机、混凝?泵?等专?于?程领域的?辆都可以被称为?程?辆。
得益于新基建的蓬勃发展，?程?辆?业已逐渐进?世界主舞台，三一、中联等?业?头企业已经在各自领域做到了世界第?。
然而，不同的?程?辆具备各自独特的功能；而每一种功能，一般也都具备各自独特的智能化手段，以及测试方法。
因此，相?于家?汽?，工程车辆的智能化还处于转型起步阶段。
对于企业内部而言，在新的领域如果?法迎头赶上，往往处于不翻身就翻盘的尴尬。
2. ?程?辆全周期智能运维简介
上图以泵车为例，从发动机的角度查看发动机的情况、泵车的情况、耗油的情况，以及对泵车的臂架、臂管等状态和稳定性的评估。
综上所述，对于工程车辆，客户关注重点主要在于：?辆健康状态、赚了多少钱、更多赚钱机会、?辆残值等。
3. ?程?辆全周期智能运维的传统架构实现
前文已经讲述了工程车辆全周期管理平台对于客户的价值；对于平台数据接入的现状如下：
上图展示了一类典型的全周期管理平台内部架构图：
① 各种类型的原始车辆数据汇总传入Kafka进行数据汇总
② Kafka数据汇总结果可以传入多个组件进行不同功能的使用
③ 对于数据的中间分析结果，可存入MySQL（或其他存档中）便于前后端交互
4. 全周期智能运维平台的痛点
前文讲述了客户常见的管理平台的内部架构整体情况；在工程应用中发现，该类平台架构存在如下诸多的痛点：
① 痛点一：复杂架构问题
架构复杂，会直接造成资源上的浪费；另一方面，数据从不同系统之间反复传递，会带来效率上的降低。
与此同时，从团队管理角度来看，架构复杂会导致招?难、养?难、留?难，给团队会带来成本压力。
② 痛点二：数据质量问题
除了资源浪费问题，遇到的第二个比较严重的问题就是数据质量问题。所谓数据质量，主要指的是：数据满足需方的程度，包括数据格式、数据准确性、数据时间一致性等。这里会带来一系列的问题，比如数据的空值、乱序，数据时间间隔不统一，数据出现明显错值等问题，会严重影响后期数据的使用。
③ 痛点三：执?效率问题
Hadoop + Spark这样的传统?数据架构更适合map reduce的场景；相较于早期基于hadoop的map reduce架构，Spark系统增加了懒加载模式，还增加了基于内存的计算。这样的处理确实使执行效率得到了一定程度的提高，然而对于大多数面向过程的工业计算，两者仍然难以实现很好的契合，比如算法思路连续性的保持等。最典型的体现是：对于分布式的HDFS系统，Spark系统无法确定待处理数据的位置，因此每次在处理和分析数据之前，需要首先发出相应的请求来获取数据；这样随着整体数据量的积累，即使是?规模的数据验证也会需要较?时间的等待（目前系统使用的Scala语言；若使?的是Python，则等待时间可能会更?）。
④ 痛点四：开发效率问题
除了系统的执行效率，开发效率也是一个大问题。这里从Sublime截取了3张代码图，可以看出存在大量的胶水代码；特别是在与pandas UDF的交互中，需要明确定义输入和输出文件的变量名、列名等，而且计算过程中也需要不断地对行和列进行索引，因此不可避免地出现非常多的胶水代码，大大增加了代码的开发和维护成本，降低了开发的效率。
--
02
MatrixDB超融合时序数据库
1. MatrixDB超融合时序数据库的提出——将复杂留给数据库
基于前文所述的诸多痛点，经过多轮调研和尝试，提出了MatrixDB超融合时序数据库，将复杂的分析和存储过程，通过一款数据库统一实现；从而减轻开发人员的工作量，让开发人员更少地参与数据治理的工作。
2. MatrixDB基本架构设计
上图展示了MatrixDB超融合时序数据库的基本架构：
这样，所有对涉及数据库有关的操作都可以在同一数据库内完成。例如，读取实时数据，只需向整合层发出请求即可；同理，读取后端数据，需向算法结果层发出请求。
3. MatrixDB的功能优势
数据库查询中常用的SQL语言一种面向数据的查询语言，很难支持工业数据分析中常用的诸如FFT变换、小波变换等类型的分析；而常见的设备预测性维护、故障诊断等问题主要是面向过程的分析，因此不可避免地使用到python/R这类面向过程的分析语言。
在实施层面，可以考虑使用pyspark结合pandas_UDF，不过前文已经讲述过这种方式的弊端：会带来大量的胶水代码，不利于系统的开发和维护。另一种方式就是在数据库中通过内建查询来实现（定义存储过程，并且把存储过程声明为外部的plpython3u语言；对于结果的存储，只需定义存储结果表，无需另行定义pandas结构）；因此大大减少了胶水代码的使用，大大提高了开发效率；由于数据结构清晰，大大降低了获取数据请求的时间，使计算更贴近数据，更加高效简洁，这也是MatrixDB对比Spark/Hive的一大优势。
MatrixDB的功能优势：
4.MatrixDB的读写性能优势
从性能测试角度看，窄表单机每秒可写2200万?以上；数据可实现分钟级、秒级、甚至毫秒级的实时写入，这也是该全周期运维平台可以实现实时查询的基础，也是对比旧版本的一大改进。
从功能角度看，除了常规的顺序写?外，对于设备网络等因素带来的延迟写?、乱序写入，以及同设备多测点数据的分批写?（涉及数据更新、插入、合并等多种烦琐操作）等，MatrixDB都可以实现良好的支持。
另一方面，在工程数据分析的过程中，经常会涉及到指标的调整；体现在数据库中，就是对表结构的动态增减调整。如果使用窄表，可以很容易地实现动态增减；然而窄表不利于后期数据的使用，这也是MatrixDB技术团队攻破的一大技术难题：在宽表的基础上增加对表结构动态增减的支持，同时保证写入和查询效率的不缺失。
此外，平台还可支持自动降采样（分层）功能，对将原始数据分层成中间结果，对中间结果进行进一步的分析，大大提升分析的效率。
平台还有一项功能值得一提：持续聚集。类似于T+0机制，用户可预设算法，该预设的算法作为一个固定的物化视图；随着数据的写入，自动计算结果并写入到指定表中。
最后一点，该平台提供丰富的工具支持（flink、kettle、nifi等常用ETL工具），以及灵活的接?支持（SQL、JDBC、HTTP等常用接口）。
总之，MatrixDB数据库从源头着?实现数据治理，让用户聚焦业务本身?不是数据处理。
5. MatrixDB的存储优势
另一个用户经常关心的问题是数据量较大时的存储效率问题。从截图中可以看出，当原始数据量较大时，使用原始分区表，采用行式存储方式，占用空间达130G；同一张表改用MatrixDB数据库存储，占用空间仅5.75G，压缩比超过10倍。MatrixDB数据库存储可以理解成一种特殊的列式存储，在存储之前基于指定的设备编号进行了排序功能。
6. MatrixDB在工程车辆全周期智能运维解决方案应用的优势小结
客户通过智能运营平台对混凝?泵?进?智能化运维。实现的场景包括针对研发?员的决策?撑、针对服务?员的预测性维护以及针对客户的设备健康管理平台。平台?前接?了超过25000台设备。每天的数据量?于8亿条，有效指标400余列，指标包括控制稳定性、油耗分析、堵管分析等??个。
上图展示了MatrixDB数据库系统在部署前后，从开发、功能和性能等方面的对比情况。相?于原先使用的传统系统：
--
03
关于MatrixDB
1. MatrixDB生态简介
MatrixDB本身是基于GreenPlum数据库和PostgreSQL数据库进行的优化，因此继承了上述两种数据库中的优点：标准SQL的丰富性，查询速度较快，并发数较高等。
GreenPlum数据库和PostgreSQL数据库的优点：
① 按表数量
② 按数据类型
③ 按分析能?
另一方面，企业级平台常用的Hadoop/Spark等开源工具在使用的过程中经常出现版本不兼容等诸如此类的问题；MatrixDB数据库系统很好地避免了这类麻烦，也与此同时还增加了方便易用的图形化部署、在线扩容等功能，可以单机部署，也可集群部署，具备了理想的企业级运维能力。
企业级运维平台：
此外，MatrixDB数据库系统具备完善的开发?具，支持常用的协议；用户使用的过程中，除了需要单独维护一些分布式的功能外，其他方面和单机版数据库，在使用方式上没有区别；但是其性能更高，可管理的数据量更大。
MatrixDB数据库系统的接口支持：
2. MatrixDB研发团队介绍
① 公司的MatrixDB研发团队的核心骨干成员主要来自Greenplum原?团队：
② 团队贡献
③ 团队荣誉
