在Hadoop发展的8年时间里，我们看到一种“使用浪潮”——一代又一代用户在相同的时间和类似的环境下使用Hadoop。每一个在数据处理时使用了Hadoop的用户，都面临着类似的挑战，为了让一切正常运转，要么被迫协同工作，要么干脆隔离。接下来我们就讨论这些客户，看他们彼此之间有何不同。
第0代——火种
这是开头：在谷歌2000年中的研究论文的基础上，一些信徒奠定了廉价存储和计算能力的商品化基础。
Doug Cutting是教父。他跟Mike Cafarella一起，实现了谷歌文件系统和MapReduce的一个开源版本，它也是Apache Nutch项目的一部分。这两者一起演绎出无处不在的Apache Hadoop，一个蓬勃发展的大数据生态系统。令人吃惊的是，没有其他竞争项目或商业实体看到这项技术的潜力，并开发出与之竞争的产品。
第一代——早期
Hadoop建立后迅速吸引了一些早期用户，包括web2.0及其后的公司Yahoo!、Facebook、Powerset、Rapleaf等，他们中的一些人比如后两者更关注Hadoop的NoSQL组件，Hadoop的数据库(又名HBase)。他们都需要一个能帮助他们应对现有及正在快速增长的用户基础平台。他们赌一个能让Google正常运转的东西也能满足他们的需求。Hadoop做到了，然后才有了今天。
更重要的是这些公司都有强大的工程背景，拥有比一般企业更多的开发人员。他们的技术专家能在公司内使用Hadoop，开发搭建于Hadoop之上的解决方案。对工程师来说，技术道路从这里开始分化：要么开始深入挖掘代码并最终构建一个Hadoop生态系统内的项目，要么被归到既做开发又做集群的那一类里…我们见证了Hadoop发展规则的诞生——参与其中的人员应该具备多种技能、能一肩挑起所有重担。这很有用，因为这些孤独战斗的武士们都是有天赋的家伙，能够完成他们的工作。
这两组工程师最终都促进了Hadoop代码库的发展，并因此被选入Hadoop提交团队，他们被允许检查提交到开源库中的代码。我们谈论的是一只约200人的团队，他们在世界范围内推动Hadoop的发展。
现在，其中的一些工程师已经转到其他项目或跳到其他公司，但他们中的绝大多数仍然活跃在Hadoop圈子里。特别值得一提的是Yahoo!公司，它在最开始的时候推动了Hadoop的发展。
第二代——追随者
在早期使用Hadoop的公司里，Hadoop成功对一批新用户留下深刻的印象，他们通常被现在蓬勃发展的Web 3.0和社交网络的公司雇佣。这些用户是Hadoop的形成和时代到来的主因(虽然一个比一个年轻)。他们通常没有你积累丰富的Java代码，但是这些用Python, Ruby 或Scala标识着“我们写代码快”的家伙们，在能量饮料和无尽的时间帮助下能够破解任何代码，唯独不包括java。因此，他们建立一个伟大的网站，如Last.fm、Spotify，网站把Hadoop缺乏的东西迅速汇集到一起，例如一个叫Dumbo(Last.fm)的Python MapReduce桥，或Luigi (Spotify)的新作业调度系统。
现在，这种缺乏Hadoop组件而引发的模块化开发方式不仅发生在年轻的创业者身上，也出现在其他公司，这些公司不愿意介入Hadoop核心开发者社区里日益增长的政治化问题。LinkedIn就是一个例子，它围绕Hadoop的核心服务开发了很多工具，它还建立辅助系统以帮助收集事件、进行队列处理等。LinkedIn将这些项目开源，以便帮助有兴趣的用户建立新社区。
第三代——大器晚成
到目前为止，对所有Hadoop项目感兴趣的下一代用户是所谓的企业公司。他们的规模从小到大都有，他们是纯粹的IT用户，他们购买需要的软硬件许可，架构师会将这些东西揉到解决方案、产品或服务中。但他们不会雇用一批核心开发者打补丁或建立Hadoop堆栈。事实上这些用户大多数采用分布式安装Hadoop，如用Cloudra的CDH以让Hadoop运行得更快。这与在不同操作系统下做事儿是一样的，你可以将精力集中于Hadoop之上的业务逻辑，如果遇到问题或缺乏组件，你跟供应商沟通，然后升级到新版本。
有趣的是这些用户对年轻的Hadoop很满意，其应用缺乏更多的企业特征。Hadoop集群被从网络中分离并由少数几个人管理，通常一个集群只跑一个应用，所以遇到多用户或多负载的任务时自然会被安全地推迟。
第四代——新浪潮
我们现在看到的应用Hadoop的公司，他们等待了很长时间，因为Hadoop缺点太多所以干脆推迟上Hadoop。但随着企业级数据中心的出现，企业也为Hadoop的运行做好了准备。等待的时间并非空等，他们认真研究Hadoop功能，花时间测试系统的各个部分，明确知道自己想要一个安全的、多用户、多负载的数据平台，能与现有的IT系统集成到一起，并带有数据管理、安全审计和综合管理功能。