Get best of the week

从无缝的Data Lake迁移到分布式Data Mesh

哈Ha！我向您介绍Zhamak Dehghani（Zhamak Degani）撰写的文章“如何从单片数据湖之外移动到分布式数据网格”的译文（所有图像均来自同一篇文章）。

现在，所有大公司都在尝试建立大型的集中式数据仓库。甚至更大的集群Data Lake（通常在hdup上）。但是我不知道成功构建这样一个数据平台的一个例子。建立数据平台的人和用户到处都是痛苦和苦难。在下面的文章中，作者（Zhamak Degani）提供了一种全新的方法来构建数据平台。这是称为数据网格的第四代数据平台的体系结构。英文原著篇幅很大，坦率地说很难阅读。事实证明，翻译量很大，文字也不是很简单：句子很长，词汇比较枯燥。为了保持措辞的准确性，我没有重新制定作者的想法。但是，我强烈建议您仍然阅读此困难的文章并阅读本文。对于那些处理数据的人来说，这将是非常有用和有趣的。

叶夫根尼·切尔尼（Evgeny Cherny）

许多公司正在投资下一代Data Lake，以期简化公司范围内的数据访问，并提供业务见解和自动做出高质量决策的能力。但是当前构建数据平台的方法存在类似的问题，这些问题使我们无法实现目标。为了解决这些问题，我们需要放弃集中式Data Lake（或其前身，数据仓库）的范例。并转到基于现代分布式体系结构的范例：将业务领域视为第一优先级，运用平台思想来创建具有自助服务能力并将数据视为产品的基础架构。

图片

内容

  • 大型公司中数据平台的当前架构
    • 有问题的架构方法
    • domain driven
      • -
      • (data pipelines),
        • (discoverable)
        • (addressable)
        • ,
    • data- -
    • 集中式数据基础架构为平台
  • 范式向数据网格的转变

建立数据驱动型组织仍然是我合作的许多公司的主要战略目标之一。我的客户深知基于高质量数据做出决策的优势：确保最高质量的客户服务，高度个性化，由于优化而降低运营成本和时间，为员工提供分析和业务分析工具。他们在建立现代数据平台上投入了大量资金。但是，尽管在构建此类平台上进行了不断的努力和投入，但许多组织却认为效果不佳。

在转变为数据驱动型公司的过程中，组织面临许多困难：从遗留系统和数十年的开发系统迁移，现有文化的抵制以及不同业务优先级之间的激烈竞争。尽管如此，我想与您分享一种架构方法，该方法考虑了构建数据平台领域中许多计划失败的原因。我将展示我们如何适应和应用过去十年在数据领域中构建分布式体系结构的经验。我称这种新的架构方法为数据网格。

在继续阅读之前，我要求您在阅读本文时，尝试摒弃传统数据平台体系结构的当前范例所产生的偏见。对于从集中式Data Lake迁移到故意分布的Data Mesh体系结构的可能性持开放态度。接受数据是固有分布的并且无所不在。

大型公司中数据平台的当前架构


让我们谈谈Data Lake数据的集中式，整体式和与业务无关的含义。

与我合作的几乎每个客户都正在计划或已经在构建他们的第三代数据平台。认识前几代人的错误。

  • 第一代：专有的企业数据仓库和商业智能平台。这些都是大笔钱的决定，这些钱让公司承担了同样大量的技术债务。成千上万的不受支持的ETL工作，表格和报告中存在技术债务，只有一小部分专家可以理解，这导致人们低估了此功能对业务的积极影响。
  • 第二代：以Data Lake为银弹的大数据生态系统。由高度专业的数据工程师组成的中央团队支持的复杂的大数据生态系统和长期运行的批处理作业。充其量用于研发分析。

第三代数据平台或多或少与前几代相似，但偏向于

  1. 流式传输以通过Kappa之类的架构提供实时数据可用性，
  2. 结合批次和流处理转化使用的框架，如数据的Apache梁，
  3. 将云服务用于数据存储和处理以及云机器学习平台。

第三代数据平台消除了前几代的一些问题，例如实时数据分析，还降低了管理大数据基础架构的成本。但是，导致前几代失败的许多潜在功能仍然得以保留。

图片
图1：三代数据平台

有问题的架构方法


为了揭示所有代数据平台本身的基本限制，让我们看一下它们的体系结构和功能。在本文中，我将以流式互联网媒体（例如Spotify，SoundCloud，Apple iTunes）的业务为例来解释一些概念。

