实现数据平台现代化有两个阶段。

在建立数据科学产品时，一个重要的方面是让您的数据随时可用。我们需要一个收集数据并在整个公司提供服务的平台。但是如何开发这样的数据平台呢？阅读相关数据仓库、数据湖、Lakehouse和数据网格的文章时，很容易迷失方向。它们有什么区别？第一步应该是什么？

一 不同的数据平台解决方案

资料平台是一种将资料汇集在一起，为整个企业提供服务环境。第一家公司的中央数据平台是数据仓库。但是，随着数据类型和来源的日益多样化，它们变得不够灵活。引入数据湖可以轻松存储任何格式、任何来源的原始数据。它是通过将方法创建和数据解释推迟到实际使用数据来完成的。这类湖泊常常变成所谓的数据沼泽，那里没有人能真正高效地使用数据。所有的数据都被添加了，但是没有准备使用的数据。接班人是Lakehouse，其中数据湖与数据库工具相结合，可以很容易地建立可用的数据视图。另外一种选择是数据网格，它不集中数据，而是利用多个零散的数据环境来更好地跨团队扩展。以后我会更全面地介绍数据网格。

但是首先，让我们看看我们实际上应该解决什么问题。这些不同数据平台的驱动力是什么？我将继续从我们追求的理想方式介绍实践中存在的平台，最后总结出两个可以采用的步骤。这两个步骤正朝着数据平台的方向发展，使机器学习解决方案成为可能，赋予数据科学家权力，共享内部工作模式。

二 理想的数据访问模式

如果所有单位的所有数据都可以轻松浏览，那岂不是很棒？通过浏览中心位置，所有数据科学家都可以随时获取所需的数据。他们可以致力于先进的机器学习，而数据工程师可以确保数据随时可用。

让我们了解一下我们的专家数据科学家王小强。他正在开发一种新的数据科学产品:收入预测。中央数据平台可以找到相关客户、产品和销售的所有数据。王小强在平台上建立了一个完整的数据集，并将其加载到JupyterLab环境中。在与业务部门协调了模型目标后，他很快开发出了模型的第一个版本。

因此，该平台为科学家提供了包括数据、计算和工作环境在内的开发模型所需的一切。平台开发者(云和数据工程师)确保其可扩展性、即时性和良好性能。他们还提供数据继承、数据治理和元数据等附加服务。科学家完全有能力摆脱工程困难。这在整体结构上表现如下:

理想的数据世界：单一的数据平台可以解决所有的数据问题。

左边是每个部门运行的应用程序和相应的数据。这包括一个从事特定领域的技术产品公司的团队。数据可以存储在任何存储中:MSExcel文档、数据库、csv文档、Kafka主题、云存储平台等。

数据平台团队在中间提取数据，并将其加载到数据湖的着陆区域。第一步是规范日期、数字格式和列名。它可以包括投射数据快照进行历史视图。生成的数据集存储在所谓的“存储”层中。接着将数据组合在一个整合层中。整合层是一种数据存储，包括连贯的数据，唯一的标识符和明确的关系。所以，我称之为DWH(数据库)。但是，它可以是任何可用的存储，包括大型云数据库（BigQuery）、Hive表、存储(S3)或DeltaLakeparquet文档的blob。该整合层的目的是为所有易于使用的数据提供总体视图。

数据科学团队利用这个平台的工作环境和数据来解决他们的用例。

这样不起作用的时候

这一理想听起来很棒。不幸的是，王晓强的亲身经历不同：

在数据平台上，王小强需要一些额外的数据集。为抓住机遇，财务部为初步分析提供了一些CSV导出。王小强发现预测需要根据产品组进行报告，而数据则根据单个产品进行报告。经过几次会议，他了解到哪些内部产品名称属于哪些组。商品收入分为几个部分，一部分来自基本商品，另一部分来自附加产品。折扣是另外一回事；由于它是从总账单中扣除的，所以归因变得有些棘手。另外一个恐怖是，三个月前，公共商品被更新，重新命名并合并了一些旧商品。在某些困难的情况下，他只删除了最少的数据，并试图将旧数据与大多数类似的新产品相匹配。

那管理数据平台的数据工程师呢？它们刚刚开始：

最后，数据工程师得到了数据工程的要求，开始对各种数据进行提取、载入和转换。第一步很简单，但是现在他们需要建立一个可用的数据视图。为了了解哪些转变非常重要，他们需要与各种可能的未来客户交谈。他们组织了包括王小强在内的一些改进会议。接着，他们需要回到数据生产部门，找出数据的实际含义，以及它是如何映射到他们的领域的。这个部门忙于一些新的内部商品。所以，他们把数据工程师交给数据科学团队，这个团队显然已经做了一些准备。

简单地说，这件事的进展并不顺利。

有几个关键问题：

