《数据工程之道》把数据工程生命周期划分为五个阶段生成 → 获取 → 存储 → 转换 → 服务如果只看这五个名词它很容易被理解成一张数据流程图上游产生数据平台把数据接进来经过存储和加工最后交给下游。但这不是作者提出生命周期的主要价值。从第一性原理看企业建设数据系统不是为了搬运和保存数据而是为了支持分析、模型或业务行动。数据只有进入真实用途才可能产生价值。因此生命周期真正要回答的是原始数据怎样逐步变成可供决策使用的数据产品以及这个过程中应该作出哪些工程判断总说这套方法可以归纳为三层理解数据来源数据怎样产生、变化并进入平台形成可信数据哪些状态需要保存哪些业务规则需要转换实现数据价值谁使用数据以及数据如何进入实际决策。五个生命周期阶段分别落在这三层中理解来源生成、获取 形成可信数据存储、转换 实现价值服务安全、数据管理、DataOps、架构、编排和软件工程则贯穿三层使生命周期能够长期、稳定地运转。一、从技术清单转向数据价值链1. 为什么不能围绕技术理解数据工程数据工程经常被具体工具定义使用Kafka接入实时数据使用Spark进行大规模计算使用Airflow或Dagster编排任务使用数据仓库为分析提供服务。但技术会不断变化。如果围绕工具组织数据工程团队很容易先决定“使用什么”再寻找“它能解决什么问题”。《数据工程之道》试图反转这个顺序最终需要支持什么用途 → 为此需要什么数据 → 数据从哪里产生 → 应该怎样获取、保存和转换 → 最后再选择合适的技术因此生命周期首先是一种思考顺序让技术选择服从数据用途而不是让业务需求迁就已经选定的技术。例如是否使用流处理不能因为数据持续产生就直接决定。真正需要判断的是更早获得数据后能采取什么行动这种行动带来多少价值以及这些价值是否值得额外的成本和复杂度。2. 生命周期不是严格顺序执行的流水线作者也明确指出五个阶段在真实系统中可能重复、重叠和交织。存储并不是普通的一站而是贯穿整个生命周期源系统保存业务状态或事件获取过程可能使用队列和缓冲转换过程会产生中间数据服务阶段需要面向查询或模型的存储。转换同样可能发生在多个位置。源系统可以在发送数据前补充事件时间获取过程可以清洗格式服务层也可能在查询时应用部分业务逻辑。因此五个阶段更适合被理解为五类责任生成理解数据怎样产生 获取决定数据怎样进入平台 存储决定哪些状态必须保留 转换赋予数据可复用的业务含义 服务让数据进入实际用途技术可以同时承担多个阶段但这些责任不能消失。二、生命周期的三层核心责任1. 理解来源生成与获取这一层解决的问题是平台怎样正确理解外部数据并将它可靠地带入自己的控制范围生成理解源系统的行为数据工程师通常不拥有源系统却必须理解源系统如何表达业务事实。书中要求工程师关注数据表示事件还是当前状态数据是否会重复或迟到源系统是否保留历史修改和删除分别代表什么schema怎样演进数据变化由谁通知下游从源系统读取是否影响生产性能。这里包含一个重要判断下游清洗只能修正格式和部分异常无法恢复源系统没有记录或已经丢失的业务事实。以金融行情为例知道供应商提供收盘价并不够。还要知道行情是初版还是最终版、历史记录是否会修订、复权因子何时发布以及历史接口返回当时版本还是最新版本。这些来源行为决定了研究能否还原真实决策时点。获取根据用途选择数据进入方式理解来源以后下一步才是决定怎样获取。书中要求判断数据什么时候需要需要多频繁获取数据量和格式是什么下游能否处理数据是否可靠到达是否需要在传输中转换同一份数据能否复用。作者对批处理和流处理的分析尤其具有代表性。数据在源头通常持续产生批处理只是将连续数据按时间或数量切成块处理。因此“数据持续产生”不能直接推出“必须采用流处理”。真正的判断链是实时数据能触发什么行动 → 行动能产生多少额外价值 → 下游能否承受实时速度 → 团队能否维护状态与恢复 → 收益是否高于成本例如20日动量用于次日开盘前选股。如果模型每天20点运行日终批量获取可能已经足够。此时真正需要解决的不是是否引入Kafka而是什么时候认为当日行情到齐初版和修订版如何区分迟到多久后应该阻断重复拉取是否产生重复修订数据是否触发重算。生成阶段解决“理解来源”获取阶段解决“可靠进入”。二者共同决定后续加工的输入是否可信。2. 形成可信数据存储与转换数据进入平台后还不能直接产生价值。平台需要保存必要状态并把原始数据转换成下游能够理解和复用的形式。存储保存数据也保存还原事实的能力本书对存储的理解不只是容量和介质选择还包括读写速度和查询SLA数据规模和访问频率schema约束元数据和血缘安全与合规技术是否被合理使用。作者用数据温度区分访问模式热数据频繁读取要求快速访问 温数据周期性使用 冷数据很少读取但需要长期保留不同访问模式对应不同的存储设计。在金融特征场景中可以对应为原始行情快照用于追溯和重算历史特征版本用于研究、回测和比较当日发布特征用于模型及时读取。更关键的是金融系统不能只保存最新值。如果供应商修订历史行情而平台覆盖旧数据那么重新运行过去的模型时可能得到与当时不同的结果。因此需要区分业务时间市场事件属于什么时候 发布时间来源什么时候发布 到达时间平台什么时候收到 可用时间什么时候允许下游使用存储的核心责任是让平台既能使用当前数据也能还原某个历史时点实际掌握的信息。转换将业务规则变成可复用数据原始数据只是材料。只有经过转换数据才开始形成下游价值。书中对转换提出三个判断转换支持什么业务价值转换是否尽可能简单并保持隔离转换实现了什么业务规则。这意味着转换不是越多越好。每项转换都应该有明确用途并以标准方式实现避免同一逻辑散落在不同脚本、查询和报表中。本书也直接讨论了特征工程。研究员根据领域知识确定哪些特征有意义当特征定义稳定后数据工程师将特征化过程自动化使它能够持续计算、验证、复用和回填。以20日动量为例需要固定的不只是公式还包括使用什么价格如何复权窗口按自然日还是交易日新股和停牌如何处理是否跳过最近交易日使用哪版股票池公式变化后是否升级版本。研究员负责特征的经济含义数据工程负责将定义转化为可重复运行的数据产品。存储负责保留事实转换负责赋予事实可复用的含义。二者共同形成可信数据。3. 实现价值服务服务是生命周期的终点也是检验前面所有投入是否有意义的阶段。书中明确指出数据只有被用于实际目的时才有价值没有被使用或查询的数据只是惰性的。如果团队建设了庞大的数据湖、数据仓库或实时平台却没有支持实际分析、模型或业务行动这就是数据虚荣项目。服务主要包括分析机器学习将分析和评分结果送回业务系统。对于机器学习书中要求关注数据质量是否足以支持特征工程数据是否容易被发现数据是否正确代表基本事实是否存在偏差数据工程与机器学习工程如何分工。书中还提到特征存储的价值保存特征历史和版本、支持团队复用、提供回填能力并降低机器学习团队的运行负担。对于金融特征计算完成并不代表已经实现服务。还需要回答哪个模型消费读取哪个版本在什么时间读取能否读取候选数据特征延迟后模型怎么办降级状态能否继续生成仓位模型结果能否反查到特征和原始数据。服务不是简单开放一张表而是让数据以满足消费要求的质量、时效和接口进入实际决策。三、让生命周期长期运转的横切能力如果只记住五个阶段生命周期确实容易变成空壳。作者的完整模型还包含六项贯穿生命周期的底层设计安全 数据管理 DataOps 数据架构 编排 软件工程这些能力可以进一步归纳为两类。1. 建立规则和边界安全、数据管理和数据架构负责定义系统应遵守的边界谁可以访问数据数据语义和责任如何统一哪些历史必须保留模块怎样分工技术选择如何平衡价值、成本和风险。它们解决的是“系统应该怎样设计”。2. 保证规则持续执行DataOps、编排和软件工程负责让这些规则稳定运行。书中将DataOps拆成三个技术支柱自动化 可观测性与监控 事件响应自动化保证数据、代码和配置按照一致方式部署和执行。可观测性让团队在用户发现问题之前识别数据缺失、质量异常、任务延迟或模型漂移。事件响应则负责在问题发生后定位根因、恢复服务并通过复盘减少重复事故。编排也不只是定时运行。书中明确区分调度器只知道时间编排系统还知道依赖、数据是否到达、条件是否满足以及如何回填。例如20日动量不能因为到了19点就直接运行而应该等待行情到齐 → 复权数据就绪 → 股票池版本确定 → 特征计算完成 → 质量检查通过 → 允许发布软件工程则通过版本控制、自动测试、流水线即代码和可重复部署保证生命周期中的处理逻辑能够验证和演进。生命周期描述责任横切能力保证责任被持续履行。四、用生命周期推导金融特征治理《数据工程之道》没有直接给出金融特征治理方案。它提供的是每个生命周期阶段应该作出什么判断。将这些判断应用到20日动量可以得到一条完整链路来源发布 → 获取批次 → 原始数据版本 → 特征计算版本 → 可信发布版本 → 模型运行 → 组合与交易结果1. 来源与获取判断行情和复权数据怎样产生、是否修订、何时到达以及日批是否满足模型运行时间。2. 存储与转换保留原始快照、来源版本和可用时间再用固定的公式、参数和股票池版本生成特征。3. 服务模型只能读取经过验证的发布版本并能够看到特征日期、版本、质量状态和是否降级。4. 运行保障通过编排等待依赖通过质量门禁阻止异常发布通过可观测性发现问题通过事件响应完成隔离、重算和恢复。当模型评分异常时团队可以沿链路逐层定位模型读取了哪版特征 → 特征使用了哪版代码和参数 → 转换使用了哪版行情和复权数据 → 这些数据来自哪个获取批次 → 来源是否发生过修订这比只检查最终特征代码更接近真实的数据工程治理。需要注意的是下面这些内容是根据金融场景进一步推导的而不是本书直接提供的现成方案Point-in-Time数据管理行情初版和修订版管理股票池与复权数据版本特征候选与可信发布异常时阻断、降级或沿用旧版本模型运行与特征版本关联。本书的价值不是替金融系统给出答案而是提供一套稳定的提问和判断顺序。最终这套方法可以收敛为从最终用途出发 → 理解数据来源 → 选择获取方式 → 保留必要状态 → 标准化业务规则 → 交付实际消费 → 用横切能力保证持续运行数据工程生命周期因此不是五个技术模块而是一套从原始数据走向业务价值的工程判断框架。它最终要求团队回答数据从哪里来怎样发生变化为什么值得加工以什么条件进入决策以及出错后如何定位和恢复。 
长河君 · 2026/11/3 2:19:45 · 阅读 1.2k 【数据治理（2）】数据工程生命周期：从数据产生到价值实现的判断框架
《数据工程之道》把数据工程生命周期划分为五个阶段生成 → 获取 → 存储 → 转换 → 服务如果只看这五个名词它很容易被理解成一张数据流程图上游产生数据平台把数据接进来经过存储和加工最后交给下游。但这不是作者提出生命周期的主要价值。从第一性原理看企业建设数据系统不是为了搬运和保存数据而是为了支持分析、模型或业务行动。数据只有进入真实用途才可能产生价值。因此生命周期真正要回答的是原始数据怎样逐步变成可供决策使用的数据产品以及这个过程中应该作出哪些工程判断总说这套方法可以归纳为三层理解数据来源数据怎样产生、变化并进入平台形成可信数据哪些状态需要保存哪些业务规则需要转换实现数据价值谁使用数据以及数据如何进入实际决策。五个生命周期阶段分别落在这三层中理解来源生成、获取 形成可信数据存储、转换 实现价值服务安全、数据管理、DataOps、架构、编排和软件工程则贯穿三层使生命周期能够长期、稳定地运转。一、从技术清单转向数据价值链1. 为什么不能围绕技术理解数据工程数据工程经常被具体工具定义使用Kafka接入实时数据使用Spark进行大规模计算使用Airflow或Dagster编排任务使用数据仓库为分析提供服务。但技术会不断变化。如果围绕工具组织数据工程团队很容易先决定“使用什么”再寻找“它能解决什么问题”。《数据工程之道》试图反转这个顺序最终需要支持什么用途 → 为此需要什么数据 → 数据从哪里产生 → 应该怎样获取、保存和转换 → 最后再选择合适的技术因此生命周期首先是一种思考顺序让技术选择服从数据用途而不是让业务需求迁就已经选定的技术。例如是否使用流处理不能因为数据持续产生就直接决定。真正需要判断的是更早获得数据后能采取什么行动这种行动带来多少价值以及这些价值是否值得额外的成本和复杂度。2. 生命周期不是严格顺序执行的流水线作者也明确指出五个阶段在真实系统中可能重复、重叠和交织。存储并不是普通的一站而是贯穿整个生命周期源系统保存业务状态或事件获取过程可能使用队列和缓冲转换过程会产生中间数据服务阶段需要面向查询或模型的存储。转换同样可能发生在多个位置。源系统可以在发送数据前补充事件时间获取过程可以清洗格式服务层也可能在查询时应用部分业务逻辑。因此五个阶段更适合被理解为五类责任生成理解数据怎样产生 获取决定数据怎样进入平台 存储决定哪些状态必须保留 转换赋予数据可复用的业务含义 服务让数据进入实际用途技术可以同时承担多个阶段但这些责任不能消失。二、生命周期的三层核心责任1. 理解来源生成与获取这一层解决的问题是平台怎样正确理解外部数据并将它可靠地带入自己的控制范围生成理解源系统的行为数据工程师通常不拥有源系统却必须理解源系统如何表达业务事实。书中要求工程师关注数据表示事件还是当前状态数据是否会重复或迟到源系统是否保留历史修改和删除分别代表什么schema怎样演进数据变化由谁通知下游从源系统读取是否影响生产性能。这里包含一个重要判断下游清洗只能修正格式和部分异常无法恢复源系统没有记录或已经丢失的业务事实。以金融行情为例知道供应商提供收盘价并不够。还要知道行情是初版还是最终版、历史记录是否会修订、复权因子何时发布以及历史接口返回当时版本还是最新版本。这些来源行为决定了研究能否还原真实决策时点。获取根据用途选择数据进入方式理解来源以后下一步才是决定怎样获取。书中要求判断数据什么时候需要需要多频繁获取数据量和格式是什么下游能否处理数据是否可靠到达是否需要在传输中转换同一份数据能否复用。作者对批处理和流处理的分析尤其具有代表性。数据在源头通常持续产生批处理只是将连续数据按时间或数量切成块处理。因此“数据持续产生”不能直接推出“必须采用流处理”。真正的判断链是实时数据能触发什么行动 → 行动能产生多少额外价值 → 下游能否承受实时速度 → 团队能否维护状态与恢复 → 收益是否高于成本例如20日动量用于次日开盘前选股。如果模型每天20点运行日终批量获取可能已经足够。此时真正需要解决的不是是否引入Kafka而是什么时候认为当日行情到齐初版和修订版如何区分迟到多久后应该阻断重复拉取是否产生重复修订数据是否触发重算。生成阶段解决“理解来源”获取阶段解决“可靠进入”。二者共同决定后续加工的输入是否可信。2. 形成可信数据存储与转换数据进入平台后还不能直接产生价值。平台需要保存必要状态并把原始数据转换成下游能够理解和复用的形式。存储保存数据也保存还原事实的能力本书对存储的理解不只是容量和介质选择还包括读写速度和查询SLA数据规模和访问频率schema约束元数据和血缘安全与合规技术是否被合理使用。作者用数据温度区分访问模式热数据频繁读取要求快速访问 温数据周期性使用 冷数据很少读取但需要长期保留不同访问模式对应不同的存储设计。在金融特征场景中可以对应为原始行情快照用于追溯和重算历史特征版本用于研究、回测和比较当日发布特征用于模型及时读取。更关键的是金融系统不能只保存最新值。如果供应商修订历史行情而平台覆盖旧数据那么重新运行过去的模型时可能得到与当时不同的结果。因此需要区分业务时间市场事件属于什么时候 发布时间来源什么时候发布 到达时间平台什么时候收到 可用时间什么时候允许下游使用存储的核心责任是让平台既能使用当前数据也能还原某个历史时点实际掌握的信息。转换将业务规则变成可复用数据原始数据只是材料。只有经过转换数据才开始形成下游价值。书中对转换提出三个判断转换支持什么业务价值转换是否尽可能简单并保持隔离转换实现了什么业务规则。这意味着转换不是越多越好。每项转换都应该有明确用途并以标准方式实现避免同一逻辑散落在不同脚本、查询和报表中。本书也直接讨论了特征工程。研究员根据领域知识确定哪些特征有意义当特征定义稳定后数据工程师将特征化过程自动化使它能够持续计算、验证、复用和回填。以20日动量为例需要固定的不只是公式还包括使用什么价格如何复权窗口按自然日还是交易日新股和停牌如何处理是否跳过最近交易日使用哪版股票池公式变化后是否升级版本。研究员负责特征的经济含义数据工程负责将定义转化为可重复运行的数据产品。存储负责保留事实转换负责赋予事实可复用的含义。二者共同形成可信数据。3. 实现价值服务服务是生命周期的终点也是检验前面所有投入是否有意义的阶段。书中明确指出数据只有被用于实际目的时才有价值没有被使用或查询的数据只是惰性的。如果团队建设了庞大的数据湖、数据仓库或实时平台却没有支持实际分析、模型或业务行动这就是数据虚荣项目。服务主要包括分析机器学习将分析和评分结果送回业务系统。对于机器学习书中要求关注数据质量是否足以支持特征工程数据是否容易被发现数据是否正确代表基本事实是否存在偏差数据工程与机器学习工程如何分工。书中还提到特征存储的价值保存特征历史和版本、支持团队复用、提供回填能力并降低机器学习团队的运行负担。对于金融特征计算完成并不代表已经实现服务。还需要回答哪个模型消费读取哪个版本在什么时间读取能否读取候选数据特征延迟后模型怎么办降级状态能否继续生成仓位模型结果能否反查到特征和原始数据。服务不是简单开放一张表而是让数据以满足消费要求的质量、时效和接口进入实际决策。三、让生命周期长期运转的横切能力如果只记住五个阶段生命周期确实容易变成空壳。作者的完整模型还包含六项贯穿生命周期的底层设计安全 数据管理 DataOps 数据架构 编排 软件工程这些能力可以进一步归纳为两类。1. 建立规则和边界安全、数据管理和数据架构负责定义系统应遵守的边界谁可以访问数据数据语义和责任如何统一哪些历史必须保留模块怎样分工技术选择如何平衡价值、成本和风险。它们解决的是“系统应该怎样设计”。2. 保证规则持续执行DataOps、编排和软件工程负责让这些规则稳定运行。书中将DataOps拆成三个技术支柱自动化 可观测性与监控 事件响应自动化保证数据、代码和配置按照一致方式部署和执行。可观测性让团队在用户发现问题之前识别数据缺失、质量异常、任务延迟或模型漂移。事件响应则负责在问题发生后定位根因、恢复服务并通过复盘减少重复事故。编排也不只是定时运行。书中明确区分调度器只知道时间编排系统还知道依赖、数据是否到达、条件是否满足以及如何回填。例如20日动量不能因为到了19点就直接运行而应该等待行情到齐 → 复权数据就绪 → 股票池版本确定 → 特征计算完成 → 质量检查通过 → 允许发布软件工程则通过版本控制、自动测试、流水线即代码和可重复部署保证生命周期中的处理逻辑能够验证和演进。生命周期描述责任横切能力保证责任被持续履行。四、用生命周期推导金融特征治理《数据工程之道》没有直接给出金融特征治理方案。它提供的是每个生命周期阶段应该作出什么判断。将这些判断应用到20日动量可以得到一条完整链路来源发布 → 获取批次 → 原始数据版本 → 特征计算版本 → 可信发布版本 → 模型运行 → 组合与交易结果1. 来源与获取判断行情和复权数据怎样产生、是否修订、何时到达以及日批是否满足模型运行时间。2. 存储与转换保留原始快照、来源版本和可用时间再用固定的公式、参数和股票池版本生成特征。3. 服务模型只能读取经过验证的发布版本并能够看到特征日期、版本、质量状态和是否降级。4. 运行保障通过编排等待依赖通过质量门禁阻止异常发布通过可观测性发现问题通过事件响应完成隔离、重算和恢复。当模型评分异常时团队可以沿链路逐层定位模型读取了哪版特征 → 特征使用了哪版代码和参数 → 转换使用了哪版行情和复权数据 → 这些数据来自哪个获取批次 → 来源是否发生过修订这比只检查最终特征代码更接近真实的数据工程治理。需要注意的是下面这些内容是根据金融场景进一步推导的而不是本书直接提供的现成方案Point-in-Time数据管理行情初版和修订版管理股票池与复权数据版本特征候选与可信发布异常时阻断、降级或沿用旧版本模型运行与特征版本关联。本书的价值不是替金融系统给出答案而是提供一套稳定的提问和判断顺序。最终这套方法可以收敛为从最终用途出发 → 理解数据来源 → 选择获取方式 → 保留必要状态 → 标准化业务规则 → 交付实际消费 → 用横切能力保证持续运行数据工程生命周期因此不是五个技术模块而是一套从原始数据走向业务价值的工程判断框架。它最终要求团队回答数据从哪里来怎样发生变化为什么值得加工以什么条件进入决策以及出错后如何定位和恢复。