以前电商平台数据量很小，现在有一份 PB 级的超大数据需要分析统计，比如对用户每日的关键词搜索进行词频统计，能够精琢定位用户需求。
我们以前的方法是使用 oracle 等传统数据库或者写 python 脚本来解决，但是现在使用会发现，太慢了，等跑完，已经错过了商机。
于是我们找到了 hadoop 这个工具，hadoop 是一个分布式系统，其中有一个部分叫分布式文件管理系统HDFS，他能把大数据分成很多块(并备份)进行存储，然后用 Mapreduce (MR) 写 java 代码进行词频统计（map）和 reduce（计算）。
但是我们又发现，这样做①速度依旧不快，因为批处理有延迟（MapReduce必须严格按Map → Shuffle（网络传输）→ Reduce顺序执行，后一阶段必须等前一阶段100%完成才能开始（如Reduce必须等所有Map任务完成）每个阶段结束都会把中间结果写入磁盘（防止失败重算），但磁盘I/O比内存慢百倍）；
而且②无法做到实时查询，缺乏随机读写能力，还③得有工作人员会写 java 代码。
问题重重，为了解决这些问题，我们找到了 spark 来帮助 Mapreduce，spark 可以把 map 和 reduce 的中间数据放在内存而不是像 MR 一样放在硬盘，消除大部分的 IO 延迟，可以解决①搜索慢的问题。
然后我们找到了 HBase ，它可以在 HDFS 之上创建文件索引，实现实时查询来解决问题②。
接着我们找到了 hive 和 phoenix，他们可以把 sql 转化为 java 语言供机器识别，这样就解决了问题③，hive 主要是用来离线数据分析，他基于 mapreduce/spark，速度会比较慢，延迟比较高，一般用来统计月度/周度数据；phoenix 基于 hbase 提供的 api，延迟低可以用来实时查询，可以用来检测订单是否支付成功等一些需要快速反映结果的问题。
这三个问题解决后，我们又发现，有时候 spark 和 mapreduce 会抢占资源（spark 不会完全替代 mapreduce），于是我们找了一个指挥官叫 yarn，来处理他们的资源调度。
我们还发现 Hbase 有时候会罢工，罢工的时候也需要个指挥官换人工作，于是我们找了 zookeeper 来指挥。