每日热议!数据工程——从数据到价值
来源：Thoughtworks 2023-05-17 08:57:36
数据工程的介绍
我们可以将数据视为一种新兴的生产要素或生产原材料。通过对其进行加工可以创造更多的价值，这些价值通常围绕着业务和场景展开。因此，我们需要以一种能够将数据生产和加工应用到实际场景和价值中的方式来使用数据。
(资料图片仅供参考)
《数据工程白皮书》中的数据范畴包括结构化、非结构化和半结构化的各种类型数据。这是因为我们需要处理各种形式的数据，无论是二维表格，还是图像、音频、视频等等。这些数据的加工和处理，是我们实现更智能化场景的关键。因此，我们需要以数据为中心，去面对并解决这些数据加工的挑战。
数据越来越重要
在面对不同的问题和企业发展现状时，数据需求也会有所不同。为了更好地说明这一点，《数据工程白皮书》列举了信息化、数字化和智能化三个阶段。在信息化阶段，企业更多地关注业务流程和线上化，在构建系统时，我们需要先关注功能实现，而非数据的整合和平台化。在功能实现之后，我们需要将业务流程的变化信息转化为数据，并将这些数据串联起来，以形成业务数据化的大方向。在智能化方面，像ChatGPT和文本生成等技术最近非常火热。然而，实现智能化需要依赖于训练数据样本、构建模型、测试和优化等过程，这些过程都需要使用数据作为基础。因此，数据在智能化过程中的使用至关重要。
企业所处的不同阶段
在使用数据的过程中，不同阶段的企业都需要从四个大方向考虑。首先，在业务数据化过程中，需要用数据展现业务经营过程，例如数据洞察和可执行业务动作。包括了现有业务过程、销售额提升、销售额提升的结构和下一步行动方向。
企业使用数据的四个阶段
这里可以用销售提升3%为例：
3%的销售额提升是描述了企业目前正在发生什么 3%销售额的提升是原有业务开展还是新兴业务开展描述了企业发生变化的原因 3%销售额的提升对企业运营来说，是需要继续投入新业务抑或是需要保持优势业务的持续开展描述了下一步的方向在哪里 企业发展诉求是要达到5%销售额的提升，那么需要如何投入、如何发力描述了企业如何确保业务发展方向与预想保持一致数据在企业中的应用场景将越来越多，因此对于数据工程的概念可能存在不同的理解。需要澄清的是，数据工程是一个体系，涵盖了从企业数据战略、需求设计、技术设计到开发、质量管控和流程等方面。它源于软件工程的实践，但是在数据工程中被提炼出来并映射到数据层面的工作。需要强调的是，数据工程不仅仅是数据开发。
为了快速实现数据工程这个复杂体系，需要规模化的方式来提高开发效率，并减少人员更替和交接所带来的影响。为此，《数据工程白皮书》提出了相关实践和对人员能力的要求，并提到了数据工程成熟度的概念。不同企业的需求和状态不同，有些企业可能只需要遵循一些规范化的开发原则，而有些企业需要应对几十人甚至上百人的开发团队，保证在每个项目上都能发挥更高的工作效率。这时，需要对整个企业的数据工程成熟度进行评估，以有针对性地提升相关方向。
Thoughtworks对于数据工程概念的定义
数据工程的价值
数据转化为业务价值的过程与企业使用数据的四个阶段紧密相连。对于销售额提升 3% 的需求，我们需要将这个数字拆解并了解其背后所要使用的数据以及所需经历的过程，比如销售额是含税还是不含税、单位是按照什么样的金额进行换算等。在处理数据时，也会涉及到不同系统的选择和数据信息的持续定义和澄清过程，最终才能得到真正的洞见。在整个数据流转过程中，我们需要不断提升各个步骤的效率。
数据在企业内流转过程
在数据工程中，数据从原料加工到成品需要考虑很多因素，如指标计算口径、数据异常预警等。同时，数据需要在不同阶段进行设计和实现，以体现企业经营的状况。在数据工程的设计中，需要考虑到各个阶段的注意要素，以保障数据工作的有效性和准确性。在业务和数据的融合过程中，需要将业务诉求与数据处理有效地融合在一起。业务和数据的边界越来越模糊，因此需要技术支撑和保障，实现业务、数据和技术的有机融合，这是实现数据到价值过程的核心要素。
数据“原料”到“成品”对加工示例
数据工程是一个复杂的体系，需要从人员层面解决开发成本和效率的问题。有标准化的设计和管控可以提高数据工程的效率和面对规模化时的应对能力。团队之间需要统一数据标准，解决数据孤岛问题，降低业务场景下的联动成本。对于企业能够快速满足业务需求，以更小的成本实现业务诉求。根本目的是打造一个高响应力的企业流程，以提高数据生产和加工的效率。只有在数据生产的相关原材料准确无误，才能挖掘数据的价值和实现智能化的演进。因此，统一、标准化和提高效率是数据工程的核心要素。
数据工程对企业对价值
数据工程的价值观
我们看到了数据工程的价值，那么为了更好地落地数据工程，我们需要明确数据工程的价值观。思特沃克数据和人工智能团队根据我们服务的不同的客户及过往的项目经验，总结了如下的价值观。我们参考了敏捷宣言中xxx胜过xxx的方式，我们认为右边的也有价值，但是更重视左边的价值，因为每个企业都有自己的发展规模和阶段，在每个时期会有不同的侧重点。我们也期望在企业内部，根据自身的实际情况，建立符合企业需求的价值观，同时不断地调整和演进。
一、以数据产生的业务价值为交付结果
我们应该关注数据处理后能为业务带来的价值，而非仅仅关注数据接入和处理指标的数量。例如，我们可以关注数据如何帮助了解销售订单的趋势及其原因，以便为业务提供有益的指导。尽管不一定非得用业务收入作为衡量标准，但我们应该努力实现数据产生的业务价值作为交付结果。
我们观察到有些企业在建立数据中台或数据平台时，非常关注接入的数据量和计算指标的多少，将其作为衡量项目成功与否的重要指标。虽然数据接入、处理和指标计算可以作为衡量数据平台或数据中台成果的指标，因为它们反映了工作量和处理量，但我们不建议将它们视为北极星指标或非常重要的指标。我们强调的是数据产生的价值，即经过处理后的数据如何服务于实际业务场景。
二、建立全功能的团队，实现端到端交付
许多企业在数据处理过程中存在类似的问题，如一个业务场景的实现可能会涉及数据湖、数据仓库和报表可视化等部门，这个跨组、部门带来的协作隔阂是非常影响交付结果的。虽然我们不一定要完全打破现有的组织形式，但我们应该改进我们的协作方式，尽量减少沟通隔阂，提高团队的协作效率。比如，建立基于项目的临时交付团队。
三、面向业务域的划分和面向未来的设计
随着数据驱动的业务和企业愿景的发展，数据分析需求将不断扩大，企业数据应用预计会有很大的发展潜力。因此，在规划时要具有一定的前瞻性，考虑到企业未来对数据存储、计算和分析的需求。
在这个背景下，数据存储、计算框架的技术选择都需要谨慎考虑。例如，选择传统数据库还是Hive，Iceberg等，大数据处理框架如Spark、Flink，还是pandas就可以。此外，还需要考虑如何划分数据存储，例如数据库的划分。在这里，我们推荐按照业务域进行划分，包括存储、ETL组织、ETL调度（DAG）和报表规划等。这样，可以根据业务需求变化进行灵活调整，适应企业的发展。
四、团队知识积累和传承胜过简单的文档交接
在项目过程中，需要业务分析师、开发人员和测试人员紧密合作，共同了解需求，通过紧密协作进行知识传承。在实际开发过程中，我们鼓励结对编程、Code Review等方式进行知识传承。我们的测试人员通常会在项目开始阶段就参与需求了解，与业务和开发人员共同参与需求的确定。这样的知识传承方式有助于项目顺利进行，而不是业务分析师把一堆文档交给开发和测试。
我们希望这些价值观能够引导大家进行深入思考，更好地落地数据工程。不只关注交付结果，更加关注交付流程中的需求、开发、测试和业务的协作和流程，从而提升交付效率和质量，建立更加和谐的数据应用交付团队。
数据工程的7条原则
基于上面的价值观，我们形成了7条原则来指导各种场景下的应用。我们将原则打印并放在显眼位置提醒团队成员。在日常工作中遇到分歧时，我们回顾这些原则以指导数据开发过程的改进，确保团队始对数据工程的一致理解。
原则一、功能设计与开发要从价值交付考量：
我们会通过一系列的活动确保项目的交付是基于业务价值的。通过愿景工作坊，针对高层管理者确定项目业务愿景。接下来，通过业务访谈，需求分析师和产品经理与一线用户进行沟通，了解现状、痛点和工作流程。基于收集的信息，我们进行桌面研究，整合类似客户和项目经验以及行业前沿洞见。
然后，我们通过访谈不同业务角色，为平台用户创建不同的用户画像（persona）。有时会为用户起有趣的名字，以便讨论时更加生动。接着，通过服务蓝图工作坊梳理业务流程、系统支撑和数据产生交互过程。在梳理出需解决问题和需完成任务后，我们通过优先级考量方式对功能进行排序，平衡紧急程度和价值，从数据、技术和业务三个维度进行考量。
通过一系列活动确保我们是在为业务交付价值，在交付过程中，我们也会有一些其他的实践确保和业务的紧密合作。
原则二、合理的架构设计不仅指解决现有问题，还能够在一定程度解决未来问题：
数据类项目的重构成本比传统应用开发要高一些，因为数据迁移和上下游库表的强依赖。所以，我们建议数据平台的架构要有一定的前瞻性。
在设计过程中，考虑四个方向：面向领域的设计，即按照领域维度拆分DAG构建和库表结构；演进式的平台和工具设计，在选择成熟的数据平台工具时，要注意短时的易用性与长期的可维护性之间的平衡；最后是数据模型设计的前瞻性，通过领域专家进行逻辑建模并达成共识，方便基于逻辑模型进行讨论和实现。
原则三、我们倡导通过统一的工作标准和流程提升团队协作效率：
虽然敏捷开发不鼓励一定要遵循某个流程，但我们仍然需要一定的工作标准。这些流程应该是可调的，以便随着时间的推移和团队的进步进行调整。
我们通过多年的实践，摸索出一套适合国内环境的敏捷开发流程。我们形成了一个稳定的交付周期，每两周进行一次迭代。在这个迭代开始前，我们会不断地与业务方沟通以确定优先级，确定迭代交付的内容。在迭代中，对每个故事卡的完成情况进行验收，确保数据准确性，并在最后进行持续发布。完整的迭代过程包括，拆分故事卡，迭代计划，故事卡墙的建立，迭代开发，功能演示，用户验收，持续发布，迭代回顾。
过程中，如何进行数据探测，单元测试，代码审核，代码提交规范，数据质量校验，都会形成团队自己的工作标准和流程，减少协作的隔阂。
原则四、工具是知识沉淀的具体表现，有效的工具能够提升规模化开发效率：
工具是知识沉淀的具体表现，通过有效的工具可以提升我们的开发效率。数据项目的交付可能包括数据集、报表、模型等可见部分，以及不可见的数据处理流程。我们需要在数据处理中提升效能，逐渐沉淀一些工具，例如数据接入层的自动化工具、ETL框架、工作台等，以提升开发效能。
原则五、欣然面对需求变化，及时调整交付策略 ：
这个原则主要是关于面对变化，并及时调整交付策略。基于一个Backlog的管理需求，我们需要处理来自不同来源的需求，如业务需求、公司规划举措、产品用户反馈和线上问题等。这些需求将被归入到一个Backlog中，并根据优先级和紧迫性进行排序，再放入后续迭代中。
然而，我们需要注意一点：在应对需求变化时要避免过于随意。例如，当客户在今天晚上提出需求，希望明天就能完成时，我们需要评估需求的紧迫性是否真的如此之高，并考虑如何更好地支持这种需求，例如通过改造系统，让业务自己完成。原因在于开发需要有自己的节奏，如果频繁地切换上下文或打破开发节奏，可能会对开发带来反向影响。因此，我们需要小心管理这些需求。
总之，在面对需求变化和管理业务变化时，要注意避免随意的变化，并确保开发能够保持自己的节奏。这样，我们才能更好地应对和管理需求变化。
原则六、数据治理需要渗透到整个数据工程落地过程当中：
在实际操作中，我们倡导精益数据治理。这是因为在企业内进行大而全的数据治理会消耗大量的人力物力，并且实施起来相当困难。
因此，我们现在的原则是基于数据应用驱动的数据治理。例如，在做一个订单相关的报表时，我们首先针对这部分的数据治理，解决数据质量、数据安全等问题，并根据应用场景设计相应的解决方案。当我们需要处理其他方面的数据，如签收和物流时，可以按照数据应用的角度逐步完善数据治理制度。
在数据项目的实施过程中，可能会遇到一些数据问题，这些数据问题需要反向到业务系统的数据源进行改变。但业务系统的变化可能会较慢或响应迟缓，这时可以通过技术债进行管理，在数据平台可以暂时采用Workaround来解决问题。
总之，我们需要采用切片式的数据治理，并通过技术债进行全面数据质量管理。
原则七、人是数据工程落地的核心，要注重人员培养、知识传承：
虽然我们将这个原则放在第七位，但实际上它是最重要的原则。敏捷宣言中提到个人和交互胜过流程和工具，所以对于整个数据工程来说，人员是核心。我们经常在跟客户探讨数据项目的交付实践的时候，最后都会归结到员工能力和文化上。因此，我们会注重人员本身的培养，包括知识传承和成长。
这里的成长并不仅仅指企业内部的职业发展路线，而是指在项目或产品开发过程中的成长。我们有一些好的实践，如项目初期，团队成员会介绍自己的能力背景，并期望在项目中的成长。在项目过程中，我们通过读书会、分享、结对编程和代码审查等方式，为数据工程师和数据分析师提供学习机会。对于长期项目，我们需要有意识的逐渐培养人才梯队。上图中这里有一句话：“你需要长得这么高才能敏捷吗？”实际上，并非如此，一个团队中会有不同层次的人才，我们需要提供一个成长环境，让大家能够提升能力和传承知识。
总结
数据工程是数字经济下确保数据价值转化的重要保障， 是加速数据转化为价值的重要手段，数据工程能力应对的不仅仅是当下的挑战，更是应对未来数字经济大趋势的秘密武器。随着需要处理的数据量的增长，为了处理数据领域的各种新问题，各种新技术、新概念逐渐涌现，现代数据仓库、数据湖、湖仓一体、分布式数据架构、机器学习、数据云原生等逐一登上舞台，数据工程的发展道阻且长。
所以无论是站在企业内部的发展诉求还是站在企业所处的社会大环境，都在要求企业加速自己转型、完善自己的数据能力，在激烈的市场竞争过程中获得有利地位才能在未来数字经济繁荣成熟期到来之前占据有利战略发展位置。
关注Thoughtworks洞见公众号，获取Thoughtworks《数据工程白皮书》
