问题现象
刚接触大数据生态的工程师，面对一长串组件名时最常见的困惑是：
- 这几个东西名字相似、都说是「大数据」方案，但说不清谁替代谁、谁依赖谁；
- 有人把 HBase 当成「避开 MapReduce 的高性能 Hadoop」，结果用它做全表扫描，慢得离谱；
- 有了 Hive 之后不知道还需要不需要 Pig，两个都写查询，看起来功能重复；
- 团队按 SQL 思路建好了表，上线后却发现单条记录的点查要十几秒，业务根本不接受；
- 选型时照着生态图逐个堆组件，最后运维成本远超收益。
这些困惑的根源，是把「存储」和「计算」混为一谈，又把「访问方式」和「底层引擎」混为一谈。
原因分析
第一，Hadoop 其实是两件事的合称。它包含一个分布式文件系统和一个分布式计算框架。文件系统负责把大文件切成块、多副本存放，换来的是高吞吐与容错；但它只支持顺序读写，就像一块只能整块擦写的硬盘，不支持随机定位。计算框架则负责把任务拆散到多台机器上并行处理，强调吞吐而非延迟。理解了这个二分法，后面几个组件的位置就清楚了。
第二，HBase 补的是「随机读写」这一环。它构建在分布式文件系统之上，按列族组织数据、以键值对的形式存放，因此可以对单条记录做毫秒级的随机读写。这是文件系统本身做不到的。反过来，它并不适合大范围全表扫描和复杂聚合——这类需求恰恰是计算框架的强项。所谓「HBase 绕开了 MapReduce」，准确的说法是它绕开了「只能顺序访问」的限制，而不是绕开了计
