摘要：导读随着数据规模的不断增长和业务复杂性的提升，传统数据架构在时效性、成本和灵活性方面的局限性日益凸显。为应对这一挑战，湖仓一体架构应运而生，成为大数据领域的关键技术方向之一。本文介绍了淘天集团客户运营部在数据湖架构落地中的实践经验与成果。内容涵盖客运业务的核心
导读随着数据规模的不断增长和业务复杂性的提升，传统数据架构在时效性、成本和灵活性方面的局限性日益凸显。为应对这一挑战，湖仓一体架构应运而生，成为大数据领域的关键技术方向之一。本文介绍了淘天集团客户运营部在数据湖架构落地中的实践经验与成果。内容涵盖客运业务的核心流程与特点、数据架构的演进过程、新架构的设计与实现，以及数据湖在实际场景中的应用。通过引入 Paimon 数据湖技术，实现了流批一体和高效的数据处理链路，显著提升了开发效率、分析性能并降低了成本。此外，还探讨了当前面临的挑战及未来规划，包括热扩缩容、物化视图和大模型结合等方向。希望为大家在数据湖架构落地时提供思路与借鉴。
今天的介绍会围绕下面 7 点展开：
1. 客运业务
2. 客运数据架构演进
3. 客运湖仓架构
4. 应用场景
5. 阶段成果
6. 未来展望
7. Q&A
分享嘉宾｜徐国政 淘天集团 数据技术专家
编辑整理｜张阳
内容校对｜李瑶
出品社区｜DataFun
01
客运业务
客运业务，源于原有的 CCO 体系，承接了大淘系服务与体验业务。
1. 核心业务流程
消费者在淘系业务中的诉求主要分为三类：
消费者在购买正向订单交易过程中可能产生咨询需求，此时平台客服会介入提供支持。在商品交付环节可能出现发货延迟或商品问题等情况，我们需要进行催发货或处理相关投诉，以提升消费者的收货体验。在售后环节，消费者可能因退货与商家产生纠纷或投诉，这是客运业务需要介入处理的逆向业务流程。为保障逆向业务的用户体验，我们配备了数万名云客服及内部小二团队提供支持。平台每日处理数亿级别的在线和离线咨询，其中千万级咨询由智能模块完成。这个智能模块体现为平台上的小蜜机器人，由我们客运业务团队开发运营。
2. 业务特点
基于上述业务背景，客运业务具有以下特点：
丰富的数据源：包括自有逆向域的 DBMS 系统、日志数据，以及上游用户行为和订单相关数据。此外，还涉及对话语聊及在热线对话等半结构化/非结构化数据。处理过程较为复杂：由于逆向是交易末端环节，业务过程比较漫长，从下单到退款、投诉、纠纷直至赔付，涉及大量长周期指标计算。同时，作为末端业务，过程中存在诸多双流 join 和多流 join 场景。此外，动态列更新是我们的重要需求。在数据仓库中间层构建过程中，经常需要将不同数据流合并为退款大宽表或工单大宽表。丰富的数据应用能力：比如之前提到的小蜜机器人，需要通过数据来实现订单预测、故障预测等智能问答能力，帮助消费者快速定位和解决问题。针对数以万计的客服小二，需要提供服务洞察、远程管理等数据能力。在 P2C 场景中，通过新灯塔等数据产品支持平台对商家进行考核。02
客运数据架构演进
接下来，介绍客运数据架构的演进过程。
1. 客运架构演进
客运部门前身为 CCO，曾是一个规模较大的中台部门。在 2018 年之前，我们就已开始设计离线和实时架构。当时离线计算使用集团内部的 ODPS，实时计算采用 Blink，服务引擎则使用 HBase 和 MySQL 来支持下游的智能小蜜、工作台以及大屏等应用场景。但当时的应用场景规模较小，主要针对特定需求进行定制化开发，属于烟囱式开发模式。
2018 年后，我们进行了架构升级。服务引擎方面做了重大调整，引入 Lindorm 替代原有的 HBase，初期采用 ADB，后期改用 Hologres，针对下游不同业务场景进行分类支持。我们将业务场景划分为 ToB、ToC 和对内运营三类，分别采用点查或 OLAP 方式进行支持。这个阶段是客运架构发展最快的时期，我们引入了数仓分层概念，加强了离线实时中间层建设，全员参与实时开发，实时任务数量从几十个增长到一千多个。此阶段我们采用典型的 Lambda 架构，但数据出口缺乏强管控，存在明显的数据孤岛问题。
基于 2.0 架构的问题，我们又进行了 3.0 架构升级，目标是实现计算一体化、存储一体化和服务一体化，即真正的流批一体架构。由于当时缺乏数据湖能力，经过多方调研后选择用 Hologres 替换 TT 作为实时中间层，开发引擎从 Blink 切换到 Flink，将离线和实时数据高性能写入 Hologres 中间层。随后再通过数据集成或 Flink CDC 将数据写入服务层的 Lindorm 和 Hologres，以及检索场景，为此，我们还引入了开源的 ElasticSearch。最终，通过统一数据服务为下游的实时特征和召回场景提供支持。
该架构中，我们临时采用 Hologres 作为实时数仓解决方案，但存在一定局限性：其初始中间层采用行式存储（行表），虽支持点查（Point Query），却无法实现 OLAP 分析。若需 OLAP 功能，需采用行列混存方案，但这将显著增加成本，且难以完全替代离线场景。因此，该架构实为向终极架构演进的过渡方案。由于 Hologres 的成本因素，下游业务分析场景的数据使用效率受到制约。
以上即为客运架构演进的三个阶段。
2. 老架构概况
经过上述演进后，整体数据流向从数据接入层开始，接入了丰富的数据源，包括淘系数据和菜鸟数据等。数据处理分为三个流向：离线处理（T+1），准实时处理（T+15 分钟或 T+半小时），以及实时处理。其中实时处理通过 Hologres 中间层实现实时数据订阅，同时进行问题排查和监控。上层则提供数据服务和数据应用。在此过程中，我们主要专注于 Hologres 的技术创新，包括大模型数据集、Hologres Warehouse、物化视图以及 jsonb 等能力。这是湖仓架构升级前所采用的架构方案。
03
客运湖仓架构
基于现有架构，我们进行了痛点调研。
从数据开发视角来看，虽然引入了 Holo，但由于成本问题，实际开发过程中仍需维护三套独立逻辑，即实时、准实时和离线。这导致开发成本较高，且存储冗余，数据一致性难以保证，经常出现 T+1 数据正常但 T+15 分钟数据异常的情况，修复工作较为困难。其次，分析链路较为复杂。对于 OLAP 数据和复杂场景，通常需要将 ODPS 数据计算后通过数据集成同步到 Holo 或其他 OLAP 系统进行分析。此外，由于缺乏中间层，面对分钟级需求时，若采用 ODPS 进行 15 分钟或半小时计算，业务方往往难以接受延迟，不得不使用实时计算 Flink 方式，成本较高。运维方面也存在挑战，由于 Holo 和 Flink 等中间层资源相互隔离，独立申请和保障，无法实现弹性调度。
从业务用数视角来看，首先业务人员使用门槛较高，同一业务需要查询多张表，例如逆向业务的对话 Touch 或工单，一个业务可能涉及 Touch 全量表、增量表、小时表和实时表，理解成本较高。且由于实时数据存储在 Holo，离线数据在 ODPS，业务人员分析时面临较大障碍。其次，实时数据的使用门槛较高，由于用户需要查询 Holo 数据，但 Holo 中间层仅支持点查不支持 OLAP 查询，因此需要数据团队将 Holo 的行表转换为列表，并同步至另一个存储系统以供分析使用。这种定制化开发工作会消耗大量人力资源。在性能方面也存在瓶颈，许多分析场景直接查询 ODPS 数据，虽然报表层具备一定加速能力，但查询速度仍然较慢，影响了业务分析人员的工作效率。
经过痛点分析，当前架构难以解决这些问题的主要原因在于数据底座存在局限性。为此，我们需要重构数据底座，提升数据新鲜度和查询性能，最终实现流批一体和湖仓一体的目标。具体方案是引入 Alake 淘天集团的数据湖技术来彻底解决上述问题。
1. 新架构
引入数据湖之后，新架构在数据处理侧和查询引擎侧存在一些改变。数据处理方面，采用湖仓一体架构，确保不会只有数据湖而没有数据仓库。因此，ODPS 数仓数据与 Paimon 数据湖的数据可以通过数据共享机制实现互通。具体而言，ODPS 数据可以查询湖数据，湖数据也可以查询 ODPS 数据。在数据湖侧，统一采用 Paimon 存储格式，并通过元数据和权限管理来实现湖数据的统一管理。关于湖计算资源管理，从资源视角来看，系统并不区分中间件是 StarRocks 还是 Flink，只关注是在线计算还是离线计算。这意味着 StarRocks 和 Flink 的资源可以共享。例如，当 Flink 资源不足或过剩时，可以将 Flink 资源调配给 StarRocks 使用，从而避免因资源不足而需要走冗长的资源申请流程。
Alake 提供了数据湖门户，使我们能够在同一平台上实现资源配额管理、作业运维、数据集成、数据治理以及统一开发平台等功能。此外，由于 StarRocks 与 Paimon 的高度集成，StarRocks 外表可以直接高性能地查询湖表数据，无需二次导入。这一特性特别适合下游分析场景，消除了数据导入 OLAP 系统的高成本问题，以及无法同时查看实时和历史数据的困扰。这就是架构升级后的新架构形态。
2. 数据流
新架构的落地需要构建新的开发链路。首先获取源头数据，包括 DBMS、消息队列（如 Kafka、内部 TT 或其他上游 Paimon），通过数据集成或 Flink CDC 方式实时写入湖仓 ODS 层。对于 DBMS 数据，可采用 input 方式；对于无 binlog 记录的上游（如 TT 或 Kafka），可通过 lookup 方式生成增量日志。生成增量日志的 ODS 表经过 partial update 合并、数据清洗和字段衍生后形成 DWD 层。DWD 层可继续通过 lookup 方式生成增量日志向下游传递。由于 DWD 层涉及复杂计算，实时计算可能无法满足需求，此时可通过离线分支或 MaxCompute 离线数据进行离线调度依赖，即离线任务可依赖湖仓中的 DWD 表，同时 DWD 表也可通过离线任务进行数据订正，最终写入 DWS 层，再通过 StarRocks 直接查询 DWS 或 ADS 层。
3. 入湖
传统的数据入仓采用多套入仓策略，包括离线增全量同步入离线数仓，以及实时通过消息队列订阅 DB 的 binlog 入实时数仓。表结构维护较为困难，主要因为业务库表结构变更无感知，需在每次业务库变更时手动变更消息队列和 ODS 层的 DDL，这一过程较为繁琐。并且，若变更未被数据团队及时发现，还需手动回刷部分历史数据。这些是传统数据入仓存在的问题。
因为数据湖的数据集成是通过 Flink CDC 实现的，Alake 数据湖项目提供了一个高效易用的数据集成工具，可以快速将 TDDL 或开源 MySQL 数据库的数据通过全增量方式导入数据湖。用户可以选择进行整库实时同步或单库离线同步。由于我们有实时数据，因此会选择整库实时同步，并配置全量同步和增量同步。配置完成后，系统会生成三个 Job，分别用于结构同步、全量数据同步和实时数据同步，这种一键同步方式大大降低了数据入湖的工作量。
4. 数据处理
在数据入湖后的数据处理阶段，以逆向工单为例进行说明。通过数据集成将业务数据写入 Paimon 的 ODS 层，这里以工单表和工单动作表为例。这两张表分别记录了工单属性和操作日志。数据通过 Flink 创建的 Paimon 任务写入 DWD 层，其中工单中间层表是一张流批一体表，具备以下能力：
partial update：支持将上游不同流的数据写入中间层。changelog：支持下游流式读取。deletion-vectors：由于工单数据量相对较小，在保证写入性能的前提下支持自定义分析。mark-done：这是一张分区表，支持离线依赖历史分区，只要 done 分区的到岗，离线就可以触发计算。另外，由于目前处于双跑阶段，因此会有数据订正。DWS 层通过聚合方式支持轻量级汇总指标计算，最终将数据提供给分析模块、服务模块、报表模块和大模型计算模块。5. 湖表管理
ALake 提供了优秀的元数据管理平台。通过 Paimon 的 Catalog 功能，可以高效管理湖表。此外，在 Flink 开发 Paimon 表时，不再需要像过去开发 TT 任务那样创建大量临时表或编写冗长代码，这使得我们的任务代码更加简洁。
6. 数据质量管理
除了数据入湖和数据处理之外，数据质量也是我们重点关注的方向。为保证数据湖的数据质量，主要有三部分工作：
首先，实时入湖监控。在实时入湖阶段，我们通过配置 Flink 任务的 Failover、Delay、Input/Output 等告警机制，使 Owner 能够及时发现并解决实时入湖数据的异常情况。其次，中间处理环节的任务也可以通过平台的监控机制实现告警功能。第三，湖表数据 DQC。由于当前平台不支持直接对湖表进行 DQC 校验，我们将湖表的离线部分同步到 ODPS 中，在 ODPS 中进行数据质量检查。检查内容包括：数据是否为空、波动环比、列枚举以及自定义 SQL 等。7. StarRocks
在数据湖数据加速方面，我们采用 StarRocks 架构来实现。但在实际应用中，我们发现 StarRocks 下游分析场景众多，且需要执行大量复杂查询，如 JOIN、COUNT(DISTINCT)的查询。虽然 StarRocks 查询湖外表性能优异，但高并发使用仍会带来挑战。为此，我们期望 StarRocks 具备多资源组隔离能力，使不同场景下的资源能够相互隔离。
我们采用了存算分离架构的 StarRocks，通过 Warehouse 资源组隔离机制来解决这个问题。用户可以通过不同的 JDBC 连接指定查询路由到特定 Warehouse。基于此能力，我们为不同场景创建了专用 Warehouse：数据分析场景使用 analyze_warehouse，服务场景使用 service_warehouse，报表场景使用 fbi_arehouse，大模型场景使用 Ilm_arehouse。这种隔离机制确保了各场景查询互不干扰，保障了整体系统的稳定性。
04
应用场景
接下来介绍具体的应用场景。我们每年都会举办一些大型活动，如双 11、双 12 大促等。这一期间会设有大屏监控系统，用于记录逆向相关数据，如退款发起、求助等。除大屏外，我们还设置了多个小屏监控，通过小时或分钟级别的退款量等逆向指标，实时监控业务状况，以便及时发现并处理逆向问题。
该场景存在一定难点，主要体现在数据口径的多样性。例如锁单口径，以订单支付时间为统计周期起点，追踪支付后的退款发起、退款拒绝、退款纠纷及退款完结等指标。业务周期可能较长，通过数据可以完整观察用户从支付到最终完结的全流程。
在湖仓架构应用前，我们主要采用 Flink 进行数据处理。在退款流、纠纷流和投诉流的多流 join 场景中，我们选择使用 Flink 而非离线计算，主要因为流数据量较大，离线计算无法保证 15 分钟内完成处理。Flink 完成 join 后将结果写入 ODPS 离线数仓，这是由于全量使用 Flink 计算长周期（如 30 天）数据会带来较大的 state 存储压力，影响系统稳定性。Flink 写入离线数仓采用批处理方式会产生大量小文件，且数据为未去重的明细数据。因此我们设置了 15 分钟调度任务对这些退款明细进行去重处理，获取最后一条退款记录后，再启动调度任务计算商家汇总指标，并将结果同步至 Holo 引擎支持报表查询。该链路涉及 Flink、实时计算引擎、离线计算引擎以及 Holo 的计算、存储和查询引擎，导致两个主要问题：一是运维复杂度高，二是数据时效性难以保证。在大促期间，离线计算资源紧张且退款订单量激增，15 分钟的调度任务可能延长至 1-2 小时完成，导致下游分析延迟。
引入 Paimon 后，我们将上游实时流数据（订单、退款、纠纷、投诉等）直接写入 Paimon 进行去重处理，随后执行join操作生成明细大宽表。由于 Paimon 表本身支持主键去重，因此这张表无需额外处理，它自动成为以退款 ID 为主键的明细表。随后，我们通过 Flink 启动 Paimon 任务查询该明细表，进行聚合计算后将结果写入汇总表。该汇总表无需同步至外部 OLAP 系统，可直接通过 StarRocks 查询湖表数据并展示至报表端。该方案具有以下优势：
链路简洁：有效解决了 Flink 大任务问题，明细表替代了原有存储方案和状态存储；时效性高：数据分钟级到岗，最长处理时间仅需 6-9 分钟（含 3 分钟 checkpoint 时间）；成本优化：存储仅需 Paimon，结合湖存储的低成本特性，整体成本降低 50%。05
阶段成果
目前 Paimon 数据湖方案已取得阶段性成果：
模型覆盖：已覆盖 20% 核心中间层数据；开发效率：数据开发人员无需维护三套系统，开发效率提升 40%；分析效能：50 个业务团队采用 StarRocks 查询湖表，分析响应时间降低 60%；成本效益：同链路成本降低 50%。06
未来展望
未来规划涉及以下三个方面。
探索：
时效提升：在现有 Paimon 分钟级延迟基础上，探索 Fluss+Paimon 方案，目标将数据新鲜度提升至秒级；物化视图：目前淘天集团内部 Flink 已支持该功能，后续将进行深入调研。大模型与数据湖的结合：目前我们正全力投入 AI 领域，众多大模型应用需要与数据仓库进行交互。然而，若直接与 ODPS 系统交互，不仅模型运行本身需要时间，与数据仓库的交互还会显著影响大模型编排链路的实时性。通过将 ODPS 数据迁移至数据湖，可大幅提升大模型应用的性能表现。稳定性：
DQC 能力：由于 Alake 在集团内部落地时间较短，当前全链路监控仍存在不足，包括湖表的 DQC 功能尚不完善。我们计划在新产品中引入 DQC 能力。StarRocks 热扩缩容：在期望 StarRocks 具备高稳定性的同时，也希望能够尽量避免其在每次进行版本升级或扩容操作时对线上服务造成影响。尽管当前 StarRooks 的扩容操作支持批量处理，并且可以设置一定的比例（例如 30% 或 40%）来逐步启动新节点，但在此过程中，仍不可避免地会导致部分线上的 Worker 节点断开连接。这种断连现象可能会对读取操作产生一定影响。因此，未来希望能够实现 StarRocks 的热扩缩容或热升级功能，从而最大限度地减少对线上服务的干扰。湖链路压测：今年我们已部署多个湖应用场景。面对即将到来的 618 和双 11 大促，湖链路压测将成为重点关注的领域。我们计划在大促前进行充分的压测探索。成本：
虽然当前湖架构的存储和计算成本已显著低于原有架构，但在 snapshot 可视化管理和治理策略工具化方面，以及冷热数据处理策略上仍有提升空间。我们期望在新的一年里实现这些功能的产品化落地，帮助业务团队更高效地使用数据湖资源，避免因不合理使用导致的成本上升问题。以上是本次分享的全部内容。
07
Q&A
Q1：如何衡量数据湖架构带来的正向收益？
A1：文中有提到几点，由于我们处于业务侧而非平台侧，对于业务而言更关注的是数据湖架构的实际提效效果和业务体验。首先，业务在使用数据湖空间进行数据分析时，是否降低了 RT（响应时间）和使用成本。我们会通过抽样调查获取业务反馈，目前已获得了一些正向反馈。其次，从架构视角来看，数据湖的引入使得原本需要通过多个步骤实现的链路变得更加简洁高效，性能提升的同时成本也有所降低。
Q2：您认为在落地数据湖架构的过程中，最大的障碍是什么？
A2：作为业务侧负责人，我感触最深的是业务同学的使用体验。我们提前构建了完善的数据体系，无论是报表、AI 应用还是通过 StarRocks 直接查询的场景，用户都能获得流畅体验。然而对数据开发同学而言，数据湖建表过程较为复杂。与传统 ODPS 或 Flink 建表只需关注分区和注释不同，湖表（如 Paimon 表）需要处理诸多细节：行级生命周期、分区生命周期、snapshot 管理，以及 bucket 数量、 bucket key 选择等参数配置。尽管我们已在业务社区沉淀了相关文档说明，但开发同学面对这些配置仍感困扰。尤其建表后还需重新执行数据写入流程，这一过程确实带来了较大挑战。
以上就是本次分享的内容，谢谢大家。
来源：DataFunTalk