逐步从单一数据湖转移到分散的 21 世纪数据网格。 (另请查看后续文章:三种数据网格)
Left: data lakes with central access, on the right: user accessing data from teams domain teams providing a great data product. (all images by the author)
21 世纪的数据格局如何?ThoughtWorks 的 Zhamak Deghani 给出了一个漂亮的、对我来说令人惊讶的答案:它是去中心化的,与我们目前在几乎所有公司中看到的都非常不同。答案被称为“数据网格”。 如果您像我一样感受到公司当前数据架构的痛苦,那么您想迁移到数据网格。但是怎么做?这就是我在本文中探索的内容。 但首先,简要回顾一下数据网格。
现代软件开发需要一种分散的数据方法。数据必须被其生成团队视为产品;他们需要为它服务;分析团队和软件团队需要改变!
DDD、微服务和 DevOps 在过去十年改变了我们开发软件的方式。然而,分析部门的数据并没有赶上这一点。为了在采用现代开发方法的公司中加快基于数据的决策,分析和软件团队需要改变。
如果简短的摘要对您有吸引力,让我带您了解如何从您当前的起点实际进入数据网格。我们将通过一个示例,在途中经过遗留的单体、数据湖和数据仓库。我们一步一步地从我们的“旧”系统转移到这个新系统。 旁注:将数据湖称为“旧”对您来说可能看起来很奇怪,对我来说也是如此。时任 Pentaho 的首席技术官/创始人的 James Dixon 仅在 10 年前就设想了数据湖的概念。然而,围绕数据湖的核心转变,即软件、DevOps、DDD、微服务也是在过去十年才出现的。因此,我们确实需要迎头赶上,因为在这些趋势完全改变我们开发软件的方式之前,中央全能数据湖是一个老问题的答案。此外,一个全能的数据湖并不是 Dixon 最初想象的那样。 我们从一个典型的电子商务业务微服务架构示例开始。
E-commerce business modeled with three operational microservices.
这是一个基本的微服务体系结构,有两个域,一个“客户域”和一个客户API,一个CRM系统,“订单域”和一个订单API。这些服务是运营服务,它们运营着电子商务网站。这些API允许您在order API中创建订单,在CRM系统中的customer API中创建客户,检查信用额度等等。它们可能是REST API,再加上一些事件流、一些发布子系统,具体的实现并不重要。
旁注:对我们来说,订单和客户是不同的领域。这意味着这些领域的语言可能会有所不同。从团队2,即订单团队中看到的“客户”只有一个意思,即通过客户id识别的人,他们刚刚在网站上买了东西。在团队1中,含义可能有所不同。他们可能会考虑客户从CRM系统中的实体,它可以将状态从仅仅“领先”改变为“购买”客户,只有第二个在团队2方知道。
团队1拥有客户域。他们对这个领域了如指掌。他们知道什么是潜在客户,从潜在客户到实际客户的过渡状态如何等等。另一方面,团队2知道关于订单域的一切。他们知道被取消的订单是否可以恢复,网站上的订单漏斗是什么样子,等等。团队可能对另一个领域略知一二,但不是所有的细节。它们不是自己的。
这两个域都会生成大量数据作为副产品。组织中的很多人都需要这些数据。让我们看看其中的一些:
针对这些需求的数据湖/数据仓库解决方案将以类似的形式出现。
一个由数据工程师组成的中央团队很可能会通过 ETL 工具或流解决方案提供所有数据。他们将拥有一个中央数据湖或数据仓库,以及一个用于营销和管理的 BI 前端。 数据科学家可能会直接从数据湖中获取数据,这可能是他们访问数据的最简单方式。 我们看到这种架构有哪些可能的问题?
这是具有数据网格架构的同一个电子商务网站。
Green: new data-APIs. Bottom: Mgmt with straight BI tool access, marketing with data form data-API, left: data scientist with data from data-API
发生了什么变化?首先,数据科学家和营销人员可以访问源域中的数据!但还有更多。 旁注:数据网格架构的关键是获取数据 DATSIS。可发现的、可寻址的、可信赖的、自描述的、可互操作的和安全的。 我会提到以下几点。 让我们逐步了解要点
allCustomers/:每行为一个“客户”提供数据。 stats/ :使用诸如“Num customers: 1,000, Num Lead: 4,000;客户电话:1,500,中小企业客户联系:500,中小企业客户:600”
更多端点。
allOrderItems/:每行提供一个订单行项目。 allBuckets/:每行提供一个存储桶,它是订单项的集合。 stats/:提供数据,如“订单:1,000,000,2019 年订单:600,000 平均桶容量:30 美元”;stats 端点可能采用日期范围、年份等参数。
- 作为位于 AWS S3 存储桶中的 CSV/parquet 文件(端点由子文件夹分隔,API 由顶级文件夹分隔)(可寻址) - 作为通过 JSON/JSON 行的 REST API - 通过中央数据库和模式。(是的,我知道“中央”不是“去中心化”)
数据团队仍然在那里,但可能的负载被适当地分配给分散的参与者,无论如何这些参与者更适合这项工作。但是,数据团队也有自己的服务。怎么可能看起来完全一样?让我们看看数据湖如何仍然适合数据网格以及可能的痛点。如果你从一个开始,就会有一个重要的过渡状态。
在三种情况下,现在不一定是中央数据湖或仓库仍然有意义: 如果我们想结合两个数据域来建模中间的东西,这不能发生在一个域中,而应该发生在一个新的域中。 如果我们想整合市场数据等外部数据。外部数据通常不符合我们的标准,因此我们需要以某种方式包装它们。 如果我们从 A -> C 点过渡,我们不仅会丢弃我们的数据湖,还会降低它的复杂性。
什么时候应该考虑迁移到数据网格?首先,如果您对自己的结构感到满意,如果您对公司使用数据做出决策的方式感到满意,那么不要这样做。但是,如果您感到以下任何痛苦,则解决方案是数据网格。
让我们面对现实吧。数据仓库或数据湖,以及负责导入和建模数据的中央分析团队。这是一个遗留的整体,团队从中导入数据时没有API,可能有直接的数据库访问和大量的ETL作业、表格等。也许我们在新的领域中获得了一些新的微服务……让我们保持简单但通用的方式。
旁注:我喜欢Michael Feathers对遗留代码的定义:没有测试的代码。这就是我的意思,大的,丑陋的,不快乐的代码,没有人喜欢使用。
请记住,目标是逐步获取所有数据 DATSIS。
所有数据当前都通过数据湖消费和服务。如果我们想改变这一点,我们首先需要在那里打开大开关,同时为未来的迁移修复可寻址性的标准化。 为此,让我们尝试使用 S3 存储桶。因此,我们将标准化固定为:
示例:可以通过以下方式访问 {name}-data-service: - - s3://samethinghere/data-services/{name} 详细地说,所有服务都至少有一个端点,即默认数据端点。其他端点是子文件夹,例如: - s3://samethinghere/data-services/{name}/default - s3://samethinghere/data-services/{name}/{endpoint1} - s3://samethinghere/data-services/{name}/{endpoint2} 架构版本位于: - s3://samethinghere/data-services/{name}/schemata/v1.1.1.datetoS.??? 我们使用格式为“vX.Y.Z”的语义版本,日期为秒。 数据文件以“vX.Y.Z.datapart01.???”的形式表示,每个文件限制为 1000 行,以便于使用。
我们将数据湖重新路由到它的新“地址”并更改 BI 工具访问权限。
s3://samethinghere/data-services/data-lake/default s3://samethinghere/data-services/data-lake/growthdata s3://samethinghere/data-services/data-lake/modelleddata ???
这对组织的其他人来说还没有改变,我们需要给他们访问权限。
我们可以通过在我们的知识管理系统中创建一个页面来实现最简单的可发现性形式(即 confluence/您的内部 wiki,...)。 好的,所以现在除了当前使用数据湖的人之外的新人可以找到数据。现在我们可以开始将节点添加到我们的数据网格中,我们可以采取任何一种方式,通过打破一个闪亮的新微服务或打破那些令人讨厌的旧旧片段之一。 让我们首先考虑微服务案例。
拆分服务的重点是将所有权交给创建数据的领域团队,例如,您可以让分析团队中的某个人加入负责的领域团队。现在,让我们以“订单团队”为例。 我们创建新的订单数据 API。修复一组基本的 SLA,并确保遵守您为数据湖设置的标准。我们现在有两个数据服务:
s3://samethinghere/data-services/data-lake/default s3://samethinghere/data-services/data-lake/growthdata s3://samethinghere/data-services/data-lake/modelleddata s3://samethinghere/data-services/order-data/default s3://samethinghere/data-services/order-data/allorderitems s3://samethinghere/data-services/order-data/stats
将新服务放入可发现性工具中。 第二种选择是让中央分析团队创建这个数据服务,在这种情况下,所有权仍然存在。但至少我们分离了服务。
遗留系统通常不像闪亮的新微服务那样好用。通常,您将拥有某种数据库表,您甚至不知道从其中获取数据,从某些服务器或任何其他形式的遗留数据中获取一些 CSV,没有良好记录和标准化的接口。 没关系。你现在可以保持这种状态。您已经有了某种方式将该数据导入您的数据仓库或数据湖,因此将其拆分出来并将其表示为数据服务。 例如,您可以从:
源数据库 — ETL 工具 → 数据湖中的原始数据 → 数据湖中的转换数据
围绕前两个阶段进行总结,并使用标准化:
(源数据库 - ETL 工具 → 数据湖中的原始数据 → S3 存储桶)= 新数据服务 (新数据服务的S3 Bucket)——ETL工具→将数据导入数据湖→数据湖转换数据
这样,当你转移服务时,域团队只需要切换主干,依赖用户就可以切换到新的数据消费方式,甚至在域团队获得所有权之前。
现在开始将您的数据服务推送给普通受众以获得快速反馈,让营销团队找到您已经突破的来源。然后将 BI 工具切换到现在的两个数据服务,而不仅仅是一个。 然后,您可以考虑关闭对数据湖服务中订单数据的支持。
如果你在这里,恭喜,你已经打破了中央数据湖的第一部分,现在你需要确保在这些服务的新功能请求流入之前,所有权也已经转移。你可以这样做:
包装,包装,包装,打破越来越多的服务。优雅地推出旧部分并用新的 API 替换它们。开始收集分布式服务的新功能请求。 到目前为止,您的中央数据湖将变得非常小,仅包含已连接和建模的数据,如果您开始转移人员,您的数据团队也会如此。
构建通用数据平台。这可能意味着每个人都可以使用库将文件放置在正确的位置或任何其他更复杂的工具集中。无论团队中有什么重复,您都可以将大部分内容掌握在中央手中。例如,如果您很快注意到营销和销售人员不容易访问 AWS S3 文件,您可能会决定从 S3 切换到可通过 EXCEL 访问的中央数据库等。 在这种情况下,您需要一个库来通过简单的升级进行切换,而不会给团队带来太多麻烦。例如,在 AWS 设置中,您可以使用通用的“data-service-shipper”创建一个 lambda 函数,该函数负责:
这样,域团队除了升级他们的“库”之外几乎没有任何努力。其他选项可能包括创建一个通用 REST API,您可以用它发出数据及其位置的信号,并让 API 处理其余部分,例如将 CSV、parquet 等转换为单一格式。
因此,与微服务一样,从单体应用开始的最佳方法是在您感到某种“痛苦”时分解部分。但是我们先突破哪一部分呢?这是基于三个考虑的判断电话:
这些好处间接表明,您将能够收集多少真实数据服务的用例,因为不断变化的数据意味着数据服务的变化,而数据的重要性意味着许多人希望从该数据服务中获得洞察力. 如果你权衡这些事情,你可能会得出不同的结论。例如,在我们的示例中,客户域可能是一个很好的起点,因为此类数据很可能经常更改。但是,有时它不如订单数据重要,另一方面,订单数据可能难以突破,这取决于您已经在其上放置了多少 1000 个 ETL 作业。 如果您有一个起点,那么您的道路上仍有垫脚石。
目前,作为副产品提供数据的团队没有适当关注该数据的动机,主要是因为该数据的潜在“利益相关者/消费者”没有直接反馈。
这是必须改变的,你必须把它作为一个核心部分来处理。这可能就是为什么Zhamak Deghani建议您使用特定的用例,识别用户,并组建一个新团队,只关心特定的用户。一、 另一方面,我不明白为什么当前的订单团队不能担任这个角色。诚然,这种转变有点困难,但公司必须花费的资源要容易得多,而且可能更容易销售。
如果你无法让数据生成团队跳上这列火车,你有两个选择:
最后,让我们探讨一下这种体系结构的可能替代方案。
我试图想出一个替代方案,但意识到这更像是一个由不同实现组成的矩阵。
数据网格的关键概念是分散所有权,我们可以这样说,因为域团队通常认为他们的数据是他们真正拥有的副产品。因此,数据湖是原始数据的集中所有权。
如果我们现在区分原始数据和转换数据,我们可以看到四种不同的数据架构。我们还可以看到从数据湖到数据网格的2-3种不同方式。
Ownership of raw & transformed data can both be central or decentralized. This produces four quadrants with a variety of solutions.
如果从“数据湖”移动到“B 点”,然后再到完整的数据网格,我们在上面所描述的内容。 然而,第二种选择是首先实现去中心化的“转换数据所有权”,然后可能考虑转向完整的数据网格。
区别在哪里?在这种情况下,您可以收集大量需求,并锐化部门对数据的确切用例。像市场营销这样的部门通常更接近领域,然后是中间数据团队,所以你会在“领域语言”问题上获得一些优势,但不是全部。您仍然会在原始数据消耗方面保持中心瓶颈,而不是将“数据作为产品”推入领域团队。我认为这两者在未来的某个地方都是必要的。