使用 Delta Sharing 进行直接数据共享 - 简介：我们在 Zalando 赋能合作伙伴的旅程

翻译于 2025-11-26 15:15:33 发布 · 11 阅读

CC 4.0 BY-SA版权

原文链接：https://engineering.zalando.com/posts/2025/07/direct-data-sharing-using-delta-sharing.html?utm_source=substack&utm_medium=email

文章标签：

#案例

在这篇文章中，我们将解释我们如何通过实施 Delta Sharing 来改变 Zalando 分散的合作伙伴数据共享方式，从试点解决方案发展成为一个组织范围的平台，从而实现我们合作伙伴生态系统中的实时、安全的数据访问。

一切的开端：挑战

试想一下：您是 Zalando 的合作伙伴，想要了解您的产品在欧洲最大的时尚平台之一上的表现。您需要洞察数据，以便制定有关库存、定价和产品组合规划的战略决策。然而，您并没有获得所需的数据，而是发现自己不得不疲于应对多个系统、格式和繁琐的手动流程，才能拼凑出一个清晰的业务绩效概览。这就是我们的合作伙伴面临的现实，也是我们不能忽视的问题。

在 Zalando 数据基础架构部门的合作伙伴技术部门，我们通过三种不同的商业模式与合作伙伴共享数据和见解，以指导他们的业务发展：

Zalando 与传统批发商建立合作关系，即购买和转售产品。
合作伙伴计划，支持直接面向消费者的销售，以及
互联零售将实体店与我们的平台连接起来。

这些合作关系都会产生宝贵的数据，但如何以有用的格式将这些数据传递给合作伙伴却成了一个巨大的挑战。

本文将介绍以下内容：

问题陈述简述
现有解决方案及合作伙伴需求概述
寻找潜在解决方案的历程
我们为什么选择增量共享？
从飞行员到平台
吸取的教训
展望未来

本文不会涵盖以下内容：

台达分享了对其技术架构的深入解释
Databricks 和 Unity Catalog 功能

警钟敲响：了解真正的影响

我们的旅程始于看似例行的合作伙伴访谈，但对话很快揭示了一个令人警醒的现实。经过数月的讨论，我们发现了破坏合作伙伴关系的关键痛点：

数据碎片化迫使合作伙伴在SFTP传输、CSV下载、自助报告和API调用之间疲于奔命。每种方法都有其用途，但它们组合在一起却形成了一个复杂的网络，需要跨多个系统具备专业知识才能获得完整的业务视图。

手动数据处理已成为一项隐形的负担，合作伙伴每月要安排 1.5 个全职员工专门用于数据提取和整合。战略人才被困在处理数据格式的泥潭中，而无法分析趋势和制定业务决策。

数据访问受限意味着我们的用户界面并非为满足高级合作伙伴所需的大量数据下载而设计。数据可用性的时间限制常常阻碍我们在关键规划周期内访问历史信息。

合作伙伴希望通过程序化方式获取可用于分析的数据，以便与现有的分析基础设施无缝集成。虽然我们提供了用于运营数据的 API，但拥有复杂分析能力的合作伙伴需要直接访问已处理、可用于分析的数据集，以进行战略分析。

除了解决这些痛点之外，我们还意识到一个重要的机遇。作为欧洲时尚生态系统中海量商业数据的拥有者，Zalando 拥有得天独厚的优势，能够充分释放合作伙伴的潜力。我们不仅可以解决数据访问问题，还可以转变合作伙伴利用数据洞察发展业务和加强合作关系的方式。

绘制合作伙伴格局图

随着我们深入研究，我们意识到“一刀切”的方法对任何人都没有好处。我们的合作伙伴生态系统涵盖数千家活跃合作伙伴，从管理几百个SKU的小型零售商到拥有数万种产品的大型品牌。数据量差异巨大，一些合作伙伴每周只需处理几兆字节的销售数据，而另一些合作伙伴则需要TB级的历史数据集来进行战略规划。我们总共管理着200多个数据集，大小最高可达200TB，这些数据资产的使用有助于指导我们总交易额超过50亿欧元的商业合作伙伴平台业务。

