Cloudera公司作为Hadoop商业领域的翘首人物，此前就对将Mahout包装为商业应用的一个商业公司进行收购；开启大数据学习领域的云计算领域，而跟Spark商业公司Databricks的进一步合作；进一步完善HDFS数据存储模型下的另外一种流式计算模型的整合。加上Cloudera自身的Impala产品。
在Hadoop领域下，或者大数据模型下的，三种计算和分析技术都集中于Cloudera公司的旗下。
在阿里巴巴内部的诸多云梯、流式计算、海量数据的实时处理方面，应该也逃不过此三大类计算模型的进一步包装或者整合，或者进一步挖掘和优化。
虽然未能够直接进入业界的最前沿的软件公司从事此类计算模型的研发和设计，但是在公司内部还是对这一一系列的技术进行分析研究、预言和POC.
个人也是奔着对Cloudera公司的关注，来持续研究分析内部的技术架构设计思路模型
Hadoop提供的HDFS分布式文件系统，首先解决分布式数据存储的问题；但是针对分布式数据的计算处理（尤其类似于RDBMS）的OLTP,OLAP以及RTAP的计算模型已经深入行业的处理业务中，所以但是大量的NoSQL或者HBase,Hive,Impala,Drill这些依赖MapReduce计算模型和实时交互性的计算模型，当然针对Spark的计算模型源头来源自CEP，同等的也有S4,Storm；而基于流式计算的产品还包括Tibco的streambase.
这些计算模型大部分都是依赖：主、从架构，异步事件处理机制，基于图形计算模型的计算框架，当然为了支持故障转移，引入通过Zookeeper来支持多节点的故障转移；或者通过类似的处理技术。
这些计算模型本身都是针对实际业务场景中的不同需求而设计诞生的，比如业务场景分为几个大类：
1：并发请求量很大，涉及的数据多达TB，业务场景要求反馈可以延迟；对此最好通过Map/Reduce的批量大规模技术来完成。
2：如果用户对系统的响应有进一步的诉求呢，可以进一步通过类似Google的Demel的产品Impala,Drill来实现大数据下的快速处理
3：如果数据量大，并且数据本身的响应时间敏感在秒级，比如用户登录后，需要实时显示推荐的商品，考虑该业务场景的支撑能力，需要进一步设计计算模型，用户登录的动作完成时间有限，需要快速根据用户特征来发起推荐数据的筛选和评级，从中筛选更加合理的商品信息推荐给客户；
这里有一个特征：根据用户的某一个动作、作为数据发起事件，然后跟该事件触发另外的用户特征识别，用户特征识别进一步产生用户购买历史规律分析、可推荐商品筛选，等一系列的推荐业务处理；而这个事件结束的重点，就是显示更加贴近用户喜欢、购买可能性更大的商品列表。
假如一个业务平台需要考虑多个大数据的处理场景，选择cloudera至少增加了更多可选择余地；
从数据存储到多种计算模型的场景，以及支持跟好的数据分析和数据挖掘的算法库，的确让我们可以增加了应对云计算时代的战斗力。