这是一篇译文，原文地址
主要介绍了Capacity Scheduler相关的内容。
Capacity Scheduler在资源分配时主要考虑两个主要属性：用户名和应用程序ID。在指定最小用户百分比和用户限制因素的队列中，用户之间共享资源时，关注的是用户名本身。在队列中，应用程序获取资源分配由叶子队列排序策略驱动：FIFO或FAIR，它只关心应用程序而不关心哪个用户正在运行它。在FIFO中，资源首先被分配给队列中最先提交的应用程序，并且只有当它不再需要任何请求时，下一个应用程序才会获得分配。对于使用最少资源的FAIR应用程序，首先询问是否存在待处理的分配，如果存在则分配，则如果不存在，则检查具有最少资源的下一个应用程序；这有助于与通常使用它们的应用程序平均共享队列。
一个Applciation运行在YARN上的流程为，从YARN Client向ResourceManager提交任务，将Applciation所需资源提交到HDFS中，然后ResourceManager启动APPMaster，APPMaster通知各个NodeManager启动container执行具体到计算任务。在启动container之前需要从HDFS上下载该container执行所依赖的资源，这些资源包括jar、依赖的jar或者其它文件，这个过程就称为资源本地化(Resource Localization)。
本篇主要介绍下资源本地化相关的内容。
分布式系统中有个著名的原则CAP原则，C为Consistency(一致性)、A为Availability(可用性)、P为Partition tolerance(分区容错性)。这里主要介绍下分布式环境下如果达到一致性。
说到一致性不得不说下经典的拜占庭问题。
cryptozombies源码解析一中对以太坊开发中的事件与合约交互进行了介绍，看过这篇文章的同学我相信对Dapp开发也有了一个初步的了解，下面我们继续学习一些智能合约开发中特性。
学习区块链的朋友应该都了解去年又一款迷恋猫的爆款游戏，他是一款基于以太网的Dapp游戏。此游戏将区块链应用推向了高潮，网上各种解读接踵而来。
但对于学习区块链的技术人员肯定想从代码层次学习下，想借此掌握一些Dapp开发的技巧，我也是这么想的，但是不巧的是我的水平有限(虽然代码真的很简单，代码量也不多)，读了一遍源码发现脑子里没有留下什么。
于是就在网上各种找资料，无意中发现了Loom Network的一个游戏教程cryptozombies，就尝试了下，发现停不下来，就把Solidity 教程: 智能合约基础教程给学完了。在学习的过程中发现很多知识也在迷恋猫的代码中出现了，瞬间感觉开朗了很多。
此篇博客算是学完课程之后的回顾和总结吧。
前面提到Ozone的原创团队对大规模Hadoop集群运维和优化有着丰富的经验，所以Ozone的设计中也体现了很多HDFS的优点，并屏蔽了一些HDFS的性能瓶颈。
HDFS目前的瓶颈主要在NN上，NN内存中维护着两个大对象，一个是NameSpace，另一个是BlocksMap，这两个是常驻内存而且随着集群存储的文件数和规模成线性增长，这就造成NN的内存占比越来越大，成为HDFS扩展的瓶颈。
那么Ozone是如何解决这些瓶颈呢？
之前一篇文章介绍了在小文件合并方面的一些心得，本篇介绍下Hadoop解决小文件的最新利器Ozone(本篇基于0.3.0-alpha版本)。
众所周知，HDFS是大数据存储系统，并在业界得到了广泛的使用。但是无论大集群还是小集群其扩展性都受NN的限制，虽然HDFS可以通过Federation进行扩展，但是依然深受小文件和4亿个文件的困扰。
于是分布式key-value存储系统Ozone诞生了，Ozone能够轻松管理小文件和大文件。(HDFS提供了类似POSIX的语义，Ozone的外观和行为更像一个Object存储系统。)
HDFS是一个大数据存储系统，主要面向的场景是一次写入多次读取，大文件。但是在实际使用过程中由于各种原因集群中总是充斥着各种小文件，而且数据惊人。无论社区还是公司都在积极解决这个问题。(为什么要解决小文件，这个问题我想看到这篇文章的人应该都知道啊!)
无论你怎么优化集群，指定各种规范，让业务方优化程序，小文件总是无法避免的。
区块链一个重要的亮点就是防篡改，那么它是怎么做到防篡改的呢？其中一个重要的知识点就是Merkle Patricia Tree(MPT)，本篇就来解析下何为MPT。
MPT是一种加密认证的数据结构，它融合了Merkle树和Patricia Trie树(基数树/压缩前缀树)两种数据类型的优点。
则在介绍MPT树之前先介绍下Merkle树(默克尔树)、Trie树(前缀树)和Patricia Trie(基数树/压缩前缀树)，介绍Trie树是因为Patricia Trie是基于Trie树衍化来的。