集中式和整体式


从10,000米的高度来看，数据平台的架构如下图2所示。
图片
图2：在单一数据平台上10,000米高处的视图

该架构的中央部分负责：

  • (to ingest) , , . , , : ; ; ; , ; ( ..).
  • , , , . , , — .
  • (to serve) . machine learning BI . , . , Kafka.

默认情况下，公认的协议是以下事实：单片数据平台存储并拥有属于不同业务域的数据。例如，“播放事件”，“销售KPI”，“艺术家”，“专辑”，“标签”，“音频”，“播客”，“音乐事件”等。 -来自大量不同域的数据。

尽管在过去的十年中，我们已经成功地将域驱动设计的概念（及其关键的绑定上下文模式）应用到了信息系统的设计中，但在数据平台的设计中，我们很大程度上忽略了这些概念。我们已经从业务域级别的数据所有权转移到了与业务域无关的数据所有权。我们感到自豪创造了最大的整体-大数据平台。

图片
图3：一个集中的数据平台，来自不同业务域的数据之间没有明确的界限。而且，由于没有业务域对相关数据的所有权，

这种集中式模型可以适用于具有简单业务域和有限数据使用选项的小型组织。但是，它不适用于具有大型和复杂业务域，大量数据源以及处理来自消费者的数据的各种需求的大型公司。

集中式数据平台的体系结构和结构中存在两个薄弱环节，这些环节通常会导致构建过程失败：

  • 大量来源和大量数据. , , . , . . , , , . , data scientists . , ( ) , . , – - .
  • . . , . .

在这里，我需要澄清的是，我并不是在说服使用遗留在传统系统深处的零散，分散的数据。难以检测，理解和使用的此类数据。我也不支持同一组织内的许多不同的数据仓库，这是多年技术债务积累的结果。但是我认为，解决这种无法访问的零散数据的答案不是要创建一个具有集中化团队的集中化数据平台，该团队可以存储和拥有来自所有业务领域的数据。

如上所示，这种方法无法在大型组织中扩展。

高度连接的输送机分解


图片
图4：数据平台

的体系结构分解数据平台的传统体系结构的第二个问题是我们如何分解体系结构。如果它跌落到数据平台的架构上方3,000米，我们将发现架构的分解涉及到加载，清理，聚合，服务数据等功能。如上一节所述，连接新资源和新消费者的需求需要平台的发展。架构师必须找到一种将系统分解为架构量的方法来扩展系统。如《建筑进化建筑》一书中所述的建筑量子”，是具有高功能连接性的可独立部署的组件，其中包括系统正确运行所需的所有结构性要素。将系统划分为架构量的动机主要在于创建独立的团队，每个团队都创建并维护自己的架构量（功能子系统）。这使您可以并行化工作并提高速度和操作可伸缩性。

受前几代数据平台的影响，架构师将平台分为一系列数据处理步骤。这是一个实现数据处理的管道：加载，准备，聚合，提供访问/卸载等。

尽管此分区提供了一定程度的扩展，但它也有一个内部限制，它会减慢平台上新功能的开发：流程步骤之间存在很高的连通性，这不允许各个团队进行必要的独立性。

让我们回到我们的流媒体示例。互联网上的流媒体平台围绕它们提供的媒体类型具有强大的域设计。他们通常以“歌曲”和“专辑”开始服务，然后将其应用于“音乐事件”，“播客”，“广播节目”，“电影”等。启用一项新功能，例如，“播客”的可见性播放率”，需要更改管道的所有组件。团队需要开发用于加载，清理和准备数据（包括聚合）的新服务，以增加“播客播放率”的可见性。这要求各个职能团队的发行版之间进行同步。许多数据平台使用基于配置的下载工具，可以轻松处理此类任务。例如简单地添加新资源或扩展现有资源。但这并不能消除在数据处理管道的所有阶段都需要端到端版本管理。为了使用户能够访问任何新数据，需要更改的最小体系结构单元是整个管道。并且这极大地限制了我们响应新数据源和用户的出现而提高数据平台开发速度和规模的能力。并且这极大地限制了我们响应新数据源和用户的出现而提高数据平台开发速度和规模的能力。并且这极大地限制了我们响应新数据源和用户的出现而提高数据平台开发速度和规模的能力。

分散且高度专业化的团队


