Razor Group在AWS上构建现代数据湖仓实践

Razor Group是欧洲领先的电商整合商之一，在多个全球市场运营超过250个品牌。公司收入超过4亿美元，依赖数据驱动每一项关键业务决策，从动态定价、库存优化到广告支出和供应链协调。

这一运营的核心是Razor操作系统（ROS），一个专有平台，每月通过9,300多条数据管道处理超过3.7亿次API调用，将市场信号转化为规模化的自动操作。

在这篇文章中，我们分享Razor Group如何通过实施湖仓架构在AWS上进行数据平台优化。我们涵盖架构决策、分阶段迁移方法以及可衡量的业务成果。无论您是想优化工作负载性能、降低基础设施成本，还是为分析解锁多引擎灵活性，这个蓝图都提供了可操作的见解，您可以根据自己的组织进行调整。

业务挑战：规模化数据基础设施以支持超增长

随着Razor Group品牌组合的快速扩张，对其数据平台的需求显著增长。公司需要其分析基础设施跟上电子商务的速度，在接近实时的环境中进行定价决策、库存补充和广告竞价。

他们现有的基于Amazon Redshift预置集群的架构在早期增长阶段表现良好。随着工作负载多样化和数据量激增，出现了几个优化机会：

图1：迁移前的Razor操作系统数据架构

• 工作负载争用：超过1,000个用于ETL、转换和分析的SQL模型竞争相同的计算资源，在峰值处理窗口期间造成资源争用。
• 成本与利用率不匹配：始终在线的集群全天候运行，但工作负载分析显示98%的计算需求来自批量ETL，而非交互式分析，导致非高峰时段大量空闲容量。
• 数据新鲜度差距：批量导向的管道提供4-6小时延迟的数据，限制了团队对快速变化的市场动态做出反应的能力。
• 扩展限制：随着并发用户和管道复杂性的增长，仅靠垂直扩展无法解决工作负载隔离和弹性容量的需求。

这些并非任何单一服务的失败。它们是架构需要演进以适应Razor Group工作负载的规模和多样性的信号。

为什么选择湖仓架构？

Razor Group没有替换现有投资，而是认识到通过采用现代湖仓架构来优化工作负载放置的机会。决策的核心原则：

• 开放表格式：Apache Iceberg提供ACID事务、时间旅行和模式演进。数据存储一次，任何兼容引擎均可访问，无需重复。
• 弹性、按工作负载扩展：数据持久化在Amazon Simple Storage Service（Amazon S3）上，每个引擎独立扩展计算以匹配其工作负载。每个引擎为峰值处理启动，空闲时缩减到零，无需过度配置共享基础设施。
• 多引擎灵活性：不同的工作负载有不同的需求。重型ETL受益于分布式Spark处理，临时探查受益于无服务器查询，商业智能（BI）仪表板受益于高性能仓库引擎，每个都针对其目的进行了优化。

这种方法允许Razor Group为每个工作负载选择最佳适配的引擎，同时保持跨整个平台可访问的单一治理数据副本。

解决方案概述

Razor Group与AWS合作实施全面的湖仓架构，汇集了多个AWS服务，每个都发挥互补作用：

图2：AWS上的端到端湖仓架构

为规模设计：湖仓愿景

推动Razor Group新架构的核心见解很简单：构建一个任何引擎都可以查询的单一开放格式数据湖。在旧模型中，每个工具维护自己的数据副本。在新模型中，Amazon S3上的单一开放格式数据湖作为事实来源，多个专用计算引擎根据手头的工作负载从中读取。

这种转变，通常称为湖仓架构，结合了数据湖的成本经济性和可扩展性与数据仓库的查询性能和治理。其开放表格式，Apache Iceberg，提供ACID事务、模式演进、时间旅行和无供应商锁定。

存储与治理：开放数据基础

• Amazon S3 Tables（Amazon S3的一项功能）与Apache Iceberg — 主要存储层，提供具有ACID事务、分区演进和时间旅行功能的开放格式表。数据存储一次，任何Iceberg兼容引擎均可访问。
• AWS Glue Data Catalog — 统一的元数据仓库，用于跨所有计算引擎的一致数据发现。
• AWS Lake Formation — 细粒度访问控制，具有列级和行级安全性，使治理随平台扩展。

