Flink 当前的计算任务调度是完全随机的，直接后果是各个 taskmanager 上运行的计算任务分布不均，进而导致 taskmanagers 之间的负载不均衡，用户在配置 taskmanager 资源时不得不预留较大的资源 buffer，带来不必要的浪费。为此，我们扩展了一种均衡调度策略，尽量保证每个 flink 算子的子任务均匀分布在所有的 taskmanagers 上，使得 taskmanagers 之间的负载相对均衡。

要理解 Flink 内部各组件交互的源码实现，首先必须要理解其 RPC 的工作机制。与 Hadoop、Spark 等系统类似，作为一个独立的分布式系统框架，Flink 也抽象了自己的一套 RPC 框架，本文尝试尽可能详尽地阐述其设计及实现原理。

在我们的很多推荐业务场景中，通常一个模型可能是一直不断增量训练的，如果哪天业务需要调整模型结构，去训练一个新模型，但是又不想完全从0开始，希望复用原来模型里面的部分参数，这样冷启动的代价就小很多了。

TensorFlow从15年10月开源至今，可谓是发展迅猛，从v0.5到如今的v2.0.0-alpha，经历了无数个功能特性的升级，性能、可用性、易用性等都在稳步提升。相对来说，对于我们工业界，大家可能更关注分布式TensorFlow的发展，本文尝试梳理下分布式TensorFlow从问世到现在经历过的变迁。

在Spark-2.4.0中社区提出一种新的Spark调度执行方式，名为Barrier Execution Mode，旨在通过Spark去调度分布式ML/DL(机器学习/深度学习)训练作业，这种训练作业一般是通过其他框架实现，例如MPI、TensorFlow等。由于Spark本身的计算框架是遵循MapReduce架构的，所以在调度执行时，每个Task都是独立执行的。然而，MPI这类分布式计算作业运行时需要所有Task一起执行，Task与Task之间需要相互通信。为了将诸如MPI分布式机器学习作业很好地与Spark结合，Spark社区提出一种新的Barrier Scheduler，可保证所有的Task全部调起(当然要保证资源足够)。