实时--千亿级数仓项目-黑马

秒速五厘米 2022-10-21 01:31 275阅读 0赞

state（状态）：可以看成一个中间结果存储系统。  
将source -> map -> faile->rdurce ->…-> sink 每个算子的计算成功结果存储起来，方便系统宕机重启后直接中状态存储中拿出计算结果继续计算，不必再重新计算。

# 大数据分析平台架构分类 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70]

数据分析的基础架构可以分为以下几类：

*  使用Hadoop/Spark进行分析
 *  将Hadoop/Spark的结果导入 RDBMS 中提供数据分析
 *  将结果注入到容量更大的 NoSQL中，解决数据分析的存储瓶颈，例如：HBase
 *  将数据源进行流式处理，对接流式计算框架，例如：Flink、Spark Streaming，结果保存到 RDBMS、NoSQL中
 *  将数据源进行流式处理，对接分析数据库，例如：Druid

#### 基于Hadoop大数据平台的问题 ####

基于 Hadoop 的大数据平台，有如下一些问题：

*  无法保障查询性能
    
     *  对于Hadoop使用的MapReduce批处理框架，数据何时能够查询没有性能保证
 *  随机IO问题
    
     *  HDFS以集群硬盘作为存储资源池的分布式文件系统
     *  在海量数据的处理过程中，会引起大量的读写操作，随机IO是高并发场景下的性能瓶颈
 *  数据可视化问题
    
     *  HDFS对于数据分析以及数据的即席查询，HDFS并不是最优的选择

传统的Hadoop大数据处理架构更倾向于一种“后台批处理的数据仓库系统”，其作为海量历史数据保存、冷数据分析，确实是一个优秀的通用解决方案，但

*  无法保证高并发环境下海量数据的查询分析性能
 *  无法实现海量实时数据的查询分析与可视化

# 1. 使用到的技术 #

*  Canal客户端采集binlog消息 （mysql->kafka/hdfs）
 *  理解google ProtoBuf序列化方式 (提高网络传输效率)

# 2.实时计算应用场景及技术选型 #

### 实时计算在公司的用处 ###

公司内已经采用MR与spark之类的技术，做离线计算，为什么用实时计算？

*  离线的伤痛就是数据出的**太慢**
 *  有对实时数据要求高的场景
    
     *  比如：滴滴的风控、淘宝双十一营销大屏、电商购物推荐、春晚的观众数统计

### 实时计算技术选型 ###

Spark streaming、 Struct streaming、Storm、JStorm（阿里）、Kafka Streaming、Flink技术栈这么多，到底选哪个？

**项目技术选型考虑点：**

*  公司员工的技术基础
 *  流行
 *  技术复用
 *  业务场景要求(最重要)

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 1]

如果**对延迟要求不高**的情况下，可以使用 Spark Streaming，它拥有丰富的高级 API，使用简单，并且 Spark 生态也比较成熟，吞吐量大，部署简单，社区活跃度较高，从 GitHub 的 star 数量也可以看得出来现在公司用 Spark 还是居多的，并且在新版本还引入了 Structured Streaming，这也会让 Spark 的体系更加完善。

如果**对延迟性要求非常高**的话，可以使用当下最火的流处理框架 Flink，采用原生的流处理系统，保证了低延迟性，在 API 和容错性方面做的也比较完善，使用和部署相对来说也是比较简单的，加上国内阿里贡献的 Blink，相信接下来 Flink 的功能将会更加完善，发展也会更加好，社区问题的响应速度也是非常快的，另外还有专门的钉钉大群和中文列表供大家提问，每周还会有专家进行直播讲解和答疑。

本次项目：使用**Flink**来搭建实时计算平台

# 3.项目实施环境 #

### 数据 ###

*  目前已经存在订单数据，业务系统会将订单写入到mysql
 *  流量日志数据（访问日志）

### 硬件 ###

*  4台物理服务器
 *  服务配置
    
     *  CPU x 2：志强E5 主频2.8 - 3.6，24核（12核 per CPU）
     *  内存（768GB/1T）
     *  硬盘（1T x 8 SAS盘）
     *  网卡（4口 2000M）

### 人员 ###

*  4人
    
     *  前端（2人 JavaWeb + UI前端）
     *  大数据（2人）

### 时间 ###

*  一个月左右
 *  阶段
    
     *  需求调研、评审（2周）
     *  设计架构（3天）
     *  编码、集成（1周）
     *  测试、上线（2天）