计算：为正确的工作负载选择正确的引擎

• 在 Amazon Elastic Compute Cloud (Amazon EC2) 上的 Apache Spark — 用于重型 ETL 和转换工作负载的弹性、分布式计算。它使用 AWS Graviton 实例和 Amazon EC2 Spot 实例以优化成本。
• Amazon Athena — 无服务器 SQL，用于对 Iceberg 表进行临时探索和轻量级查询，无需管理基础设施。
• Amazon Redshift Serverless — 用于 BI 仪表板、Tableau 工作负载和交互式分析的高性能服务层。Amazon Redshift Serverless 自动扩展以满足需求，并在空闲时暂停，因此对于其最擅长的分析工作负载，它保持了成本效益。

编排和可观测性

• Apache Airflow — 管道编排，管理 9,300+ 条数据管道，具有依赖跟踪和服务水平协议 (SLA) 监控。
• 全面可观测性栈 — 跨所有层的成本归属、管道健康监控和数据质量检查。

注意： 当首次设计该架构时，Amazon Redshift 不支持 Iceberg 写入，使得自管理 Spark 成为唯一可行的摄取路径。此限制现已解除。 Amazon Redshift 现在支持完整的 Apache Iceberg DML (UPDATE、DELETE、MERGE)，补充了其早期的 CREATE/INSERT 功能和 AWS Glue Iceberg 物化视图。这使其成为一个完整的读写 Iceberg 引擎。

迁移方法

Razor Group 没有采用风险较大的大爆炸式切换，而是采取了分五个阶段的迁移方式，每个阶段都提供独立价值，同时为下一阶段奠定基础。在过渡期间，Amazon Redshift 和 Spark 管道并行运行，这保持了业务连续性，并让团队有信心地比较输出。在任何时候，生产管道都没有暂停，仪表板也没有不可用。

迁移历程：五个阶段

迁移分五个结构化阶段展开，每个阶段都建立在前一阶段的基础上，并在下一阶段开始前提供增量价值。

阶段 1：建立湖仓基础

在迁移第一个查询之前，Razor Group 需要回答三个问题：数据存放在哪里，如何管理，以及我们如何查询？

为什么选择 S3 Tables 而不是自管理 Iceberg

Razor Group 已经承诺使用 Apache Iceberg 作为表格式：开放、引擎无关，并具备 ACID 事务和时间旅行。问题在于是否在标准 S3 存储桶上自管理 Iceberg，还是使用 Amazon S3 Tables。

自管理 Iceberg 功能强大，但运维成本高。必须有人运行压缩作业以防止小文件激增。必须有人在元数据膨胀影响查询规划之前过期旧快照。必须有人清理中断写入后留下的孤立数据文件。由于有 700 多个模型运行在 40 多个 schema 上，其中许多每天多次物化，维护负担将随平台增长而不是减少。

S3 Tables 消除了这一整类工作。压缩、快照管理和未引用文件删除持续自动运行。集成的 Iceberg REST Catalog API 允许任何兼容引擎（如 Spark、Trino、Athena、Amazon Redshift 和 Flink）发现和查询表，而无需维护单独的元数据存储。通过 AWS Glue Data Catalog 统一发现，后者现在将其访问接口暴露为 Iceberg REST Catalog 协议。由于表是 AWS 一等资源，访问控制、加密和生命周期策略在表级别运行，而不是通过堆叠在文件路径约定之上的复杂 S3 存储桶策略。

对于一家不想承担自管理开放表格式维护运维负担的公司来说，这是决定性因素。

AWS Glue Data Catalog 提供跨所有层的统一元数据发现。Lake Formation 处理列级和表级访问控制，AWS Identity and Access Management (IAM) 角色遵循最小权限原则，并启用 AWS CloudTrail 以提供完整的审计跟踪。

选择查询协议

