数据不是微服务
标签： 数据不是微服务
2023-07-14 18:23:31 80浏览
【编者按】本文主要讨论了软件工程和数据工程之间的差异，以及微服务架构如何影响数据工程的实践。作者认为，尽管微服务架构在软件工程中有其优势，但在数据工程中，它并不能解决所有问题。
他提出了三个主要观点：
1、数据团队需要一个真实的数据源，而微服务无法在不彻底改变软件工程学科的情况下提供这样的数据源。
2、我们无法预先知道何时数据会变得有价值，这使得数据微服务的前期所有权过于限制性。
3、数据开发生命周期与软件工程开发生命周期不同，微服务并不适合满足数据团队的需求。
尽管作者承认微服务在某些情况下可能有其价值，但他认为微服务并不能直接解决大多数企业在数据管理方面的核心问题。他建议，我们应该从基本原则出发，规划理想环境中应该实现的目标，然后反向工作，找出能够实现这种方法的技术和组织模式。
原文链接：https://dataproducts.substack.com/p/data-is-not-a-microservice
未经允许，禁止转载！
作者 | Chad Sanderso 译者 | 明明如月
责编 | 夏萌
出品 | CSDN（ID：CSDNnews）
目前，许多公司都在逐渐放弃单体架构，转向微服务架构，以求取得快速发展和突破。微服务架构模式改变了应用程序的构建方式，将其分解为一系列松散关联的服务，这些服务通过轻量级协议进行交互。该模式的主要目标之一是让各团队能够独立地开发和部署服务，减少对他人的依赖。
开发人员通过最小化代码库中的依赖性，进而可以在最少的限制下优化他们的服务。因此，组织可以更轻松地进行扩展，根据需要集成现有工具，并以服务所有权为中心，组织他们的工程团队。
最初由 Thoughtworks 的顾问提出的“微服务”一词，目前已经通过 Martin Fowler 的博客得到了广泛的知名度。随后，数据网格（Data Mesh）的创始人 Zhamak Dehghani（也是 Thoughtworks 的成员) 也发布了关于（数据微服务的等价概念）数据网格的相关书籍。
网格中的数据领域
在适应软件开发模式中，特别是微服务架构方面，数据领域的转变似乎总是面临困难且发展迟缓。在 21 世纪初， Google 和 Amazon 迅速崭露头角，并成为科技巨头。与此同时，各行各业也普遍出现了"错失恐惧症"（FOMO）。他们纷纷表示需要开发应用程序、迁移到云端以及进行数据分析等工作。因而，无论这些需求是否实际存在，各个企业和新兴公司还是都雇佣了专业顾问，试图模仿顶级科技公司的架构。在这个"软件改变世界"的大潮中，数据的重要性似乎相对被边缘化了。
然而，这种偏向性带来了严重问题，对原本构建良好数据生态系统的必要元素，开始被人遗忘，取而代之的是那些旨在满足上游工程需求的设计方法。在本文中，我将持不同于主流观点的立场，主张数据不应被视为一种微服务。尽管我认为，数据网格是解决数据团队面临的组织复杂性挑战的一种方式，但我坚信数据需要一种与其本质特性相符且独一无二的处理方法。我的论点主要基于以下三个核心观点：
数据团队需要一个可信赖的真实数据源，而微服务无法在不彻底改变软件工程学科的情况下提供这一点。
我们无法预见何时数据将具有价值，这使得提前承担数据微服务所有权受到过多束缚。
数据开发生命周期与软件工程生命周期不同，微服务模式无法满足数据团队的需求。
请注意，我并没有质疑微服务的价值，甚至也没有质疑基于微服务的方法能否解决数据团队在后期阶段面临的重要问题，结合其他以数据为中心的倡议，它们完全有可能实现。但是，我认为微服务并没有直接解决当前大多数企业在数据管理方面面临的核心问题。也就是说，将微服务的解决方案应用于数据领域，就如同把方块硬塞进圆孔——尽管它们可能解决某些问题，但总会有更简洁、更适合的方法来处理。
寻找真像
微服务方法无法解决数据真实性来源的核心问题
我在上一篇文章中就提及过这个问题，不过由于这点非常重要，我在此再次强调：软件工程团队与数据团队在驱动力本质上存在着差异。这是因为工程师们的任务是快速发布新功能，因而工程团队的架构选择目的是提高效率、分离关注点以及提升灵活性，微服务的设计目标是提供一种驱动某一特定用户体验的工具，其主要特点在于可操作性。而数据的目的在于支持决策制定，其主要特性是真实性。这种真实性可能以可操作性的方式（例如，用于机器学习模型）被使用，也可能以解的方式被使用（例如，用于回答一些重要的问题）。
许多企业已经以惊人的速度开始收集大量的数据，并将原始日志倾倒到数据湖中，以供数据工程师后续整理。数据开发者所面临的问题在于，他们所依赖的数据缺乏明确的所有者，底层含义模糊不清。当源系统发生变化时，很少有人能够理解变化的原因，也无法预测新的“真实性”应该是什么。在数据领域，我们的主要问题是信任的缺失。
在我看来，真实性的来源应该是一个明确所有权、管理得当且在语义上有意义的数据资产，它能够准确地反映真实世界的实体或事件在代码中的表现。
在传统的本地数据仓库中，经验丰富的数据架构师负责在集中环境中定义真实性的来源。虽然这种方式可能相对较慢且看起来有些笨重，但它确实实现了数据生态系统的主要目标。聪明且勤奋的数据专业人士们维护着一个整合层，以确保下游消费者能够可靠地使用一组经过验证、值得信赖的数据集。
在微服务的架构中，由于每个团队都独立地管理着自己的数据产品，这就导致了数据的重复和不一致。而且，我们还缺乏统一的规则来约束各个微服务中数据定义的方式，以及当数据发生变动时能够通知下游消费者。
以 Convoy 公司为例，该公司有一个名为 shipment_margin 的度量指标，该度量指标是通过将服务收入减去服务成本来计算得到。然而，不同的团队对于哪些成本与其特定的收入流相关，会有不同的解读。他们会根据自己的理解添加维度、调整 SQL 查询中的 CASE 语句、重命名字段，并将结果数据推送到新的模型中。然而，这些数据被再次使用时往往可能基于完全不同的假设。
对于数据消费者来说，这无疑是一种挑战。他们往往无法分辨哪些数据是稳定可信赖的，哪些数据是还处于实验阶段的。除非深入探索底层查询，否则很难区分具有相似名称的字段或表之间的区别，这导致分析师需要花费大量的时间和上游开发者进行沟通，得以理解数据的真正含义以及如何使用，而这无疑加大了他们的工作难度。
计算利润时，我应该选择哪个？
这种模式不仅使数据的获取变得更为困难，也使问题的可信度降低。此外，它还显著增加了花费。云分析数据库的定价模型主要基于查询操作的执行过程中所消耗的计算资源量。由于复杂的查询需要更多的资源，它们将导致每次查询的成本增加和总的计费增加。在缺乏集中化管理的情况下，各团队需独自决定，如何才能最有效地计算一组相同的度量。尽管对于单个分析师来说，费用可能并不明显，但在整个公司中，对大数据集进行数千次重复计算时，费用就会变得极其昂贵。
在以微服务为导向的环境中，每个常见的事实表或维度表都会变得异常分散，尝试进行跨组织的比较会变得困难。为了在开发阶段逐步提高迭代速度，数据的真实性就被忽略掉了，然而讽刺的是，这反而使分析层的速度大幅下降。
从根本上来说，数据的最根本原则就是真实性。根据用例，我们从更准确的数据中获得的投资回报可能很小（例如，临时报告），或者非常大（例如，经过审计的会计管道）。团队需要具有灵活性，根据需求将定向数据集转化为更可信的数据集。然而，在微服务的世界里，我们似乎完全放弃了数据的一致性，接受每个团队都在独立的环境中运行的事实。
大多数数据都没那么有用
这带出了微服务导向方法的另一个主要问题：在数据湖中的大部分数据实际上并不那么有用。
请考虑下面的 JSON 数据转储示例：
交易数据（其储存在一处定义不明确的 blob 中）可能对数据分析和机器学习至关重要，也可能毫无价值。数据中某些部分可能在未来具有重要性，或者部分现有的重要数据可能在未来会失去价值。
数据价值随时间变化这一理念，在哲学上与微服务的角色有着显著差异。微服务架构是针对当前需求定制构建的，而不会为了未来可能出现的需求而设计。如果为了某种潜在的未来需求来设计一个微服务，大多数工程师会对你说：
"等到有了具体的应用场景的时候，再来讨论。"
据 Forrester 的研究数据显示，“在所有的企业中，平均有 60% 至 73% 的数据未被用于分析”。这表明，在一个数据湖中，最多有四分之三的数据没有被有效利用。
然而问题并未止于此。一个数据节点被使用，并不一定意味着它具有价值。例如，假设一家打车服务平台的软件工程师创建了一个名为 vehicle_metadata 的数据库。其发出的一个事件的表述较为生硬，可能导致读者难以理解。经过修改后：这个数据库中，驾驶员车辆的传感器记录车速，一旦检测到速度显著增加，就会触发一个事件。应用程序将车速与限速进行比对，计算出两者的差值。如果驾驶员的速度显著超过限速，应用程序将向驾驶员发出警告，告诫他们可能因为不安全的驾驶行为而受到处罚。
公司的一位产品经理假设每次行驶的平均速度可能是一个有用的特征，用于他们正在构建的预测司机事故概率的机器学习模型。这个数据可以帮助理解公司应为司机投保的额度，以及计算每个司机需要支付的保险费。数据科学家将这个特征引入他们的训练集，并使用新数据训练模型，分析结果。然而，经过几天的实验后，团队得出结论，每次行驶的平均速度并不能有效预测事故发生的概率，因此他们决定舍弃这个特征，以降低噪声和降低成本。
在此例中，产品经理提出了一个假设，数据科学家进行了一个实验，将数据作为一项特性并入生产环境——然而由于数据价值缺失，这个特性被干净利落地剔除了。如果没有其他数据使用场景的需求，那么软件工程团队是否仍需要构建数据微服务、维护 API 和管理 schema 演进，仅应对自家团队使用的数据点？几乎所有的人（近乎 100 %的工程师）都会回答“无需如此”。
大部分企业都有数百上千个曾经有过实用价值，但如今已无用武之地的分布式仪表盘。数据混乱无序，以至于无法明确区分哪些问题已经解决，哪些问题仍然存在。由于转向面向微服务的数据策略无法解决这个问题（实际上考虑到之前的观点，这更可能使问题恶化），因此复制的数量将持续以指数级膨胀，还需要额外增加工程团队维护这些无用的上游工件的成本。从数据管理角度来看，这种方式无法实现扩展，对于工程速度来说也是毁灭性的。
微服务转型的主要目的是提高开发和部署的速度。然而，当每个架构都置于严格的管理下，会带来什么影响呢？可能的结果有两个：A）工程团队发布代码的速度会大大降低，或者更可能的是 B）工程团队将停止向数据团队提供完整的访问环境的数据。
最关键的一点是：在数据湖或现代的“数据仓库”中，大部分数据实际上是无用的。在数据确实具有价值之前就对其进行管理，对于数据生产者来说要求过于苛刻。只有当确定数据资产具有价值时，生产者才应被要求承担所有权。所有权的认定应从确保现有数据流通过简单的数据契约保持连贯性开始，然后可以扩展到更复杂的契约，如业务驱动的个人身份信息( PII )或数据安全约束。另外，所有权必须根据用例逐步提升。
数据开发的生命周期
软件开发生命周期（Software Development LifeCycle）是一个指导软件应用开发的规范化过程。它涵盖了从需求收集、确定项目目标与规格，软件部署到生产环境并为客户创造业务价值的多个阶段。
在过去的 30 年中，软件开发生命周期经历了多次优化，得到了众多开发工具的支持。我们可以将软件开发生命周期分为两个层次：战术层和战略层。战术层主要包含构建软件的具体工作流程与技术，如系统设计、版本控制、协作、持续集成/持续交付（CI/CD）、配置管理、云部署等，这是对“如何实施”问题的解答。而战略层则关注与技术无关的目标与任务，深入探究我们为何要以特定方式构建软件。
以下列举了战略性的软件开发生命周期的主要步骤：
根据客户的问题进行需求识别。
制定用户故事和需求分析。
创建包含系统设计和架构的技术规范。
撰写满足技术规范的代码。
将代码部署至开发环境进行测试和质量控制。
部署代码到生产环境供客户使用。
监控和维护代码，保证客户体验稳定。
这个流程中的几个关键步骤值得我们特别关注。首先，软件需满足特定目标，即它需要根据特定的架构设计，以实现特定的运行结果。其次，质量保证和测试过程，通常只需要进行一次。一旦代码验证、部署完成，我们通常不希望在未来对其进行实质性的修改，除非出现意外的边界情况。最后，此流程形成一个自给自足的循环，一名工程师可以独立完成所有步骤，不需要额外的帮助（当然，如果和产品经理与客户进行过沟通也有很很大帮助！）。
接下来，我们将一起深入探讨数据开发的生命周期：
首先，提出一个关于业务的问题。
然后，理解已有的数据，了解其来源以及所蕴含的含义。
接着，构建一个能解答该问题的查询代码。
在此基础上，评估该问题的答案是否具有实际应用价值。
如果答案是肯定的，那么应该将查询部署到生产环境中。
接下来，评估查询是否需要进行数据质量控制和管理。
若需要，那么就构建一个健壮的数据模型，并在整个数据流管道中执行数据质量检查及预警（这里需要上游所有者的参与）。
最后，随着新数据的产生或现有数据的改变，我们需要持续评估并重构查询。
此刻，你可能已经察觉到，这两种生命周期之间存在着显著的差异。软件开发生命周期（SDL）旨在生产出特定目的的软件，而数据工程更注重于探索和重新利用已有数据，以适应新的场景。我们收集到的数据始终在变化中，而且人们普遍预测数据实现会随着时间推进而演变，有时这种演变甚至会十分严重。由此，数据开发并非自成一体，下游团队与上游生产者之间需要紧密地协作。
总结归纳如下：正如文章开篇所述，微服务的设计目的在于提供灵活性、速度、独立性以及稳定性。而数据开发生命周期包括数据的发现、复用、紧密耦合以及持续的变化和演进。因此，微服务框架和数据开发的需求构成了不兼容的关系。
方形钉子放不进圆形的孔中
与软件相比，数据存在着很多独特之处，这使得微服务在满足分析和数据产品的需求方面有所挑战。
数据需要一个可信赖的来源，而微服务的本质是解耦和独立。
数据的价值并不均等：将所有数据封装为微服务的成本相当高昂，因为工程师需要负责那些可能没有用的用例，或者可能随着时间推移而失去价值的数据。
这与数据资产的特性形成了矛盾，即数据的价值会随着用例的变化而增减。
数据团队非常重视数据的发现以及为新的用例重新利用数据，这使得数据团队必须紧密依赖上游的数据源。然而，微服务的建立目的在于消除依赖，这与上述工作流程相悖。
如果我们选择不采用微服务，那么应该如何进行操作呢？传统的数据库管理方法并不能满足团队快速交付产品的需求，因此，我们必须寻求一种能够与微服务相容，同时又能支持适当的数据开发流程的解决方案。从最基本的原则出发，首先确定理想环境中应实现的目标，然后反向思考可支持此类方法的技术和组织模式，这是至关重要的一步。
数据团队应具备对 来自生产环境的原始数据 进行迭代和实验的权限，限制应降到最低。
工程团队不应仅出于对原型设计或实验目的，而被强制承担管道所有权。
一旦下游确定了合理的应用场景，数据消费者应有能力将数据资产"提升"到更高的质量级别。
这种提升应将数据资产设定为真实来源。未来任何的提升都应该修改真实来源的资产，而非创建多个版本。
由真实来源产生的数据应当从生产级管道分离出来，以替代原型环境中的相应原始数据。
当这些提升发生时，数据生产者应了解其依赖性的变化，并认识到向后不兼容的变化，更可能对数据依赖者产生的影响。
数据生产者应有一种方式来处理变更通知，如管理发布说明和声明已弃用的字段，以适应他们的服务随时间的演变。
如果数据资产对消费者不再有价值，那么不应再要求数据生产者继续将其作为产品维护下去。
数据治理应在必要时根据用例逐步加入，而非过早实施。
在我看来，微服务和数据网格往往被视为最终的理想解决方案，然而它们如敏捷开发一般，代表着理想化的后期组织模型。绝大部分公司在实践中，无法严格按照敏捷宣言来操作，而是选择实施那些能让迭代发布代码变得极为简便的技术，其中微服务就是一例。
同理，对于数据的生产者和消费者而言，他们应当在数据开发生命周期的各个阶段，及时地进行协作，最终以高质量的数据产品和根据需要提供的数据合同来达到工作的高峰。
在我即将发布的下篇文章中，我将深入探讨，一个支持在联合生态系统中，实施数据开发生命周期的架构，应如何构建，以及它如何与数据合同、可观察性、数据目录以及迭代式治理接口相结合。
数据契约为导向的架构示例
微服务是为软件开发者设计的，而不是数据。如果企业仍然固守老旧的方法，坚持用不适合的工具去解决问题，那么他们在研究人工智能领域的计划可能无法按照预期进行。数据工程师们需要主动争取认可和支持，帮助首席技术官理解数据开发的角色差异以及其相应的需求。如果你能成功做到这一点，那么解决当前面临的问题将变得轻而易举。
对于软件工程和数据工程之间的差异以及微服务架构对数据工程实践的影响，你有何看法？
推荐阅读：
好博客就要一起分享哦！分享海报
此处可发布评论
评论（0）展开评论
展开评论
