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

微信云原生大数据平台构建及落地实践 腾讯-微信技术架构部/涂小刚 主要内容 一、大数据上云概述 1.为什么大数据要上云 2.微信大数据平台架构演进 三、稳定性及效率提升 1.K8S集群稳定性与弹性配额 2.可观测性与智能运维 二、大数据上云基础建设 1.统一编排 2.Pod设计及大数据配套能力 3.计算组件云环境适配 一、大数据上云概述 1.为什么大数据要上云 基础设施的变迁 •物理机->云主机、云盘、云网络 •存算一体->存算分离 •单一集群环境->多种集群环境（专用、离在线混部、 GPU） 业务对平台个性化需求 •业务灵活定制计算框架 –自研或基于tensorflow、mpi等二次开发 •支持多种计算模式 –CPU计算 –GPU计算 –CPU&GPU混合计算 业界大数据资源平台发展演进 IDC时代 云时代 WhyK8S？ •灵活高效的容器编排、插件扩展能力 •计算存储分离，互不影响，各自按需弹性扩缩容 •大数据及AI框架几乎都原生支持，无需侵入式改造，可以灵活适配 •运维成本低，应用层无需要运维介入 一、大数据上云概述 2.微信大数据平台架构演进 早期微信大数据平台架构 任务 调度 Web/API 优势： Spark HadoopMR Python … 计算 组件 TensorFlow MPI Shell PyTorch •自研调度和存储，自主可控 •充分利用在线闲时段资源 不足： •各模块组件高度耦合 资源调度 自研资源调度平台 •侵入性对接开源计算框架，开发迭代慢 存储 自研存储/HDFS 最初是为了在线微服务设计，当时还没有k8s •运维成本大 微信云原生大数据平台架构 @since2020 应用平台 BI/画像/机器学习/AB实验 任务调度 扩展组件 原子级框架 工作流调度API运营管理 MRDistCSparkFlink业务定制… PSQLSQL SparkFlinkTensorFloPyTorcMPIJob wh PAAS 大数据专用离/在线混算力PulsaHDF 部GPUrSCOS TKE(K8S) IAAS 虚拟机云盘云网络 灰色部分为云上设施和能力 •高效的任务调度 •资源管理&弹性资源&智能运维 •不再有Hadoop，相关组件使用Spark实现 •集成丰富的功能组件并支持业务扩展 •云原生适配开源主流计算框架 •自研通用Job框架，支持无状态批处理 •资源编排基于K8S，多种集群环境 •打通适配多种分布式存储 二、大数据上云基础建设 1.统一编排 业界计算框架接入K8S方案不统一 •Spark –SparkonK8SNative:框架自带，版本要求>=2.3 –SparkOperator:开源生态 •Flink –FlinkonK8SNative:框架自带，版本要求>=1.12 –FlinkOperator:开源生态 •TensorFlow/PyTorch/MPI –KubeFlowTrainingOperators NativeVSOperator KubernetesAPI Master masterworkerworkerPodPodPod NodeKubernetes Core KubernetesAPI CRD Master Controller Node Kubernetes CR NativeOperator •框架直接与apiserver交互，控制pod的启停 •优点：可以根据计算特点实现动态申请资源 •缺点：提交端要负责任务生命周期管理、权限管理等 •自定义crd，声明式接口，由controller管理生命周期 •优点：对提交端更友好，只管提交和同步状态 •缺点：不能实现动态分配（可以跟native结合使用） 如何接入？ 任务提交 … 只需要负责提交以及状态跟踪 CRD CR Service Master Controller NodeKubernetes ConfigMapWorkloads DeploymentStatefulSetsJob Pod … 为了简化提交端逻辑，所有框架的应用（作业）通过Operator声明式API接入 APIServer 不同框架casebycase接入 SparkOperator FlinkOperator sparkapp sparkapp flinkapp flinkapp 任务提交 TensorFlowOperator MPI Operator tfjob tfjob mpijob mpijob … … … … •提交端需要分别对接各种框架的接口 •具有共性的功能需要在各个operator里分别实现一遍 APIServer 统一接入-AllinOne … SparkOperator FlinkOperator TensorFlowOperator MPI Operator sparkapp sparkapp BigDataObject flinkapp flinkapp 任务提交 tfjob tfjob 屏蔽不同框架的差异，透明接入 mpijob mpijob … … … BigDataOperator •任务提交端只需要对接bigdataoperator •具有共性的功能统一在bigdataoperator里做 APIServer BigDataOperator 统一接入-AllinOne BigDataObject … SparkOperator FlinkOperator TensorFlowOperator MPI Operator … sparkapp sparkapp flinkapp flinkapp 任务提交 tfjob tfjob 屏蔽不同框架的差异，透明接入 mpijob mpijob … … •进一步整合，编译到一起 •方便跨集群环境部署 #框架Operator本身的CRD规格 #统一所有框架应用的运行状态 对所有框架的运行状态判断逻辑一致，简化任务提交端的逻辑 BigDataOperatorCRD 提交超时控制 任务提交 … pending pendingpending Controllers 编排超时时间控制，超过阈值则失败，并给出失败原因 MutatingAdmissionWebHook BigDataOperator 资源回收加强 运行结束的作业，Service资源不会被回收！！！ driverdriversvc JobManagerDeployment JobManagersvc headlesssvc ps-0 executo executor TaskManager Job tbsvc worker-1 rDeployment Submitterworker-0 Controllers MutatingAdmissionWebHook BigDataOperator 1.任务结束，主动回收Service，释放IP资源 2.TTL配置，一定时间后回收整个任务的资源（delete） hostNetwork网络适配 使用hostNetwork时，同一个节点不同业务端口冲突！！！ Node Spark-1driver-pod Spark-2driver-pod 冲突 Flink-1JobManager-pod Flink-2JobManager-pod 冲突 TensorFlow-1worker-pod TensorFlow-2worker-pod 冲突 WebUIPort:4040RPCPort:7078 WebUIPort:8080RPCPort:6123 BlobPort:6124 WhyhostNetwork？ 1.Pod调度量大，容器网络ip不足 2.容器网络网络传输效率低 ServerPort:2222TensorBoardPort:6006 hostNetwork网络适配 预分配端口，利用K8SPod反亲和调度避免冲突 随机预分 配端口 注入Pod反亲和配置 从系统可用端口范围中随机分配端口 Spark-1driver-pod 分配port：62222,62225 可调度 违反 Node1 bigdataoperator编排 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: -labelSelector: topologyKey:kubernetes.io/hostnamematchExpressions: -key:xxxPortoperator:Invalues: -"xxx" Spark-2driver-pod 分配port：62222,63030 Spark-3driver-pod 分配port：61020,62225 pod反亲和 可调度 Node2 … 二、大数据上云基础建设 2.Pod设计及大数据配套能力 大数据及AI多集群环境下Pod设计 BigData独�集群 （稳定性要求高的任务） 混部集群/算力GPU集群 （离线或者GPU训练） Node 业务PodinitContainer Spak/Fink/TensoFow/…lrlrConanerit hostIPC hostNetwork hostPath OssAgentPod ClusterAgent Pod … Node 业务Pod intConaneriti Spark/TensorFlow /…Container OssAgentContainer ClusterAgentContainer hostNetwork 以DaemonSet方式将辅助agents部署到每个节点上 最小化公共组件的成本，最大化机器资源利用 业务和agents以多容器方式运行在同一个Pod 业务之间尽可能完全隔离，充分利用机器空闲资源 使用initContainer解耦平台与业务 业务更灵活，平台更稳定 大数据类：Spark、Flink AI类：TensorFlow、PyTorch 用户只需提供业务Jar包即可，运行环境平台统一提供 Pod Init-container（平台提供镜像） 挂载主机临时目录 pod销毁时自动回收 emptydir 业务容器（平台提供镜像） Init-container： 拷贝用户Jar和依赖到挂载目录 -hdfs://xxx/path/to/jar 运行环境千变万化，平台只提供公共能力，核心运行环境由用户提供 Pod Init-container（平台提供镜像） 挂载主机临时目录 pod销毁时自动回收 emptydir 业务容器（用户提供镜像） Init-container： 1.拷贝hadoop等基础库到挂载目录 2.拷贝启动脚本entrypoint.sh（安全启动）到挂载目录 •业务容器启动命令：/xxx/entrypoint.shuser_cmd 运行日志持久化 业界常规做法ELK的不足！！！ Node 业务业务 podpod LogAgent Kafka ES/Kibana … 1.检索 2.分析 3.可视化 4.告警 … 可以查看运行中pod的日 志 Node SparkFlink podpod Web系统 kubelet … Node Pod销毁后无法查 看日志！ Sparkpod Flinkpod kubelet K8Scluster APIServer ELK的不足： 1.日志量大，agent实时采集上报，会占用较多宿主机资源 2.整套方案太重且成本昂贵（流量、存储、查询、维护等多种费用） 运行日志持久化 实现一套轻量级的大数据作业日志系统 APIServer 监听本机Pod Sparkpod Node … Flinkpod Node Web系统 运行中，直接通过 k8s拉取日志展示 容器退出事件 上传 Pod容器日志 LogBa