数据仓库、数据湖以及中心化数据所有权的问题

在数据和分析领域中，数据网格（Data Mesh）范式是取代数据湖、成为主要架构模式的强势候选者。 重要的是，数据网格引入了新的组织视角，并且它与特定技术无关。 其关键思想是将领域驱动设计（DDD）和产品思维，应用到数据和分析领域的难题中。与引入DevOps文化相比，建立数据网格文化包含人与人的连接，同理心，以及联合责任结构的建立。 通过这种方式，从数据中产生业务价值能够实现可持续的规模化。

随着各个公司在关键业务领域进行数字化，他们收集了越来越多的有关其自身流程和客户的数据。 因此，他们希望使用这些数据来推动基于事实的决策，以便更好地满足客户的需求。 在某些行业中，数据驱动的水平，即公司能够基于数据而不是凭直觉做出决策的速度，已经成为决定性的竞争优势。

数据仓库、数据湖以及关于中心化数据所有权的问题

在传统的商业智能（BI）中，集中维护的数据仓库是许多商业决策的基础，例如：通过最新的报表来支持这些商业决策。 随着大数据技术的成熟以及数据科学的日益普及，许多公司投资建设了中央数据湖——有些是为了替代数据仓库，但更多情况下是对现有数据仓库的补充。 二者的主要区别在于集展和建模的不同：通过数据仓库的方式，数据在摄取时，已经根据特定的应用进行了转换； 对于数据湖，这种转换仅在数据用于消费时发生。 但是，这两种方法的共同特点是中心化。 而正是这种中心化导致了问题的反复出现。

我一次又一次看到，一个模式是不堪重负、压力重重的中央“数据团队”。 这个团队维护着中央数据基础设施，无论是数据仓库还是数据湖。然而，更重要的是，该团队孤立地负责向利益相关者，产品团队和数据科学家提供及时可靠的数据集或报表。 我故意称其为数据团队，而不是更具体地称为数据工程或数据洞察团队，是因为它反映了这个团队经常要处理的不明确的责任组合。

因此，该数据团队的成员经常会陷入困境。 他们花费大量时间进行“消防员”式的救急工作，也修复数据生产团队引入的问题，但也很难使数据的消费者满意。 尤其令人悲伤的是，这些团队成员通常是公司中最精通数据的人。并且经常可以看到的是：这种长期的压力会导致生产力下降，工作场所满意度降低，甚至员工流失率增加。

如今有能力的工程师为什么无法解决这种问题？ 原因在于这不是技术问题，而是组织问题。 主要问题之一是参与各方的职责划分不当。

数据生产者一方，具有领域专业知识，即他们了解数据的含义，并且可以直接更改数据的形式； 而数据使用者一方，是数据的既得利益者，了解数据的业务潜力，因此可以清楚地描述需求，包括数据质量的相关需求。 数据团队的成员夹于这两方之间：他们有责任交付可靠和高质量的数据，但他们既没有领域专业知识，也无法直接影响数据如何产生。 此外，他们并不是最终使用数据的决策者。 这意味着利益，责任和能力分布在三个不同的方面，这导致了摩擦，沮丧和误解。

图一，处理数据的传统方式切断了数据负责人与数据使用者的关系

Data Mesh：去中心化的领域所有权，共享的基础设施

相反，数据网格的目标状态是让数据生产者和数据使用者尽可能紧密地合作。从组织的角度来看，理想的情况是同一团队同时生产和使用相同的数据，以便能够在同一个团队中考量利益，责任和能力。在实践中，这通常是不可行的，因为数据生产团队已经在其特定领域承担了太多责任，以至于他们也无法完全负责数据消费应用。因此，将这些角色分成两个直接沟通无需中间人的团队，已经是向前迈出了一大步。数据生产团队的目标应该是提供数据，以便其他人可以在不需要详细领域知识的前提下就能从该数据中获得价值，即数据产生者应隐藏“实施细节”。当然，这样的数据生产团队也可以同时处于数据消费者的位置。有一些面向消费者的数据领域非常复杂，足以证明整个领域专家团队的价值，但是这些专家自己使用的数据与数据源对齐。

单纯从组织角度来看，这种数据生产者和消费者的双边关系结构将特定领域的一切交给了一个团队，有利于减少摩擦，增加了所有权，从而能够高质量地扩展。如果我们接受这个前提，那为什么有着集中所有权的中央数据团队的模式如此普遍？以我的经验，有三个主要的关注点，它们在很大程度上驱动了企业中不幸的中心化数据所有权模式：

