炒作是一件有趣的事情。有时你会发现自己处于《教父2》的境地，其中的炒作是完全合理的。你听说过它。你试一下。生活被改变了。万岁！
其他时候，你会发现自己更像是《阿凡达：水之道》的情况……你周围的每个人都在嘀咕诸如“令人惊叹的身临其境”之类的东西，而你在一旁想知道你可以花多少时间观看蓝色外星人不擅长游泳。
在过去四年里，几乎没有什么数据行业流行语比自助服务宠儿“数据网格”更受炒作了。播客。时事通讯。整个 Slack 小组都致力于去中心化架构。太多了。
现在，我只想说一下前端，数据网格不是阿凡达 2 的情况。 （詹姆斯，14 年。呃。）数据网格是一种深思熟虑的去中心化方法，有助于创建领域驱动的自助数据产品。
问题是，并非每个组织都应该以这种方式组织其架构，或者能够支持它。
数据网格（包括数据网格治理）需要流程、工具和内部资源的正确组合才能发挥作用。无论是平台设计还是组织结构，有时数据网格对您的业务没有意义，但这没关系！
但这引出了一个问题——你怎么知道？
在本文中，我们将重新审视数据网格，讨论它是什么、为什么它对某些团队有意义，以及何时对您的团队没有意义！
跳上炒作周期，让我们开始吧。
什么是数据网格？
一段时间以来，数据访问一直是组织的呼声。我们如何更快地获取我们需要的数据？我们怎么知道里面有什么？我们如何验证该数据对于我们的用例的准确性和适用性？
一度，数据网格是这些问题的最佳答案。
与软件工程团队从 转型的方式非常相似从单体应用程序到微服务架构，数据网格在很多方面都是微服务的数据平台版本。
Zhamak Dehghani 在 2019 年首次定义，数据网格是一种分散式方法，通过利用面向领域的自助式设计，拥抱企业中无处不在的数据。
它主要由四个关键组件组成：
- 数据即产品：定义关键数据资产，包括为每个领域带来价值的分析、运营和面向客户的资产
- 面向域的所有权：数据所有权及其生成的数据产品在域所有者之间联合，包括基于一组统一的功能对自己的 ETL 管道负责。
- 自助服务功能：数据网格允许用户抽象化技术复杂性，并通过包含数据管道引擎、存储和流传输的中央平台专注于自助服务其个人数据用例基础设施。
- 互操作性和标准化：每个域都有一套通用的数据标准，有助于促进具有共享数据的域之间的协作，包括格式设置、数据网格治理、可发现性和元数据字段等数据特征。
在现实部署中，这通常会转化为一个小型中央平台团队，提供共享基础设施和基线标准，每个域中的嵌入式数据团队都可以在此基础上进行构建并根据自己的需求进行定制。
但随着数据网格理论在炒作周期中的传播，很明显数据网格的用例比最初提出的概念要窄得多。 而且要困难得多。
因此，尽管数据网格非常灵活，而且我们真的很喜欢它，但以下是数据网格可能不具备的一些情况：没有道理。
当数据网格不起作用时
领域人才密度不足
图片由提供蒙特卡洛。
虽然数据网格的主要目标是跨领域联合产品所有权，但这只有在相关领域团队知道如何处理这些数据职责后才有效。
即使具有所有抽象的技术复杂性，数据网格仍然需要在每个域中嵌入足够的数据人才才能使其发挥作用。如果没有掌舵经验，您的数据网格将受到低质量、维护不善的数据产品的困扰，无论如何最终都需要重建。
因此，在您的数据团队一头扎进数据网格项目之前，请花一点时间考虑一下您组织的背景。每个领域团队是否都具备取得成功的技能和能力？如果没有，需要什么才能让他们到达那里？您是否会得到领域利益相关者的支持来促进这一变革？
如果这些问题的答案是“否”或“短期内不会”，请不要羞于暂时跳过数据网格，并在您的组织能够更好地实现其价值时再回来。
业务领域有重叠的产品需求
数据网格可能没有意义的另一种情况是当您的数据产品跨业务领域重叠时。
无论是共享收入仪表板还是供外部用户使用的操作机器学习模型，共享数据产品都会给民主化架构带来有趣的组织困境。
就像旅行裤姐妹会一样，没有人群吸引力。
同样，数据网格的主要理念是民主化所有权。 那么，如果你无法与数据产品的所有者划清界限，你如何决定谁获得金票？ （稍微混合一下比喻。）
当涉及重叠数据产品时，您基本上有两种选择。
- 选项 1：独立于业务域设计数据域。虽然这绝对是一个可行的选项，只要您的“数据网格或不数据网格”独白的其余部分有效，但它是也可能会造成一些组织上的麻烦——至少在项目的入职阶段。
- 选项 2：继续由中央数据团队管理这些数据产品。这可以通过维护完全集中的架构或简单地在中央数据团队下管理这些单独的数据产品来实现——尽管后者仍然可能在此过程中造成一些组织上的麻烦。
此外，Sanne Group 还指派了数据管理员来管理其共享数据资产。虽然数据管理员的想法多年来已经不再流行，但这是针对给定用例增强数据网格的一个很好的例子。
但是，如果您不确定如何回答这个问题，请考虑暂时维护集中式架构，并在稍后重新审视数据网格讨论。
您的数据组织太小
小一点也没什么不好。事实上，作为一个小型组织通常意味着更大的敏捷性、更多的控制力以及更有效地迭代的能力。
但这也意味着数据网格可能不是近期最务实的举措。
从表面上看，过早地走向权力下放似乎是一个好主意。您可能会想，“如果我尽早启动数据网格，我现在就可以在文化中建立所有权，并避免以后适应更大的组织带来的混乱！”
不幸的是，您更有可能发现这实际上带来的麻烦远大于其价值。
首先，构建数据网格成本高昂，不仅会影响您的预算，而且会影响负责促进变革的数据团队的关键工程时间。面对刚起步的数据团队更重要的优先事项（例如提供关键数据产品和建立质量标准），这笔费用很难证明是合理的。
您首先需要管理基本功能和基础架构，然后才能开始考虑支持它们的架构。
数据网格需要数月的专门规划、范围界定、构建和培训才能使其落地 – 并且假设您手头有足够的预算来支付它。
与其不断地跟上炒作的步伐，不如将资源用于提供早期价值，而不是为利益相关者解决新业务用例的功能和数据产品。
更重要的是，对于已经实现数据所有权民主化的大型组织来说，抱怨他们已经变得过于去中心化，而且他们的民主化实际上造成了新的孤岛，使得数据所有权难以统一和分散，这并不罕见。利用整个组织的数据——数据网格旨在提供的关键组件之一。
通常，小型组织的数据需求较小。如果您可以轻松维护集中控制（不牺牲业务价值），那么您可能应该这样做。在一个团队中执行治理和质量标准总是比五个团队更容易，而且对您（和您的预算）造成影响的基础设施也更少。
当您是一个精益团队时，请选择精益解决方案。从集中的所有权结构开始，然后乘坐火车到达终点站。然后然后购买民主化列车的车票。
您拥有一个碎片化的数据平台
<图>
新的托管和开源数据工具的爆炸式增长继续给平台团队带来统一平台的挑战。图片由Lakefs.io提供。
回想一下，数据网格的关键方面之一是标准化和互操作性。
数据网格使集中式数据团队能够释放对其数据产品的控制的主要原因是他们仍然控制着支持它们的基础设施。这意味着，为了让平台团队有效监管数据网格并实现跨团队共享数据，每个域都需要在具有标准化工具和数据网格治理实践的单一平台上运行。< /p>
如果您的平台工具是分散的（营销团队选择“特殊”ETL 工具，财务团队选择他们首选的 BI 解决方案），那么您在数据网格之战还没有开始之前就已经失败了。
因此，第一要务是为数据产品的构建方式定义“黄金途径”，然后在考虑联合之前与集中式数据团队尽可能多地对该流程进行压力测试跨域的所有权。
请记住：数据网格更多的是关于流程而不是工具。如果您没有能力影响执行这些流程的文化，那么定义正确的工具也无济于事。
每个可靠的数据架构都需要可靠的数据
有时，数据网格的答案不是“不”，而是“现在不行”。如果您真的决心追求自助式架构，请从小事做起。通过明确定义的数据产品和受控管道来确定组织的特定领域，并尝试首先为该团队提供支持。看看您是否能够检查此列表中的每个问题，并仍然提供您期望从数据网格项目中获得的价值水平。
数据沿袭和数据可观测性等工具 可以帮助数据领导者了解整个组织的消费模式，并帮助他们向更加去中心化的结构过渡。
您可能意识到集中式方法毕竟是您团队的最佳解决方案，并且您加倍投入 SLA 或更好的数据产品，而不是启用自助服务模型。
但是，无论您选择民主化还是集中化，您可以为数据架构做的最好的事情就是用高质量且可靠的数据来支持您的数据产品。