科学家需要建立一个特定于用例的转换。

为了促进他们未处理的用例，平台团队应该准备他们所没有的域数据。

数据平台团队成为数据科学家团队的瓶颈。

由此产生的解决方案

需要大量的领域知识来解释和转换与特定用例相关的高度详细的数据。每个用例都需要特定的数据准备。因此，数据工程师只能完成数据科学家要求的一些工作。当数据科学家深入研究业务案例时，他们会获得大量的领域知识。这样他们就可以准备数据了。

这样就导致了下列解决方案：

如今，数据科学团队准备将来自中央数据平台的数据转换为模型训练。虽然数据平台提供了理想情况下完全可用的数据集，但实际上太简单了，不能满足所有客户的需求。

这一新情况有一些好处：

数据学家变得更加自给自足。

在组织中，数据工程师不必为每一个人创造视图。它们能够致力于数据的标准化接口。

在保持数据最新的同时，数据工程师也能提供很好的浏览方法。

但是，许多事情仍然不太正确：

数据科学家的数据集及其生产管道与数据平台的标准不同。他们没有得到很好的监控，故障恢复能力差，任务调度不规范。

由于转型更加分散，多个数据科学团队正在重新发明轮子。

三 新方法：数据网格

不久前，数据网格的概念就出现了。这些数据来自组织中的许多地方。数据网格接受数据的渗透性，而不是建立所有组合数据的单一表示。每一个团队的数据也被视为该团队的商品，以便在整个公司范围内使用数据。公司团队还负责建立其数据的可用视图。在这种情况下，机器学习(ML)产品团队(数据科学家)也将转换后的数据作为产品交付给其它数据科学家。它们可以从各种产品团队中获得自己的数据。所以，每一个产品团队或团队不仅要开发自己的产品，还要为其它团队提供有用的视图。在我解释优点之前，让我先介绍一下新情况：

左边，部门或商品团队提供通用数据作为服务。虽然一组标准化的表格(DWH)这是一个概率，但是它也可能包括事件流(Kafka)或者blob存储。这就要求产品团队具备更多的数据工程能力。数据工程师不再由一个拥有所有数据工程师的中心团队组成，而是分布在所有产品团队中，包括分析和机器学习团队。

中央数据平台已经从数据产品团队(需要领域知识)转变为数据平台，即服务团队(需要技能知识)。他们开发内部平台，让所有团队都能创建自己的案例，如数据存储、特征存储、数据处理、数据传承、调度、流程监控、模型工件、模型服务实例等。所以，以前数据平台团队的所有技术技能都是用来建立工具的。通过这种方式，每一个团队都可以成为自己的小型数据平台团队。这样就保证了整个公司统一的工作方式和高标准。

右边的数据科学团队不仅是数据的消费者，也是数据的生产者。与其他数据科学团队分享他们的特色工程和数据整理结果。

它有许多优点：

转换是在领域知识所在的地方建立的。

清除了数据平台团队的瓶颈。

自给自足的产品团队。

挑战在于：

为服务团队建立一个中心平台。

避免新的中央数据平台，也就是服务团队逐渐成为瓶颈。

使所有团队都能以共享的方式接受这一新方法。

在这个设置中，中央平台，即服务团队(或几个团队)起着关键作用。他们以简单的自助方式设置和提供基础设施和软件服务。当他们建立一个平台，也就是服务时，团队不需要很多具体领域的知识。它只注重技术，使其可以复制，并将解决方案转发给所有团队。这个方便的设置可扩展性很好！但是有一个很大的风险:选择瀑布法。

数据网格解决了与数据器相关的领域知识问题。这是通过将数据的责任转移到生成和处理数据团队来完成的。现在，我们需要一个中央团队来帮助所有团队合作他们的数据，而不是一个中央团队拥有所有的数据。

一个陷阱是通过瀑布启动和运行核心团队。在加入团队之前，不要从建立所有必要的基础设施和服务开始。只要没有一个团队使用这些服务，就没有附加值。因此，当团队可以使用服务时，有必要迭代发展和优化服务。

另一种风险是让平台即服务团队决定工作模式。这样，团队就会成为整个公司的瓶颈。有些团队在敏捷和迭代方法中会需要新的工具或服务，但是这些工具或服务还没有准备好在企业范围内选择。也就是说，平台服务团队不应该限制这些早期用户，而应该允许和授权发现和尝试新的工具和服务。让他们授权产品团队并团结起来。这样，两个团队就可以在整个公司范围内进一步分享工具和服务所需的经验。

四 两步走向现代数据平台

有没有可能转换成数据网格？有没有可能在中央数据平台和数据网格之间建立一些东西？如何务实迈出第一步？我们在哪里可以尽快获得尽可能多的好处？在为您组织的基础设施能力量身定制的解决方案中。本文的其他部分将解释如何将其转换为支持机器学习解决方案、赋能数据科学家、共享内部工作模式的数据平台。

