Flink实时数仓（尚硅谷）- 数据采集_flink实时数据采集

本博客内容出自尚硅谷b站公开课，如有侵权，请联系博主删除

第 1 章 电商实时数仓分层介绍

1.1 普通实时计算与实时数仓比较

普通的实时计算优先考虑时效性，所以从数据源采集经过实时计算直接得到结果。如此
做时效性更好，但是弊端是由于计算过程中的中间结果没有沉淀下来，所以当面对大量实时
需求的时候，计算的复用性较差，开发成本随着需求增加直线上升。

实时数仓基于一定的数据仓库理念，对数据处理流程进行规划、分层，目的是提高数据
的复用性。

1.2 实时电商数仓，项目分为以下几层

• ODS：原始数据，日志和业务数据
• DWD：根据数据对象为单位进行分流，比如订单、页面访问等等
• DIM：维度数据
• DWM：对于部分数据对象进行进一步加工，比如独立访问、跳出行为，也可以和维度进行关联，形成宽表，依旧是明细数据。
• DWS：根据某个主题将多个事实数据轻度聚合，形成主题宽表。
• ADS：把ClickHouse中的数据根据可视化需进行筛选聚合

第 2 章 实时需求概览

2.1 离线计算与实时计算的比较

离线计算：就是在计算开始前已知所有输入数据，输入数据不会产生变化，一般计算量级较大，计算时间也较长。例如今天早上一点，把昨天累积的日志，计算出所需结果。最经典的就是 Hadoop 的 MapReduce 方式；

一般是根据前一日的数据生成报表，虽然统计指标、报表繁多，但是对时效性不敏感。从技术操作的角度，这部分属于批处理的操作。即根据确定范围的数据一次性计算。

实时计算：输入数据是可以以序列化的方式一个个输入并进行处理的，也就是说在开始的时候并不需要知道所有的输入数据。与离线计算相比，运行时间短，计算量级相对较小。强调计算过程的时间要短，即所查当下给出结果。

主要侧重于对当日数据的实时监控，通常业务逻辑相对离线需求简单一下，统计指标也少一些，但是更注重数据的时效性，以及用户的交互性。从技术操作的角度，这部分属于流处理的操作。根据数据源源不断地到达进行实时的运算。

2.2 实时需求种类

2.2.1 日常统计报表或分析图中需要包含当日部分

对于日常企业、网站的运营管理如果仅仅依靠离线计算，数据的时效性往往无法满足。通过实时计算获得当日、分钟级、秒级甚至亚秒的数据更加便于企业对业务进行快速反应与调整。

所以实时计算结果往往要与离线数据进行合并或者对比展示在 BI 或者统计平台中。

2.2.2 实时数据大屏监控

数据大屏，相对于 BI 工具或者数据分析平台是更加直观的数据可视化方式。尤其是一些大促活动，已经成为必备的一种营销手段。

另外还有一些特殊行业，比如交通、电信的行业，那么大屏监控几乎是必备的监控手段。

2.2.3 数据预警或提示

经过大数据实时计算得到的一些风控预警、营销信息提示，能够快速让风控或营销部分得到信息，以便采取各种应对。

比如，用户在电商、金融平台中正在进行一些非法或欺诈类操作，那么大数据实时计算可以快速的将情况筛选出来发送风控部门进行处理，甚至自动屏蔽。 或者检测到用户的行为对于某些商品具有较强的购买意愿，那么可以把这些“商机”推送给客服部门，让客服进行主动的跟进。

2.2.4 实时推荐系统

实时推荐就是根据用户的自身属性结合当前的访问行为，经过实时的推荐算法计算，从而将用户可能喜欢的商品、新闻、视频等推送给用户。

这种系统一般是由一个用户画像批处理加一个用户行为分析的流处理组合而成。

第 3 章 统计架构分析

3.1 离线架构

3.2 实时架构

第 4 章 日志数据采集

4.1 模拟日志生成器的使用

略

4.2 日志采集模块-本地测试

略

4.2.1 SpringBoot 简介

设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。 该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。

1) 有了 springboot 我们就可以…

不再需要那些千篇一律，繁琐的 xml 文件。

• 内嵌 Tomcat,不再需要外部的 Tomcat
• 更方便的和各个第三方工具（mysql,redis,elasticsearch,dubbo,kafka 等等整合），而只要维护一个配置文件即可。

2) springboot 和 ssm 的关系

