痛点
什么时候应该考虑迁移到数据网格？首先，如果您对自己的结构感到满意，如果您对公司使用数据做出决策的方式感到满意，那么不要这样做。但是，如果您感到以下任何痛苦，则解决方案是数据网格。
- 如果您将域复杂性与微服务/域驱动设计相结合，您可能会觉得事情过于“复杂”，以至于中央团队无法立即正确地提供数据。
- 如果确实如此，您认为将数据导入数据仓库的成本很高，因此您忽略了要导入的对个人用户有价值的数据源。这些应该单独提供服务，并且是“作为数据网格节点剥离”的完美候选者。
- 你还没有关闭数据 -> 信息 -> 洞察力 -> 决策 -> 行动回到数据的循环。
- 您是数据 -> 连续智能周期中的数据速度以周和月为单位，而不是几天或几小时。
- 您已经在“将数据转换尽可能靠近数据用户”；这是我们目前正在做的事情，通常这是数据 -> 信息 -> 洞察力 -> 决策 -> 行动 -> 数据管道中出现瓶颈的迹象。这可以被认为是一个中间阶段，有关更多信息，请参见最后一段。
从单一数据湖到数据网格
让我们面对现实吧。数据仓库或数据湖，以及负责导入和建模数据的中央分析团队。这是一个遗留的整体，团队从中导入数据时没有API，可能有直接的数据库访问和大量的ETL作业、表格等。也许我们在新的领域中获得了一些新的微服务……让我们保持简单但通用的方式。
旁注：我喜欢Michael Feathers对遗留代码的定义：没有测试的代码。这就是我的意思，大的，丑陋的，不快乐的代码，没有人喜欢使用。
请记住，目标是逐步获取所有数据 DATSIS。
- 第 1 步：（可寻址数据）重新路由数据湖数据并更改 BI 工具访问权限。
所有数据当前都通过数据湖消费和服务。如果我们想改变这一点，我们首先需要在那里打开大开关，同时为未来的迁移修复可寻址性的标准化。
为此，让我们尝试使用 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
？？？
这对组织的其他人来说还没有改变，我们需要给他们访问权限。
- 第 2 步：（可发现性）创建一个空间来查找我们的新 data-* 源。
我们可以通过在我们的知识管理系统中创建一个页面来实现最简单的可发现性形式（即 confluence/您的内部 wiki，...）。
好的，所以现在除了当前使用数据湖的人之外的新人可以找到数据。现在我们可以开始将节点添加到我们的数据网格中，我们可以采取任何一种方式，通过打破一个闪亮的新微服务或打破那些令人讨厌的旧旧片段之一。
让我们首先考虑微服务案例。
- 第 3 步：开发一个新的微服务。
拆分服务的重点是将所有权交给创建数据的领域团队，例如，您可以让分析团队中的某个人加入负责的领域团队。现在，让我们以“订单团队”为例。
我们创建新的订单数据 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
将新服务放入可发现性工具中。
第二种选择是让中央分析团队创建这个数据服务，在这种情况下，所有权仍然存在。但至少我们分离了服务。
- 第 4 步：打破传统作品。
遗留系统通常不像闪亮的新微服务那样好用。通常，您将拥有某种数据库表，您甚至不知道从其中获取数据，从某些服务器或任何其他形式的遗留数据中获取一些 CSV，没有良好记录和标准化的接口。
没关系。你现在可以保持这种状态。您已经有了某种方式将该数据导入您的数据仓库或数据湖，因此将其拆分出来并将其表示为数据服务。
例如，您可以从：
源数据库 — ETL 工具 → 数据湖中的原始数据 → 数据湖中的转换数据
围绕前两个阶段进行总结，并使用标准化：
（源数据库 - ETL 工具 → 数据湖中的原始数据 → S3 存储桶）= 新数据服务
（新数据服务的S3 Bucket）——ETL工具→将数据导入数据湖→数据湖转换数据
这样，当你转移服务时，域团队只需要切换主干，依赖用户就可以切换到新的数据消费方式，甚至在域团队获得所有权之前。
- 第 5 步：（可发现性）切换可发现性和 BI 工具源。
现在开始将您的数据服务推送给普通受众以获得快速反馈，让营销团队找到您已经突破的来源。然后将 BI 工具切换到现在的两个数据服务，而不仅仅是一个。
然后，您可以考虑关闭对数据湖服务中订单数据的支持。
- 第 6 步：迁移所有权。
如果你在这里，恭喜，你已经打破了中央数据湖的第一部分，现在你需要确保在这些服务的新功能请求流入之前，所有权也已经转移。你可以这样做：
- 通过迁移一些人，连同服务到域团队
- 也许通过为新服务创建一个新团队
- 只需将服务迁移到域团队
- 第 7 步：继续。
包装，包装，包装，打破越来越多的服务。优雅地推出旧部分并用新的 API 替换它们。开始收集分布式服务的新功能请求。
到目前为止，您的中央数据湖将变得非常小，仅包含已连接和建模的数据，如果您开始转移人员，您的数据团队也会如此。
- 第 8 步：（TSIS）使其值得信赖、自我描述、可互操作且安全。
构建通用数据平台。这可能意味着每个人都可以使用库将文件放置在正确的位置或任何其他更复杂的工具集中。无论团队中有什么重复，您都可以将大部分内容掌握在中央手中。例如，如果您很快注意到营销和销售人员不容易访问 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 点”，然后再到完整的数据网格，我们在上面所描述的内容。
然而，第二种选择是首先实现去中心化的“转换数据所有权”，然后可能考虑转向完整的数据网格。
去中心化转换后的数据所有权如何？
- 数据湖仍然可以导入所有“原始数据”
- 然后，靠近决策者的数据知识丰富的用户可以访问原始数据，并在本地桌面 ETL 解决方案中进行转换。
- 原始数据也可以被推送到分散的数据仓库中，在那里，离用户更近的“某人”可以对该数据进行基本的 ETL。
- 当然，每个部门都可以有自己的小型数据团队为该部门做 ETL。
区别在哪里？在这种情况下，您可以收集大量需求，并锐化部门对数据的确切用例。像市场营销这样的部门通常更接近领域，然后是中间数据团队，所以你会在“领域语言”问题上获得一些优势，但不是全部。您仍然会在原始数据消耗方面保持中心瓶颈，而不是将“数据作为产品”推入领域团队。我认为这两者在未来的某个地方都是必要的。
