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

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

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

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

二 理想的数据访问模式

如果所有部门的所有数据都可以轻松访问，那岂不是很棒。从一个中心位置访问，这样所有数据科学家都可以随时获取所需的数据。他们可以专注于高级机器学习，而数据工程师则确保数据随时可用。

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

因此，该平台为科学家提供了开发模型所需的一切，包括数据、计算和工作环境。平台开发人员（云和数据工程师）确保其可扩展、实时且性能良好。他们还提供数据沿袭、数据治理和元数据等附加服务。科学家完全有能力并摆脱工程困难。这在整体架构上表现如下：

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

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

在中间，数据平台团队提取数据，并将其加载到数据湖的着陆区。第一步是标准化日期和数字格式以及列名等方面。这可以包括为历史视图映射数据快照。生成的数据集集合存储在所谓的“暂存”层中。然后将数据组合并放置在整合层中。整合层是一个包含连贯数据集、唯一标识符和明确关系的数据存储。因此，我将其称为DWH（数据仓库）。但是，它可以是任何可用的存储，包括大型云数据库（BigQuery）、Hive表、blob存储（S3）或DeltaLakeparquet文件。这个整合层的目标是提供易于使用的所有数据的整体视图。

在右侧，数据科学团队使用该平台的工作环境和数据集来解决他们的用例。

当这不起作用时

这个理想听起来很棒。不幸的是，王晓强的真实经历略有不同：

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

那么管理数据平台的数据工程师怎么样？他们才刚刚开始：

最后，数据工程师拿到了数据工程请求，开始提取、加载和转换各种数据集。第一步很简单，但现在他们需要创建可用的数据视图。他们需要与各种可能的未来用户交谈，以了解哪些转换很重要。他们组织了一些改进会议，其中包括王小强。然后他们需要回到数据生产部门，弄清楚数据的实际含义，以及它如何映射到他们的领域。该部门忙于一些新的内部产品。因此，他们将数据工程师转交给数据科学团队，该团队显然已经做了一些准备工作。

简而言之，这件事进展不太顺利。

有几个关键问题：

数据科学家需要能够创建特定于用例的转换。

平台团队需要准备他们不拥有的域的数据，以促进他们没有处理的用例。

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

由此产生的解决方法

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

这导致以下解决方法：

数据科学团队现在将来自中央数据平台的数据转换为模型训练的准备。尽管数据平台理想情况下提供了完全可用的数据集，但实际上它过于简单，不足以满足所有客户的需求。

这种新情况有一些好处：

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

数据工程师不必为组织中的每个人创建视图。他们可以专注于数据的标准化接口。

数据工程师可以专注于保持数据最新并提供良好的访问方法。

然而，有些事情仍然不对劲：

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

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

三 新方法：数据网格

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

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

在中间，中央数据平台已从数据产品团队（需要领域知识）转变为数据平台即服务团队（需要技术知识）。他们开发内部平台，使所有团队能够为数据存储、特征存储、数据处理、数据沿袭、调度、流程监控、模型工件、模型服务实例等创建自己的实例。因此，之前数据平台团队的所有技术技能都用于创建工具。这样，每个团队都可以成为自己的小规模数据平台团队。这确保了整个公司统一的工作方式和高标准。

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

这有很多好处：

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

数据平台团队瓶颈已消除。

自给自足的产品团队。

挑战在于：

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

防止新的中央数据平台即服务团队成为新的瓶颈。

让所有团队以共享的工作方式接受这种新方法。

在这个设置中，中央平台即服务团队（或多个团队）发挥着关键作用。他们以简单的自助方式设置和提供基础设施和软件服务。当他们创建平台即服务时，该团队不需要很多特定领域的知识。它只关注技术方面，使其可复制，并将解决方案分享给所有团队。这种便利的设置扩展性非常好！但是有一个很大的风险：采用瀑布方法。

数据网格方法解决了与数据重用相关的领域知识难题。这是通过将数据的责任转移到生成和处理该数据的团队来实现的。我们现在需要一个中央团队来协助所有团队管理他们的数据，而不是由一个中央团队拥有所有数据。

一个陷阱是采用瀑布式方法来启动和运行这个核心团队。在加入团队之前，不要从创建所有必需的基础设施和服务开始。只要没有一个团队使用这些服务，就没有附加值。因此，需要在团队已经可以使用服务时迭代地发展和改进服务。

第二个风险是让平台即服务团队决定工作方式。这将使团队成为整个公司的瓶颈。在敏捷和迭代方法中，一些团队将需要新的工具或服务，但这些工具或服务尚未准备好在公司范围内采用。平台即服务团队不应限制这些早期采用者，而应允许和授权发现和试用新工具和服务。让他们授权产品团队并联合起来。这将使两个团队获得在整个公司范围内进一步共享工具和服务所需的经验。

四 迈向现代数据平台的两个步骤

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

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

创建该数据平台的第一步是什么？遗憾的是，没有千篇一律的模板。方法应取决于具体情况，包括现有的技术堆栈、可用的技能和能力、流程以及一般的DevOps和MLOps成熟度。我可以给你一般性建议，希望这些建议能给你一个有用的视角。

一种方法是结合以前版本的优点，作为未来更高级版本（如数据网格）的基础：

数据工程师专注于提取和加载，并尽量减少转换。

特定领域（数据科学）团队专注于高级转换。

应该提供工具来增强团队的能力。

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

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

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

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

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

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

在这种情况下，数据科学家仍然需要进行大量的数据处理。然而，我们不会假设这种情况不会发生，而是接受它，并为他们提供工具，以最佳方式完成工作。

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

结果如下：

左侧我们保留原来的情况，即部门或产品团队只开发或运营其生产实例。这限制了公司范围内的变更。

中间部分，数据工程师专注于轻量级数据建模和高质量管道。他们主要负责加载所有数据，并提供标准化的访问方法。他们非常注重技术，包括基础设施和服务。

右侧，数据科学团队专注于根据所有必需的领域知识创建数据产品。他们通过向客户（使用其数据产品的客户）和上游数据源团队学习来获得上述领域知识。他们运行所有必需的分析和转换，同时得到平台即服务团队的支持。他们具有很强的领域和用例重点。

最底层，平台即服务团队致力于创建可重复使用的组件。因此，他们专注于技术。他们为专注于领域的数据科学团队提供服务。平台即服务团队应该由他们的需求驱动。

第二阶段：跨团队扩展和共享

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

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

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

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

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

不要忘记这些数据平台计划的目标。目标是启用更多数据产品。因此，除了加入多个数据科学团队外，努力实现生产模型也很重要。让第一批（少数）团队能够真正将他们的模型预测嵌入到业务中。

有了这些平台、流程和工作方式，下一步该怎么做就不太清楚了。有很多机会可以提高服务质量和团队协作。

根据业务需求，所提供服务的质量可以得到改善。也许需要实时特征存储、新的模型服务平台、自动ML工具或更好的模型监控？

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

五 小结

以上展示了一种向更加数据驱动的组织迈进的方法，即采用敏捷方法进行开发。这篇文章并不建议任何解决方案作为“最佳方法”，而是希望提供一个额外的视角来参照现在所处状态。

该方法的关键组成部分包括：

敏捷（内部）以客户为中心的方法。

平台思维。

消除瓶颈，同时提供灵活且能够增强数据科学团队能力的平台。

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

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