在重新架构之前，Amazon Redshift 集群 98% 用于 ETL，只有一小部分计算小时用于分析人员的 SELECT 查询。替代引擎需要同时处理繁重的批处理转换和交互式临时查询。

传统 Spark (spark-submit) 能很好地处理批处理 ETL，但将客户端与集群耦合。每个作业都需要打包驱动 JAR、管理类路径，并从集群内部提交。对于一个运行 200+ 个生产有向无环图 (DAG) 的平台，每天处理海量数据，这种运维摩擦是不可接受的。

Spark Connect 是 Spark 3.4 中引入的基于 gRPC 的客户端-服务器协议，它完全解决了耦合问题。集群运行一个持久 gRPC 端点。客户端远程连接并通过网络提交查询。Airflow 操作符变成瘦客户端：它们打开会话、提交 SQL、获取结果，成功和失败直接映射到任务状态。没有驱动 JAR，也没有轮询。多个消费者，包括管道编排器、Web 应用程序和开发人员笔记本，共享一个集群，而无需在本地安装 Spark。

部署 Spark Connect

Razor Group 在 Amazon EC2 上部署了自托管 Spark 集群：一个按需 AWS Graviton 领导节点，Spot worker 节省约 70% 成本，Spark Connect 端点通过内部网络负载均衡器暴露。自定义亚马逊机器映像 (AMI) 内置了完整的 Spark、Iceberg 和 S3 Tables 栈，因此私有子网节点无需在运行时访问互联网即可拥有所需的一切。

这一阶段没有产生直接的业务价值，但它使后续所有工作成为可能。

阶段 2：迁移数据摄取

Razor Group 的摄取层从 Amazon Selling Partner API、Seller Central 门户、NetSuite ERP 和自定义网络爬虫拉取数据。在之前的架构中，所有这些数据都通过 COPY 命令进入 Amazon Redshift，这意味着数据新鲜度由批处理任务调度决定，并与服务于分析查询的同一个集群争抢资源。

Razor Group 将这些管道迁移到由 Apache Airflow 编排的 AWS Lambda 函数，将数据直接以 Iceberg 格式写入 S3 Tables。从调度驱动到事件驱动的转变显著提高了数据新鲜度。Lambda 函数仅在有数据需要处理时启动，Airflow 传感器在新数据落地时立即触发下游转换。这取代了僵化的每小时批处理窗口，使数据新鲜度以分钟计。

编排层管理着 90 多个流程中的 200 多个 DAG，并大规模处理来自数十个来源的数据。迁移需要将目的地从 Amazon Redshift COPY 改为 Iceberg 写入，但编排逻辑本身几乎无需改动即可延续。

仅这一阶段就通过切断摄取对常驻集群的依赖，消除了约 40% 的计算成本。

阶段 3：转换处理管道

这是技术要求最高的阶段，也是 Razor Group 学到最多的阶段。团队将 1,000 多个 SQL 模型从 Amazon Redshift 迁移到 Apache Spark，在 40 多个模式中沿依赖链增量推进。模型遵循奖章结构：Bronze 用于原始摄取数据，Silver 用于清洗和整合后的数据，Gold 用于业务就绪的聚合结果。

Razor Group 构建了自动化转换工具和验证框架，并行运行 Amazon Redshift 和 Spark 输出，在停用任何内容之前逐行比较结果。有几类转换将自动化能处理的范围推到了极限：

• 窗口函数：Amazon Redshift 中的 QUALIFY 子句在 Spark 中没有对应项。每个实例都需要包裹在带有显式行号的子查询中，仅库存模式中的几十个模型就受到了影响。
• JSON 序列化：这是最耗时的类别。Amazon Redshift 中存储为 JSON STRING 的复杂列在 Spark 中需要使用 from_json() 和手写的 STRUCT 定义。广告、订单和交易管道中的每个嵌套负载列都需要进行模式内省，毫无捷径可言。
• 函数方言：包括 NVL 转 COALESCE、DATEADD 转区间算术、LISTAGG 转 ARRAY_JOIN(COLLECT_LIST()) 在内的 20 多项函数级转换。
• 快照消除：这是最大的隐性成本。每天多次运行的全表复制仅为了保留时间点状态，每周消耗超过 35 小时的 Amazon Redshift 计算资源。借助 Iceberg 的原生时间旅行，这些操作一夜之间变成了零成本。