springboot 整合了 springmvc，spring 等核心功能。也就是说本质上实现功能的还是原有的 spring ,springmvc 的包，但是 springboot 单独包装了一层，这样用户就不必直接对 springmvc，spring 等，在 xml 中配置。

3) 没有 xml，我们要去哪配置

springboot 实际上就是把以前需要用户手工配置的部分，全部作为默认项。除非用户需要额外更改不然不用配置。这就是所谓的：“约定大于配置”

如果需要特别配置的时候，去修改 application.properties（application.yml）

4.3 日志采集模块-打包单机部署

略

4.4 日志采集模块-打包集群部署，并用 Nginx 进行反向代理

略

第 5 章 业务数据库数据采集

5.1 FlinkCDC 入门

尚硅谷大数据技术之 Flink-CDC（转）

5.2 MySQL 的准备

略

5.3 环境搭建

略

5.4 代码实现

5.4.1 将流数据推送下游的 Kafka 的 Topic 中

略

5.4.2 编写主程序，消费 MySQL 变化数据并将数据写入 Kafka

略

5.5 运行测试

略

第 6 章 附录 1：Nginx 教程

6.1 Nginx 简介

Nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器,特点是占有内存少，并发能力强，事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用 nginx 网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

Nginx 是由俄罗斯人 Igor Sysoev 采用 C 语言开发编写的，第一个公开版本 0.1.0 发布于 2004 年 10 月 4 日。

6.2 正向代理和反向代理概念

正向代理类似一个跳板机，代理访问外部资源。比如：我是一个用户，我访问不了某网站，但是我能访问一个代理服务器，这个代理服务器，它能访问那个我不能访问的网站，于是我先连上代理服务器，告诉它我需要那个无法访问网站的内容，代理服务器去取回来,然后返回给我。

反向代理（Reverse Proxy）方式是指以代理服务器来接受 internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器；

6.3 Nginx 主要应用

6.3.1 静态网站部署

Nginx 是一个 HTTP 的 web 服务器，可以将服务器上的静态文件（如 HTML、图片等）通过 HTTP 协议返回给浏览器客户端。

6.3.2 负载均衡

在网站创立初期，我们一般都使用单台机器对外提供集中式服务。随着业务量的增大，我们一台服务器不够用，此时就会把多台机器组成一个集群对外提供服务，但是，我们网站对外提供的访问入口通常只有一个，比如 www.web.com。那么当用户在浏览器输入www.web.com 进行访问的时候，如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡要做的事情。

负载均衡通常是指将请求"均匀"分摊到集群中多个服务器节点上执行，这里的均匀是指在一个比较大的统计范围内是基本均匀的，并不是完全均匀

常用的负载均衡策略：轮询、权重、随机…

6.3.3 静态代理

把所有静态资源的访问改为访问 nginx，而不是访问 tomcat，这种方式叫静态代理。因为 nginx 更擅长于静态资源的处理，性能更好，效率更高。

所以在实际应用中，我们将静态资源比如图片、css、html、js 等交给 nginx 处理，而不是由 tomcat 处理。

6.3.4 动静分离

Nginx 的负载均衡和静态代理结合在一起，我们可以实现动静分离，这是实际应用中常见的一种场景。

动态资源，如 jsp 由 tomcat 或其他 web 服务器完成

静态资源，如图片、css、js 等由 nginx 服务器完成

它们各司其职，专注于做自己擅长的事情

动静分离充分利用了它们各自的优势，从而达到更高效合理的架构

6.4 Nginx 安装以及相关命令

略

6.5 配置负载均衡

略

第 7 章 附录 2：Maxwell 介绍

Maxwell 是由美国 Zendesk 开源，用 Java 编写的 MySQL 实时抓取软件。 实时读取 MySQL 二进制日志 Binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。

官网地址：http://maxwells-daemon.io/

略

第 8 章 附录 3：Canal 搭建教程

8.1 Canal 入门

8.1.1 什么是 Canal

阿里巴巴 B2B 公司，因为业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了同步杭州和美国异地机房的需求，从 2010 年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务。

Canal 是用 java 开发的基于数据库增量日志解析，提供增量数据订阅&消费的中间件。目前，Canal 主要支持了 MySQL 的 Binlog 解析，解析完成后才利用 Canal Client 来处理获得的相关数据。（数据库同步需要阿里的 Otter 中间件，基于 Canal）。

8.1.2 使用场景

(1) 原始场景： 阿里 Otter 中间件的一部分

