1. 从“人肉”到“资产”一个数仓工程师的痛点自述如果你在数据仓库团队待过尤其是负责过用户行为数据也就是我们常说的“埋点数据”的接入、清洗和治理那你一定对下面这个场景不陌生。产品经理或者业务方拿着一个Excel表格过来里面密密麻麻写了几十个新的埋点需求“这个按钮要加点击事件那个页面要加曝光事件参数名是xxx取值是yyy……” 你接过需求开始“翻译”先在数据采集SDK的配置后台可能是神策、GrowingIO或者自研的里一条条手动录入这些规则确保事件名、参数名、参数类型都正确。然后你转头去数仓的ETL抽取、转换、加载脚本里再写一遍逻辑从原始的Kafka或日志文件中根据这些规则解析出字段做类型转换处理空值最后写入到ODS原始数据层或者DWD明细数据层的表里。这个过程我们戏称为“人肉同步”。问题在哪规则维护了两份且完全靠人工保证一致性。采集平台改了一个参数类型数仓脚本忘了改下游报表直接报错。业务方临时加了个枚举值如果只在采集端加了数仓没同步这个新值在分析时就“消失”了。更头疼的是当你想回溯某个数据字段的来龙去脉时你得翻聊天记录、找需求文档、对照ETL代码链路长且易出错。规则这个数据生产的“图纸”散落在各处没有形成可管理、可复用、可追溯的资产。这就是“得物”或其他中大型互联网公司数仓团队在埋点数据治理上普遍面临的挑战。而“Hermes Agent”这个概念的出现以及与之相关的“规则资产化”工作流重构正是瞄准了这个痛点。它不是一个简单的工具更新而是一次从工作模式到数据治理理念的系统性升级。简单说它的目标是把埋点需求、采集规则、数仓处理逻辑用一套统一的、声明式的“规则”语言描述出来并使其成为贯穿数据生命周期的核心资产。今天我就结合对相关技术趋势的理解和实践经验来拆解一下这套工作流重构的核心逻辑、关键组件以及落地时你必然会遇到的“坑”。2. 解构 Hermes Agent它究竟是什么又解决了什么问题首先需要澄清一个常见的混淆点。从网络热词来看“Hermes Agent”这个词同时指向了几个不同的概念这增加了理解的复杂度。我们需要把它们拆开看作为开源AI智能体框架的 Hermes Agent这是目前最火热的概念。一个基于大语言模型LLM的AI智能体开发框架允许你通过配置让AI自动执行网页浏览、信息提取、工具调用等任务。它的核心是“智能”与“自动化”。作为数据采集端“信使”的 Hermes Agent在数据领域的语境下“Hermes”赫尔墨斯是希腊神话中的信使之神。因此很多数据采集SDK或代理程序会以“Hermes”命名其角色是作为“信使”将客户端App、Web的埋点数据可靠地传输到服务器。这里的“Agent”更偏向一个常驻的、负责传输的代理程序。在得物语境下的 Hermes Agent结合标题“重构得物数仓工作流”这里的 Hermes Agent 极有可能是一个埋点规则的管理与执行引擎。它扮演的角色是上述两种概念的结合与升华它不仅是一个传输代理更是一个规则执行器它不仅执行规则还可能通过一定的智能化手段不一定是LLM可能是规则引擎来管理和应用这些规则。所以在本文讨论的“数仓工作流重构”场景中我们可以这样定义 Hermes Agent一个中心化的、统一管理埋点采集规则并能将这些规则自动同步并应用到数据采集端与数仓处理端的系统或服务。它的核心价值是解决“规则一致性”和“流程自动化”问题。它具体解决了哪些问题消除信息孤岛将原本散落在产品文档、采集平台、ETL代码中的规则收归到一个统一的“规则仓库”进行管理。这里存储的是标准的、声明式的规则定义比如用JSON Schema或某种DSL描述。实现单向发布多处消费数据产品经理或分析师在“规则仓库”中定义或修改一个埋点规则。Hermes Agent 负责将这个规则“发布”出去向下游一采集端自动生成或更新数据采集SDK的配置确保App/Web能按新规则上报数据。向下游二数仓端自动生成或更新ETL任务如Flink SQL、Spark SQL脚本确保数仓能按新规则解析和清洗数据。保障数据血缘与质量因为处理逻辑源于同一份规则资产所以从数据采集到数仓各层ODS-DWD-DWS-ADS的血缘关系是清晰、可自动生成的。同时规则本身可以包含数据质量校验逻辑如非空检查、枚举值检查、数值范围检查在数据入库的早期环节就能进行拦截或告警。注意这里描述的是一种理想的、高阶的架构理念。在实际落地中可能初期只实现了规则仓库和向数仓端的自动同步采集端的同步可能仍需部分人工介入。但方向是明确的让规则驱动一切。3. 规则资产化工作流重构的核心引擎“规则资产”是这次重构的灵魂。它不再是文本描述而是结构化的、可编程的、可版本管理的对象。3.1 一份规则资产长什么样我们可以用一个简化的例子来说明。假设要定义一个“商品详情页按钮点击”事件。{ event_id: product_detail_click, event_name: 商品详情页点击事件, description: 用户在产品详情页点击各类按钮的行为, owner: 电商产品部-张三, status: active, // draft, active, deprecated fields: [ { field_name: page_type, field_type: string, is_required: true, default_value: product_detail, description: 页面类型固定值 }, { field_name: element_id, field_type: string, is_required: true, description: 被点击元素的唯一标识 }, { field_name: element_name, field_type: string, is_required: false, description: 元素展示名称 }, { field_name: product_id, field_type: int64, is_required: true, validation: { min: 1 }, description: 商品ID必须大于0 }, { field_name: click_timestamp, field_type: timestamp, is_required: true, description: 客户端点击时间戳毫秒级 } ], output_targets: [ { target_type: data_collection, config: { sdk_type: iOS/Android/Web, // 可自动生成各端SDK的初始化或事件上报代码片段 } }, { target_type: data_warehouse, config: { ods_table: ods_log_click, dwd_table: dwd_page_click_event, sql_template: SELECT ... FROM {raw_table} WHERE event{event_id} // 可自动填充的SQL模板 } } ] }这份JSON或YAML或专用DSL就是规则资产。它定义了事件的元数据、字段规范、校验规则以及输出目标。3.2 规则资产如何驱动工作流新的工作流将彻底改变需求提出与规则设计产品经理不再提交Excel而是在一个Web界面上通过表单或低代码方式填写事件信息、拖拽字段定义。系统后台即生成上述规则资产草稿。这一步就将非结构化的需求变成了结构化的资产雏形。规则评审与上线数据开发、测试、业务方在线对规则资产进行评审类似代码Review。确认后规则状态变为active。这个“上线”动作触发了Hermes Agent的工作。Agent自动同步Hermes Agent 监听到规则资产状态变更。根据output_targets配置调用不同插件或适配器采集插件调用数据采集平台如神策的API自动创建或更新对应的事件与变量。数仓插件在ETL调度平台如Airflow、DolphinScheduler中自动创建任务或向实时计算平台如Flink提交新的SQL解析作业。它可能会渲染预置的SQL模板将规则中的字段映射、类型转换逻辑固化成代码。数据验证与监控规则资产中定义的validation规则可以被下游数据质量平台引用在数据入仓后立即进行校验。同时规则资产本身的变更历史就是最清晰的数据血缘和变更审计日志。3.3 资产化的深远影响效率提升从“天级”甚至“周级”的埋点上线周期缩短到“小时级”。规则一旦审核通过后续流程全自动。质量保障源头统一避免了人工同步导致的不一致。结构化校验前置问题发现更早。成本降低数据开发人员从繁琐的、重复的“规则翻译”工作中解放出来更专注于数据模型建设和复杂业务逻辑处理。能力沉淀规则资产库成为公司的数据字典和知识库新人能快速了解现有数据体系数据分析的取数成本大大降低。4. 技术架构选型与关键组件拆解要实现上述愿景技术架构上需要精心设计。这里结合常见的开源组件和业界实践勾勒一个可行的架构蓝图。4.1 核心组件分层一个完整的“规则资产化”平台通常包含以下几层规则管理与设计层前端提供Web界面进行规则的可视化设计、编辑、评审、版本管理和搜索。技术上可以是React/Vue 后端API。关键在于设计友好且强大的规则设计器能支持复杂的数据类型和校验逻辑。规则存储与元数据层后端核心是“规则资产库”。可以用关系型数据库如MySQL存储规则的基本信息和版本用文档数据库如MongoDB或直接使用Git仓库来存储规则的具体内容JSON/YAML。强烈建议将规则文件用Git管理这样可以天然获得版本历史、分支管理和变更对比的能力。元数据服务负责提供规则的检索、查询和血缘分析API。规则执行引擎Hermes Agent核心这是一个无状态的微服务集群。它的职责是监听规则变更事件如监听Git的Webhook或监听数据库的binlog。解析变更的规则资产。调度对应的插件去执行具体动作。它本身不处理具体业务逻辑只是一个调度器和协调器。插件生态层这是灵活性和扩展性的关键。每个下游系统都需要一个对应的插件。采集插件封装对神策、GrowingIO、自研采集SDK等平台的API调用实现规则的自动配置。数仓插件这是最复杂的插件之一。它可能需要实时链路生成Flink SQL或Flink CDC作业配置提交到Flink集群。离线链路生成Spark SQL脚本或Hive SQL文件并在Airflow等调度系统中创建DAG任务。元数据注册自动将新建的表和字段信息注册到Hive Metastore或数据地图中。质量插件根据规则中的校验逻辑自动在数据质量平台如Griffin、Deequ中创建监控任务。通知插件在规则上线、同步成功/失败时通过钉钉、企微或邮件通知相关人员。下游系统层即现有的数据采集平台、实时/离线计算引擎、调度系统、数据质量平台等。4.2 关键技术与选型考量规则描述语言DSL是使用通用的JSON Schema还是自研一套DSLJSON Schema生态好工具多但表达复杂的业务逻辑可能不够直观。自研DSL更贴合业务但设计和维护成本高。折中方案是用JSON/YAML作为基础格式通过定义一套标准的“扩展字段”来表达业务语义。变更监听机制Git Webhook 是最优雅的方式能与开发流程完美结合规则评审即代码Review。如果规则存DB则需要通过Canal/Debezium监听binlog或业务系统主动发送事件到消息队列如Kafka。执行引擎的可靠性Hermes Agent 必须考虑失败重试、幂等性、并发控制。例如同一个规则短时间内被多次修改Agent需要保证最终状态的一致性。可以引入一个轻量级任务队列如Redis Streams或RabbitMQ来缓冲任务由Agent的Worker消费执行。插件开发的标准化需要定义清晰的插件接口Interface包括初始化、执行、回滚、健康检查等方法。让插件开发者只需关注与下游系统的交互逻辑。4.3 与热门技术概念的结合点从网络热词可以看到dify工作流、n8n工作流、comfyui工作流等概念很火。它们代表了低代码/可视化的自动化流程编排。Hermes Agent 的规则执行流程本身就是一个非常典型的工作流规则变更 - 触发 - 执行采集插件 - 执行数仓插件 - 执行质量插件 - 发送通知。在实现时完全可以考虑集成或借鉴这些工作流引擎来可视化地编排和监控规则发布的全过程进一步提升可观测性和可运维性。5. 落地实践避坑指南与心得分享理想很丰满但落地过程一定充满挑战。下面分享几个关键“坑点”和应对思路。5.1 坑一历史存量数据的迁移与兼容新系统上线最难处理的是历史。已有的成千上万个埋点对应的ETL脚本散落在各处如何平滑迁移思路不要追求一步到位。采用“双轨制”和“增量迁移”。新老并存新上线的埋点走新流程规则资产化。老埋点暂时不动继续由原流程维护。逆向工程开发一个“逆向解析”工具尝试从现有的ETL脚本、数仓表结构中反向提取出规则定义录入到新系统。即使不能100%自动化也能极大减少人工梳理的工作量。逐步迁移当业务方对某个老埋点提出变更需求时要求其必须通过新系统重新定义和上线借此机会将老埋点迁移到新体系。这样迁移成本被分摊到日常需求中阻力最小。5.2 坑二规则冲突与覆盖问题多个产品经理可能定义了相似或冲突的规则。比如对同一个“购买”事件A定义了一个coupon_type字段B定义了一个voucher_type字段实际业务中是一个东西。如何避免思路建立企业级的“数据字典”或“业务指标库”作为基石。字段标准化在规则设计层之上先维护一个公共的“字段库”。例如提前定义好“优惠券类型”这个标准字段discount_type明确其枚举值。产品经理设计规则时只能从字段库中选择不能随意创建新字段名。规则合并与继承支持规则的继承和覆盖。可以定义一个基础的“交易事件”包含通用字段。具体的“商品购买”、“课程购买”事件可以继承它并添加自己特有的字段。强大的搜索与提示在产品经理输入字段名时系统自动提示相似或已存在的字段促进复用而非新建。5.3 坑三下游系统API的稳定性和权限Hermes Agent 要调用采集平台、调度系统的API。这些API可能不稳定或者有严格的权限和频控限制。思路插件设计必须健壮并做好降级预案。重试与退避插件内必须实现带指数退避的重试机制应对下游系统的临时故障。异步与队列将API调用任务放入队列异步执行避免同步调用阻塞整个Agent。即使下游系统挂了一小时任务也能在恢复后继续执行。权限集中管理由运维人员统一为Hermes Agent申请下游系统的高权限服务账号并在插件配置中妥善保管密钥。避免每个开发人员都去申请个人权限。人工干预通道当自动同步失败时系统应能清晰告警并提供手动触发同步或上传配置的“后门”。自动化不能完全替代人工监督。5.4 坑四实时与离线链路的差异处理实时数仓如Flink和离线数仓如Hive/Spark的技术栈、处理逻辑、时效性要求差异很大。同一个规则如何生成两份不同的代码思路在规则资产的output_targets配置中明确区分实时和离线目标并使用不同的SQL模板或代码生成器。双模板引擎为实时链路准备Flink SQL的Velocity/FreeMarker模板为离线链路准备Spark SQL模板。规则中的字段和类型会被渲染到不同的模板中。逻辑统一实现分离在规则中定义的是业务逻辑如“字段A需从字符串转为整型”。插件负责将业务逻辑翻译成技术实现。实时链路可能用Flink的CAST函数离线链路用Hive的CAST。插件需要封装这些差异。测试一体化需要建立一套测试框架能够用同一份测试数据同时验证生成的实时作业和离线脚本的输出结果是否一致。5.5 一个实操心得从小处着手证明价值不要一开始就试图做一个大而全、覆盖所有埋点、所有下游系统的“终极平台”。风险极高容易失败。我的建议是选择一个垂直场景进行MVP最小可行产品验证。例如只针对“营销活动类”埋点或者只对接一个数据采集平台如公司自研的和离线数仓。用最小的成本跑通“规则设计 - 评审 - 自动生成ETL SQL - 自动部署”这个端到端流程。哪怕一个月只处理了10个埋点需求只要你能向团队证明“这10个需求的上线时间从3天缩短到了3小时且零配置错误”你就能获得巨大的支持从而争取资源进行下一步扩展。从埋点需求到规则资产通过Hermes Agent重构数仓工作流本质上是一场数据生产的“工业化”革命。它将手工作坊式的、依赖个人经验的流程升级为标准化、自动化、资产化的流水线。这个过程技术挑战不少需要协调的部门也多但一旦走通其对数据团队效率和数据资产质量的提升将是颠覆性的。这条路值得每个被“埋点之痛”困扰的数据团队认真思考和尝试。