在迁移 1,000 多个 SQL 模型时，自动化工具可以很好地处理机械性的语法转换。但大约 30% 的模型需要人工判断：那些具有复杂 JSON 负载、深度嵌套窗口函数或跨模式快照依赖的模型。这些模型消耗了 70% 的迁移工作量。

Razor Group 构建了一个结构化的迁移工作流，使用 Claude 来加速这项工作：读取源 SQL、识别依赖、转换语法、解析缺失的基表、添加 JSON 解析、验证输出并写入湖仓。该系统不仅仅是翻译 SQL，它应用了模式上下文，追踪跨模型依赖，并标记出工程师们手动查找需要数小时才能发现的边缘情况。原本可能耗时数年的工作变成了数周内系统化、可重复的过程。这种方法从根本上改变了迁移的速度。

阶段 4：统一服务层

随着数据通过 Iceberg 表流动，Razor Group 精简了服务层。最终用户通过 Amazon Redshift Serverless 查询 Gold 层 Iceberg 表，内部探索和机器学习（ML）工作负载则通过 Spark Connect 读取相同的表。这消除了为不同消费者维护单独数据副本、物化视图或提取作业的需求。

这是开放表格式的战略回报。S3 上的 Iceberg 表与引擎无关：今天用 Spark 进行批处理转换，明天用 Trino 进行交互式查询，下个季度用 Flink 进行流处理。任何支持 Iceberg 的引擎都可以读取数据，无需转换或迁移。Razor Group 从被锁定在单一供应商的 SQL 方言中，转变为可以在不触碰存储层的情况下自由采用新引擎。

阶段 5：运营与可观测性

最后一个阶段使湖仓达到生产级水平。Razor Group 构建了一个全面的可观测性堆栈，将每个管道组件的指标、追踪和日志聚合到统一视图中。该视图支持集中式日志搜索、异常检测和自动告警，并关联整个数据平台中的故障。

这个可观测性层不仅仅提供可见性，它还赋予了团队信心。当你每天运行数千次管道执行时，你需要在几分钟内知道何时出了问题、原因是什么，以及哪些下游消费者受到影响。这就是被动救火和主动运维之间的区别。

管道编排围绕三种模式整合：每日管道（从摄取到物化再到导出供 AI 代理分析），一个每 15 分钟轮询的操作 worker，以及每周的爬虫作业。

切换在设计上实现了零停机：两个调度器并行运行了两周。自动化对比检查验证了每个管道在旧架构系统被禁用之前都产生了相同的输出。

结果与业务影响

湖仓架构在各个方面都带来了可衡量的改进：

63%的减少比较了湖仓运行率（2026年1月至3月）与重构前的运行率（2025年10月至12月），即重构前的最后三个月。该数字是同类混合基础设施数据，包括两种架构的计算和存储。之前的列涵盖Amazon Redshift集群计算和托管存储。之后的列涵盖Amazon EC2（Spark工作节点，包括按需和竞价）、AWS Lambda、AWS Glue、Amazon Athena、Amazon Redshift Serverless以及S3 Tables存储。数据传输和辅助服务被排除在外，因为它们在两个时期没有实质性差异。工作负载组合（管道、模型和最终用户查询卷的数量）在两个窗口期大致相当。

经验教训

从决策循环开始，而不是从工具开始，在替换你的数据仓库之前了解你的工作负载。

整个迁移中最有价值的活动不是写一行代码。而是在做出任何架构决策之前运行的Amazon Redshift工作负载分析。发现98%的计算用于ETL，只有一小部分用于分析师查询，这验证了转向按需Spark的决策。它还防止我们为几乎不存在的交互式工作负载过度配置替代基础设施。架构决策应始终追溯到核心业务需求：定价准确性、促销响应性、日内P&L可见性。从那里开始，而不是从技术开始。