绘制合作伙伴格局图

大型合作伙伴运作高效，如同精密运转的机器，寻求通过安全、自动化的管道进行程序化访问。他们拥有处理复杂集成所需的技术实力，但需要数据能够无缝流入其现有的分析基础设施。

中型合作伙伴身处混合型环境中，他们习惯于使用仪表盘和定期数据提取，但未必具备实时流解决方案的能力。他们需要灵活性，但又不希望过于复杂。

小型合作伙伴通常依赖于电子表格等常用工具，并且需要临时访问特定数据集。对他们而言，简便易用比技术复杂程度更为重要。

与此同时，数据需求也同样多种多样。一些合作伙伴渴望实时洞察，以便快速应对市场变化；而另一些则需要全面的历史数据集，用于长期趋势分析。有些合作伙伴需要增量更新以保持系统同步，而另一些则更倾向于符合其内部工作流程的批量处理。我们现有的解决方案——API、SFTP、S3存储桶和电子邮件——虽然各自满足了部分需求，但没有一个能够提供全面的解决方案。我们只关注了局部问题，却忽略了整体情况。

寻求更佳解决方案

基于这种认识，我们开始系统地寻找一种解决方案，既能满足合作伙伴多样化的分析需求，又不会创建另一个孤立的系统。我们深知，我们需要的是一种经得起时间考验，并且能够随着我们不断壮大的合作伙伴生态系统而扩展的方案。

解决方案标准

我们的评估标准虽然严格，但却必不可少。解决方案必须与Zalando 的整体数据战略保持一致，同时还要具备足够的云平台无关性，以便与合作伙伴多样化的基础设施兼容。它必须能够支持所有类型的合作伙伴生态系统，从使用电子表格的小型企业到拥有复杂数据管道的企业级运营。

性能和可扩展性是不可妥协的，我们需要高效地处理TB级数据集。安全性也不容忽视；我们需要细粒度的访问控制、数据加密和全面的审计功能。此外，该解决方案还需支持合作伙伴所需的所有数据访问模式：实时流式传输、批量更新、增量和差值更改以及历史分析。

或许最重要的是，我们需要一种不会让我们陷入困境的方案。该方案必须具有可扩展性，并且兼容开源工具，确保我们的合作伙伴能够将其集成到现有的工作流程中，而不是强迫他们采用全新的流程。

探索 Delta 共享：颠覆性的变革

我们的研究让我们发现了Delta Sharing，了解得越多，我们越兴奋。这是一个专为跨组织安全数据共享而设计的开放协议，正是我们所需要的。但吸引我们的不仅仅是它的技术能力，更是它背后的理念。

Delta Sharing承诺实现零拷贝数据访问，这意味着合作伙伴无需承受持续数据传输的开销即可使用实时数据集。它支持通过程序接口、商业智能工具，甚至电子表格进行访问，在一个解决方案中涵盖了我们所有的合作伙伴群体。该协议能够高效处理海量数据集，并通过设计本身而非附加功能来确保安全性。

当我们发现 Databricks 的托管式增量共享服务时，我们的选择就变得清晰明了。虽然我们很欣赏该协议的开源特性，但这项托管服务提供了一项无比宝贵的优势：它为我们服务于关键合作伙伴关系的生产系统带来了卓越的运维能力。

该托管解决方案通过与 Unity Catalog 的集成、内置安全功能和全面的审计日志记录，提供了强大的治理能力。最重要的是，它使我们的团队摆脱了维护另一项基础设施组件的运维负担。我们可以专注于为合作伙伴创造价值，而不是忙于服务器故障排除。

该架构简洁优雅，功能强大。合作伙伴可以通过基于令牌的身份验证（我们在初始阶段支持此方式）结合凭证文件访问共享数据，从而在保证安全性的同时简化操作。该系统既支持所有合作伙伴的开放共享，也支持已在其数据环境中使用 Databricks 的合作伙伴之间的 Databricks 数据共享，这使我们能够随着需求的演变而灵活调整。

