资深技术专家分享：大数据实时计算微服务引擎总结

总结《大数据架构之道和项目实战》第七章：

• 学习目标

1. 掌握分布式采集服务Flume部署及数据采集
2. 掌握分布式消息服务Kafka部署及数据发送
3. 掌握Hbase数据库设计和Spark集群环境构建
4. 掌握Spark连接Kafka的两种方式
5. 掌握Scala的基本语法和常用算子
6. 掌握Spark中Job的执行流程
7. 掌握Spark的Shuffle过程
8. 掌握Spark解决数据倾斜的几种方式和原理
9. 掌握分布式实时处理引擎SpringStreaming原理和数据处理方法
10. 掌握微服务实现数据处理
11. 掌握微服务实现数据可视化

• 知识技能

1. Flume

1. 介绍：flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(比如文本、HDFS、Hbase等)的能力 。
2. 可靠性：当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将　event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。
3. 核心概念：

Client：Client生产数据，运行在一个独立的线程。

Flow： Event从源点到达目的点的迁移的抽象。

Source： 数据收集组件。（source从Client收集数据，传递给Channel）

Channel： 中转Event的一个临时存储，保存由Source组件传递过来的Event。（Channel连接 sources 和 sinks ，这个有点像一个队列。）

Sink： 从Channel中读取并移除Event， 将Event传递到FlowPipeline中的下一个Agent（如果有的话）（Sink从Channel收集数据，运行在一个独立线程。）

1. Flume数据流：

     Flume 的核心是把数据从数据源收集过来，再送到目的地。为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。

      Flume 传输的数据的基本单位是 Event，如果是文本文件，通常是一行记录，这也是事务的基本单位。 Event 从 Source，流向 Channel，再到 Sink，本身为一个 byte 数组，并可携带 headers 信息。 Event 代表着一个数据流的最小完整单元，从外部数据源来，向外部的目的地去。

1. Kafka介绍：

   在流式计算中，Kafka一般用来缓存数据，Storm通过消费Kafka的数据进行计算。

1. pache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。
2. Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。
3. Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。
4. 无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性

1. 为什么需要消息队列

1. 解耦
2. 冗余
3. 削峰

1. 消息模式：

1. 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

1. 发布/订阅模式（一对多，数据生产后，推送给所有订阅者

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。

1. 架构：

1. Producer ：消息生产者，就是向kafka broker发消息的客户端。
2. Consumer ：消息消费者，向kafka broker取消息的客户端
3. Topic ：可以理解为一个队列。
4. Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
5. Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
6. Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
7. Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

1. Flume和kafka对比

1. kafka和flume都是日志系统。kafka是分布式消息中间件，自带存储，提供push和pull存取数据功能。flume分为agent（数据采集器）,collector（数据简单处理和写入）,storage（存储器）三部分，每一部分都是可以定制的。比如agent采用RPC（Thrift-RPC）、text（文件）等，storage指定用hdfs做。
2. kafka做日志缓存应该是更为合适的，但是 flume的数据采集部分做的很好，可以定制很多数据源，减少开发量。所以比较流行flume+kafka模式，如果为了利用flume写hdfs的能力，也可以采用kafka+flume的方式。
3. Flume：Flume 是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展API.
4. Kafka：Kafka是一个可持久化的分布式的消息队列。

1. Spark集群环境构建

   搭建前必须满足Hadoop集群的安装，因为Spark的存储依赖hdfs，hadoop集群可以在yarn上，也可以由zookeeper协调。

Jdk安装。

Scala的正确安装，Ssh免密登录

1. Scala

1.    介绍：Scala 是一门多范式（multi-paradigm）的编程语言，设计初衷是要集成面向对象编程和函数式编程的各种特性。

             Scala 运行在Java虚拟机上，并兼容现有的Java程序

             Scala 源代码被编译成Java字节码，所以它可以运行于JVM之上，并可以调用现有的Java类库。

（2）scala基础

1. Spark

1. 介绍：Spark是是用于大规模数据处理的统一分析引擎。
2. 特点：高效性、易用性、通用性、。兼容性
3. 组成：

SparkCore：将分布式数据抽象为弹性分布式数据集（RDD），实现了应用任务调度、RPC、序列化和压缩，并为运行在其上的上层组件提供API。

SparkSql：Spark Sql 是Spark来操作结构化数据的程序包，可以让我使用SQL语句的方式来查询数据，Spark支持 多种数据源，包含Hive表，parquest以及JSON等内容。

SparkStreaming：是Spark提供的实时数据进行流式计算的组件。

