Flink real-time data warehouse completed

First look at the effect of the finished project

GitHub地址：https://github.com/GTyingzi/Flink_Demo

Gitee地址：https://gitee.com/gtcs/Flink-Demo

Main frame version selection

框架	版本
Hadoop	3.13
Zookeeper	3.5.7
Kafka	2.4.1
HBase	2.0.5
Phoenix	5.0.0
MySQL	5.7.16
Redise	6.2.1
ClickHouse	20.4.5.36
Flink	1.13.0
Nginx	1.12.2
java	1.8.0_212
SpringBoot	2.3.7
scala	2.12

集群服务器规划

服务名称	子服务	服务器(hadoop102)	服务器(hadoop103)	服务器(hadoop104)
HDFS	NameNode	√
	DataNode	√	√	√
Zookeeper	Zookeeper Server	√	√	√
Kafka	Kafka	√	√	√
MySQL	MySQL	√
Redise	Redis	√
ClickHouse	ClicHouse	√
Nginx	Nginx	√
HBase	HMaster	√
	HRegionServer	√	√	√
Flink	Flink	√	√	√
Phoenix	Phoenix	√

实时架构

• ODS：原始数据,日志、业务数据
• DWD：根据数据对象为单位进行分流,比如订单、页面访问等
• DIM：维度数据
• DWM：Further processing of some data objects,It can also be associated with dimensional data,形成宽表
• DWS：根据某个主题将多个事实数据轻度聚合,形成主题宽表
• ADS：将ClickHouse中的数据可视化

架构的选择

分层分析

ODS

数据源：行为数据,业务数据
架构分析：
FlinkCDC：
	DataStream/FlinkSQL
	FlinkCDC/Maxwell/Canal
	保持数据原貌,不做任何修改！
	ods_base_log,ods_base_db

DWD-DIM

行为数据：DWD（Kafka）
  1、过滤数据 -> 侧输出流 dirty data rate
  2、新老用户校验 -> Front desk check is not allowed
  3、分流 -> 侧输出流 页面、启动、曝光、动作、错误
  4、写入Kafka
 业务数据：DWD（Kafka）-DIM（Phoenix）
  1、过滤数据 -> 删除数据
  2、读取配置表创建广播流
  3、连接主流和广播流
	1）广播流数据：
		a、解析数据
		b、Phoenix建表
		c、Write status broadcast
	2）主流数据
		a、读取状态
		b、过滤字段
		c、分流（添加SinkTable字段）
  4、提取Kafka和HBasethe corresponding positions of the streams
  5、HBase流：自定义Sink
  6、Kafka流：自定义序列化方式

DWM

DWM的定位：服务DWS,Some of the requirements are directly from DWD到DWSThere will be a certain amount of calculation in the middle,And this part of the calculation results may be multipleDWSTopic reuse,Hence this partDWD会形成一层DWM,There are four main businesses here：访问UV计算、跳出明细计算、订单宽表、支付宽表

UV（Unique Visitor）：独立访客,Also known as in real-time computingDAU（Daily Active User）.Identify today's visitors from user behavior logs
	1、Identify the first page the visitor opens,Indicates that the visitor started entering our app
	2、Visitors can enter the app multiple times a day,Deduplication is to be carried out within a day

跳出：The user exits after successfully visiting a page of the website.Do not continue to visit other pages of the site.跳出率 = 跳出次数/访问次数,Paying attention to bounce rate can see whether the incoming visitors can be attracted quickly,Comparison of the quality of users attracted by channels.Jump out of behavioral traits（The essence is conditional time+A combination of timeouts）
	1、该页面是用户近期访问的第一个页面
	2、首次访问之后很长一段时间,用户没继续再有其他页面的访问
	
订单宽表：Orders are important objects for statistical analysis,围绕订单有很多的维度统计需求,如用户、地区、商品、品类、Brands, etc. are convenient for subsequent statistical calculations,减少大表之间的关联,Therefore, in the real-time calculation process, the relevant data around the order is integrated into an order-wide table
	Cache bypass optimization
	Asynchronous query optimization
	
支付宽表：支付宽表的目的,最主要的原因是支付表没有到订单明细,支付金额没有细分到商品上,没有办法统计商品级的支付状况.The core of the payment wide table is that the information of the payment table is associated with the order wide table
	1、一个是把订单宽表输出到 HBase 上,在支付宽表计算时查询 HBase,这相当于把订单宽表作为一种维度进行管理
	2、一个是用流的方式接收订单宽表,然后用双流 join 方式进行合并.因为订单与支付产生有一定的时差.所以必须用 intervalJoin 来管理流的状态时间,保证当支付到达时订单宽表还保存在状态中.

DWS

DWS层的定位：
	轻度聚合,因为 DWS 层要应对很多实时查询,If it is a complete detail, the pressure of the query is very large
	将更多的实时数据以主题的方式组合起来便于管理,同时也能减少维度查询的次数
	
需求分析与思路：
	Receive individual detail data,becomes a data stream
	把数据流合并在一起,becomes a stream of data objects of the same format
	Aggregate the merged stream,聚合的时间窗口决定了数据的时效性
	Write the aggregated results in the database

FlinkCDC的选取

	FlinkCDC	Maxwell	Canal
断点续传	CK	MySQL	本地磁盘
SQL -> 数据	无	无	一对一（炸开）
初始化功能	有（多库多表）	有（单表）	无
封装格式	自定义	JSON	JSON（c/s自定义）
高可用	运行集群高可用	无	集群（ZK）

Cache bypass optimization

A very common pattern for allocating cache on demand.如下图,任何请求优先访问缓存, 缓存命中,直接获得数据返回请求.如果未命中则,查询数据库,At the same time, the result is written to the cache for preparation 后续请求使用

Considerations for this caching strategy

• 缓存要设过期时间,不然冷数据会常驻缓存浪费资源
• 要考虑维度数据是否会发生变化,如果发生变化要主动清除缓存

缓存选型

一般两种：堆缓存或者独立缓存服务(redis,memcache)

• 堆缓存：Better from a performance perspective,Access data paths are shorter,减少过程消耗.但是管理性差, 其他进程无法维护缓存中的数据
• 独立缓存服务：本身性能也不错,不过会有创建连接、网络 IO 等消耗.但是考虑到数据如果会发生变化,那还是独立缓存服务管理性更强,而且如果数据量特别大,独立缓存更容易扩展

Asynchronous query optimization

默认情况下,在 Flink 的 MapFunction 中,单个并行只能用同步方式去交互: 将请求 发送到外部存储,IO 阻塞,等待请求返回,然后继续发送下一个请求.这种同步交互的方式往往在网络等待上就耗费了大量时间.为了提高处理效率,可以增加 MapFunction 的并 行度,但增加并行度就意味着更多的资源,并不是一种非常好的解决方式

异步查询实际上是把维表的查询操作托管给单独的线程池完成,This will not be because of a certain investigation query causes blocking,单个并行可以连续发送多个请求,提高并发效率,这种方式特别针对涉及网络 IO 的操作,减少因为请求等待带来的消耗

原文链接：FlinkThe real-time data warehouse is completed~