3吴乾豪.pdf

1、演讲嘉宾演讲嘉宾：微信微信/吴乾豪吴乾豪微信大数据平台与微信大数据平台与AIAI框架作业框架作业规模化上云的优化实践规模化上云的优化实践目录目录0 0 1 1项目背景项目背景0 0 2 2核心挑战与解决核心挑战与解决0 0 3 3总结与展望总结与展望0 0 1 1 项目背景项目背景大规模全实时深度学习时代下面临的特殊挑战 视频号、AIGC等新兴业务高速发展 井喷的业务需求VS旧平台迭代慢 大数据及 AI 平台需求日益旺盛 多框架多语言，社区发展迅速 大规模，稳定性要求高 平台开发迭代周期长 各模块组件高度耦合 侵入性对接开源框架，迭代慢 运维成本大 大模型实时训练VS离线训练框架为主 模型越来

2、越大 越来越多业务选择实时训练 以往大数据计算以离线为主，达不到业务需求早期微信大数据平台(2013年底启动)内部云资源管理与调度系统自研存储存储Spark/MR/MPI等资源管理演进迈向云原生时代(2020年启动)Why云原生？灵活高效的容器编排能力，从微服务到大数据、AI workload 生态繁荣，大数据及 AI 框架几乎都原生支持，可以灵活适配 灵活的插件扩展能力，可以方便地对K8S做定制化扩展 运维成本低，存算分离 资源共享，混部&资源弹性 公司在硬件环境上做了非常全面的支持0 0 2 2 核心挑战与解决核心挑战与解决挑战一：如何接入 跨平台和多框架作业管理的困境大数据专用集群算力C

3、PU集群跨平台环境任务配置调度（上层难以统一对接）离在线混部集群算力GPU集群海外环境痛点：难以屏蔽平台环境差异，无法向上提供统一功能 多平台共用共用operator，框架和operator难以深度联动 共性管理功能需要在各个框架operator实现 自研框架接入难度大开源框架接入方式分散跨平台计算组件统一编排作业生命周期管理，统一抽象和接入简化和沉淀可重复的作业管理功能，避免case by case开发以可扩展方式支持框架作业生命周期管理的特定运行逻辑具有共性的功能统一在 wxgbigdata operator 里做1.维护不同类型作业状态2.框架作业驱逐感知3.HostNetwork4.原

4、地重启5.过载保护，快速拒绝统一方案输出，整合和编译原地升级收益：1.使用本地共享内存、磁盘数据快速恢复作业2.预防多租户场景作业重发布，资源被其它用户抢走3.新节点镜像拉取时间过长框架作业原地升级，如何处理好框架实例间重启的编排工作？实时训练场景对停训敏感，变更升级需要快速恢复作业，减少作业训练中断时间hostNetwork网络选取系统可用端口随机分配利用k8s调度反亲和特性防止端口冲突适配各框架的hostNetwork，service、configmap等大量pod创建时，vpc下的容器ip不足，且容器网络传输效率低框架作业异常状态修正平台兜底：异常作业修正：精准判断”假死作业”无侵入抢占

5、、驱逐感知，webhook和event获取，无需多团队的联合改造框架作业低优资源使用痛点：作业区分失败：无法区分作业是正常逻辑失败还是抢占失败 作业”假死”：pod抢占，自动补充实例，框架无法续训低优任务运行过冲中被高优任务抢占，缺乏感知等机制，导致计算浪费和状态异常挑战二：如何支持大规模业务高效上云大批量任务 VS 系统矛盾 大量作业下发，apiserver高负载，响应延迟瞬时流量突增，etcd出流量异常，P99时延几秒Master系统盘io突增，95%的io利用率，系统运营于崩溃边缘大数据作业对k8s架构的挑战 Native式提交架构创建、运行和销毁由spark native自维护，每个作

6、业都是一个controller，一套list&watch 大数据作业的特点 -时间段内的大量提交：api batch提交，瞬时量大 -短运行、小作业居多：实例多，单实例资源分配小 -数据量大：每个作业有配置、event等其它对象 List请求对k8s的压力频繁的List占用大量磁盘IO，网络带宽和CPU、内存等大规模部署存在的问题 大量及非常频繁的创建销毁 向apiserver的大量List&Watch 请求穿透到etcdClient().CoreV1().Pods().List(ctx(),ListOptionsFieldSelector:spec.nodeName=node1)客户端可能只