一、架构总览二、项目亮点2.1 架构选型解决 Lambda 架构痛点维度传统 Lambda 架构Paimon 流批一体架构改善幅度存储实时表 离线表分开~20 张冗余表统一一张 Paimon 表表数量减少 60%查询需合并两份数据逻辑复杂下游直接查一张表查询链路缩短 50%口径实时/离线一致率 ~92%修正后 100% 一致口径问题归零维护成本两套链路、两套代码~40 Flink 任务共享存储各自写入~25 个任务任务数减少 35%2.2 分层修正的数据质量保障机制 *设计了完整的逐层修正触发链路修正覆盖率 100%修正完成时间 T1 06:00前2.3 查询层架构设计Paimon 做统一存储Doris 做 OLAP 加速查询Paimon 负责流批写入、snapshot 隔离、changelog 产出Doris 通过 Catalog 直接读取 Paimon 数据提供高性能聚合查询查询性能单表聚合查询 P99 1.5s并发能力支持100 QPS的 OLAP 查询满足看板高峰期需求2.4 成本收益指标改造前改造后收益系统运维成本4 套Hive Kafka ClickHouse ES2 套Paimon Doris运维成本降低 50%存储成本月~15TB 冗余存储~9TB节省 ~40%数据链路故障率月均 3-4 次口径不一致告警月均 0-1 次故障率降 80%三、难点与解决方案3.1 小文件问题 *问题描述Flink 流式写入 Paimon 时每个 checkpoint 都会产生新的数据文件。写入并发高时短时间内产生大量小文件单文件 KB~几 MB 级别严重影响下游查询性能。影响Doris 查询 Paimon 表时 P99 延迟从预期 3s 飙升到 10sHDFS NameNode 压力增大解决方案① 减少文件产生频率— 调整 Flink checkpoint 间隔-- 从 1min 调整为 3min每个 bucket 产生文件的频率降低 3 倍SET execution.checkpointing.interval 3min;② 自动 compaction— 配置合并触发阈值-- 单个 bucket 积累 5 个文件时触发异步合并compaction.min.file-num 5,-- 合并后文件数不超过 10 个compaction.max.file-num 10,-- 合并后单文件目标大小 256MBcompaction.target-file-size 256MB③ 定时 full-compaction— 兜底清理未触发自动合并的 bucket-- DolphinScheduler 每小时调度一次强制合并全表CALL sys.compact(db_name.ad_traffic_detail);④ 快照清理— 及时释放已合并旧文件的存储空间-- 保留 5~10 个快照过期快照关联的旧文件自动删除snapshot.num-retained.min 5,snapshot.num-retained.max 10业务收益指标优化前优化后改善Doris 查询 P99 延迟8-10s1.5s降低 80%单分区文件数~500 个小文件~100 个减少 80%单文件平均大小2-5MB200MB提升 ~50 倍DWS 聚合任务耗时~15min~6min缩短 60%HDFS NameNode RPC高峰期告警正常水位压力消除3.2 流批并发写入冲突问题描述流任务 7×24 持续写入 Paimon 表批修正任务在 T1 凌晨对同一张表做 OVERWRITE两者并发时可能出现 snapshot 冲突write conflict导致某一方任务失败。解决方案利用 Paimon 分区隔离从设计上规避冲突时间线7月29日白天 → 流任务写入 dt 2026-07-29当天分区7月29日凌晨 → 批任务修正 dt 2026-07-28昨天分区流写当天批修昨天操作不同分区天然无 snapshot 冲突为什么有效Paimon 的 snapshot 冲突发生在同一分区被多个 writer 并发提交时流和批写不同分区各自独立提交 snapshot互不影响3.3 数据一致性窗口期问题描述从实时写入到批修正完成之间存在一个数据不够准确的时间窗口。业务侧如果在这个窗口内做结算或对账可能产生偏差。解决方案数据状态标记在表中增加data_status字段realtime— 实时写入未经修正corrected— 批修正后的最终值修正完成通知批修正任务完成后发送消息通知下游系统标记该分区数据已修正。3.4 Schema 变更与数据回填 *问题描述业务迭代中上游经常会新增字段如新增广告创意类型、投放策略标签等。在流批一体架构下一次 schema 变更会影响整条链路Paimon 表需要加字段— 表结构要跟着变流任务需要重启— Flink SQL 中要新增字段的处理逻辑重启意味着中断实时写入历史数据缺失新字段— 已写入的数据该字段为 null业务查询可能出错多层级联动— DWD 加了字段DWS 的聚合逻辑可能也要改核心矛盾改表和重启流任务期间Kafka 数据在持续产生但无人消费堆积越久恢复越慢。解决方案按是否需要修改 Flink SQL 逻辑分两种情况处理情况一新字段只需透传不涉及业务逻辑变更无需停任务利用 Paimon 自动 Schema Evolution-- 数据源配置开启自动 schema 变更schema-change.enabled true上游新增字段后Paimon 表自动加列流任务使用SELECT *或 CDC 全量同步模式新字段自动透传写入全程不停任务零影响情况二新字段需要参与计算/聚合必须改 Flink SQL需要重启任务通过 savepoint 机制最小化影响# ① 停任务并触发 savepoint一步完成记录 Kafka offset 和算子状态flink stop --savepointPath hdfs:///savepoints/ jobId# ② ALTER TABLE 加字段如果没开自动 schema evolution# ALTER TABLE ad_traffic_detail ADD COLUMN new_field STRING;# ③ 修改 Flink SQL加入新字段的处理/聚合逻辑# ④ 从 savepoint 恢复任务从断点 offset 继续消费不丢数据flink run -s hdfs:///savepoints/savepoint-xxx -d new_job.jar# ⑤ 任务恢复后自动追赶堆积数据追完后恢复实时学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】