一、流计算 Oceanus 介绍
随着大数据技术的发展，客户对实时处理与分析需求日益增长，实时数据分析已成为驱动业务创新、提升竞争力的关键要素。传统批处理方式存在时效性差、数据孤岛、难以扩展等问题，因此需要实时计算来弥补。
腾讯云流计算基于开源的 Apache Flink 搭建，作为腾讯云大数据产品中的实时链路，是企业级实时大数据平台，具备一站式开发、5 秒无缝衔接、亚秒延迟、低成本、安全稳定等特性。
二、腾讯云流式湖仓架构
接下来进入本次分享的核心部分，详细介绍腾讯云流式湖仓解决方案。
首先来介绍基于 Iceberg 的湖仓一体化基础方案，该方案以 Iceberg 为核心，其生态稳定，能提供强大的表管理与数据组织能力，支持大规模数据集高效处理，即便海量数据场景也可稳定运行，且生态集成良好，与主流大数据计算引擎（如 Spark、Flink、Presto 等）无缝对接，在腾讯云内部与 DLC、EMR 等大数据产品深度结合。
Iceberg 湖仓链路可以覆盖从实时流处理到离线批处理的完整数据链路，在腾讯云内部广泛应用于离线分析场景，因此腾讯云流式湖仓基于 Iceberg 设计。
回顾大数据链路发展，除离线链路外，许多客户都有实时链路需求。传统上，实时与离线业务客户常用 Lambda 架构搭建实时分析链路。在 Lambda 架构中，离线与实时链路分离，离线链路数据存储于 Iceberg 等离线存储引擎，后用 Spark 进行多层数据转换。在时效需求不高时，在数据规模支持与成本方面有优势。但随着实时场景增加，单一 Iceberg 方式难以满足业务需求，客户常采用 Flink 加 Kafka 方式构建实时分层链路，数据最终写入数据仓库或主流数据库（如 CK、Doris 等）。
此链路虽可实现秒级延迟，但存在诸多问题。
其一，灵活性低，Kafka 仅作数据管道，无法应用于数据探索、分析场景，且不能保存较长历史数据，限制用户使用灵活性，导致数据处理问题排查困难。
其二，成本高，实时链路单独存在，Kafka 与 Flink 对 state 维护及存储计算资源需求大，导致成本较高。
其三，对 update 场景支持不足，Kafka 写入非完整 change log 流时，后续接入 Fink 作业进行流式处理困难，虽 Flink 提供 upset Kafka 解决，但依赖本地状态存储，成本较高。
此外，Lambda 架构将离线与实时链路、存储及计算引擎隔离，相同数据需多次重复存储，实时与离线计算逻辑需单独开发，维护、管理及业务变更成本高，因此需要新的架构来统一实时与离线分析链路，降低成本。
基于此，内部调研了社区原生 Iceberg Upsert 表方案，发现其存在一些问题。如 Iceberg 通过 upsert 表写入数据时，产生的数据是无序的，数据管理面临挑战。基于 EQ DELETE 的数据合并机制，在 update 场景下会产生非常大的合并开销，无法满足高数据量与扩展性需求。且无法支持点查与部分列更新功能，不能满足维表 join 和性能优化的需求。同时，该链路缺乏生成 binlog 的能力，无法适应流式写入与流读场景，限制了其在实时链路中的有效性。
针对这些问题，我们设计了全新的流式湖仓架构。该架构引入了 LSM Tree来组织数据，解决数据无序问题。先排序再写入，确保高效的数据管理。Compaction 过程中生成逻辑日志文件，并引入了额外的元数据描述 LSM Tree 结构与日志文件关系。
该方案的优势包括，可生成完整 binlog，增强对实时数据流支持；LSM Tree 自身的合并特性，可以减少数据合并开销，提升系统性能；支持部分列更新与点查功能，为后续 state 优化与增量计算方案提供了基础。
基于 Iceberg 生态的流式湖仓解决方案，采用了 LSM Tree 进行存储管理，支持高效逐行更新场景，数据写入时通过增强数据合并优化效率，支持单行数据部分列更新，使用户能够精准管理数据变更，应对复杂业务需求。流式湖仓可在数据处理过程中生成完整的 change log 记录，为下游（如 Flink）提供支持，使增量处理与实时数据流管理成为可能。下游 Flink 作业可基于变更记录生成下一层数据，实现流式数据的高效管理。整体方案增强了数据的实时性与灵活性，提供了一体化流式湖仓体验。
从整体架构看，流式湖仓方案基于开源 Iceberg 生态建设，天然支持 Iceberg 兼容能力。如上图所示，蓝框部分为普通 Iceberg 写入，Flink 写入数据并生成快照时生成 Iceberg 元数据。
腾讯云流式湖仓写入流程中，数据除先排序外，格式与原生 Iceberg 相同，生成原生元数据时，同时生成两份元数据。一份是调用原生 Iceberg 包生成的兼容元数据，与开源 Iceberg 社区完全一致，支持 Iceberg 主要功能（如影视分区、schema 变更、partition 变更等）及所有版本系统高效支持；另一份是湖仓原生元数据，包含 LSM tree 结构与逻辑日志文件等原生不支持信息，支持额外性能优化与流读场景。借助数据合并能力，生成的 Iceberg 表不含 EQ DELETE 记录，可高效读取。
支持用户基于 Iceberg 原生客户端数据写入能力，实现无缝集成与多数据源接入。其原理为客户通过原生客户端写入数据后，先在兼容元数据版本中生成新快照记录，系统定时任务或下次数据提交时，通过冲突检测识别新提交快照中的新增数据文件，提取并重新排序插入 LSM tree 的 L0 层，在兼容与流式湖仓元数据中重复提交，分别生成完整 snapshot 实现数据的正式提交。
基于 LSM Tree 的流式湖仓在写入过程中进行数据合并操作，确保数据准确有序及一致性，为后续数据读取提供性能保障。整体采用 universal compaction 策略平衡读写放大，保证全局有序并减少文件数量。
数据从 L0 层首次合并至 L0 层以上时，系统查询现有文件中相同组件前值，与新写入值合并生成 binlog，更新现有 pos deletion 记录。为提升合并性能，引入了索引定位数据位置，并且在本地增加了热点文件缓存，以提升索引与合并性能。
支持 pos deletion 合并与更新，优化数据更新性能，系统支持内置与自定义值合并函数，应对不同业务需求，并实现了部分列更新与点查能力，丰富数据链路处理能力，满足复杂场景需求。
除数据合并外，流式湖仓在数据并发提交方面也有实现。数据文件写入后，流式湖仓通过提交生成众多源数据文件，在提交部分进行了并发提交优化，以提升性能。对比传统 Iceberg 单一节点完成 snapshot 生成，流式湖仓采用两阶段提交流程。多 bucket 需要提交时，commit 算子并行完成所分配 bucket 源数据文件更新与历史文件合并操作，生成 bucket 级别的元数据文件后，由全局 global committer 算子完成快照生成。此设计在 bucket 较多时可显著提高数据提交性能，避免数据提交过程中的 OM 情况，保证高效数据处理。同时支持多流写入同一表，多个数据流可同时写入，结合部分列更新能力，实现类似多流 join 的效果。多流写入同一表时，每个流写入并提交，需保证写入快照可序列化，采用基于 sequence number 的冲突检测与提交重试机制。每次提交时，若发现更新快照，对应流需合并之前提交文件变化与最终快照并重新提交，确保数据一致性。此提交创新提高流式湖仓高并发场景性能，为用户提供灵活高效的数据管理体验。在该场景下，一般采用多流单流 compaction 方式实现数据合并，避免多流 compaction 冲突，优化数据合并与整理过程，保证数据高效存储与快速访问。
在 CDC 优化方面，CDC 入湖是流式湖仓架构关键部分。流式湖仓架构中，客户先将业务数据同步至腾讯云流式湖仓，CDC 是常用实时数据抽取方法，可及时捕捉原系统数据变化并传输至目标系统，保证数据实时性与一致性。在 CDC 过程中，提供整库同步能力，便于客户迁移数据库数据至流式湖仓，系统支持自动表结构变更，简化了数据同步管理操作，用户可轻松应对数据库 schema 调整。
具体实现中，CDC 采用高效 at-least-once 数据同步模式，即便网络波动或系统故障，也能确保数据至少传输一次，避免丢失，通过目标端 upsert 功能保证端到端一致性，即数据传输中重复时，目标端可通过 upsert 操作更新已有数据，避免冗余与不一致。
在存量数据同步阶段，进行了显著优化，通过改进同步机制，经内部性能测试，实现了与开源相比 10 倍以上性能提升，体现在数据传输速度与系统资源占用上，同步大规模数据时可显著减少系统延迟与资源占用。
总体而言，CDC 场景优化提升了数据同步效率与一致性，可为企业提供可靠的实时数据同步解决方案，从而更好地应对大规模数据管理与分析需求。
腾讯云流式湖仓的主要优势包括：
其一，统一存储，可简化离线与实时两套链路架构，打破传统 Lambda 架构数据存储壁垒，避免业务数据重复存储与不同引擎计算逻辑重复开发，通过统一数据存储与计算引擎可简化系统运维管理，降低运维成本。
其二，具有较强的实时处理能力，可生成完整 changelog，使流处理引擎（如 Flink）可对数据进行增量处理，保证实时数据实时性，基于 RSM Tree 引擎支持高效组件更新与部分列更新，以满足业务快速响应需求。
其三，数据访问灵活，基于开源 Iceberg 架构，与 Iceberg 生态完全兼容，支持无缝迁移现有 Iceberg 作业，支持 Spark SQL、Trainer、Presto 等多种查询引擎，可满足不同客户查询需求。
其四，性能优化，对大表数据提交流程进行了优化，提高了写入速度，采用高效分区策略，可减少存储空间，提高查询性能。
其五，成本低，通过实现存储与计算引擎统一，可避免数据冗余，降低企业成本。
三、腾讯云流式湖仓实践
腾讯流式湖仓方案广泛应用于多个行业与场景，如游戏、出行、教育、电商等。
以游戏行业为例，可实时采集玩家行为数据，反馈给开发团队，从而快速调整游戏内容、优化用户体验，通过实时湖仓增量处理数据，了解玩家偏好，推出个性化活动与推荐，增强用户粘性。
出行行业中，提供实时数据分析能力，监控交通流量与用户实时出行需求，动态调整车辆分配与路线规划，减少等待时间，提升服务质量，通过整合历史与实时数据预测需求高峰，优化调度资源配置，提升运营效率。
教育行业可在直播场景下跟踪学生学习进度，基于数据提供个性化教学建议。
电商行业通过流式湖仓帮助商家分析用户画像，实时监测行为数据，调整推荐算法与营销策略，快速适应市场变化，优化促销活动。
在基于腾讯流式湖仓的游戏行业实时直播买量数据分析场景中，用户链路为通过 Flink 或 Spark 将业务数据导入腾讯流式湖仓并实时整合。如玩家在游戏直播中点击、下载等互动行为数据与游戏分类等相关数据实时汇总，通过流式湖仓架构实时收集并分析。用户行为数据聚合到 ODS 层，小文件合并等治理操作可以保证查询准确性与高效性。流式湖仓的每一层可通过 Doris 关联外表进行 OLAP 分析，实现数据多次复用，也可通过 DRC、MR 中的 Spark、Presto 等引擎进行离线业务报表计算。
通过该案例可以展现出腾讯云流式湖仓的诸多优势，如灵活的数据写入与高效管理。直播中用户互动数据以实时或批量方式同步，系统根据业务需求灵活处理不同更新频率。批量数据写入时，Iceberg 可自动完成小文件合并等优化操作，确保系统性能不因小文件过多而下降。还可进行实时聚合与多维分析，ODS 层聚合数据通过流式湖仓生成 changelog，经 Flink 进一步处理，如游戏直播下载与点击数据与用户信息、游戏分类等维表关联生成宽表，实现更深入实时分析，监控用户行为趋势，优化广告投放策略与直播内容，同时也可以通过部分列更新能力提高系统效率。此外，多层数据复用与灵活查询，在流式湖仓架构中的每一层可多种方式分析计算，全面复用链路数据，如分析直播中历史行为数据，用 Spark 引擎离线处理并决策分析。最后，统一存储简化了大数据管理，实现了成本控制，游戏行业需实时响应用户行为与离线分析历史数据，传统架构较为复杂，而流式湖仓实现了离线与实时链路统一，可避免重复存储与复杂系统维护。
针对车企与出行行业的车联网场景，需要分析运行过程中的车机信号，这些信号由车辆传感器上报，可能分批次上传，涉及大量数据更新操作。
客户早期使用传统架构，采用 HBase 加 Hive 链路，HBase 用于快速检索，满足车辆上报场景下对单辆车特定信号快捷分析需求，但保存数据有限，无法长期管理；Hive 用于离线分析，生成全面历史性报告，但分析延迟高，只能达到小时级。
客户痛点为储存成本高，同一数据在 HBase 与 Hive 中重复存储，受系统储存性能限制，成本较高；另外，时效性不够，基于 Hive 的离线分析在车辆运行出现问题需快速了解分析结果时，延时较高。
引入腾讯云流式湖仓方案后，数据采用 Iceburg 统一存储，既具备传统 HBase 按 key 查询的能力，又可以满足实时检索需求，也可实现离线分析能力，从而降低数据储存成本。流式湖仓还可实现实时增量计算，支持生成 binlog 能力，系统可以捕捉数据实时变更，将计算逻辑转换为增量计算，数据上报时无需等待批量处理结束，即可实时计算更新分析结果，提高分析实时性，在紧急业务场景（如故障发生）下可分钟级获取分析结果，未来有望优化至秒级。同时，系统管理优化，统一存储与计算。
四、腾讯云流式湖仓发展规划
最后简单分享一下后续发展规划。
腾讯云流式湖仓基于 Iceberg 生态系统，除了 Iceberg 之外，市面上还有其它一些优秀的湖格式。我们后续会考虑兼容 Paimon，通过 Paimon Adapter 写入腾讯云流式湖仓中。同时会在稀疏数据场景、数据提交、合并检索加速等方面提供额外的优势。
后续还将支持秒级延迟秒级可见，支持二级索引，并考虑为流式湖仓提供专有 API 与完善的生态。
五、Q&A
Q1：数据存储问题：车联网场景中，热数据和冷数据是如何存储的？
A1：目前均统一存储在 Iceberg 中。
Q2：链路延迟评估：每个阶段为保证准确性，链路延迟大概是多少？
A2：具体时间暂无法给出，但在车联网客户使用场景下，相比之前链路，延迟性能更优。
Q3：并发度及解决方案：车联网或其他场景的并发度如何？如何解决高并发场景问题？
A3：高并发场景下，我们对提交部分进行了优化。传统 Iceberg 用单节点生成 snapshot，我们采用两阶段提交流程。多个 bucket 提交时，先并行完成 bucket 元数据文件更新与历史文件合并，生成 bucket 级元数据文件，再由全局 global committer 完成快照生成。此设计在 bucket 数量较多时可提高写入性能，避免并发高导致的 OM 情况。
Q4：计算性能对比：计算过程中，使用 Iceberg 与 Spark 本身计算在性能对比（查询效率、内存使用、CPU 使用等）方面的情况如何？
A4：目前产品处于内测与标杆客户落地阶段，性能数据暂不方便提供。后续产品上线后，将基于市面上所有湖格式在基础场景上进行全面性能对比，届时可关注。
Q5：私有化部署能力：这套能力能否在私有化部署中获得？
A5：可以。最初在公有云产品上线，已通过客户落地，后续计划将场景下沉到私有化部署中，可实现完整 1:1 对应。
Q6：Iceberg 与 Paimon 相关问题：湖格式中，Iceberg 部分列更新特性及与 Paimon 的对比，以及流式湖仓对 Paimon 的支持计划如何？
A6：最初选择 Iceberg 后发现其部分问题，在现有架构中已补齐列更新、检查、流读等能力。Paimon 推广较多，客户有使用需求，计划在明年年初或今年年底兼容现有 Paimon 格式，并针对 Paimon 与 Iceberg 后续发展进行功能更新。
