这是我参与「第四届青训营 」笔记创作活动的第16天
1. 企业数据架构
开发工具套件：做数据开发操作、大数据生产、数据资产管理等
数据治理：关注数据生产结果是否符合预期、数据权限管理、数据生命周期管理
1.1 数据集成
业务数据收集-CDC
- 要保证数据不丢失
- 要保证数据有顺序
业务数据收集-Log
数据流向：client/server log --> 数据系统
系统间同步传输
存储系统间数据传输
1.2 数据生产-离线 & 实时
实时处理链路：Flink + Kafka
离线处理链路：Hive + Spark
1.3 数据服务
2 数据中心案例
以房产数据平台为例：
供需关系：
- 房源
- 房增（新增房子的录入量）
- 客源
- 客增（新增客户的录入量）
过程：
- 通话次数
- 带看次数
结果：
- 成交量（成交合同数量）
数据查询要求：
数据中心看板查询条件：
- 时间范围：今天前的任意日期范围
- 业务类型：租赁/买卖/全部
数据展示：
- 查询条件下的每个经纪人的汇总数据
- 支持下钻明细数据
技术要求：
- 300ms内返回结果
- 数据是实时秒级
3，实时数据生产
3.1 数据分析
根据日期、业务类型（买卖、租赁）查询经纪人汇总数据
目标数据产出粒度：经纪人+业务日期+业务类型
计算目标：
- 开发效率：较快满足用户的需求
- 资源成本：计算效率高
- 数据质量：准确无误、数据实时
3.2 计算分析
Lambd架构
Lambda计算架构，分为离线数据流和实时数据流两部分处理，最后通过merge进行合并。
问题：如果遇到历史数据变通，会造成统计错误
全量计算架构
用实时引擎来计算所有的数据
问题：如果遇到历史数据变通，会造成统计错误
解决：
1.取最新“快照”
create view dk as select * from (select * , row_number() over (partition by id order by utime desc) as rownum from dk) where rownum = 1;
2.计算
select date,staff_id,house_type,count(id) as dk_cnt from dk where audit_status=1 group by date, staff_id, house_type
3.2 对比
| 目标 | Lambda架构 | 全量计算架构 |
|---|---|---|
| 开发运行效率 | 效率低：存在实时离线开发任务和merge逻辑 | 效率高：只存在一套实时任务 |
| 资源效率 | 计算资源占用高：离线全量+实时增强 | 状态存储成本相对高：全量+增量 |
| 数据质量实时、准确 | 符合要求 | 符合要求 |
4. 数据服务
4.1 查询快（引擎选择）
指定Key，查询value，类似HashMap --> redis
分析，join，Agg --> ClickHouse、Doris
4.1 查询快（怎么做）
简化查询逻辑模型
select
field1, field2, ... (目标信息)
from
(
select count, sum, max, avg (计算处理)
from
table1 (left/right/inner join table2...) (原始信息关联)
where field1 > xxx and field2 > xxx (原始信息筛选)
group by group_fields
)
查询优化分析：
- 关注目标：不需要的信息不关注
- 计算处理：count/sum/avg等聚合函数
- 原始信息：单表筛选够不够快、信息关联够不够快
4.1 查询快（关注目标信息）
行存：大量io，每行查找需要的列
列存：直接取出对应的列文件
筛选分区：
将数据存储的格式按照 天 进行分区存储，之后可以根据日期快速筛选
筛选PK：
将经常查询的内容，组织成PK，可以利用索引快速定位。
传统优化：RBO CBO
应用优化：
原始信息关联
- Local join
- 预关联：直接生产“大宽表”
计算复杂度
- 预计算
- 提升信息密度
4.2 如何保证稳定
熔断触发策略:
- 比如错误率每秒超过10%
- 响应时间大于5s
动作：直接返回失败
限流、降级
- 限流：根据查询客户端、接口等配置查询限额
- 降级：主备存储/服务集群，降级预案