Mllib：提供常用机器学习算法的实现库。

Graphx：提供一个分布式图计算框架，能高效进行图计算。

BlinkDB：用于在海量数据上进行交互式SQL的近似查询引擎。

Tachyon：以内存为中心高容错的的分布式文件系统。

1. Spark专业语定义

• Application：Spark应用程序
• Driver：驱动程序
• Cluster Manager：资源管理器
• Executor：执行器
• Worker：计算节点
• RDD：弹性分布式数据集
• 窄依赖
• 宽依赖
• DAG：有向无环图
• DAGScheduler：有向无环图调度器
• TaskScheduler：任务调度器
• Job：作业
• Stage：调度阶段
• TaskSet：任务集
• Task：任务
• Hbase

1. Echart可视化工具

• 介绍：Echart是百度研发团队开发的一款报表视图JS插件，功能十分强大，使用内容做简单记录
• Echart的支持图表：折线图（区域图）、柱状图（条状图）、散点图（气泡图）、K线图、饼图（环形图） 雷达图（填充雷达图）、和弦图、力导向布局图、地图、仪表盘、漏斗图、事件河流图等12类图表。
• Echart的使用

1. Spark连接kafka的两种方式

Receiver-based： 这种方法使用一个 Receiver 来接收数据。在该 Receiver 的实现中使用了 Kafka high-level consumer API。Receiver 从 kafka 接收的数据将被存储到 Spark executor 中，随后启动的 job 将处理这些数据。

Direct-based：自 Spark-1.3.0 起，提供了不需要 Receiver 的方法。替代了使用 receivers 来接收数据，该方法定期查询每个 topic+partition 的 lastest offset，并据此决定每个 batch 要接收的 offsets 范围。

• 技术难点

1. SparkStreaming从kafka拉取数据

   设置每3秒切分一次RDD，需要设置拉取的kafka参数，需要拉取的topic，从哪开始消费等。

1. 使用spark-streaming完成日期转换和数据清洗操作

   拉取过来的数据需要根据“\t”进去切分，做数据清洗操作，最后调用filter方法过滤掉companyID为0的CompanyLog

1. 操作HBase数据库的工具类的设计

   在HBaseUtils的构造方法中要设置指定zookeeper的地址和HBase的rootdir。

1. HbaseUtils的使用

   在使用HBaseUtils的时候需要先调用其中的getHTbale（）获取表的对象再用对象调用HBaseUtils里的其它操作方法。

1. 智能终端运动数据对象DAO层的开发

   对调用HbaseUtils获得的表保存并按rowkey进行累加

1. 计算每个公司总步数并把数据保存在HBase上

   在计算每个公司的总步数的时候通过循环镶嵌

ForeachRDD ->foreachpartition->在partiton中创建连接

在foreachpartition中把list（数据）保存到HBase上

 

1. 单例模式的使用

在HBaseUtils类中需要定义一个static HBaseUtils类提供getInstatnce（）的输入。

  在可视化服务这块也需要顶一个Static Map<String,String>提供展示

1. 对于Company的HBaseUtils的query（）的实现

   根据表面和输入条件获取Hbase的记录数，获得表的实例后，要使用前缀过滤器。对表做Scan操作后将结果集封装成map对象并返回。

1. 根据day获取每个公司对应的步数的实现

   在Dao层调用CompanyUtils的query（）方法，因为query（）使用前缀过滤器，所以只需要将day作为参数当作前缀就可以实现功能

1. 可视化Echart的使用

• 案例经验总结

1. Scala与java的关系：

   Scala与Java的关系是非常紧密的！！

因为Scala是基于Java虚拟机，也就是JVM的一门编程语言。所有Scala的代码，都需要经过编译为字节码，然后交由Java虚拟机来运行。

所以Scala和Java是可以无缝互操作的。Scala可以任意调用Java的代码。所以Scala与Java的关系是非常非常紧密的

1. 启动了kafka时执行命令会报错:zookeper is not a recognized option ,原因应该是kafka版本过高，解决方法1：kafka换成旧版本，2：使用新版本的命令
2. 启动kafka之前要启动zookeeper。启动kafka：进入到kafka安装目录：

kafka-server-start.sh config/zookeeper.properties &

创建topic

Bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

展示topic

bin/kafka-topics.sh --list --zookeeper localhost:2181

描述topic

bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic

生产者：

bin/kafka-console-producer.sh --broker-list 130.51.23.95:9092 --topic my-replicated-topic

消费者：

bin/kafka-console-consumer.sh --zookeeper 130.51.23.95:2181 --topic test --from-beginnin

