江苏龙网

  1. 首页 > 人文 > >

阿里经济体核心调度系统Fuxi( 十 )


1. 流控和负载均衡前面的数据归集模型中 ， shuffle agent作为新角色衔接了mapper的数据发送与数据落盘 。 分布式集群中磁盘、网络等问题可能影响这条链路上的数据传输 ， 节点本身的压力也可能影响shuffle agent的工作状态 。 当因集群热点等原因使得shuffle agent负载过重时 ， 我们提供了必要的流控措施缓解网络和磁盘的压力；和模型中一个reducer有一个shuffle agent收集数据不同 ， 我们使用了多个shuffle agent承担同样的工作 ， 当发生数据倾斜时 ， 这个方式可以有效地将压力分散到多个节点上 。 从线上表现看 ， 这些措施消除了绝大多数的shuffle期间拥塞流控和集群负载不均现象 。 2. 故障shuffleagent的切换各种软硬件故障导致shuffle agent对某个reducer的数据工作不正常时 ， 后续数据可以实时切换到其他正常shuffle agent. 这样 ， 就会有更多的数据可以从shuffle agent侧读到 ， 而减少低效的备份副本访问 。 3. Shuffle agent数据的回追很多时候发生shuffleagent切换时（如机器下线） ， 原shuffle agent生成的数据可能已经丢失或访问不到 。 在后续数据发送到新的shuffle agent同时 ， Fuxi还会将丢失的部分数据从备份副本中load起来并同样发送给新的shuffle agent, 使得后续reducer所有的数据都可以读取自shuffle agent侧 ， 极大地提升了容错情况下的作业性能 。 4. 新shuffle模式的探索前述数据归集模型及全面扩展优化 ， 在线上集群中单位资源处理的数据量提升了约20%, 而因出错重试的发生频率降至原来文件系统shuffle的5%左右 。 但这就是最高效的shuffle方式了吗？
我们在生产环境对部分作业应用了一种新的shuffle模型 ， 这种模型中mapper的发送端和reducer的接收端都通过一个agent节点来中转shuffle流量 。 线上已经有部分作业使用此种方式并在性能上得到了进一步的提升 。
内存数据shuffle
离线大数据作业可能承担了主要的计算数据量 ， 但流行的大数据计算系统中有非常多的场景是通过实时/准实时方式运行的 ， 作业全程的数据流动发生在网络和内存 ， 从而在有限的作业规模下取得极致的运行性能 ， 如大家熟悉的Spark, Flink等系统 。
Fuxi DAG也提供了实时/准实时作业运行环境 ， 传统的shuffle方式是通过网络直连 ， 也能收到明显优于离线shuffle的性能 。 这种方式下 ， 要求作业中所有节点都要调度起来才能开始运行 ， 限制了作业的规模 。 而实际上多数场景计算逻辑生成shuffle数据的速度不足以填满shuffle带宽 ， 运行中的计算节点等待数据的现象明显 ， 性能提升付出了资源浪费的代价 。
我们将shuffle service应用到内存存储中 ， 以替换network传输的shuffle方式 。 一方面 ， 这种模式解耦了上下游调度 ， 整个作业不再需要全部节点同时拉起；另一方面通过精确预测数据的读写速度并适时调度下游节点 ， 可以取得与network传输shuffle相当的作业性能 ， 而资源消耗降低50%以上 。 这种shuffle方式还使得DAG系统中多种运行时调整DAG的能力可以应用到实时/准实时作业中 。
4.2.3 收益
Fuxi Shuffle 2.0全面上线生产集群 ， 处理同样数据量的作业资源比原来节省15% ， 仅shuffle方式的变化就使得磁盘压力降低23% ， 作业运行中发生错误重试的比例降至原来的5% 。
阿里经济体核心调度系统Fuxi
本文插图
【线上典型集群的性能与稳定性提升示意图（不同组数据表示不同集群）】
对使用内存shuffle的准实时作业 ， 我们在TPCH等标准测试集中与网络shuffle性能相当 ， 资源使用只有原来的30%左右 ， 且支持了更大的作业规模 ， 和DAG 2.0系统更多的动态调度功能应用至准实时作业 。
5. 单机调度
大量分布式作业汇集到一台机器上 ， 如何将单机有限的各种资源合理分配给每个作业使用 ， 从而达到作业运行质量、资源利用率、作业稳定性的多重保障 ， 是单机调度要解决的任务 。


推荐阅读


上一篇：『美军』美国欠中国的钱可造一万架歼-20，如果不还怎么办？专家称美国不敢

下一篇：那个年薪3亿的“打工皇帝” 终究是雷军得不到的男人