设计支持多个计算引擎，并为每个工作负载选择正确的引擎。

运行单一引擎架构的最清晰教训之一是你会失去什么。避免将BI、数据摄取、回填和机器学习都锁定在一个计算层中，因为它们具有根本不同的成本和性能特征。一旦你做出转变，Iceberg、Spark和S3 Tables就能很好地协同工作。技术不是难点。难点在于映射超过40个模式中的1000多个模型，追踪超过200个DAG中的依赖关系，并发现一个列实际上是一个JSON字符串，在两个引擎之间静默地以不同的方式序列化。迁移既是一个挖掘项目，也是一个工程项目。

自动化转换，但为30%的剩余工作做预算。

自动化工具能很好地处理机械语法转换，它们应该是你首先使用的工具。但带有复杂JSON负载、深度嵌套窗口函数或跨模式快照依赖的模型需要人工判断，而且这项工作无法压缩。大约30%的模型需要大量人工干预，这些模型消耗了总迁移工作量的70%。从一开始就诚实地规划这一点。

可观测性必须包括成本归属，并警惕隐藏的成本炸弹。

快照操作是我们最大的惊喜。为了保留时间点状态，每天多次运行的全表复制每周花费超过35小时的计算时间，没有人质疑，因为“快照就是这样工作的”。Iceberg的时间旅行功能消除了这些成本，并且这一单一功能本身就证明了迁移的很大一部分合理性。更广泛地说，你无法优化你看不到的东西，所以追踪查询级别的使用情况并将其归因于团队和功能。成本可观测性不是可有可无的。它是基础性的。

治理不是可选的。将其构建到基础中，并从第一天起让利益相关者保持一致。

目录和访问控制需要先于大规模采用，而不是之后。同样的原则也适用于人：迁移是一个跨职能项目，而不是一个基础设施项目。我们的两周并行运行捕获了行级验证完全忽略的边缘情况：Amazon Redshift和Spark之间的时区差异、并发写入下的分区修剪行为，以及非确定性窗口函数中的细微排序差异。那次并行运行不是安全网。那是迁移真正证明自己的地方。没有从一开始就让正确的利益相关者参与并保持一致，这一切都不起作用。

结论

Razor集团的历程为寻求优化其数据架构的组织提供了宝贵的经验：

1. 首先分析你的工作负载组合。 理解98%的计算是ETL而非交互式查询，这指导了将繁重处理卸载到弹性Spark的决定，同时保留Amazon Redshift Serverless用于它最擅长的交互式分析。
2. 为多引擎灵活性设计。 像Apache Iceberg 这样的开放表格式消除了选择单一引擎的需要。每个工作负载都运行在最适合其访问模式、成本概况和性能要求的引擎上。
3. 自动化迁移，但为复杂性做预算。 自动转译处理了70%的SQL模型，但剩余的30%消耗了70%的工程工作量。相应地做出规划。
4. 可观测性必须包括成本归属。 没有按工作负载的成本可见性，优化就是猜测。Razor集团发现仅Iceberg快照维护每周就消耗超过35小时的计算时间，这是一个隐藏的成本，可观测性将其暴露出来，自动化将其解决。
5. 将治理构建到基础中。 AWS Lake Formation 和AWS Glue Data Catalog从第一天起就提供了细粒度的访问控制，而不是在迁移后改造。
6. 用并行系统验证。 新旧架构之间两周的并行运行捕获了自动化测试遗漏的边缘情况，这支持了自信的生产切换。

未来之路

在湖仓一体基础就绪后，Razor Group 得以加速创新，从实时定价模型到 AI 驱动的库存优化，这一切都由 AWS 上统一、开放且受管治的数据平台提供支持。

该公司的转型表明，现代数据架构并非要在各种服务之间做出选择，而是将每个工作负载放在其性能最佳的位置，使用开放格式消除数据孤岛，并随着业务增长独立扩展每一层。

要了解其他组织如何在 AWS 上实施类似的湖仓一体架构，请参阅How BigBasket uses the Iceberg-based lakehouse architecture on AWS to power lightning-fast grocery delivery across India。