1. 关于@SpringBootApplication

  @SpringBootApplication是一个复合注解，包括@ComponentScan，和@SpringBootConfiguration，@EnableAutoConfiguration

• @SpringBootConfiguration继承自@Configuration，二者功能也一致，标注当前类是配置类，并会将当前类内声明的一个或多个以@Bean注解标记的方法的实例纳入到srping容器中，并且实例名就是方法名。
• @EnableAutoConfiguration的作用启动自动的配置，@EnableAutoConfiguration注解的意思就是Springboot根据你添加的jar包来配置你项目的默认配置，比如根据spring-boot-starter-web ，来判断你的项目是否需要添加了webmvc和tomcat，就会自动的帮你配置web项目中所需要的默认配置。在下面博客会具体分析这个注解，快速入门的demo实际没有用到该注解。

@ComponentScan，扫描当前包及其子包下被@Component，@Controller，@Service，@Repository注解标记的类并纳入到spring容器中进行管理。是以前的<context:component-scan>（以前使用在xml中使用的标签，用来扫描包配置的平行支持）。所以本demo中的User为何会被spring容器管理

1. 在项目需要配置log4j日志的输出路径不然会报错

在boot项目中CompanyStepCountDAO中类中测试按天数查询数据时，自己把CompanyHBaseUtils 中query方法中的自定义family（cf） 和qualifier 不小心多一个字母，然后一直查不出数据。所以以后多多细心。

1. 在可视化图中（localhost：8080.echart）这个公司分类(在echart.xml)的数据是@SpringBootApplication的main方法用复合注解把数据给扫描出来了，具体数据是在CompanyStepStatApp类里面
2. Spark运行基本流程

1. 构建Spark Application运行环境
2. SparkContext向资源管理器注册
3. SparkContext向资源管理器申请运行Executor
4. 资源管理器分配Executor
5. 资源管理器启动Executor
6. Executor发送心跳至资源管理器
7. SparkContext构建DAG图
8. 将DAG分解成Stage（TaskSet）
9. 把Stage发送给TaskScheduler
10. Executor向SparkContext申请Task
11. TaskScheduler将Task发放给Executor运行
12. 同时将SparkContext将应用程序代码发放给Executor
13. Task在Executor上运行，运行完毕后释放所以资源

1. Spark计算比MapReduce快的原因：

1. Spark是基于内存去计算的
2. park的中间结果不落地，MapReduce每次执行完都会讲结果重新写入磁盘
3. 一次MapReduce只有一个job，而Spark程序中一个action相当于一个job，一个Spark程序可以有多个action，中间计算的结果会放在内存中，当内存不够的情况下才会落地到磁盘。
4. Scala中的下划线总结
5. 方法转为函数
6. 集合中的每一个元素
7. 获取元素Tuple的值
8. 模式匹配
9. 队列
10. 导包引入的时候
11. 初始化变量

1. SparkStreaming连接kafka的两种连接方法对比：Receiver-based（非直连），Direct-based（直连）

   在实际的应用中，Direct Approach方式很好地满足了我们的需要，与Receiver-based方式相比，有以下几方面的优势：

1. 降低资源。Direct不需要Receivers，其申请的Executors全部参与到计算任务中；而Receiver-based则需要专门的Receivers来读取Kafka数据且不参与计算。因此相同的资源申请，Direct 能够支持更大的业务。
2. 降低内存。Receiver-based的Receiver与其他Exectuor是异步的，并持续不断接收数据，对于小业务量的场景还好，如果遇到大业务量时，需要提高Receiver的内存，但是参与计算的Executor并无需那么多的内存。而Direct 因为没有Receiver，而是在计算时读取数据，然后直接计算，所以对内存的要求很低。实际应用中我们可以把原先的10G降至现在的2-4G左右
3. 鲁棒性更好。Receiver-based方法需要Receivers来异步持续不断的读取数据，因此遇到网络、存储负载等因素，导致实时任务出现堆积，但Receivers却还在持续读取数据，此种情况很容易导致计算崩溃。Direct 则没有这种顾虑，其Driver在触发batch 计算任务时，才会读取数据并计算。队列出现堆积并不会引起程序的失败。

缺点：提高成本。Direct需要用户采用checkpoint或者第三方存储来维护offsets，而不像Receiver-based那样，通过ZooKeeper来维护Offsets，此提高了用户的开发成本。

监控可视化。Receiver-based方式指定topic指定consumer的消费情况均能通过ZooKeeper来监控，而Direct则没有这种便利，如果做到监控并可视化，则需要投入人力开发