流程挖掘需要哪些ETL工具？

流程挖掘需要ETL吗？

ETL工具会从源系统提取数据，转换为可用格式，再加载供分析使用。本文聚焦流程挖掘项目实际需要的ETL工作，以及哪些环节可以省去，不是数据管道选购指南。如果系统能导出记录，文件中也包含案例ID、活动和时间戳，您通常可以跳过数据管道，直接加载导出文件开展首次分析。

答案取决于流程、相关系统，以及分析需要多频繁地更新。先提取能够回答问题的最少数据，再根据首次分析结果决定是否需要数据准备和自动化。

以下三种情况值得投入ETL工作：

• **流程涉及多个系统。**需要关联记录并统一标识符，才能端到端追踪一个案例。
• **源数据无法直接读取。**活动名称、时间戳或案例标识符需要标准化，分析才能使用。
• **需要重复提取数据。**如果数据每天都在变化，分析也需要及时更新，手动导出就不再实用。

这些情况说明需要准备数据，但不代表在回答第一个问题前就必须搭建数据管道。先加载现有数据，找出缺失之处，再决定下一步。

以下情况也可以不搭建单独的数据管道：

• 流程主要记录在一个系统中。
• 相关记录可以导出。
• 导出文件包含案例ID、活动和时间戳。
• 文件规模适中，可以手动准备。
• 您仍在验证数据能否回答问题。

您可以在电子表格中重命名列、修正明显的不一致，并删除不需要的字段。手动准备不必成为长期做法：当分析证明有用且数据需要频繁更新时，再将重复步骤自动化。

数据提取必须包含什么

流程挖掘事件日志需要三个字段，并且每个事件占一行。

成本、用户、团队、客户细分或CO2足迹等属性均为可选项。它们也能让流程视图进一步用于分析：保留的每个属性，之后都可以作为筛选条件、拆分维度或度量。数据集属性参考介绍了各字段可用于哪些分析。

源数据中有某个字段，不代表它就能直接使用。不同系统中的案例ID如果不一致，事件就无法关联；活动标签不统一，一个实际步骤可能被拆成三个；以文本存储的时间戳可能导致事件顺序错误。映射数据前先检查导出文件，并优先核实三个必需字段。关于日志还需包含哪些内容，请参阅流程挖掘需要什么。

最简可用事件日志查询

如果源数据已经按每个活动一行存储，查询只需执行选择操作。以下示例假设表名为process_events，其中包含案例、活动和事件时间：

SELECT
  case_id        AS case_id,
  activity_name  AS activity,
  event_time     AS timestamp
FROM process_events
WHERE case_id IS NOT NULL
  AND activity_name IS NOT NULL
  AND event_time IS NOT NULL
ORDER BY case_id, event_time;

该查询为三个字段命名，删除无法使用的行，并按案例对事件排序。请根据您的数据源调整表名和列名，然后在加载前抽查一些案例：每个案例都应包含预期的事件，且顺序符合实际执行工作的人员的认知。

哪些转换步骤值得关注

数据转换应修正可能影响分析结果的问题。大多数情况下，以下四个步骤就足够了。

1. 规范化事件

   即使源数据将流程步骤分别存储在不同列中，也要将每次活动单独放在一行，并包含案例ID和时间戳。

2. 确保时间戳可用

   确认这些值是有效的日期和时间，并检查它们使用的是本地时间还是UTC。合并多个来源时应统一时区，否则事件顺序可能失真。

3. 统一活动名称

   每个实际步骤使用一个标签、一种语言和一种拼写。不要为了缩短列表而合并看起来相似、实际不同的步骤。

4. 仅在需要时关联数据源

   找出关联记录的键，并验证其是否匹配。关联操作如果重复事件或丢弃案例，就会改变流程视图，因此请比较操作前后的记录数。

如果导出文件已经做到每个事件一行，并包含三个必需字段，就无需转换。这很常见，并非走捷径。如何创建流程挖掘事件日志通过Excel和SQL示例介绍了同样的内容。

应该将事件日志加载到哪里？

将准备好的数据加载到您要进行分析的平台。首次查看时，一个文件就够了：准备数据、加载文件、查看流程视图，再根据数据所能支持的分析完善提取内容。不要只为流程挖掘新建存储层。如果团队已经维护数据仓库或数据湖，就继续将数据保存在那里，并加载该环境生成的文件。

支持的数据格式页面列出了详细信息。如果不想手动上传，也可以通过数据API使用定时任务推送相同格式的文件。

加载的数据集会关联到模型。面板会显示其中包含的案例，并标出尚未映射的活动。 Source: ProcessMind

无论采用哪种方式，数据都应加载到实际开展分析的地方。放在无人维护的文件夹中的文件不算数据策略；有人映射并审核的数据集才算。

哪些ETL工具适用于流程挖掘？

没有一份ETL工具清单适用于所有项目。请选择工具时，应考虑数据存放位置、团队现有工具，以及日志需要多少准备工作。ETL本身属于常规数据工程，流程挖掘唯一特有的要求是输出数据保留案例ID、活动和时间戳。

流程挖掘项目中最常见的工具包括：用于提取数据和进行SQL转换的CData和dbt；用于数据仓库的BigQuery、Snowflake和Databricks；以及在系统间传输数据较为复杂时使用的Talend、Apache NiFi和Airbyte。开源工具也是可行选择，NiFi和Airbyte通常是首选。还有一些厂商提供专为流程挖掘打造的ETL工具，例如Evidant和Konekti，并为常见系统提供模板。

这些只是示例，并非推荐，也不代表任何合作关系。建议选择团队在项目结束后仍能维护的工具和格式，并尽可能将转换逻辑保留在流程挖掘产品之外。内置ETL需要谨慎权衡：留在同一平台时确实方便，但数据准备逻辑也会因此难以复用于后续的分析或AI项目。

数据加载后，如何管理？

数据提取只完成了一半。后续如何管理数据集，决定了几个月后分析结果是否仍然可靠。

• 根据内容命名数据集。 Q1_2025_Sales_Data或Customer_Support_Logs都比export_final_v3更清楚。
• **根据用途选择格式。**手动上传的小文件用CSV或Excel即可。大型数据集或由数据管道生成的数据，使用Parquet或ORC更合适。
• **映射前先预览。**检查数据结构、列类型和部分行，并在数据集配置中确认案例ID、活动和时间戳。
• **检查活动映射。**先用自动映射完成初步匹配，再逐一处理未映射活动。对于实际发生但未留存数据记录的步骤，可标记为数据流经，使其保持可见，同时不影响数值。
• **定期刷新，无需重新构建。**对于定期导出的数据，按分析所需的频率（日更或周更）用新文件替换数据集，并保留原有映射。
• **记录数据未覆盖的内容。**在分析备注中注明缺失的时间段、系统和步骤，因为这些因素会影响最终结论。
• **管理访问权限，并归档数据。**仅向有需要的人员开放数据集；项目结束后，归档不再使用的数据。

要点总结

ETL是流程挖掘项目的手段，而非目标。合理设置ETL，避免拖慢首次分析：

• 从本周能获取的数据开始。
• 无论删去哪些其他字段，都要保留三个必需字段。
• 先加载导出文件，待分析证明有必要后再自动化加载。
• 使用团队已经在维护的工具和格式。

相比管道过于简单，更多项目失败的原因是：还没弄清要回答什么问题，就先搭建了数据管道。