现代数据平台的第三个问题是我们如何组织创建和维护平台的团队。当我们深入研究传统数据平台的体系结构时，我们将看到一群狭specialized的专业数据工程师，他们与在其中创建数据或用于决策的组织单位分开。数据平台工程师仅根据其技术能力和大数据技术经验被选入单独的团队。在这样的团队中，缺少相应学科领域（业务领域）的业务知识。

图片
图5：分散的狭窄专业数据平台团队

我个人并不羡慕数据平台工程师的生活。他们应从无动力提供高质量和正确数据的团队那里接收数据。他们缺乏对您必须下载的数据的业务含义的理解。他们必须准备数据以满足分析和操作需求，而不能清楚地了解此数据的最终用途，也不能与使用这些数据的领域的专家取得联系。

应该注意的是，我们以前遇到过类似的团队分离问题。他们能够找到成功解决此问题的方法。

图片

在带有多媒体流的示例中，我们具有“媒体播放器”命令，该命令拥有有关用户如何与播放器交互的数据：用户听的歌曲，购买的商品，他们听的歌曲的音频质量等。另一方面，有相关数据的消费者团队：一组歌曲推荐；销售监控团队；艺术家付款团队等在他们之间，是一个悲伤的数据平台开发人员团队，他们付出了巨大的努力才从一个团队那里接收数据，并向所有消费者提供对它们的访问（在初步处理之后）。

实际上，我们没有一支涉及数据源的团队和一群沮丧的数据消费者团队，他们必须争取在数据平台开发团队积压的工作中占据一席之地。

我们创建的体系结构和组织结构无法提供必要的可伸缩性，并且无法实现构建数据驱动型组织的目标。

下一代数据平台架构


对于我们上面讨论的问题，解决方案是什么？我认为，需要进行范式转换。方法的交汇处发生了范式转换，这些方法在构建现代可伸缩分布式体系结构中发挥了重要作用，整个技术行业已在加速实施。取得成功结果的方法。

我相信，下一个企业数据平台体系结构将集成分布式域驱动的体系结构，设计自助服务平台和数据的产品思维。

图片
图6：转移下一代数据平台范例转移。

我知道这听起来像是一句话中的许多流行语，但是这些组件中的每一个对改变我们的信息系统的技术基础都产生了不可思议的积极影响。让我们看看如何将这些学科中的每一个应用于数据世界，以摆脱当前的模式，这种模式已从多年构建前几代数据仓库中转移过来。

数据和分布式域驱动架构


基于业务领域定位的数据分解和所有权


埃里克·埃文斯（Eric Evans）的著作《域驱动设计》（Domain-Driven Design）对当代建筑思想以及组织建模产生了深远的影响。新的微服务体系结构将信息系统分解为在特定业务域的边界内构建的分布式服务。这从根本上改变了团队的形成方式：从现在开始，团队可以独立自主地拥有其微服务。

有趣的是，我们忽略了数据领域中业务领域的概念。域驱动设计在数据平台体系结构中的即将到来的应用：这是业务域事件的出现信息系统中并将其加载到整体数据平台中。但是，将数据上传到集中存储后，将失去由不同团队来自不同业务域的数据所有权的概念。

要分散单一数据平台的权限，您需要更改对数据，其位置和所有权的看法。域不应将数据传输到Data Lake或平台，而应以用户友好的方式存储和维护其数据集。

在我们的示例中，为什么不将数据从媒体播放器加载到集中式存储库中，以由存储库支持团队进行进一步处理，为什么不在域内存储和处理这些数据集，而不给其他团队访问权限？您可以根据需要在域内从技术上实现物理存储这些数据集的位置。当然，您可以使用集中式体系结构，但是媒体播放器本身的数据将保留在生成此数据的相应域的团队的所有权和支持下。类似地，在我们的示例中，歌曲推荐开发域可以基于来自媒体播放器的数据以最适合使用的格式（例如，以图形结构的形式）创建数据集。如果还有其他队伍如果他们认为此格式既方便又有用，他们也可以访问它。

当然，这意味着当我们将数据格式更改为适合特定用户的格式时，我们可以在不同的域中复制数据。

所有这些都要求我们转变思维，从下载数据（通过ETL或流式传输）到将此过程扩展到所有域。面向领域的数据平台中的体系结构范围是业务领域，而不是加载和转换数据的阶段。

图片
图7：基于业务域和数据拥有团队的架构分解。

