字节跳动云原生大数据发展之路
如果无法正常显示,请先停止浏览器的去广告插件。
1. 字节跳动云原生
大数据发展之路
余炜强
火山引擎云原生计算架构师
2.
3. 自我介绍
• 2015-2022 美菜网营销数据中台、推荐平台负责人
• 2022-2023 字节云原生计算架构师 ,负责云原生大数据横向架构
4. 目 录
01 01 字节云原生大数据背景
01 字节云原生大数据实践
01 未来发展
02
03
5. 01
01
字节云原生大数据背景
6. 字节云原生大数据背景
• 已有的基础
大规模
高性能
稳定
定制优化
EB级存储,TBps级实时流量, 千万core资源调度
• 面临的问题
运维负担大
运营能力弱
业务接入复杂
成本压力大
• 技术趋势
实时化
智能化
存算分离
云原生化
安全合规
产品一体化
7. 字节云原生大数据背景
云原生大数据构建思路
规模化 => 实时化
垂直化 => 整合化
中心化 => 分离化
平台化=>智能化
敏捷构建=>标准增强
• 大规模实时计算 • 统一云原生存储体系 • 混合云能力 • 大数据+人工智能 • 成本优化
• 大规模存储能力 • 统一容器调度体系 • 多云资源管理能力 • 可分析 • 安全合规
• 极致实时优化 • 一站式大数据平台 • 统一的基础架构 • 可预测 • 数据治理体系
• 实时处理 • 流批一体化 • 轻量化 • 可优化 • Serverless化
• 实时分析 • 离在线一体化 • 高内聚低耦合 • 智能优化 • 解决方案
• 实时生效 • 软硬件一体化
• 多模数据体系
• 智能运维
8. 01
02
字节云原生大数据实践
9. 字节云原生大数据实践
大数据存储
多云资源纳管
大数据高性能实时读写
支持实时横向伸缩,应对实时突发过载。
支持多种存储介质和存储底座。纳管 低延迟读写,端到端读延迟< 30ms, 写延
不同环境的存储资源。 例如:ssd, 迟 < 100ms.
硬盘,远程磁盘,对象存储……
低存储成本
Serverless模式 分级存储, 自动将冷数据用底层本
支持多租户的资源隔离和权限隔离 存储介质进行存储。
10. 字节云原生大数据实践
大数据存储
•
•
•
•
可以纳管EB级别数据
热点无法快速扩容
状态重、重启慢、迁移难
故障恢复时间⻓
•
•
•
•
快速横向扩容
无状态、重启快、迁移易
跨机房负载不均
整理资源利用低
•
•
•
•
对中间件做专⻔优化
感知数据和机房依赖
全局资源优化
成本低资源利用率高
11. 字节云原生大数据实践
大数据存储-CloudFS
• 元数据单集群读写: 水平扩容
• 顺序写: 接近存储介质性能
• 顺序读: 有缓存 900MB/s,
存储
引擎
无缓存接近存储介质性能
• 单集群inode 数量: 10billion!100billion
• Block映射数量: >= 300billion
• 多级存储自动优化存储成本
• 兼容HCFS
数据
底座
12. 字节云原生大数据实践
多云高可用容灾
运行时服务
离在线一体
离线在线资源调度一体化。 共享资源,
支持多云容灾调度,为大数据作业 降低流量潮汐带来的资源浪费。运维、
提供有效的容灾支持。 秒级容灾恢 管控面服务统一,降低维护成本。
复,保证大数据作业稳定运行。
资源弹性
多租户资源隔离 快速应对大流量过载, 提高离在线
支持多租户的资源隔离 资源转化效率,为重大活动场景提
供坚实的技术支撑
13. 字节云原生大数据实践
云原生进程解决的问题和痛点 统一资源湖方案
•可以做到资源跨机房弹性
•人工管理数据、应用、网络依赖,复杂且困难
•弹性受到应用依赖和机房容量上限制约
•资源碎片多整体利用率低 •统一的资源管理,运维和管理成本低
•离在线一体化调度,平滑迁移传统大数据应用
•可以跨机房、跨集群、跨群快速转化资源
•全链路资源优化,资源利用率高
14. 字节云原生大数据实践
运行时服务
15. 字节云原生大数据实践
大数据计算引擎
一站式大数据平台
支持开发、调试、运维、调度,
Olap数据治理等一站式大数据服
务。
多租户资源共享
资源共享带来更低成本。无状态多
租户共享的离线开发和交互式开发
平台。 多租户共享底层计算存储资
源
统一元数据服务
支持湖仓一体、流批一体化、大数
据AI一体化,多数据源管理的统一
元数据服务。
开源增强特性
为开发、运维、快速故障恢复、弹
性扩缩、资源管理等提供企业级增
量能力。
16. 字节云原生大数据实践
• 产品体系复杂
• 学习成本高
• 互联互通难
• 数据治理难度大
• 运维管理复杂
• 产品运营复杂
• 产品体系简单
• 学习成本低
• 数据/工具互通
• 统一数据治理
• 运维管理简单
• 产品运营简单
17. 字节云原生大数据实践
大数据计算引擎
18. 字节云原生大数据实践
大数据计算引擎
19. 字节云原生大数据实践
云消息引擎
即时弹性
高性能大规模读写
实时计算、在线应用都支持弹性扩 支持TB级别大规模数据读写,PB
缩。 消息引擎也需要支持即时弹性 级数据存储。
扩缩才能得到更好的资源利用。
秒级容灾恢复
作为实时计算和在线应用的基础中
间件,应当支持秒级容灾恢复,减
少故障恢复带来的业务损失。
兼容开源+流批一体
兼容Kafka协议,支持大数据量存
储, 同时支持流式读取和批式读取
20. 字节云原生大数据实践
存算分离架构-对比Kafka
重启时间
• Kafka: 5~10分钟
• ByteMQ: 15秒
运维复杂度
•
•
•
•
Kafka: 人工恢复broker
Kafka: 数据容量管理
ByteMQ: 自动秒级容灾恢复
ByteMQ: 近乎无限数据容量
扩容对比
• Kafka: 2~7天
• ByteMq: 1分钟以内
21. 字节云原生大数据实践
云消息引擎
22. 字节云原生大数据实践
云消息引擎
23. 字节云原生大数据实践
大规模存储支持
支持PB级别数据存储,单集群支持
百万分片,引入写入均衡技术。分
钟级数据恢复。高性能高压缩算
云搜索
稳定性增强
支持熔断限流,支持丰富熔断策略
和query级别熔断覆盖大部分异常
场景。
法。
高性能大吞吐
企业级运维支持
支持从hive/hdfs外部构建,低资 支持全链路监控,支持存储计算
源占用10倍写入速度。支持物理复 资源运维、集群运维。Query诊断
制。支持模糊查询、向量化查询, 和管理。
高性能点查,语义增强。
24. OpenSearch 内部使用介绍:海量实时数据场景
使用场景: 主要痛点:
全文检索的日志场景 a)高吞吐量环境下的写入瓶颈
搜索场景 b) 读写资源争用导致查询缓慢
分析场景 c) 大数据量下的资源利用和成本
海量实时数据写入
OpenSearch 集群规模
700+集群
9000+节点
单集群最大700+节点
2PB 数据
截至:2023年02月
25. OpenSearch 产品实践:持续优化投入和演进
1. 海量实时索引的外部构建,Mini Batch Loader 大规模应用
主要痛点:
a) 高吞吐量环境下的写入瓶颈
b) 读写资源争用导致查询缓慢
c) 大数据量下的资源利用和成本
低 CPU 消耗单节点 3w QPS
低CPU消耗单节点 增加 10倍+ QPS 写入
2. 单集群百万分片性能优化,全链路观测保障查询实时可视化
元数据更新吞吐低且内存压力大
性能优化,读写隔离,诊断慢 Query
3. 服务云原生化:基于 K8s 打造 Serverless 的 OpenSearch
频繁扩容,重复构建索引资源浪费
写入资源外置,资源可以弹性管理
未来1-2年,字节内部系统将计划全部从 Elasticsearch 迁移到 OpenSearch
26. 字节云原生大数据实践
云搜索
27. OpenSearch 产品增强特性:读写性能优化
ZSTD 压缩, 读写性能
不变,降低存储成本
写入
30%
降低
30%
默认
压缩
ZST
压缩
开源软件多层聚合场景下,
序列化开销大的问题
查询
X
定向路由,对 Append-only
类型索引优化
√
写吞吐
提升30%
30%
集群 CP
负载下降30%
读写性能优化
功能:
50%
协调节点单 Query 级别
熔断(内存)
X
物理复制 V
原生 Document 复制
复制情况的写
吞吐提升50%
查询使用索引比纯匹配(不走索
引)的查询开销更大的问题;
针对字节内部海量数据场景,通过压
缩、资源调度、模型优化等,解决整个
数据处理链路中的性能瓶颈点。
价值:
解决开源软件在实际使用过程的问题,
√
并进行特殊的优化和增强,提升资源利
开源
软件
GroupByAg
增强
开源
软件
特性
增强
原生
Terms 开销
Byte_Term
开销
用率,降低使用成本。
28. –
GIM S
Quota
GPM S
GRO
GWS
GAS
Gateway
–
Flink
Serverless
M LP- Spark
Serverless
BM Q
OpenSearch
CloudFS
HDFS
TOS
-
Helm Chart
- VKE/ VCI
– veStack
/
K8s
大数据平台现存痛点 云原生计算价值点
•大数据架构复杂,使用成本高;
•传统大数据部署方式资源使用效率低,运维不够便捷;
•实时场景多,传统的数据开发不能满足实时要求。 •一站式大数据管理平台,支持实时和离线计算,便捷的运维开发;
•基于云原生技术部署,高效的资源管理和调度,提升资源利用率;
•字节跳动深度优化的实时计算链路,提供消息队列—>实时计算—>实时
服务的全链路场景。
29. 01
03
未来规划
30. 字节云原生大数据未来
• 流数仓
• 软硬件结合(RDMA、NVM)
• Serverless演进
• 更好的弹性
• 更低的成本
31. 技术交流请扫码!
32.