随着大数据技术架构的演进，存储与计算拆散的架构能更好的满足用户对升高数据存储老本，按需调度计算资源的诉求，正在成为越来越多人的抉择。相较 HDFS，数据存储在对象存储上能够节约存储老本，但与此同时，对象存储对海量文件的写性能也会差很多。

mlflow 的更新迭代速度还是很快的，均匀一个月一个大版本的更新，截止到11月1号，曾经更新到了1.11.0版本 咱们查看mlflow release,就能看到早在1.10.0版本，就提供了对model registry的更好的feature反对，以及可能对试验进行逻辑删除操作， 而这些features 在mlflow 1.4.0是没有的，特地是删除试验的个性，如果试验很多…

mlflow是Databrick开源的机器学习治理平台，它很好的解藕了算法训练和算法模型服务，使得算法工程师专一于模型的训练，而不须要过多的关注于服务的, 而且在咱们公司曾经有十多个服务稳固运行了两年多。

最近我的项目中，用akka(2.6.8) cluster在k8s做分布式的部署，，其中遇到unreachable node 如果始终未手动重启，则会导致其余的node退出不到cluster中来， 具体的操作为其中的一个非seed node节点因为pod 重启导致，部署到了其余的节点上，而之前的node(ip)，cluster则会始终去连贯该node(ip)，从而导致异样

应用 java -javaagent:jvm-profiler-1.0.0.jar=reporter=com.uber.profiling.reporters.KafkaOutputReporter,brokerList=’kafka1:9092′,topicPrefix=demo_,tag=tag-demo,metricInterval=5000,sampleInterval=0 -cp target/jvm-profiler-1.0.0.jar

spark on yarn对于DynamicResourceAllocation调配来说，从spark 1.2版本就曾经开始反对了. 对于spark相熟的人都晓得，如果咱们要开启DynamicResourceAllocation，就得有ExternalShuffleService服务， 对于yarn来说ExternalShuffleService是作为辅助服务开启的，具体配置如下：

前者是spark社区反对k8s这种资源管理框架而引入的k8s client的实现 后者是k8s社区为了反对spark而开发的一种operator

特地阐明 对于podsWatchSnapshotSource的实现，咱们是基于k8s watch机制实现的，然而存在一个问题: 如果某一时刻，podsWatchSnapshotSource产生了故障导致了该组件产生了重启，那么问题来了，重启这段时间就会失落event， 这里咱们采纳k8s的resourceVersion机制，如果咱们定时存储resourceVersion，且在重启的时候读取，…

Kryo是一种对象序列化和反序列化工具。通信单方须要相互发送音讯，livy抉择了Kryo作为音讯的编解码器，并在netty框架中实现编码和解码接口：

ReplDriver是真正最终运行的Driver程序对应的类（其基类是第三篇中提到的RSCDrvier）。在这一层，重点关注handle系列办法：