源域数据集


一些业务领域与数据源（信息系统）保持一致。在理想情况下，信息系统及其附带的团队不仅负责添加和支持业务功能，而且还提供描述相应业务领域的事实和现实的数据集。但是，通常在大型组织的规模上，业务域和信息系统之间没有单个对应关系。通常，对于每个域，都有多个信息系统可以自动执行给定域的不同业务流程，并因此存储与之相关的数据。对于这样的域，需要集成和聚合不同的数据，以便获得在整个业务域中一致且一致的数据集。

存储描述业务领域的事实的最佳格式是Domain Events。它们可以存储为带有时间戳的分布式事件日志。可以授予此日志访问授权使用者的权限。

除了这些日志之外，数据源还必须提供对其域中关键数据集的定期快照的访问。汇总此类图像的时间间隔可以更好地反映您域的更改间隔（通常是一天/周/月/季度等）。

请注意，为消费者准备的业务域数据集应与内部数据源（信息系统用于其工作）分开。它们应存储在物理上不同的地方，适合使用大数据。接下来，将描述如何创建这样的数据仓库和服务基础结构。

为消费者准备的特定于域的数据集是整个体系结构的最基本元素。它们不进行转换，也不是针对特定用户量身定制的，而是原始数据和未经处理的数据。

消费者域数据集


其他域与数据使用者密切相关。创建此类域的数据集的方式应使其在使用时适合相关的用户方案集。这些数据集与源域数据集不同。这不是原始数据，而是经过多个转换阶段的数据。这些数据集的结构及其表示方式适合于其使用的特定情况。那些。这类似于集中式存储库中的专用数据集市。对于此类消费者域（消费者域数据集）数据集，应提供从原始数据快速恢复的可能性。

在其域内实现的分布式数据管道


我们新架构中的数据所有权是从中央平台委派给业务领域内的团队的，但是对数据清理，准备和聚合（使用数据管道）的需求并没有消失。因此，实现自己的数据管道成为业务领域团队的内部任务。结果，我们得到了自己的域数据管道，分布在所有域中。

例如，源域应包括数据清除，重复删除，数据丰富等，以便其他域可以使用此数据而无需进行初步处理。每个此类数据集必须在数据质量方面符合其服务水平目标。

同样，构建用于处理数据的集中式管道的专门展示的阶段进入构建消费者域数据集的消费者域自己的数据管道。

图片
图8：在其域内实现的分布式数据处理管道

看来，这样的模型将导致每个域在创建自己的数据处理管道实现方面的大量重复工作。我们将在“集中式数据基础架构作为平台”部分中讨论此问题。

数据与产品思维


数据所有权的转移以及对数据处理管道的开发和维护的责任转移到业务域的一侧可能会引起人们对此类分布式数据集的持续可用性和易用性的严重关注。因此，在这里我们可以方便地进行有关数据的产品思考。

域数据作为产品


在过去的十年中，产品思想已经深刻渗透到组织信息系统的发展中，并已严重改变了这种发展方式。用于信息系统开发的领域团队以API的形式提供了新功能，开发人员在组织中使用这些API作为构建块来创建更高阶的功能和更高的价值。团队努力通过易于访问的清晰详细的文档为API用户创造最佳体验；测试环境仔细跟踪质量指标。

为了使分布式数据平台成功，业务领域的数据团队必须在提供数据集方面应用产品思维：感知他们准备作为产品准备的数据以及消费者（分析师，数据科学家，数据工程师，机器学习专家）等）作为您的客户。

图片
图9：域数据集作为产品的特征

考虑我们的示例-通过Internet流媒体内容。最重要的商业领域是复制的故事：听谁，何时何地，何时听哪些歌曲。该域在组织内具有各种关键数据使用者。一种要求接近实时模式的数据来研究用户体验并及时发现任何问题和播放错误。其他人则对按天或月汇总的历史快照感兴趣。因此，我们的域以两种格式提供数据：流形式的播放事件（流，kafka中的主题或类似内容）和批处理格式的聚集播放事件（文件，Hive中的表等）。

为了向消费者提供最佳的用户体验，业务域数据产品必须具有以下关键功能。

方便且易于检测（可发现）


必须确保可以轻松找到任何数据产品的条件。此要求最常见的实现是存在注册表-具有必要的元信息（例如所有者，来源，数据集样本，更新频率，数据集结构等）的所有可用数据产品的目录。这种集中式服务使数据使用者可以轻松找到他们感兴趣的数据集。任何业务域中的每个数据产品都必须在集中数据目录中注册。

