思维导图

思维导图

宏观之实时流架构

实时流之lamda架构

lamda架构.png

分析:

1. 批处理层: 也就是大数据中的离线存储。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图
2. 速度层，也就是Flink为代表实时计算,通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了

优势

• lambda使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性

缺点

• lambda架构的复杂性在于我们要同时维护两套系统架构: 批处理层和速度层，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性

应用场景

1. 在广告投放场景中，用户的实时访问数据由实时处理进行处理，进行实时推荐，但推荐内容也需要考虑用户的历史访问记录，这些离线的历史记录则由离线处理进行处理提供
2. 在智能停车场景中，实时系统对进入停车场的车辆数据进行实时分析，但如果多辆车进入，系统可能会给多辆车提供同一个车位，系统体验会很差。但如果通过历史数据，根据拥挤程度，和停车场车位的使用率，来建立模型。这样，实时系统与离线系统的结合，会给出更为出色的方案

实时流之kappa架构

kappa架构.png

优势

• 相对比lamda架构，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层

缺点

• 因为 Kappa 架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会有数据更新出错的情况发生，这就需要我们花费更多的时间在处理这些错误异常上面。还有一点，Kappa 架构的批处理和流处理都放在了速度层上，这导致了这种架构是使用同一套代码来处理算法逻辑的。所以 Kappa 架构并不适用于批处理和流处理代码逻辑不一致的场景

---

宏观之数仓整体架构分层

整体架构分层详解

Flink实时处理架构分层图

flink实时处理架构图.jpg

• 名称解释

