Spark Streaming + Kafka + Flume + HBase
Spark Streaming 模块是对于 Spark Core 的一个扩展，目的是为了以高吞吐量，并且容错的方式处理持续性的数据流。目前 Spark Streaming 支持的外部数据源有 Flume、 Kafka、Twitter、ZeroMQ、TCP Socket 等。
Discretized Stream 也叫 DStream) 是 Spark Streaming 对于持续数据流的一种基本抽象，在内部实现上，DStream会被表示成一系列连续的 RDD(弹性分布式数据集)，每一个 RDD 都代表一定时间间隔内到达的数据。所以在对 DStream 进行操作时，会被 Spark Stream 引擎转化成对底层 RDD 的操作。
https://blog.csdn.net/BD_Jiang/article/details/52982194?locationNum=8&fps=1
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
https://blog.csdn.net/ychenfeng/article/details/74980531
Kafka部分名词解释如下：
Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。
· Broker：Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。
· Topic：一类消息，消息存放的目录即主题，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。
· Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列
· Segment：partition物理上由多个segment组成，每个Segment存着message信息
· Producer : 生产message发送到topic
· Consumer : 订阅topic消费message, consumer作为一个线程来消费
· ConsumerGroup：一个Consumer Group包含多个consumer, 这个是预先在配置文件中配置好的。各个consumer（consumer 线程）可以组成一个组（Consumer group ），partition中的每个message只能被组（Consumer group ） 中的一个consumer（consumer 线程 ）消费，如果一个message可以被多个consumer（consumer 线程 ） 消费的话，那么这些consumer必须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的consumer thread来处理，即便是来自不同的consumer group的也不行。它不能像AMQ那样可以多个BET作为consumer去处理message，这是因为多个BET去消费一个Queue中的数据的时候，由于要保证不能多个线程拿同一条message，所以就需要行级别悲观所（for update）,这就导致了consume的性能下降，吞吐量不够。而kafka为了保证吞吐量，只允许一个consumer线程去访问一个partition。如果觉得效率不高的时候，可以加partition的数量来横向扩展，那么再加新的consumer thread去消费。这样没有锁竞争，充分发挥了横向的扩展性，吞吐量极高。这也就形成了分布式消费的概念。
Kakfa的设计思想
- Kakfa Broker Leader的选举：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka brokercontroller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功
总结:
1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partitionleader建立socket连接并发送消息.
2) Broker端使用zookeeper用来注册broker信息,已经监测partitionleader存活性.
3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。
Flume是一个分布式，可靠地，用户高效收集，聚合，移动大量数据的可用系统服务，有着基于流动数据技术的简单灵活架构。具有健壮性和容错性，使用可调节的可靠机制以及多种容灾和恢复机制。使用可扩展数据模型，运行在线分析应用。
https://blog.csdn.net/Java_Soldier/article/details/78937720
1.1.2 运行机制
1、 Flume分布式系统中最核心的角色是agent，flume采集系统就是由一个个agent所连接起来形成
2、 每一个agent相当于一个数据传递员，内部有三个组件：
a) Source：采集源，用于跟数据源对接，以获取数据
b) Sink：下沉地，采集数据的传送目的，用于往下一级agent传递数据或者往最终存储系统传递数据
c) Channel：angent内部的数据传输通道，用于从source将数据传递到sink
案例：https://blog.csdn.net/Java_Soldier/article/details/78937747
HBase是建立在HDFS之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的分布式列存储的开源数据库系统。
HBase是Apache的Hadoop 项目的子项目。
HBase中每张表的记录数（行数）可多达几十亿条，甚至更多，每条记录可以拥有多达上百万的字段。而这样的存储能力却不需要特别的硬件，普通的服务器集群就可以胜任。
HBase表是一个分布式多维表，表中的数据通过一个行关键字（row key）、一个列族和列名（column family，column name）和一个时间戳（time stamp）进行索引和查询定位。
1.Row Key
HBase一张表中可以有上亿行记录，每一行都由一个行关键字(row key)来标识。
特点：
（1）HBase保证对所有行按照row key进行字典序(byte order)排序。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)
（2）Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。
（3）HBase中的row key 只能是一个字段而不能是多个字段的组合。（这与关系型数据库的主键（primary不同））。
2.列族和列
hbase表中的每个列，都归属于某个列族。
列族是表的schema（模式）的一部分(而列不是)，必须在使用表之前定义。
列名都以列族作为前缀。例如courses:history，courses:math都属于courses 这个列族。
特点：在每个列族中，可以存放很多的列，而每行每列族中的列数量可以不同，数量可以很大。列是不需要静态定义的，每行都可以动态的增加和减少列。
3.时间戳
HBase中通过行关键字、列（列族名和列名）和时间戳的三元组确定一个存储单元（cell）。
每个 cell都保存着同一份数据的多个版本。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
版本通过时间戳来索引。时间戳的类型是 64位整型。
时间戳可以由hbase(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。