请注意，从拥有所有数据的单个集中式平台向注册在单个数据目录中的不同业务域的分布式数据产品转变。

唯一地址（可寻址）


每个数据产品必须具有唯一的地址（根据全球协议），这将使它的使用者可以通过编程方式访问它。组织可以根据数据物理存储的可用方法和数据本身的格式，对数据产品的名称及其位置采用各种协议。对于分布式分散式体系结构，此类常规约定是必需的。数据集地址标准将消除搜索和访问数据产品时的摩擦。

资料品质


没有人会使用不可靠的产品。在当前的数据平台中，广泛地下载和发布包含错误并且不能反映整个业务真相的数据，即无法信任的数据。在此部分中，大量的ETL作业被集中，这些作业在加载后清除数据。

新架构要求数据产品的所有者就数据的准确性，可靠性和相关性采用SLO（服务水平目标）。为了确保可接受的质量，在创建数据产品的阶段必须使用诸如数据清理和自动数据完整性测试之类的方法。每个数据产品的元数据中有关数据沿袭的信息使消费者对产品本身及其对特定需求的适用性更有信心。

数据质量指标的目标值（或可接受范围）取决于特定业务域的数据产品。例如，“重播事件”域可以提供两种不同的产品：一种处于准实时模式，准确性较低（包括丢失或重复的事件）；第二个具有更长的延迟和更高的数据质量。每个数据产品都以一组SLO（服务水平目标）的形式定义并维护其数据完整性和可靠性的目标水平。

语义和数据语法的清晰描述


优质的产品应该易于使用。要创建尽可能简单的数据产品以供分析人员，工程师和数据科学家使用，需要存在描述良好的语义和数据语法。理想情况下，提供样本数据集作为示例。

数据可集成性和组织范围的标准


分布式域驱动的数据体系结构中的主要问题之一是需要集成来自不同域的数据。域之间轻松高效的数据集成的关键是定义并遵循规则和标准。此类标准应在组织级别定义。在确定可接受的数据类型和应用规则，数据产品名称和地址的约定，元数据格式等方面，需要进行标准化。

对于那些可以以不同形式存储并且在不同域中具有不同属性集的实体，有必要实施主数据管理实践。为它们分配全局标识符并在所有域中对齐集合值，最重要的是对齐属性值。

确保数据的互操作性以进行有效集成，以及在组织级别定义用于存储和展示数据产品的标准，是构建此类分布式系统的基本原则之一。

数据安全与访问控制


无论体系结构是否集中化，都必须确保对数据的安全访问。在分散的面向业务域的数据产品世界中，访问控制是可能的（并且应该应用），每个数据集的详细程度更高。数据访问控制策略可以集中定义，但可以针对每个数据产品单独实施。作为对数据集实施访问控制的便捷方法，可以使用企业身份管理系统和基于角色的访问控制。

接下来，将描述单个基础结构，它使您可以轻松，自动地为每个数据产品实现上述功能。

跨职能业务域数据命令


在以数据产品形式提供数据的团队中应代表以下角色：数据产品所有者和数据工程师。

数据产品的所有者负责其概念和路线图以及其产品的生命周期。衡量其客户的满意度，并不断衡量和提高其业务领域的数据质量。它填补和平衡了其数据产品的积压与数据使用者的需求。

此外，数据产品所有者必须为其产品定义关键指标和性能指标（KPI）。例如，用户熟悉自己并开始使用数据产品所需的时间可能是这些指标之一。

为了在业务域内创建和维护自己的数据管道，团队必须包括数据工程师。一个好的副作用是相关技能在业务领域中的传播。根据我的观察，目前一些数据工程师虽然能够使用其工具和技术，但在创建数据产品时缺乏对标准软件开发实践的了解。首先，DevOps这样的实践包括连续交付和自动测试。另一方面，开发信息系统的软件开发人员通常在将数据作为产品使用的技术和工具领域没有足够的经验和知识。将他们组合成业务领域内的多功能团队将导致出现更广泛的专家。在开发新类型的工程师时，我们在DevOps的开发过程中观察到了类似的情况，例如SRE。

图片
图10：跨功能域数据命令

集中式数据基础架构为平台


