我是望繁信科技CTO，应该是中国最早一批从事大数据分析并将大数据分析技术应用到了流程挖掘中的从业人员。今天，借这个话题与大家分享一下望繁信是如何利用大数据技术将流程挖掘做到商业落地的。通过这次分享，希望能有更多流程挖掘的爱好者了解我们，加入我们。

在此之前，我们先看一下三个知名的开源流程挖掘项目，1）ProM， 2）Pm4PY，3）Apromore，我分别说下这三个开源项目在商业落地方面的优缺点。

首先，ProM我不想展开说，因为这是个起源很早的纯学术研究项目，里面可以通过Plugin实现各类流程挖掘算法，但是这个开源项目最大的问题是纯PC客户端版本，要从里面剥离出我们可商业落地的算法和技术架构的工作量太大，因此，要以ProM为蓝本快速实现商业落地很难，但如果大家对算法感兴趣，ProM到是个做实验的不二选择。

其次，Pm4Py是个了不起的开源学术项目，我从2019年开始就在跟这个项目的更新，更新迭代速度惊人，最大的优点的是以接口的方式对外暴露，所以常见流程挖掘算法和计算框架Pm4Py都有，都可以通过方法和接口去调用；因此只要根据接口开发一个前端界面就可以迅速搭建一个流程挖掘引擎，换上自己公司的logo就是个可用的平台；只要你也愿意在Pm4Py基础上做的二开工作也开源出来，Pm4Py倒是个不错的选择。

最后，Apromore是商业行为的开源项目，整合了流程挖掘的前后端技术，是个开箱即用的流程挖掘引擎，但是你得注意了，很多高级功能并没有开源出来，还需要你做二开，那么有人会问为啥Celonis、UI-path等巨头不开源流程挖掘，而Apromore要开源呢，这又回到了一个开源协议的问题，学术版本的流程挖掘几乎都是GPL开源协议，Apromore也是一群大学教授搞的，所以Apromore的CE版本所二开的库都必须遵循GPL协议，比如流程数据XLog（就是个标准GPL），因此他们在上面做二开就不得不开源，这也是个无奈之举。但是商业版本Apromore把GPL开源协议的代码都重新编写了一遍；所以Apromore CE可以迅速搭建一个差不多可以用的流程挖掘引擎，只要在上面下点功夫做二开，改下前端的样式和公司的logo，就可以快速上线一个流程挖掘平台。

看到这里，你有没有发现开源项目的作者们清一色都是大学的学术工作者，我想他们应该都没有考虑流程挖掘如何在大企业大数据量上的应用，根据我们的实际测试的结果，Pm4Py和Apromre CE的数据处理量为百万级别（event数量），如果是千万级别的数据量，那对不起直接卡死，最关键的问题是它们都是单机版，就是没法做分布式，这也最大程度限制了它们的数据处理量。

因此我们望繁信走了一条自己的路，在大数据分析技术这个巨人的肩膀上实现流程挖掘的商业落地！

提到大数据，大家第一个想到的是hadoop，hive，spark，impala，hbase，flink，clickhouse，cassandra, mongodb等关键词，我们的技术方案也是在这个基础上做的，首先所有的eventLog数据要做分布式存储，对上提供数据读写服务，再向上提供数据计算服务。

很多小伙伴会说数据查询啥的用hive+hadoop就很简单而且实用，这也是大数据存储和读写的好方法，但是问题来了，这是离线的技术方案，也就是说hive对上提供的数据读写效率太慢，达不到流程挖掘效率的要求；那又有人说用impala、druid、clickhouse等都能支持eventlog的存储，并通过SQL对上提供数据服务不也可以嘛，可以确实是可以，但是流程挖掘的计算和分析过于复杂，比如复杂流程变体计算、一致性检验计算、社交网络分享计算、根因分析计算模块、多节点跟随的过滤条件等等，这些想用SQL来完成实在困难重重，即使实现效率也不高；接下来自然而然就想到了non-sql的方案，无论是hbase，mongodb还是cassandra都是存储eventlog的好方法，可以将eventlog的属性列放在non-sql数据库中，然后通过spark读取这些KV数据，通过RDD来实现eventlog的各种在线计算。

（流程挖掘大数据技术架构）

上图为我们望繁信的流程挖掘大数据技术架构图，当Eventlog的数据量达到千万级别以上的时候，就需要将数据分布到各个workers上，数据的存储媒介我们用了Hbase，在Hbase上利用KV数据特性开发了一个数据服务API，将Hbase数据快速无缝地对上提供数据分析支撑。计算的核心放在Spark引擎中，Spark就不需要赘述了，自从2015年（我是从2014年spark只有0.8版本的时候就开始玩的）开始在大数据界一直有着良好的口碑并获得很多大厂的青睐。

但是！！！Spark是一个“通用”性的并行计算框架，但很多这种“通用性”对流程挖掘处理EventLog来说会很冗余，我们为了能够让Spark能更快的处理EventLog数据，将Spark RDD中的shuffle等算法做了优化，降低反复硬盘操作并更大限度地利用内存来提速EventLog的并行处理速度。又一个关键问题来了，如果Spark 只用local运行的话没什么问题，那么单机运行就可以了，可是在Spark集群中运行是通过mesos或者yarn等方式来进行任务资源管理的，而这套任务管理体系是通过spark-submit来提交任务，为了能方便管理EventLog在spark集群中的任务队列管理，我们在yarn的基础上开发了基于WebSocket的任务管理引擎，这样可以高效地提交和管理正在运行的Spark任务，也进一步提速了EventLog的计算速度。

根据我们最新的客户数据结果，处理5000万行EventLog在点击任一类型过滤条件后，聚合各种复杂的分析，在线分析和加载的总时间不超过8秒，当然取决于过滤后的数据量，如果过滤后只有百万级的数据，加载时间在2秒左右，越少时间越短。

最后再说一下流程图算法，画流程图有两个知名的开源软件，一个是d3-dagre，还有一个是GraphViz，这两个包所提供的算法我都仔细研究过，但从使用上来说差别不大，但是算法略有不同，用哪个都是可以。但是这两个包算法都有个问题，算法复杂度为，当流程图边非常多的情况下，需要耗费大量的CPU性能；因此我们流程图算法在d3-dagre上做了二开，用组合优化算法优化了流程图的层次和排序，降低了算法复杂度，因此流程图的速度比传统的d3-dagre有了很大提升。