接下来，章宇开始从研究代码的层面介绍Sahara的设计与实现。Sahara的设计有两大特点：
1、模块化、可配置： Sahara中的大量功能和机制，都基于可选择、可配置的模块化插件实现，例如：可以通过对engine的配置来选择不同的Hadoop集群编配引擎，通过对plugin的配置来选择不同的Hadoop发行版安装与部署方式和工具，等等。
2、代码重用： Sahara也尽可能重用了OpenStack自身提供的IaaS层组件及其服务，例如：利用Nova提供虚拟机资源，利用Horizon提供人机界面，等等。
Sahara对Horizon（界面）、Glance（镜像管理）、Keystone（身份认证）、Heat（集群配置）、Ceilometer（监控）、Nova（虚拟机管理）、Neutron（网络）、Cinder（块存储）和Swift（对象存储）都有不同程度的代码复用，其中Nova、Glance和Keystone是必要组件，其他组件可选用。
Sahara的整体架构可参考其架构图。其中，章宇建议： 在分析集群创建流程时，主要应关注sahara.api、sahara.service.api、sahara.service.engine和sahara.plugins这四个package的各自行为及相互关系。其中，sahara.service.api中的_provision_cluster()驱动了整个cluster创建的过程。
接下来，章宇从产品和技术的层面将Sahara与EMR、Serengeti进行了对比，要点如下： - EMR在Sahara基本模式的基础上融合了EDP模式的特点
- EDP的用户只需要指定“哪些数据”、“哪个集群”、“哪个程序包”这三要素，而完全不用关心集群如何创建、如何管理这样的与自己核心业务诉求无关的问题
- EMR的用户则除了需要在创建集群时指定大量信息外，还需要负责集群和业务的运行管理
- 比较而言，EDP的用户是纯粹的大数据业务应用者，而EMR的用户则身兼业务应用和系统运维两种职责
- 基于EMR的大数据解决方案，全面涵盖了数据的存储、计算、分析、共享等各个处理环节，这是Sahara还难以企及的
- Sahara和Serengeti的区别，可以说是“应用云化”和“应用虚拟化”的区别。Serengeti项目的主要关注点在于如何为搭建在虚拟机环境下的Hadoop集群提高性能和可靠性，这里面的思考是Sahara可以借鉴的
介绍到这里，章宇对Sahara目前的状态进行了概述，认为目前的Sahara还面临以下几点挑战： - Sahara的管理平面性能存在疑问，创建和发布集群的等待时间有待测试
- 复杂管理的成功率方面，目前Sahara中没有看到明确的处理机制，这是一个缺失
- Sahara搭建的Hadoop在虚拟化环境下的性能有待优化，不过这个问题可以等到前面两个关键问题解决了之后再来优化
- Auto-scaling的缺失。目前Sahara要扩展需要人工执行
- Sahara最大的亮点在EDP，其价值有待进一步挖掘
| 