担心团队中没有足够的数据工程师和数据科学专家来组成多个团队。相反，中央团队被认为可以更有效地利用那些稀缺的专家，并可以更平等地支持多个团队。

担心失去对数据质量的控制，例如建立去中心化所有权的全局标准似乎很困难。

担心重复的基础设施投资，因为每个团队都需要创建和维护类似的基础设施，例如管道，服务和存储。

通常，中心化数据所有权和中心化数据基础设施之间缺乏概念上的分离， 阻碍了去中心化数据所有权的优势。 实际上，在上述所有三种情况下，创建专注于自助服务工具的共享数据基础设施平台可以帮助缓解此类担忧。但是，至关重要的是，与领域无关的自助服务工具要能够使该数据架构平台脱离中心化的领域数据所有权。 然而，通过使用领域无关的自助服务工具，能够与让数据基础设施平台脱离中心化的领域数据所有权。否则，数据基础设施平台将存在迅速成为具有中心化数据所有权的中央数据平台的风险，这正是我们首先要摆脱的境况。 最后，此方法还需要与建立针对数据的产品思维相结合，以确保去中心化的数据所有权是可持续的。

图2：与领域无关的数据平台

领域无关基础架构以及产品思维

为什么说数据基础设施平台确实是领域无关且专注于自助服务的呢？一个标志是，无需联系数据基础设施平台团队，团队即可通过提供领域数据来共享其专业知识。这意味着，那些数据基础设施平台的开发人员在完成本职工作时，并不需要详细的领域知识。

另一方面，该平台必须提供工具，让领域数据专家在无需深厚的数据工程专业知识的情况下管理其数据交付物的整个生命周期。这意味着必须使他们能够创建数据领域产品，对其进行描述和演进升级，观察其使用情况以及适时销毁数据。

创建提供这种使能水平的自助服务平台是一项巨大的技术和产品开发挑战。不过，它的核心是传统的内部软件产品开发可以从实现最常见的用例开始，再逐步地扩展平台的功能。

这样，可以避免了构建重复的基础设施，因为没有将基础设施平台团队拉入中心化的数据所有权中。这样一个与领域无关的平台团队可以更好地进行扩展，因为其成员不需要跟进特定领域的难题和所有业务领域的需求。相反，那些领域数据团队应该积极地培养和维护这些详尽的领域知识。因此，如果能够正确地关注重点，一个中型团队就能够可持续地开发和维护共享的数据基础设施平台。

共享的自助服务数据基础设施平台的另一个重要优点是，除了避免重复工作外，还关乎数据治理和标准化。如果对于领域数据团队而言，使用平台的工具提供数据要比通过构建自己的基础设施还方便，那么通过这些平台工具来实施某些标准将变得很容易。这样，标准化和一定程度上的治理就会由便利性驱动。

因此，在上面概述的关于去中心化数据所有权的三个问题中，仅剩下一个数据质量的相关问题。现在，中心化团队无法承担数据质量的责任。如今，数据质量的责任无论如何也不能由一个中心化的团队以可扩展和可持续的方式来承担。没有任何一个团队可以针对所有业务领域建立足够的领域专业知识来确保数据质量。这就是数据质量的意义：它不是对数据形态的普遍保证，而是与数据的具体内容，语义和演进的息息相关。

但是，单纯以去中心化的责任制还不能解决这一挑战。为此，产品思维开始发挥作用。需要激励领域数据团队以可靠的方式提供高质量的数据，例如通过使预算与数据消费者的数量和消费满意度相匹配。这样，领域数据团队将尝试提高其数据的价值，并尝试满足其数据消费者的需求。

最后总结一下，我们需要建立三种方法，以实现具有去中心化数据所有权的可扩展和可持续的数据格局：

使用领域驱动设计作为主要手段构建数据，并将领域（或子域）的完整端到端所有权分配给一个能够满足其职责所需的跨职能团队。

利用平台思维，投资创建共享且与领域无关的自助数据基础设施平台。该平台没有中心化的数据所有权，而是专注于支持和促进数据生产者和消费者者之间的直接协作。

利用产品思维，激励领域数据团队提高高质量的数据以满足数据消费团队的需求。

fqj