inicio tema library logo biblioteca mío
más

微信云原生大数据平台构建及落地实践

如果无法正常显示，请先停止浏览器的去广告插件。
分享至：
1. 微信云原生大数据平台构建及落地实践 腾讯-微信技术架构部 / 涂小刚
2.
3. 主要内容 一、大数据上云概述 三、稳定性及效率提升 1. 为什么大数据要上云 1. K8S 集群稳定性与弹性配额 2. 微信大数据平台架构演进 2. 可观测性与智能运维 二、大数据上云基础建设 1. 统一编排 2. Pod 设计及大数据配套能力 3. 计算组件云环境适配
4. 一、大数据上云概述 1. 为什么大数据要上云
5. 基础设施的变迁 • 物理机 -> 云主机、云盘、云网络 • 存算一体 -> 存算分离 • 单一集群环境 -> 多种集群环境（专用、离在线混部、 GPU）
6. 业务对平台个性化需求 • 业务灵活定制计算框架 – 自研或基于tensorflow、mpi 等二次开发 • 支持多种计算模式 – CPU 计算 – GPU 计算 – CPU & GPU 混合计算
7. 业界大数据资源平台发展演进 IDC时代 云时代 Why K8S？ • • • • 灵活高效的容器编排、插件扩展能力 计算存储分离，互不影响，各自按需弹性扩缩容 大数据及 AI 框架几乎都原生支持，无需侵入式改造，可以灵活适配 运维成本低，应用层无需要运维介入
8. 一、大数据上云概述 2. 微信大数据平台架构演进
9. 早期微信大数据平台架构 任务 调度 Web / API Spark 计算 组件 Shell Hadoop PyTorch MR Pytho TensorFlo n w 资源 调度 自研资源调度平台 存储 自研存储/HDFS 优势： … MPI • 自研调度和存储，自主可控 • 充分利用在线闲时段资源 不足： • 各模块组件高度耦合 • 侵入性对接开源计算框架，开发迭代慢 • 运维成本大 最初是为了 在线微服务 设计，当时 还没有k8s
10. 微信云原生大数据平台架构 应用 平台 任务 调度 扩展 组件 原子级 框架 PAAS BI / 画像 / 机器学习 / AB实验 API 工作流调度 MR DistC P Spark 大数据专用 Spark SQL Flink 虚拟机 业务定制 PyTorc h TensorFlo w 离/在线混 部 运营管理 Flink SQL 算力 GPU TKE (K8S) IAAS @since 2020 云盘 Pulsa r MPI HDF S • 高效的任务调度 • 资源管理 & 弹性资源 & 智能运维 … • 不再有Hadoop，相关组件使用Spark实现 • 集成丰富的功能组件并支持业务扩展 Job • 云原生适配开源主流计算框架 • 自研通用 Job 框架，支持无状态批处理 COS • 资源编排基于 K8S，多种集群环境 • 打通适配多种分布式存储 云网络 灰色部分为云上设施和能力
11. 二、大数据上云基础建设 1. 统一编排
12. 业界计算框架接入 K8S 方案不统一 • Spark – Spark on K8S Native: 框架自带，版本要求 >=2.3 – Spark Operator: 开源生态 • Flink – Flink on K8S Native: 框架自带，版本要求 >=1.12 – Flink Operator : 开源生态 • TensorFlow / PyTorch / MPI – KubeFlow Training Operators
13. Native VS Operator Kubernetes API Kubernetes API CR Core CRD Master master Pod worker Pod Master worker Pod Controller Node Node Kubernetes Kubernetes Operator Native • • • 框架直接与 api server 交互，控制 pod 的启停 优点：可以根据计算特点实现动态申请资源 缺点：提交端要负责任务生命周期管理、权限管理等 • • • 自定义crd，声明式接口，由 controller 管理生命周 期 优点：对提交端更友好，只管提交和同步状态 缺点：不能实现动态分配（可以跟native结合使用）
14. 如何接入？ … 任务提交 CR CRD Master 只需要负责提交以及状态跟踪 Service Controller ConfigMap Workloads Node Deployment StatefulSets Job Pod … Kubernetes 为了简化提交端逻辑，所有框架的应用（作业）通过 Operator 声明式 API 接 入
15. 不同框架 case by case 接入 任务提交 … • • Spark Operator spark app spark app Flink Operator flink app flink app TensorFlow Operator tf job tf job MPI Operator mpi job mpi job … … … 提交端需要分别对接各种框架的接口 具有共性的功能需要在各个operator里分别实现一遍
16. 统一接入 - All in One … 屏蔽不同框架的差异，透明接入 • • 任务提交 BigData Object Spark Operator spark app spark app Flink Operator flink app flink app TensorFlow Operator tf job tf job MPI Operator mpi job mpi job … … … 任务提交端只需要对接 bigdata operator 具有共性的功能统一在 bigdata operator 里做
17. 统一接入 - All in One … 任务提交 BigData Object 屏蔽不同框架的差异，透明接入 • • 进一步整合，编译到一起 方便跨集群环境部署 Spark Operator spark app spark app Flink Operator flink app flink app TensorFlow Operator tf job tf job MPI Operator mpi job mpi job … … …
18. BigData Operator CRD # 框架Operator本身的 CRD 规 格 # 统一所有框架应用的运行状 态 对所有框架的运行状 态判断逻辑一致，简 化任务提交端的逻辑
19. 提交超时控制 pending … 任务提交 pending pending 编排超时时间控制，超过阈值则失败，并给出失败原因 Controllers Mutating Admission WebHook BigData Operator
20. 资源回收加强 运行结束的作业，Service 资源不会被回收 ！！！ JobManager Deployment driver headless svc JobManager svc driver svc executo r executor ps-0 TaskManager Deployment Job Submitter tb svc worker-0 worker-1 Controllers Mutating Admission WebHook BigData Operator 1. 2. 任务结束，主动回收 Service，释放IP资源 TTL 配置，一定时间后回收整个任务的资源（delete）
21. hostNetwork 网络适配 使用 hostNetwork 时，同一个节点不同业务端口冲突 ！！！ Node Spark-1 driver-pod Spark-2 driver-pod 冲突 Why hostNetwork？ Flink-1 JobManager- pod Flink-2 JobManager- pod 冲突 TensorFlow-1 worker-pod TensorFlow-2 worker-pod Web UI Port: 4040 RPC Port: 7078 冲突 Web UI Port: 8080 RPC Port: 6123 Blob Port: 6124 Server Port: 2222 TensorBoard Port: 6006 1. Pod 调度量大，容器网络 ip 不足 2.容器网络网络传输效率低
22. hostNetwork 网络适配 预分配端口，利用 K8S Pod 反亲和调度避免冲突 随机预分 配端口 从系统可用端口范围中随机分配端口 Spark-1 driver-pod 可调度 Node 1 分配 port：62222, 62225 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: 注入Pod反 topologyKey: kubernetes.io/hostname matchExpressions: 亲和配置 - key: xxxPort operator: In bigdata operator 编排 values: - " xxx" … Spark-2 driver-pod 违反 pod反亲和 分配 port：62222, 63030 Spark-3 driver-pod 分配 port：61020, 62225 可调度 Node 2
23. 二、大数据上云基础建设 2. Pod 设计及大数据配套能力
24. 大数据及 AI 多集群环境下 Pod 设计 BigData 独立集群 混部集群/ 算力GPU集群 （稳定性要求高的任务） Node （离线或者GPU训练） Node 业务 Pod 业务 Pod initContainer initContainer Spark / Flink / TensorFlow / … Container hostIPC OssAgent Pod hostNetwork hostPath ClusterAgent Pod Spark / TensorFlow / … Container OssAgent Container ClusterAgen t Container hostNetwork … 以 DaemonSet 方式将辅助 agents 部署到每个节点 上 最小化公共组件的成本，最大化机器资源利用 业务和 agents 以多容器方式运行在同一个Pod 业务之间尽可能完全隔离，充分利用机器空闲资源
25. 使用 initContainer 解耦平台与业务 业务更灵活，平台更稳定 大数据类：Spark、Flink AI 类：TensorFlow、 PyTorch 用户只需提供业务 Jar 包即可，运行环境平台统一提供 运行环境千变万化，平台只提供公共能力，核心运行环境由用户提供 Pod Init-container （平台提供镜像） Pod Init-container（平台提供镜像） 挂载主机临时目录 pod销毁时自动回收 empty dir 挂载主机临时目录 pod销毁时自动回收 empty dir 业务容器（平台提供镜像） 业务容器（用户提供镜像） Init-container： Init-container： 拷贝用户 Jar 和依赖到挂载目录 - hdfs://xxx/path/to/jar 1. 拷贝 hadoop 等基础库到挂载目录 2. 拷贝启动脚本 entrypoint.sh（安全启动） 到挂载目录 • 业务容器启动命令：/xxx/entrypoint.sh user_cmd
26. 运行日志持久化 业界常规做法 ELK 的不足 ！！！ 可以查看 运行中 pod的日 志 Pod 销毁 后无法查 看日志 ！ Web 系 统 Node Flink pod Spark pod kubelet … Node 业务 pod 业务 pod LogAgent … Kafka ES/Kiba na 1. 2. 3. 4. … 检索 分析 可视化 告警 Node Spark pod Flink pod kubelet K8S cluster ELK 的不足： 1. 日志量大， agent 实时采集上报，会占用较多宿主机资源 2. 整套方案太重且成本昂贵 （流量、存储、查询、维护等多种费用）
27. 运行日志持久化 实现一套轻量级的大数据作业日志系统 Web 系 统 运行中，直接通过 k8s 拉取日志展示 Node 监听本机Pod 容器退出事件 … Flink pod Spark pod LogBackup kubelet 运行结束，从 cos 拉取日志展 示 COS bucket ├── cluster │ ├── namespace │ │ ├── pod-name │ │ │ ├── container- name │ │ │ │ ├── stdout │ │ │ │ └── xxx.log └── xxx Node Node 上传 Pod容器日 志 按一定的路由规则组织: Node K8S cluster 优势： 1. 足够轻量，日志上传频次低，几乎不占用 系统资源 2. 成本低，只有对象存储的成本，相比 ELK 可忽略不计
28. Application UI 外部访问 业界常规做法不够灵活 ！！！ 办公环境 Cloud Provider LoadBalanc er Kubernetes Ingress Spark Application Flink Application 缺陷： 1. 只能静态配置路由规则，然而每个作 业是动态生成的 2. Spark UI 的静态资源（css, js, png, …）无法加载 TensorBoard
29. Application UI 外部访问 动态路由，无需维护 ingress DN S Cluster A Cloud Provider LoadBalanc er NGINX Spark Application 办公环境 Flink Application http://spark.x.y/a/b a集群 + b账号 + c应用 /c/ http://flink.x.y/a/b/ c/ http://tb.x.y/a/b/c/ Cluster B 根据集群动态转发 TensorBoard Spark Application Cloud Provider LoadBalanc er NGINX Flink Application 基于nginx动 态转发规则路 由到不同的作 业 TensorBoard
30. 二、大数据上云基础建设 3. 计算组件云环境适配
31. Spark 外置 Shuffle 服务云原生适配 • 社区 Spark on K8S 无外置 Shuffle，容错能力不足 Executor - 1 Map shuffle write Shuffle Server shuffle read Reduc e Executor - 2 Map shuffle write Shuffle Server Why not ? Node Node Executor Executor Map shuffle write Reduc e shuffle read Reduc e shuffle read Map shuffle write shuffle read Reduc e 内置 Shuffle Executor 挂了之后，shuffle 数据也丢了，需要重新跑 map Shuffle Server Shuffle Server 外置 Shuffle Executor 挂了之后，Shuffle 数据在节点上，map 没有 白做 云环境下，shuffle 磁盘不定，所以社区没有给出统一解决方 案
32. Spark 外置 Shuffle 服务云原生适配 • 友商做法：Remote Shuffle Service Executor Map shuffle write Reduce shuffle read Shuffle Server 不足： Shuffle Server 1. shuffle 网络开销大，中小作业性能有损耗 2. 部署运维成本高，中心化服务，有问题影响面大 Shuffle Server 使用存储型机器，单独部署分布式 Shuffle Service 可弹性扩缩容，超大 shuffle 无爆盘风险
33. Spark 外置 Shuffle 服务云原生适配 • 方案：External Shuffle Service 上云 挂载 增加磁盘保护 功能，写到一 定阈值主动 fail容错转移 Node Executor Executor shuffle write Map 挂载 Reduc e Reduc e shuffle read External Shuffle Service 挂载 Map shuffle write shuffle read DaemonSet External Shuffle Service 自动清理已 完成作业的 shuffle数据 可按需挂载云盘 到宿主机，实现 磁盘可扩展 挂载 优势： 1. 稳定可靠，部分节点故障不影响整个集群 2. 部署运维成本低，磁盘可弹性扩容，按量算成本
34. Hadoop 工具组件上云 Hadoop- Streaming 没有 Hadoop Yarn 如何使用？ Hadoop-Distcp 平替 Spark-Pipe Spark-Distcp … Hadoop 所有工具本质都是基 于 MapReduce 实现，其功能 完全也可以通过 Spark 实现
35. Flink 流计算弹性伸缩 Web / API TaskManage r 调整 deployment replica 缩容 JobManager TaskManage r 伸缩期间 Job 重启， 节省重新申请资源的等 待时间 TaskManage r 扩容 JobManager Deployment # 使用 flink adaptive 调度器 jobmanager.scheduler=adaptive Deployment JobManager Deployment
36. 三、稳定性及效率提升 1. K8S 集群稳定性与弹性配额
37. K8S master 组件稳定性优化 任务提交 流水线提交， 限制并发 1. 资源配额拒绝 2. 负载感知，快速拒绝 Controller WebHook 指标收集 Etcd (核心数据) 核心数据 分离 kube-apiserver kubele kubele kubele t t t promtheus/metric-server BigData Operator 全方位的平台组件治理： • Etcd 核心数据分离 • 任务调度流水线提交 • Operator 限流 Etcd (event) 使用 ssd
38. 弹性配额 将quota限制从 admission control 迁移 到scheduler 中，在调度 过程中进行quota 判断 当账号A下有更多 的请求过来时，则 强制回收其他账户 借用的资源
39. 三、稳定性及效率提升 2. 可观测性与智能运维
40. 可观测性建设 指标 同步 全方位指标收集及监控 • 接入内部告警系统 • 持久化 event
41. 智能运维 异常通知 多维监控系统 数据拉取 节点、容器 指标上报 外部 系统 运行 指标 运行 环境 运行指标上报 异常及归因 K8S 集群 归因与建议 计算任务 操作调整 移动端处理 调度与调整 任务调度平台
42.

inicio - Wiki
Copyright © 2011-2024 iteam. Current version is 2.129.0. UTC+08:00, 2024-06-29 18:49
浙ICP备14020137号-1 $mapa de visitantes$