实时数仓简介

电商实时数仓分层介绍

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

传统实时数仓

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

实时数仓

但是会牺牲一定的时效性，因为前面的计算流程会被保留以便于后续。但是在生产环境中，需求繁多且复杂，这时需要牺牲一定的时效性。

数仓分层

ODS： 原始数据、日志和业务数据存放于Kafka中，因为我们要做实时计算。

DWD： 根据数据对象单位进行分流(侧输出流)，比如订单、页面访问等。（日志数据和业务数据的事实表存放DWD层，放在Kafka中，DIM数据也会存在DWD中，放在Hbase中，DWD层数据存储分为Kafka和Hbase两块，结合Phoenix使用）；

DIM： 存放维度数据，维度表通过和事实数据join，使得事实数据更加完整。事实表数据通过查维度数据的id将维度数据补充到事实表中，这是维度数据的一个用法；

DWD和DIM可以看作同一层，两者数据同时生成，不过存储位置不一样。（一个Kafka，一个HBase）

DWM：对于部分数据对象进行进一步加工，比如独立访问、跳出行为，也可以和维度进行关联，形成宽表，依旧是明细数据。是将DWD和DIM数据计算抽取到DWS层一些共用的计算中间数据存放在DWM层，以提高计算复用性。数据存放在Kafka中，因为还需要接着被消费加工；

DWS：根据某个主题（维度）将多个事实睡觉轻度聚合，形成主题宽表。数据来源于DWD和DIM加工后的DWM层或某些不需要加工的DWD数据。DWS最后要进行轻度聚合做查询，所以数据存放在ClickHouse中；

ADS：把 Clickhouse中的数据根据可视化需求进行筛选聚合，不落盘，后续进行深度聚合；

为什么ODS、DWD数据存放在Kafka中，而DIM维度数据存放在HBase？

Kafka无法永久保存数据，只能默认保存数据一段时间，而维度数据保存期限长，不适合放在Kafka保存；

维度表的使用需要通过事实表的id去查询维度表对应的维度主题id，而Kafka中该操作不支持；

实时需求概览

离线和实时计算对比

离线计算

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

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

实时计算

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

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

即席查询

除了上述两者，还有一个即席查询。离线计算和实时计算突出的是固定的需求，而即席查询突出的是临时需求，不是每天固定的计算指标，而是临时的一些计算，比如某个月几号到几号的数据指标。

Presto:当场计算（基于内存速度快）

Kylin：预计算（提前算好），多维分析

sex dept addr =>

人数

0-dim 1

1-dim 3

…

实时需求种类

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

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

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

实时数据大屏监控

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

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

数据预警或提示

预警系统只做实时，不做离线，预警需求最要求时效性。

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

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

实时推荐系统

（有电影的推荐系统，先看电影的，里面讲了数学基础）

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

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

*统计架构分析

离线架构

系统数据流程设计

Sqoop

sqoop同步数据的方式：

增量同步

全量同步（where 1=1）

新增及变化

特殊（仅导入一次）

sqoop如何处理导入的数据：

在sql中通过where条件来判断日期，只要是新增，那创建时间等于当前时间。新增及变化则是创建时间 or 修改时间等于当前时间。

Flume

在离线数仓中，我们采用Flume采集行为数据，用的是：

TailDirSource
- 优点：断点续传，监控多目录多文件
- 缺点：当文件更名之后，会重新读取该文件，造成数据重复 — [[Flume TaildirSource重复读取实操]]
- 注意：
  - 1.要使用不更名的打印日志框架(logback)
  - 2.修改源码（flume-taildir-source-1.9.0.jar），让TailDirSource判断文件时只看iNode值
KafkaChannel：
- 优点：便于实时监控，将数据写入Kafka省了一层sink

KafkaChannel这个组件在Flume中属于Channel，在Kafka中该组件是生产者，同时也可以作为消费者。

KafkaChannel用法：
1. Source-KafkaChannel-Sink
2. Source-KafkaChannel
3. KafkaChannel-Sink

记框架：数据流、监控、优化、配置。（锻炼逻辑思维和表达能力）

复习参考：大数据数据采集框架复盘—Flume

Kafka

生产者（Producer）：

往Kafka写数据
ACK
- 0
- 1
- -1
主题、
分区、
拦截器、
序列化器、
分区器、
发送流程、
事务、
sebder线程和main线程、发送流程中的事务幂等性、
分区规则
- 有指定分区则发往指定分区
- 没有指定分区则根据key值hash
- 没有分区也没有key，轮询（粘性分区））

如何保证生产者不丢数据？

问的就是ACK

Kafka服务集群（Broker）

Topic
- 副本：高可靠
  - ISR： LEO、HW
- 分区：高并发（从生产者和消费者角度上，读写）、负载均衡（从集群角度上看，防止热点—假设某个主题数据用的特别多，该主题下只有一个分区，分区存在一个服务器上，那么所有消费者都来找这个分区，对这台机器造成压力过大，其他机器比较空闲）

消费者（Consumer）

分区分配规则
- 粘性分区，当当前分区个数或消费者个数发生变化，会启用粘性分区，尽量让之前的消费者和之前分区是绑定的。
- 但是，第一次启动的时候采用的是login range来绑定
offset保存问题
- 2.4.1 默认保存到__consumer_offsets主题，默认50各分区
- 其他保存方式：
  - 手动维护Offset（mysql,有事务，可以将最终的数据和offset保存到一个事务 —> 做到精准一次性消费），即保存数据&保存事务写到一个事务
  - 如果保存数据和保存offset不提交到一个事务，则会导致一前一后发生。
    - 比如先保存数据，后提交offset ，可能会造成重复数据
    - 先保存offset后保存数据，会导致丢失数据。
    - 如果下游没有事务，但是有幂等性，重复数据+幂等性（精准一次消费），
    - 生产环境一般以重复数据+幂等性来做到精准一次消费，通过框架的幂等性，对重复数据进行去重。