数据平台的分布式域驱动架构的敏感方面之一是需要在每个域中复制操作数据管道中使用的基础结构和技术堆栈所需的工作和技能。幸运的是，创建通用基础设施作为平台是一项在IT领域（但不是在处理数据的领域）可以很好解决的任务。

数据基础架构团队必须拥有并提供业务领域收集，处理和存储其数据产品所需的工具作为服务。

图片
图11：数据基础架构作为平台

作为平台的数据基础架构应没有任何特定于领域的概念或业务逻辑。而且，该平台应向用户隐藏其实现的复杂性，并提供最大数量的功能以用于自助服务模式。这是集中式数据基础结构（例如平台）应提供的一些功能的列表：

  • 各种格式的可扩展数据存储
  • 数据加密（此处为散列，去个性化等）
  • 版本化数据产品
  • 存储数据产品数据架构
  • 资料存取控制
  • 记录中
  • 编排线程/数据处理流程
  • 内存中缓存
  • 存储元数据和数据沿袭
  • 监视，警报，记录
  • 计算数据产品的质量指标
  • 数据目录维护
  • 标准化和政策，控制合规性的能力
  • 寻址数据产品
  • 用于数据产品的CI / CD管道

创建集中式数据基础结构时，必须确保在这样的基础结构上创建数据产品花费的时间尽可能少。因此，关键功能的最大自动化非常重要，例如：使用简单的配置下载数据的能力，在数据目录中自动注册数据产品等。使用云基础架构可以降低运营成本，并提高按需提供对数据基础架构的访问速度。

范式向数据网格的转变


这是很长的阅读！让我们简要总结一下上面编写的所有内容。我们研究了现代数据平台的一些关键特征：集中的，整体的，复杂的数据管道（成千上万的工作相互紧密联系），分散的高度专业化的团队。在我们讨论了一种新的数据网格方法之后，该方法包括将分布式数据产品侧重于由跨职能团队（数据产品所有者和数据工程师）管理的业务领域，并使用通用数据基础结构作为托管平台。

数据网格是一种分布式体系结构，具有集中管理和确保数据可集成性的已开发标准，并且具有允许使用自助服务的集中式基础结构。我希望读者很明显，这种架构与在不同部门独立开发的一组不可访问的数据的松散耦合存储相差很远。

图片
图12：10,000米的数据网格架构

您可能会问：Data Lake或Data Warehouse如何适合此体系结构？在此分布式体系结构中，它们只是简单的单独节点（域）。在这种架构中，我们很有可能不再需要Data Lake。毕竟，我们将有机会研究以数据产品形式设计的不同业务领域的原始数据。

因此，Data Lake不再是整个体系结构的核心元素。但是，我们将继续使用用于构建Data Lake的技术和工具，以创建通用的数据基础结构或内部实施我们的数据产品。

这实际上使我们回到了一切的起点。詹姆斯·迪克森在2010年，他打算将Data Lake用于一个业务领域，而几个数据领域将组成Water Garden。

主要的范式转换是将业务域数据产品视为第一优先级任务，并将工具和技术视为第二优先级任务（作为实现细节）。这是为了将思维模型从集中的Data Lake转移到数据产品的生态系统中，这些数据产品可以无缝高效地相互集成。

关于报告和可视化的几句话（使用BI工具等）。相同的原则适用于它们：在此体系结构中，它们是单独的节点。那些。它们是业务领域内的独立数据产品，主要侧重于消费者而不是数据源。

我承认，尽管我看到客户成功应用了Data Mesh原理，但是在大型组织中扩展这些原理还有很长的路要走。但是技术显然不是这里的限制。我们今天使用的所有工具都可以由不同的团队很好地用于数据产品的分发和所有权。特别是，数据包和流数据处理作业向标准化的过渡以及Apache Beam或Google Cloud DataFlow之类的工具的使用，使处理具有唯一地址的各种数据集变得容易。

数据目录平台，例如Google Cloud Data Catalog，使发现​​，访问控制和分布式业务域数据集的集中管理变得容易。大量的云平台允许业务域选择适合其数据产品的目标存储。

范式转换的需求显而易见。有所有必要的技术和工具。业务主管和数据处理专业人员必须承认，使用一个大Data Lake平台的当前大数据范例和方法只能使用新的云技术和工具来重复过去的失败。

让我们从集中的整体数据平台过渡到数据产品生态系统。

图片

链接到该主题的主要资源和其他材料


More articles:


All Articles