第一阶段：轻量级中央数据平台

建立这个数据平台的第一步是什么？不幸的是，没有相同的模板。方法要看具体情况，包括现有的技术堆栈、可用的技能和能力、流程、一般的DevOps和MLOps成熟度。我可以给你一个一般的建议，希望这些建议能给你一个有用的角度。

一种方法是将之前版本的优点结合起来，作为未来更先进版本(例如数据网格)的基础：

在提取和载入方面，数据工程师致力于尽量减少转换。

具体领域(数据科学)团队致力于高级转换。

为了提高团队的能力，应该提供工具。

这种方法是创建一个轻量级的中央数据平台，包括以下步骤：

例如，一个具有特定用例的数据科学团队。

组建一支由平台工程师和数据工程师组成的团队。

在数据科学团队中，平台工程师提供至少存储和处理的分析环境。

数据工程师从源表中载入原始数据，添加基本的标准化转换，并提供给用户团队。他们与平台工程师一起建立所需的服务。

数据科学家与数据平台工程师合作，安排、运行和操作数据转换、模型训练循环和模型服务。他们与数据工程师合作，使数据转换系统化。

在这种情况下，数据科学家仍然需要大量的数据处理。然而，我们不会假设这种情况不会发生，而是接受它，为它提供最好的工具来完成它。

这种方法的一个关键方面是首先关注一个用例。数据工程师、平台工程师和数据科学家首先解决了这个用例。同时，他们获得了开发必要工具的经验，以便将来扩展。

结果如下：

在左边，我们保留了原来的情况，即部门或产品团队只开发或经营其生产案例。这样就限制了企业范围内的变化。

在中间部分，数据工程师致力于轻量级数据建模和优质管道。它们主要负责载入所有数据，并提供标准化的浏览方法。它们非常注重包括基础设施和服务在内的技术。

在右边，数据科学团队致力于根据所有必要的领域知识建立数据产品。他们通过向客户(使用他们的数据产品的客户)和上游数据库团队学习来获得上述领域的知识。他们经营所有必要的分析和转换，并得到平台，即服务团队的支持。他们有很强的领域和用例重点。

最底层，平台是服务团队，致力于建立可重复使用的部件。因此，他们致力于技术。他们为数据科学团队提供服务，他们致力于该领域。也就是说，平台服务团队应该由用户的需求驱动。

第二阶段：跨团队拓展与共享

下一步是扩大规模。扩大规模可以从多个方面进行，包括获取更多的源数据集，吸收更多的数据科学团队，或者添加更多的赋能平台作为服务(如功能存储、模型服务等)。).同样，这些选择也取决于具体情况。

现在，让我们采取一个典型的步骤:加入更多的数据科学团队。加入第一个团队，确保开发服务有用。第一个团队是启动客户。也就是说，平台服务团队保证了与内部客户的良好市场契合度。下一个团队应该启动和运行得更快更顺利。

随着多个团队使用这些服务，下一个障碍将允许数据科学团队共享数据。这可能需要改变服务和工作方式。但是，如果达到这个里程碑，平台计划将真正改进所有后续团队的工作模式。这导致以下情况:

与上图相比，我们现在有一个数据科学团队，正在开发一种欺诈检测产品。他们应该能够重视平台工程师开发的服务，重视第一个预测团队的数据。

后续步骤：专业化和规模化

不要忘记这些信息平台计划的目标。目标是使用更多的数据产品。因此，除了加入多个数据科学团队之外，努力实现生产模式也非常重要。让第一批(少数)团队真正将自己的模型预测嵌入到业务中。

有了这些平台，流程和工作方法，下一步该怎么做就不清楚了。能提高服务质量和团队合作的机会很多。

根据项目要求，可以提高提供的服务质量。也许需要即时特色存储、新的模型服务平台、自动ML工具或者更好的模型监控？

在团队协调方面，可能需要做出一些改变。在许多情况下，我们需要“客户360视图”，这可能会导致建立一个团队来管理整合视图，并具有一些自动生成的功能。各种类似的常见问题可以作为创建新的通用解决方案。

五 总结

以上展示了一种向更多数据驱动的组织迈进的方法，即采用敏捷的方法进行设计。本文不推荐任何解决方案作为“最佳方法”，而是希望提供一个额外的视角来参考当前的状态。

该方法的主要组成部分包括：

以客户为中心的敏捷(内部)方法。

平台思维。

清除瓶颈，提供一个能够提升数据科学团队能力的灵活平台。

自给自足的团队，拥有自由和自主。它们可以自由使用适合自己的服务，并且可以自己准备数据。

本文来自微信微信官方账号“数据驱动智能”（ID：Data作者：晓晓，36氪经授权发布，_0101)。

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com