小红书云原生实时数仓的建设与实践

1. 小红书云原生实时数仓的建设与实践 OLAP研发专家 / 王成

2.

3. 王成 • 2020年12月加入小红书大数据技术部 • 从0到1主导/负责小红书云原生实时数仓架构、落地与迭代工作

4. CONTENT • 背景：云原生落地前，使用ClickHouse遇到的问题和挑战 • 云原生 OLAP V1.0 建设之路 • V-next 湖仓一体建设规划

5. 分析型数据库(OLAP) 开源项目: 商业项目: ClickHouse Hologres …… ……

6. 云原生大数据架构 - 云上的原住⺠分析工具数据生产工具应用层 Dor Rugal Waypoint Vela Guanyuan 实时/离线引擎计算引擎层计算资源层 Tez Red Spark 数据分析 Flink Hive K8s Yarn Pavo 数据层 Parquet ORC Avro … 存储层 S3 OSS Gravity COS Alluxio Presto

7. OLAP的引入数据生产工具应用层 Dor Rugal Waypoint Vela 分析工具 Guanyuan Gravity UBA 实验平台实时/离线引擎计算引擎层 Tez 计算资源层 Red Spark 即席分析 Flink Presto Pavo 数据层 Parquet ORC Avro … 存储层 S3 Yarn K8s OSS 内容产品工具蒲公英 Norma 灵犀鹰眼 COS Alluxio ClickHouse StartRocks 独立的机器资源自有数据格式 SSD, HDD, 云盘

8. 实时数仓发展历程 10 月 01 月 05 月 V1.0 全面落地试水应用 ClickHouse 2019 自研云原生数仓立项 2020 11 月 2021 主要业务线 2021 07 月 2022 2022 + 11 月业务拓展自研云原生数仓 V1.0 湖仓一体 40+集群 10+业务线正式落地云原生数仓 V-next

9. 背景：云原生落地前ClickHouse 遇到的问题和挑战

10. 痛点:

11. 痛点: • 扩容周期⻓ • 需要额外的数据搬迁或重写 • 多副本机制引入的中心瓶颈

12. 扩容难 - 扩容周期⻓ - 手动的数据搬迁或重写 ClickHouse share nothing(无共享) 架构新增节点

13. 扩容难 - 多副本机制中心瓶颈 • ZK引入同步瓶颈，制约集群扩展 • 多副本 -> 成倍的成本 • 查询的一致性问题

14. 痛点: • 一致性问题 • 数据同步链路复杂

15. 数据同步难 - 数据同步链路复杂 • 同步链路复杂 • 数据写入影响用户查询体验

16. 痛点: • 资源利用率低 • 用户查询体验不稳定

17. 运维难 - 资源利用率低 • 集群容量预估困难 • 存储计算比例失调 • 业务需求呈现规律性的波峰谷振荡平均CPU使用率低

18. 运维难 - 用户查询体验不稳定用户查询体验不稳定 • 高峰查询期间失败率高 • 多用户/业务线互相干扰，无优先级管理

19. 解决方案：云原生问题: • • • 目标: 存算耦合 • 存算分离、弹性扩展资源隔离能力弱 • 提供更强的计算资源隔离能力 • 打破数据壁垒 • 支持事务和原子性数据同步成本高、一致性差

20. 自研云原生实时数仓的价值 - 灵活性：快速响应业务 - 自主可控：保障性能、稳定性、安全性 - 符合小红书多云战略

21. 云原生OLAP V1.0 建设之路

22. 云原生OLAP V1.0 数据源数据集成数据应用 RED ClickHouse 服务日志元信息中心离线多用户管理查询调度计算用户行为分析数据对象计算隔离弹性扩展 OLTP 数据流实时报表故障恢复容器化 A / B测试存储实时广告业务事务分桶冷热分层 aws/cos/oss 数据加速

23. 云原生存算分离架构元信息层元信息中心架构特性: 计算层查询路由器 • 共享元信息中心，共享存储计算组 - 1 • 基于云存储，按需使用，无限扩展 Master Server • 计算资源池化，以计算组为单位，弹性扩展计算组 N Worker 缓存存储层分布式文件系统对象存储 CFS / JuiceFS COS / S3 / OSS

24. 分布式执行框架 - 分布式写入事务

25. 分布式执行框架 - 分布式写入事务

26. 弹性扩容和故障容错

27. 分布式存储选型对象存储 —— 优点挑战 —— 缺点 • 价格低 • 延迟高 • 无限扩容 • 单点性能低 • 高并发 • 不稳定查询分析 • 查询性能慢 • 并行读取 • 查询受网络影响，成功率不稳定 • 断点续传数据摄入 • 亿级QPS数据无法实时写入 • 写入不稳定，影响数据一致性

28. 多级智能缓存 – 加速数据查询 READ READ • 被动缓存 • 主动缓存 WORKER • 元信息缓存 • 表级别自定义缓存策略内存缓存 • 基于查询历史智能缓存策略 WORKER ... SSD SSD HDD HDD 分布式缓存对象存储内存缓存

29. 海量数据实时分析 - 分层存储内存云盘对象存储延迟 *** ** * IOPS *** ** * 可靠性 * *** *** 扩展性 * ** *** 成本 * ** *** 写入云盘对象存储

30. 离线数据同步链路优化-优化前 Flink ODS / DW Parquet 对象存储 ClickHouse MergeTree 本地存储 BI

31. 离线数据同步链路优化-优化后 ODS / DW RedCK Sp ark 对象存储 Wr ite Attach r MergeTree BI

32. 总结数据摄入 • 存算分离 • 计算资源弹性伸缩 • 存储资源按需申请 • 千万级实时数据集成 => 分层存储 • 写入不稳定 => Exactly-once语义 • 数据同步链路⻓ => Spark MergeTreeWriter 查询分析 • 查询性能慢 => 多级智能缓存 • 关联分析瓶颈 => Bucket模型、数据本地化集群可用性 • 快速的故障自动恢复机制 • 分布式缓存，加速预热

33. 业务落地实践

34. 降本提效用户行为分析 A/B TEST 几十TB（月） RedCK PB +（年）几十 PB 年 100+ 99.9% 数据量存储时间节点数量查询可用性 ClickHouse 资源成本 - 磁盘 - 集群扩容 RedCK 相比开源Clickhouse，存储成本明显降低 - CP RedCK 通过弹性伸缩、集群整合，提升工作时效率 RedCK 通过容器化混合部署, 提升夜间使用率运维成本 RedCK 小于30mi 开源ClickHouse 以周/月为单位 - 集群故障：分钟级自动恢复

35. 实验平台 - 多租户管理路由规则 • 业务需求 • 查询类型在线查询重查询冷查询 • • • • 弹性扩容队列

36. 用户行为分析 – 海量数据实时接入

37. V-next: 湖仓一体建设

38. 为什么要湖仓一体化？ - 数据湖和实时数仓的数据是割裂的，造成了大量的存储和计算冗余 - 目前的实时数仓无法应对复杂ETL加工的场景 - 查询方式不同引入额外的使用成本

39. 湖仓一体

40. 开放的MergeTree格式 ETL ODS DW RedCK Sp Storage 融合分析 ark Wr ite Parquet Spark BI r MergeTree Presto Flink

41. 湖仓一体

42. 未来规划 • 持续推进湖仓统一建设 • 更丰富的引擎功能 • 自动敏捷的弹性伸缩机制

43. 欢迎关注微信公众号：小红书技术REDtech Q&A 小红书招聘

44.