1. 数据源层: ODS(Operational Data Store）
   ODS 层, 是最接近数据源中数据的一层, 为了考虑后续可能需要追溯数据问题，ODS层原封不动地接入原始数据。比如从监听数据库变更的Canal读取数据后放入kafka
2. 数据明细层: DWD(Data Warehouse Detail）
   该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。这一层也是为了提高复用性。比如DWS层有多个主题要统一，可能都要用到DWD的某表，所以独立出DWD层有助于数据复用，里面数据叫事实表，跟DIM维度表相对应
3. 维表层: DIM(Dimension）
   如果维表过多，也可针对维表设计单独一层，维表层主要包含两部分数据：比如枚举值含义，SPU，SKU具体内容，省份等
4. 数据中间层: DWM(Data WareHouse Middle）
   该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。比如订单宽表，支付宽表等，当然数据源是可以直接从DWM结合DIM取到，只是为了减少聚合提高复用增加了这一层
5. 数据服务层: DWS（Data WareHouse Service）
   DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表, 主要提供主题域查询
6. ADS: 也叫APP数据应用层，全称可能是Application Data Service
   大屏直接从直接获取数据，ADS从DWS获取数据

Flink实时处理架构分层细节_广播流

flink实时处理架构细节_广播流.png

• 从ODS去获取的数据，具体是要分流到DIM作为维度层数据，还是要到DWD作为事实表存储，可以从mysql配置读取。这里apollo读取没那么合适，因为不是完整的springboot体系

分层举例

举例.png

• 事实数据(绿色)进入kafka数据流(DWD层)中，维度数据(蓝色)进入hbase中长期保存。那么我们在DWM层中要把实时和维度数据进行整合关联在一起，形成宽表。那么这里就要处理有两种关联，事实数据和事实数据关联, 事实数据和维度数据关联。这样对于DWS而言订单是一张宽表，不需要再次聚合DIM获取维度数据，商品主题域等其他主题域也可以复用

需求案例讲解

• 大屏展示中有部分数据需要从商品主题ClickHouse查询

  
  
  

  大屏展示.png

• 需要统计商品主题(DWS层，数据存放到ClickHouse)，商品主题的需求指标是: 点击(DWD)，曝光(DWD)，收藏(DWD)，加入购物(DWD)车，下单(DWM)，支付(DWM)，退款(DWD)，评论(DWD)，需要关联一些DIM，比如SKU, SPU等

  
  
  

  详细例子.png
• ODS层, 可以从canal来, 也可以从kafka等介质来。点击(DWD)，曝光(DWD)，收藏(DWD),加购物车(DWD), 数据可以放到Kafka。SKU，SPU(DIM层，数据是可以放在Hbase)。DWM(下单宽表, 支付宽表，从Kafka取数据)。DWS商品主题(写入ClickHouse)。ADS大屏展示查询，从ClickHouse取数据。这种分层方式，其他主题可以从DWM层获取订单宽表，支付宽表，当然也可直接从DWD层获取数据，更好的分层

上线流程

• 离线数仓初始化数据
• Flink实时从0点开始

---

宏观只数据仓库对比数据湖

• 企业级数据湖最佳实践参考文章中全球化在线游戏实践案例分析
  
  

  在线游戏实践案例分析.png
• OSS 数据湖承载所有日志数据的长期存储。OSS 在这个场景中，作为了日志的的永久存储。SLS 把采集的日志定期投递到 OSS，存储到 OSS 的日志可以进一步通过离线分析，如通过 Spark、Hive 做更大规模的分析，并将深度分析的结果再写入到 ClickHouse，提供更多的分析查询
• 承接更大数据量，全球化，更廉价的业务场景

---

实时数仓常见应用

电商和市场营销

• 实时数据报表，广告投放，实时推荐

1. 在电商行业中，网站点击量是统计 PV、UV 的重要来源，也是如今流量经济的最主要数据指标。很多公司的营销策略，比如广告的投放，也是基于点击量来决定的。另外，在网站上提供给用户的实时推荐，往往也是基于当前用户的点击行为做出的。网站获得的点击数据可能是连续且不均匀的，还可能在同一时间大量产生，这是典型的数据流。如果我们希望把它们全部收集起来，再去分析处理，就会面临很多问题。首先，我们需要很大的空间来存储数据; 其次，收集数据的过程耗去了大量时间，统计分析结果的实时性就大大降低了。所以实时处理就排上用场了。PV，UV这些埋点数据是通过Kafka接收

物联网lot

• 传感器实时数据采集和显示、实时报警，交通运输业

1. 物联网是流数据被普遍应用的领域。各种传感器不停获得测量数据，并将它们以流的形式传输至数据中心。而数据中心会将数据处理分析之后，得到运行状态或者报警信息，实时地显示在监控屏幕上。所以在物联网中，低延迟的数据传输和处理，以及准确的数据分析通常很关键。交通运输业也体现了流处理的重要性。比如说，如今高铁运行主要就是依靠传感器检测数据，测量数据包括列车的速度和位置，以及轨道周边的状况。这些数据会从轨道传给列车，再从列车传到沿途的其他传感器；与此同时，数据报告也被发送回控制中心。因为列车处于高速行驶状态，因此数据处理的实时性要求是极高的。如果流数据没有被及时正确处理，调整意见和警告就不能相应产生，后果可能会非常严重

• 告警可以通过http接口调用发邮件或者发钉钉

物流配送和服务业

• 订单状态实时更新、通知信息推送

1. 在很多服务型应用中，都会涉及订单状态的更新和通知的推送。这些信息基于事件触发，不均匀地连续不断生成，处理之后需要及时传递给用户。这也是非常典型的数据流的处理,
2. 推送可以调http接口推送到, emqx集群，然后再推送。或者直接http接口调小米，华为等推送接口

银行和金融业

• 实时结算和通知推送，实时检测异常行为

1. 银行和金融业是另一个典型的应用行业。用户的交易行为是连续大量发生的，银行面对的是海量的流式数据。由于要处理的交易数据量太大，以前的银行是按天结算的，汇款一般都要隔天才能到账。所以有一个说法叫作“银行家工作时间”，说的就是银行家不仅不需要 996，甚至下午早早就下班了：因为银行需要早点关门进行结算，这样才能保证第二天营业之前算出准确的账。这显然不能满足我们快速交易的需求。在全球化经济中，能够提供 24 小时服务变得越来越重要。现在交易和报表都会快速准确地生成，我们跨行转账也可以做到瞬间到账，还可以接到实时的推送通知。这就需要我们能够实时处理数据流。
2. 信用卡欺诈的检测也需要及时的监控和报警。一些金融交易市场，对异常交易行为的及时检测可以更好地进行风险控制；还可以对异常登录进行检测，从而发现钓鱼式攻击，从而避免巨大的损失

---

Flink

K8s, 应用模式

K8s, 应用模式.png

更细致化整体构成

flink整体架构图.jpg

yarn模式per-job作业提交流程

yarn模式per-job作业提交流程.jpg

并行度

• 每个算子都有自己并行度，一般都说最大并行度，这里是2，整个程序包含了 7 个子任务，至少需要 2 个分区来并行执行，这段流处理程序的并行度就是 2

  
  
  

  并行度.png

并行度设置

1. 对于一个算子，首先看在代码中是否单独指定了它的并行度，这个特定的设置优先级最高，会覆盖后面所有的设置
2. 如果没有单独设置，那么采用当前代码中执行环境全局设置的并行度
3. 如果代码中完全没有设置，那么采用提交时-p 参数指定的并行度
4. 如果提交时也未指定-p 参数，那么采用集群配置文件中的默认并行度
5. 最佳实践: 那就是在代码中只针对算子设置并行度，不设置全局并行度，这样方便我们提交作业时进行动态扩容

合并算子链

• 并行度相同的一对一(数据流维护着分区以及元素的顺序。比如图中的 source 和 map 算子，source算子读取数据之后，可以直接发送给 map 算子做处理，它们之间不需要重新分区，也不需要调整数据的顺序)算子操作，可以直接链接在一起形成一个任务。

  
  
  

  合并算子链.png
• 将算子链接成 task 是非常有效的优化：可以减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量
• 可以手动禁止合并或者自行定义

生成图的顺序

• 逻辑流图（StreamGraph）→ 作业图（JobGraph）→ 执行图（ExecutionGraph）→ 物理图（Physical Graph）

  
  
  

  StreamGraph->JobGraph.png
  
  
  

  ExecutionGraph.png
  
  
  

  物理图.png

Task Slot

• 通过集群的配置文件来设定 TaskManager 的 slot 数量

  
  
  

  Task Slot分配.png

• 保持 sink 任务并行度为 1 不变，而作业提交时设置全局并行度为 6，那么前两个任务节点就会各自有 6 个并行子任务，整个流处理程序则有 13 个子任务

  
  
  

  Task Slot分配1.png
• 可以考虑把计算密集型和IO密集型的任务同时放到一个 slot 中，它们就可以自行分配对资源占用的比例，从而保证最重的活平均分配给所有的
• 也可以通过设置slot 共享组（SlotSharingGroup）手动指定，只有属于同一个 slot 共享组的子任务，才会开启 slot 共享

.map(word -> Tuple2.of(word, 1L)).slotSharingGroup(“1”);

实战

• 以上分析均参考了开源的尚硅谷开源Flink
• 实战篇可以参考 业务实战场景(十一)实时流Flink实战

---

参考文章

• 实时数仓：Lambda架构
• lambda架构和kappa架构的对比
• 离线+实时数仓建设方案
• 企业级数据湖最佳实践
• 数据湖和数据仓库的区别是什么
• 事实表和纬度表区别
• Flink广播流——BroadcastStream