Otter 是阿里用于进行异地数据库之间的同步框架，Canal 是其中一部分。

(2) 常见场景1：更新缓存

(3) 常见场景2：抓取业务数据新增变化表，用于制作拉链表。

(4) 常见场景3：抓取业务表的新增变化数据，用于制作实时统计（我们就是这种场景）

8.1.3 Canal 的工作原理

(1) MySQL 主从复制过程

• Master 主库将改变记录，写到二进制日志(Binary log)中
• Slave 从库向 mysql master 发送 dump 协议，将 master 主库的 binary log events 拷贝到它的中继日志(relay log)；
• Slave 从库读取并重做中继日志中的事件，将改变的数据同步到自己的数据库。

(2) Canal 的工作原理

很简单，就是把自己伪装成 Slave，假装从 Master 复制数据

8.1.4 MySQL 的 Binlog

(4) 什么是 Binlog

MySQL 的二进制日志可以说 MySQL 最重要的日志了，它记录了所有的 DDL 和 DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL 的二进制日志是事务安全型的。

一般来说开启二进制日志大概会有 1%的性能损耗。二进制有两个最重要的使用场景:

• 其一：MySQL Replication 在 Master 端开启 Binlog，Master 把它的二进制日志传递给 Slaves 来达到 Master-Slave 数据一致的目的。
• 其二：自然就是数据恢复了，通过使用 MySQL Binlog 工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的 DDL 和 DML(除了数据查询语句)语句事件。

(5) Binlog 的开启

找到 MySQL 配置文件的位置

• Linux: /etc/my.cnf
• 如果/etc 目录下没有，可以通过 locate my.cnf 查找位置
• Windows: \my.ini
• 在 mysql 的配置文件下,修改配置
  在[mysqld] 区块，设置/添加 log-bin=mysql-bin
• 这个表示 binlog 日志的前缀是 mysql-bin，以后生成的日志文件就是 mysql-bin.123456 的文件后面的数字按顺序生成，每次 mysql 重启或者到达单个文件大小的阈值时，新生一个文件，按顺序编号。

(6) Binlog 的分类设置

mysql binlog 的格式有三种，分别是 STATEMENT,MIXED,ROW。

在配置文件中可以选择配置 binlog_format= statement|mixed|row

三种格式的区别：

• statement
  • 语句级，binlog 会记录每次一执行写操作的语句。
  • 相对 row 模式节省空间，但是可能产生不一致性，比如
  • update tt set create_date=now()
  • 如果用 binlog 日志进行恢复，由于执行时间不同可能产生的数据就不同。
  • 优点： 节省空间
  • 缺点： 有可能造成数据不一致。
• row
  • 行级， binlog 会记录每次操作后每行记录的变化。
  • 优点：保持数据的绝对一致性。因为不管 sql 是什么，引用了什么函数，他只记录执行后的效果。
  • 缺点：占用较大空间。
• mixed
  • statement 的升级版，一定程度上解决了，因为一些情况而造成的 statement 模式不一致问题
  • 默认还是 statement，在某些情况下譬如：
  • 当函数中包含 UUID() 时；
  • 包含 AUTO_INCREMENT 字段的表被更新时；
  • 执行 INSERT DELAYED 语句时；
  • 用 UDF 时；
  • 会按照 ROW 的方式进行处理
  • 优点：节省空间，同时兼顾了一定的一致性。
  • 缺点：还有些极个别情况依旧会造成不一致，另外 statement 和 mixed 对于需要对 binlog 的监控的情况都不方便。

综合上面对比，Cannel 想做监控分析，选择 row 格式比较合适

8.2 MySQL 的准备

略

8.3 canal 架构以及安装

8.3.1 canal 架构

8.3.2 canal 的下载和安装

略

8.4 canal 单机版

略

8.5 canal 高可用（了解）

这种 zookeeper 为观察者监控的模式，只能实现高可用，而不是负载均衡，即同一时点只有一个 canal-server 节点能够监控某个数据源，只要这个节点能够正常工作，那么其他监控这个数据源的 canal-server 只能做 stand-by，直到工作节点停掉，其他 canal-server 节点才能抢占。因为有一个 stand-by 也要占用资源，同时 canal 传输数据宕机的情况也比较少，所以好多企业是不配置 canal 的高可用的。

略

8.6 Maxwell 与 Canal 工具对比

略

8.7 Maxwell 的初始化数据功能

略