最近恶补了一下整个大数据圈的一些概念，概念太多，记录下来以备后忘。
之前一直在做数据库，主要是hbase，做着发现需求大部分是存储和全表扫描，感觉没必要用hbase，直接用hdfs+hive就足够了。我感觉hbase还是应该做实时处理的OLTP，在hadoop生态圈里hbase应该是提供随机访问能力的。全表扫描和OLAP应该是hive来做。于是开始看hive，然后接触到以下这些东西。
hbase上的sql
用hive而不用hbase的一个重要原因是hbase写sql太麻烦，于是开始搜索在hbase上做sql（尤其是join）的解决方案。
Phoenix
是把sql转换成hbase的scan，速度快，适合少量数据，百万级。
impala
没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。
Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间，倾向于实时分析，适合做adhoc查询。impala在小数据集上的表现要好于hive。另外最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。
面向BI用impala，hive面向ETL
- Impala性能不错，但是在大数据排序上，需要限制返回的行数，大表间Join也是个问题。
- 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
- 没有索引，无法做精确的查找，都是暴利扫描。
hive
hive现在很成熟了。虽然直接用hql没有自己写mapreduce job效率高，但胜在开发成本和学习成本较低。适合于ETL, 批处理场景。所谓批处理就是存储在处理，不同于下面介绍的流处理框架（实时处理）。
另外利用hadoop的sqoop工具可以很方便的把数据从文本或者关系型数据库导入到hive或hbase中，且hive可以在hdfs上或者hbase上建外部表，非常方便。
Reasons to use Hive on HBase:
A lot of data sitting in HBase due to its usage in a real-time environment, but never used for analysis
Give access to data in HBase usually only queried through MapReduce to people that don’t code (business analysts)
When needing a more flexible storage solution, so that rows can be updated live by either a Hive job or an application and can be seen immediately to the other
比较
hadoop vs spark
Spark一直宣称比hadoop快。实际上从应用场景上区分，Hadoop更适合做批处理，而Spark更适合做需要反复迭代的机器学习。(批处理 vs 迭代)。
spark 对于hadoop的替代 应该是指替换掉hadoop中的mapreduce，至于hdfs，yarn都是可以不变的，spark要消耗更多的内存，它的RDD，和流程DAG比mapreduce更加灵活。
spark sql 和 hive on spark 实际速度差不多，要快于直接用hive，代价自然是内存消耗大。hive on spark需要依赖hive的一些jar包， spark sql这方面要好一些。另外spark sql是对shark的替代。感觉hive on spark还是hive社区的，而spark sql是spark社区的，并且依赖于hive的一个snapshot。
于此相对的还有Tez, 一种新的hive执行引擎， 替代mapreduce为DAG. 不管是spark hive 还是 tez 都是避免把不必要的中间结果写在hdfs上，还有减少不必要的shuffle。
spark + hadoop
- 数据量不是特别大，完全装入内存，可以提供秒内的非统计类查询。
- 不能完全装入内存的统计分析，结果与hive+tez的组合不会差太多，也不会领先特别多。
- 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
- 没有索引，无法做精确的查找，都是暴利扫描
hadoop + hive + tez
- Hive 目前这个软件适合做OLAP数据仓库类分析、数据清洗等对实时性要求不高的场景
- Hive 不支持按照关键词查询，所以不能做搜索
- Hive 索引比较弱，达不到数据库的性能。
- Hive 不能满足3秒，5秒类似的快速返回的Ad-hoc query（即便将HDFS数据加入内存）
- 有Insert,update 等初级事务操作，所以可以认为未来可能可以做oltp
小结
目前来看Hive依然是批处理/ETL 类应用的首选。Hive on Spark能够降低Hive的延迟，但是还是达不到交互式BI查询的需求。目前交互式BI查询最好的选择是Impala。Spark SQL/DataFrame是Spark用户使用SQL或者DataFrame API构建Spark pipeline的一种选择，并不是一个通用的支持交互式查询的引擎，更多的会用在基于Spark的机器学习任务的数据处理和准备的环节。
流处理框架比较
spark streaming vs storm
都是实时流处理框架， spark streaming思想还是spark的思想， 计算向数据迁移。 storm则是数据在流动。
如果大家的需求主要集中在流处理与CEP（即复杂事件处理）式处理层面，而且需要从零开始为项目构建一套目标明确的集群设施，那么我个人更倾向于选择Storm——特别是在现有Storm流机制能够确切满足大家集成需求的情况下。这一结论并不属于硬性要求或者强制规则，但上述因素的存在确实更适合由Storm出面打理。
在另一方面，如果大家打算使用现有Hadoop或者Mesos集群，而且/或者既定流程需要涉及与图形处理、SQL访问或者批量处理相关的其它实质性要求，那么Spark则值得加以优先考虑。
资源管理调度框架比较
mesos
mesos 两层调度，主从结构。先交给framework再framework内部调度。Mesos比较适合短任务，并且是那种大量的执行起来比较快的任务，这些任务所需要的资源同整个集群资源相比，又是很小的这种场景。这其实又和Mesos选择的资源分配粒度有关，Mesos的资源分配是all or nothing的类似原子性的分配方式，拥有大需求量的任务有可能会被饿死，且Mesos自身对Frameworks无优先级对待。
yarn
YARN的第一层是ResourceMaster，每一个第二层的业务应用称为ApplicationMaster，资源按Container划分。在资源表示模型上，YARN设定的是虚拟CPU和虚拟内存。在资源管理方式上，YARN对内存资源和CPU资源采用了不同的资源隔离方案。对于内存资源，为了能够更灵活的控制内存使用量，YARN采用了进程监控的方案控制内存使用；对于CPU资源，则采用了Cgroups进行资源隔离。此外YARN对调度语义的支持更丰富，支持：请求某个特定节点上的特定资源量；请求某个特定机架上的特定资源量；将某些节点加入或移除黑名单；请求归还某些资源。在资源保证机制上，YARN采用的是增量资源分配机制，优先为应用程序预留一个节点上的资源，优点是不会发生饿死现象，但有一定的浪费。YARN支持资源抢占模型，负载轻的队列会把暂时空余的资源交给负载重的队列使用，当轻的队列收到应用，需要取回原先分配出去的资源的时候，就出现抢占。默认是不开启的，可以在配置里触发，且抢占策略是插拔式组件。YARN Scheduler policy更丰富，包括FIFO、Capacity、Fair。