迈出第一步：我们的概念验证

作为Zalando首个实施Delta Sharing的团队，我们踏入了未知的领域。我们秉持着之前在识别问题时行之有效的严谨方法：仔细测试、全面评估，并诚实地分析其局限性。

然而，我们并非孤军奋战。成功离不开与Zalando技术部门各关键利益相关者的紧密合作。我们的中央数据基础团队为Unity Catalog的集成和治理框架提供了至关重要的指导，帮助我们理解Delta Sharing如何融入Zalando更广泛的数据架构。他们的专业知识在应对我们现有数据基础设施的复杂性方面发挥了不可估量的作用。

同样重要的是我们与应用安全和身份与访问管理(IAM)团队的合作。鉴于我们实际上是在创建新的外部数据访问途径，安全考量至关重要。这些团队帮助我们评估身份验证机制，分析潜在的安全漏洞，并确保我们的实施方案从一开始就符合 Zalando 严格的安全和身份验证标准。

我们开展了一项全面的概念验证，以了解增量共享在我们特定环境中的能力和局限性。这种协作方式使我们能够及早发现关键限制并制定缓解策略。

我们的概念验证既展现了实施的潜力，也揭示了实际面临的挑战。与 Unity Catalog 的集成虽然功能强大，但也带来了权限和访问管理方面的操作复杂性，需要与数据基础架构团队的同事密切协调。由于缺乏用于令牌管理的自助式 API，我们最初不得不手动处理合作伙伴的入驻流程——这对于大规模应用来说并不理想，但在应用安全团队的指导下，安全令牌分发方案在试点阶段尚可应对。

这些发现并没有让我们气馁；相反，它们指导了我们的实施策略，并加强了我们跨团队的协作。任何开创性的工作都会遇到障碍，而拥有合适的协作框架使我们能够将这些挑战转化为学习机会，从而使Zalando未来的各项工作受益。

简化架构：Zalando 的运作方式

在概念验证得到验证后，我们采用了精简的架构，以展示增量共享的核心原则。

简化架构

了解差价分摊术语：

Delta Share：一个逻辑容器，用于将相关表分组，以便安全地分发给外部接收者。
接收方：代表我们 Delta 共享系统中每个合作伙伴的数字身份
激活链接：一个安全的URL，合作伙伴可以通过该URL下载其身份验证凭据。

第一步：数据准备和集中化

我们根据合作伙伴的需求准备数据集，并将其存储在可扩展的存储系统中。然后，这些数据集会被编入中央元数据和治理层，从而确保数据的一致性和可控性，并作为单一数据源。

步骤 2：访问配置

我们为每个合作伙伴创建访问点（接收方），并分配相应的权限。这些访问点作为相关数据的逻辑分组，实现安全有序的数据分发。每个访问点都会生成一个唯一的链接，然后安全地将其提供给相应的合作伙伴。

步骤 3：直接数据访问

合作伙伴收到激活链接后，即可使用该链接与数据分发系统建立安全连接。身份验证成功后，合作伙伴即可直接请求访问底层数据。

这种方法具有以下几个主要优点：

合作伙伴可直接访问实时数据，无需承担数据复制的额外开销。
身份验证机制通过有时限的、合作伙伴特定的访问凭证来确保安全性。
由于数据仍保留在原始位置，因此我们避免了存储重复和持续同步的挑战。

实施步骤：简化版

实现视图

向外部共享数据集的典型步骤

1. Prepare the final datasets (delta tables) via Unity Catalog.
2. Create a 'Share' (logical container).
3. Add the 'delta tables' to the ‘Share’.
4. Create a recipient for each partner.
5. Grant permissions to the recipient for accessing the share.

Databricks提供了详尽的文档，帮助用户了解 Delta 共享的技术细节及其 API，以便构建基于 Delta 共享的解决方案。

弥合差距：让合作伙伴无缝融入