## 需求分析 ##

### 项目需求 ###

*  目前已经有前端可视化项目，公司需要大屏用于展示订单数据与用户访问数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 2]

### 数据来源 ###

#### PV/UV数据来源 ####

*  来自于页面埋点数据，将用户访问数据发送到web服务器
 *  web服务器直接将该部分数据写入到kafka的**click\_log** topic 中

#### 销售金额与订单量数据来源 ####

*  订单数据来源于mysql
 *  订单数据来自binlog日志，通过canal 实时将数据写入到kafka的**order**的topic中

#### 购物车数据和评论数据 ####

*  购物车数据一般不会直接操作mysql，通过客户端程序写入到kafka（消息队列）中
 *  评论数据也是通过客户端程序写入kafka（消息队列）中

# 4. 常见的软件工程模型 #

1.  瀑布模型
2.  敏捷开发

## 1. 瀑布模型 ##

*  在一些银行、政府、等传统行业系统中，该模式应用较多

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 3]  
特点

1.  上一项开发活动其成果作为本次活动的输入
2.  给出本次活动的工作成果，作为输出传给下一项开发活动
3.  对本次活动的实施工作成果进行**评审**
    
     *  评审通过，则继续进行下一项开发活动
     *  评审不通过，则返回前一项，甚至更前项的活动

使用范围

1.  用户需求很清楚，在开发过程中变化较少
2.  开发人员对业务很熟悉
3.  用户的使用环境较稳定；
4.  开发工作对用户参与的要求很低。

优点

1.  人员职责明确、具体，有利于大型软件开发过程中人员的组织、管理
2.  实施步骤清晰、有序，有利于软件开发方法和工具的研究，保障大型项目质量/效率

缺点

1.  开发过程一般不能逆转，否则代价太大
2.  实际的项目开发很难严格按该模型进行
3.  客户很难清楚地给出所有的需求
4.  软件实际情况必须到项目开发的后期才能看到，这要求客户有足够的耐心

## 2. 敏捷开发 ##

#### 介绍 ####

*  以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发
 *  把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成
 *  在开发过程中软件一直处于可使用状态

#### 优点 ####

*  敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品
 *  注重市场快速反应能力，也即具体应对能力，客户前期满意度高

#### 缺点 ####

*  敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累
 *  需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题

# 5.实现方案 #

## JAVA web 方式实现 ##

**JAVA web 方式实现数据量小情况和大数据没有关系**

*  一些中小企业当中，由于数据量较小（比如核心总量小于20万条），可通过Java程序定时查询mysql实现
 *  比较简单，但是粗暴实用
 *  仅仅需要对mysql做一些优化即可，比较增加索引

## 通过flink方案实现 ##

*  数据量特别大、无法直接通过mysql查询完成，有时候根本查询不动
 *  要求实时性高，比如阿里巴巴双十一监控大屏，要求延迟不超过1秒

# 6.实时数仓项目架构 #

目前实时数仓项主要是通过 flink dataStreaming只做前期数据的清洗(ETL)，保存在存储中(如Hbase)，后期的查询计算用过Sql查询的方式实现。  
避免每次更改查询维度(如修改时间窗口)，修改flink 代码 重新打包测试上线。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 4]

apache druid（德鲁伊） 是分布式列存储的 OLAP 框架数据库，还是一个时间序列数据库  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 5]

![在这里插入图片描述][20210505152541773.png]

# HBase整合Phoenix --黑马 #

[HBase整合Phoenix --黑马][HBase_Phoenix --]

# Flink程序优化 #

[Flink程序优化][Flink]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70]: /images/20221021/abbaaaa6dfff4838bde189b1ae19b123.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 1]: /images/20221021/dfc525fe948347aebe5875ea0c333e7e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 2]: /images/20221021/2346b5d5c63a4bf9a7f9961eafbf02ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 3]: /images/20221021/709ecb0dc32f42399b5023895ffb04d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 4]: /images/20221021/9c10847a52194d4fa8173f1610154ddf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 5]: /images/20221021/0b10ad5de8e9446ba2071c322e86d32a.png
[20210505152541773.png]: /images/20221021/bdf6c226932746bdb0616a9b72fd5bb3.png
[HBase_Phoenix --]: https://blog.csdn.net/yangshengwei230612/article/details/116426195
[Flink]: https://blog.csdn.net/yangshengwei230612/article/details/116426223