数据中的微服务与单体方法
原文：towardsdatascience.com/microservices-vs-monolithic-approaches-in-data-8d9d9a064d06比这些令人惊叹的雕像更加单一的是 Airflow。照片由在拍摄。
原文：
towardsdatascience.com/microservices-vs-monolithic-approaches-in-data-8d9d9a064d06
比这些令人惊叹的雕像更加单一的是 Airflow。照片由Stephanie Morcinek在Unsplash拍摄
引言
我不需要用很多话来让你相信在数据空间中选择工具是多么困难。有数百种，甚至数千种方法来解决这个问题。
人们忽视的是架构如何影响这些决策。
大约 20 年前，应用程序存在于需要它们的公司的电脑上——这被称为“本地化”。拥有这些电脑是一个架构决策。因此，云软件供应商不存在，因为云软件由于其固有的与当时架构的不兼容性而没有任何需求。
快进到 2024 年，情况正好相反——大多数人已经完全在云端。然而，我们中的一些人仍在运行自己的服务器。其他人有混合模式。这意味着理解你的架构对你选择的解决方案的影响比以往任何时候都更重要，在这篇文章中，我们将深入探讨微服务与单体方法在数据架构上如何影响你购买的工具。
微服务与单体架构
数据中发生的事情是微服务与单体争论的重新点燃。为了理解这是什么：
单体应用作为一个单一统一的单元构建，而微服务架构是一系列更小、可独立部署的服务。
在数据领域，十年前单体应用相当普遍。一个例子可能是一个大型 Airflow 仓库，包含你的数据摄取代码、数据转换代码和业务自动化。
业务自动化可能包括刷新仪表板、发送报告或在任务失败时发送警报。
相比之下 - 云的爆炸式增长，部分由风险投资资金（见这份报告）推动，已经催生了与微服务非常相似的数据架构。微服务包括用于管理批量数据移动、数据转换和仓库管理，或管理流数据的程序。
无论你将你的数据堆栈视为单体还是微服务，都应该影响你选择软件的方式。
单体架构 - 在这个例子中，所有“应用程序功能”如数据摄取基本上都生活在同一个存储库中，同一个应用程序负责所有功能的部分。这个应用程序直接或通过存储层向可视化层提供数据。想象一下作者的观点
微服务数据架构：假设
如果选择微服务架构，你隐含地做出了一些关于你希望微服务做什么以及你希望它们如何通信的假设。这些应该影响你选择完成任务的方式。
假设 1：分布式基础设施
微服务允许数据团队将他们的基础设施分布在不同部分的云和本地基础设施上。这意味着每个微服务可以专注于自己的事情。这有两个好处。
- 专业化与效率
与使用单一基础设施进行数据摄取、转换等不同，你可以为不同的目的使用不同的部分。这导致专业化程度更高，最终效率也更高。
- 更容易扩展
通常通过将工作负载分割成不同的微服务，这意味着计算能力（在内存和存储方面）被分割到不同的地方。这意味着上下文扩展服务变得不那么头疼。例如，你可能能够通过运行基本工作负载在无服务器函数（自动扩展）而不是维护一个Kubernetes 集群来解决问题。
微服务数据架构。在这个例子中，数据管道的每一部分都是由一个独立的应用程序执行的。这可能是一个自建的服务或 SaaS 工具。这些服务通过一个独立的编排仓库连接在一起。想象一下作者的
假设 2：高互操作性和治理
通过假设微服务基础设施，你隐含地假设这些服务可以相互通信并且是互操作的。在软件工程中，这是通过合约、基于事件的通信和集中式日志系统（如Datadog）实现的。
这在数据方面有些棘手。如果你有一个数据摄取服务、一个位于仓库上的数据转换服务以及一个 BI 工具（第三方 SaaS），那么如何将它们连接并一起治理呢？
传统的方法是使用像Airflow这样的工具将它们连接起来，但这每次连接点时都需要编写代码。这种成本很高，这降低了互操作性，违反了假设。
此外，在许多“现代数据堆栈”架构中，获取端到端可观察性和治理的唯一方法是通过购买额外的工具，如数据目录或可观察性工具，这些工具都极其昂贵。通常，采用微服务架构的数据团队无法解释地接受缺乏互操作性和几乎没有任何治理。
假设 3：可接受的数据流出和存储
在数据架构中，从微服务生成的大量数据和元数据都具有很高的价值。这些数据存储在各个地方，但会在服务之间共享。这导致了一些"数据流出"成本，你假设在微服务风格的架构中这是可以接受的。
例如，如果你采用“ELT”模式，简单地“将所有数据倒入 Snowflake”，你可能需要支付比先进行一些“T”操作更多的流入费用——如果你希望你的架构以更事件驱动的方式通信，这通常是一个好主意。Kafka 支持这一点，例如。
它还揭示了一些最近广泛传播的其他工具。以可观察性、血缘或异常检测工具为例。所有这些工具都会从你的底层系统中获取数据（数量相当大）。这意味着你通过使用这些工具支付了数据流出的费用。
其次，它们存储这些数据，所以你也会在那里支付存储费用。第三，它们倾向于运行与您用于交付数据产品的时间表不相关的计划，这可能会使它们变得昂贵。最后，并且至关重要，它们经常拼凑出它们没有的上下文，因为它们实际上是新的微服务，不属于你已有的东西——这导致不必要的计算成本过高，而你反过来要为此付费。
在这个例子中，微服务架构部分被 SAAS 工具所取代。对于这些 SAAS 工具，没有仓库需要管理，然而它们涉及 A) 出口，因为数据必须从数据层向外传输。它们还涉及 B) 分离的存储，这当然是有成本的。这些工具通常通过 UI 提供自己的可视化层。想象一下作者的图片
我不会深入讨论单体架构的考虑因素，那将是另一篇文章的主题！
微服务或模块化架构的学习经验
拥有大量相互交互或被编排的数据应用并不真的是微服务——阅读这篇文章的软件工程师会因此责备我！所以让我们称它为“模块化”。
这种“模块化”方法与现代数据堆栈相一致。然而，现代数据堆栈违反了假设 2 和 3。
它违反了假设 2，因为 MDS 的互操作性和自我通信程度相当低。让它真正工作的唯一方法是有一个大型的 Airflow 仓库和大量的代码。这在构建单体架构时是一个更自然的事情。
它违反了假设 3，因为没有真正可接受的出口和存储成本水平。通过拥有多个非本地化且具有独立存储/计算的独立应用程序，你实际上在每次添加新的软件时都要支付数据成本的两倍。
为了更清楚地说明这一点，我经常问这样的问题：“如果我必须自己构建这个，它会是什么样子”？
答案总是“它是[插入云服务提供商名称]的内部构建服务”。这是因为我们的大部分数据都在云中，所以如果我们的云服务提供商提供了我们想要的服务，我们就不需要为出口和存储支付两次费用。
以数据目录为例。从架构上讲，数据目录从您的仓库（比如说，BigQuery）中检索所有元数据，存储它，对其计算一些东西，并为您提供用户界面。
如果你自己使用那种架构构建它，你将需要支付出口费用，支付额外的存储费用，一些额外的计算费用（目录计算相当简单，所以费用很低），而且除非你在我自己的云中部署它，否则你还会有一点点安全上的烦恼。
大部分这种成本都是不必要的 – 它应该只发生在已经拥有数据的那个服务中。或者也许数据应该像在湖屋/虚拟化模式中那样可供多个服务使用。但我不建议像目录那样构建它 – 之前图中的棕色盒子。
但等等 – GCP 难道没有类似的东西吗？名字从我脑海中溜走了，就在舌尖上……我想起来了！它是数据目录！
如果你使用 BigQuery，从架构上讲，使用已经存在的数据目录会更有意义。没有出口费用，没有重复的存储，没有额外的安全风险，而且从理论上讲，UI 可能更好，因为所有这些都在同一个地方/Chrome 标签页上，并且使用相同的条款。
因此，那些“应该在的地方”的东西总是会比那些“不在应该在的地方”的第三方 SaaS 工具具有优势，因为提供它的成本更低。
这可以在下面的图中说明，其中 GCP 的交付成本低于像 Collibra 这样的公司。从长远来看，这些服务将不得不变得非常好，并且与云提供商构建的任何内部工具相比都非常高效。
在 5 年后，如果你支付价格 P1，你将从 Collibra 获得与 Q1 相当的服务质量。如果你选择 GCP，你将获得与 Q2 相当的东西。Q2 比 Q1 好，所以你应该选择 Q2。今天 – GCP 的数据目录不如 Collibra 的好，如果你想得到与 Q1 相当的东西，你大概只能购买 Collibra 或者支付 GCP 更少的费用，然后接受比 Q1 略差的东西。随着 GCP 在数据目录上的投资增加，这种情况将会改变。想象一下作者的图片
从长远来看，GCP 的数据目录总是会比 Collibra 的便宜。记住，GCP 也不需要雇佣中央成本并成立另一家公司来为你提供数据目录 – 他们只是派了 100 名开发者来做这件事）。
在相同的价格下，如果云服务提供商执行得高效，第三方 SaaS 供应商是无法竞争的，因为他们的提供成本太高，除非他们的服务实质上更好（目前可能就是这样）。
结论
在本文中，我们看到了数据架构如何迫使数据工程师和架构师对他们的应用程序如何运行以及如何相互操作做出假设。我们看到，在采用微服务或“模块化”风格架构的情况下，良好的架构需要你做出一些假设。
当利用现代数据堆栈作为整体，并使用一个也是独立 SAAS 的微服务时，这些假设被违反，因为互操作性程度低和出入/存储成本高。
有趣的是，云基础设施提供商在开发附加功能方面相对于独立软件供应商具有优势。这是因为他们拥有更多的资源，并且由于他们是已经掌握所有数据的那些人，因此在架构上具有优势。
动机示例将云服务提供商（GCP）与数据目录提供商（Collibra）进行了比较。这可以扩展到许多软件提供商，但并非所有。通常，控制平面上的工具，如治理、目录、数据质量等，很好地适应现有基础设施。
需要大量计算并专注于将数据输入到云基础设施的工具在外部是有意义的。例如，包括流平台或数据摄取工具。
最有趣的是，像 Airflow 和 Monte Carlo 这样的编排和可观察性工具强迫在现代数据堆栈中使用的模块化架构采用了一种在架构上不吸引人的模式。
我认为观察架构和成本如何开始影响人们在数据空间中的选择将非常有趣。自由市场以神秘的方式运作。其力量在数据方面并不亚于其他任何地方！💸
联系我，如果你想了解这种观点如何应用于单体架构、其他工具或一站式数据平台。
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
14
0- 0
已为社区贡献496条内容
所有评论(0)