构建一套优雅的技术方案只是挑战的一半，另一半在于确保我们的合作伙伴能够有效地使用它。我们开发了全面的用户指南，其中包含使用 Pandas 和 Apache Spark 等常用工具访问共享数据的分步说明。

这些指南包含实用示例和故障排除方案，使合作伙伴能够在收到激活链接后几分钟内完成从接收到提取第一个数据集的整个过程。通过提供清晰的 Delta Sharing 连接器 API 文档，合作伙伴可以将我们的数据直接集成到他们现有的分析流程中，而不会中断既定的工作流程。

从试播集到正式平台：涟漪效应

我们的Delta共享试点项目的消息开始在Zalando内部网络中传播，引发了来自公司各团队的咨询。其他与合作伙伴协作的部门也开始联系我们，意识到他们自身在数据共享方面可能面临的挑战。

这种需求验证了我们的方法，并为我们避免业务碎片化提供了契机。我们没有让每个团队各自开发自己的实现方案，而是通力合作，将解决方案发展成为一个覆盖整个 Zalando 的综合收件人管理平台。

构建平台：从解决方案到服务

这一认识促成了我们的下一步发展：将试点项目转型为Zalando面向所有用户的综合收件人管理平台。我们不再仅仅将其作为合作伙伴技术团队的单一解决方案，而是构建一个基础设施，使Zalando的任何团队都能通过增量共享实现安全、可扩展的数据共享。

我们不仅在构建技术，更在构建专业知识。我们的平台为准备数据集的团队提供全面的指导，确保数据集符合平台预期并能有效扩展。我们将概念验证和试点阶段积累的经验教训进行系统总结，并将来之不易的知识转化为可复用的最佳实践。

随着我们业务规模的扩大，超越了最初的合作伙伴用例，我们正在探索通过Databricks OIDC联合身份验证功能来提高合作伙伴的数据访问效率。这将允许部分合作伙伴直接访问其数据，这些数据由他们自己的身份基础设施保护，无需生成中间令牌。

规模带来的挑战

从单团队试点扩展到全组织平台会带来一系列独特的挑战。我们并非只是简单地复制现有解决方案，而是针对尚未充分探索的各种用例对其进行重新构想。不同的团队有着不同的数据治理要求、不同的安全限制以及独特的集成需求。

适用于我们合作伙伴技术用例的技术架构必须足够灵活，能够满足从实时运营数据共享到定期分析导出等各种需求。我们本质上是在构建一个数据共享平台，该平台可以作为多个团队的基础，同时保持每个团队所需的性能、安全性和可靠性标准。

此次扩展也意味着与 Zalando 数据治理框架的更深入合作。随着越来越多的团队通过我们的平台采用 Delta Sharing，我们需要确保数据访问、审计跟踪和合规性报告方面的策略保持一致。该平台既要足够强大，能够处理复杂的多租户场景，又要足够简单易用，以便团队无需大量培训即可上手。

经验教训：达美航空共享之旅的关键洞见

我们从分散的数据共享转型为统一的增量共享平台，从中汲取了宝贵的经验教训，这些经验教训不仅仅局限于技术实施。

首先要深入了解合作伙伴，而不是从技术入手。

我们最大的发现是，技术选择并非出发点，而是真正理解合作伙伴痛点的结果。我们花费数月时间与合作伙伴进行访谈，这不仅仅是调研，更是后续一切工作的基石。合作伙伴每月花费在手动数据处理上的1.5个全职员工，意味着战略人才被浪费在了运营任务上。

均码并不适合所有人，这也没关系。

我们需要一个能够以不同方式服务于不同合作伙伴群体的平台。大型合作伙伴需要程序化购买渠道，中型合作伙伴需要灵活性，而小型合作伙伴则需要简便易用。

跨团队协作不容协商

作为Zalando首个实施Delta Sharing的团队，我们深刻体会到，开拓新技术需要与公司各部门建立强有力的合作关系。我们的成功完全依赖于与中央数据基础团队（提供Unity Catalog方面的专业知识）、应用安全团队（提供安全指导）以及身份与访问管理（IAM）团队（提供身份与授权指导）的通力合作。