这是我参与「第四届青训营」笔记创作活动的的第18天
01.企业数据架构
1.1 数据集成-业务数据收集CDC
数据流向:业务数据库->数据系统
1.1 数据集成业务数据收集-Log
1.1 数据集成-系统间同步传输
存储系统间数据传输
1.2 数据生产-离线&实时
数据流向:原始数据->数据处理pipeline
1.3 数据服务
数据流向:数据系统->业务系统
02.数据中心案例
02.房产业务介绍
2.1 房产数据中心-核心数据指标
- 供需(房子全不全?客户多不多?)
(1)房源
(i)房增(新增房子的录入量)
(2)客源
(i)客增(新增客户的录入量)
2) 过程(工作做的怎么样?)
(1)通数经名人和客户电话次数)
(2)带看次人带客户看房次数)
- 结果(结果好不好?)
(1)成交量(成交合同量)
2.2 房产数据中心-数据查询要求
数据中心看板查询条件:
● 时间范围:今天前的任意日期范围
● 业务类型:租赁/买卖/全部
数据展示:
● 查询条件下的每个经纪人的汇总数据
● 支持下钻明细数据
技术要求:
● 300ms内返回结果
● 数据是实时秒级
03.实时数据生产
3.1 数据分析数据产出目标
用户要什么数据? 根据日期、业务类型(买卖、租赁)查询经纪人汇总数据
目标数据产出粒度:经纪人+业务日期+业务类型
3.1 数据分析数据生产可行性
生产逻辑:
select
Dk.date, //日期
Dk.staff id, //经纪人
House.house_ type, /业务类型
Count(id) as dk _cnt //指标，带看量
from dk left join house On dk.house_ id = house.house_ id
Where audit_ status = 1(可变更)
Group by dk.date, Dk.staff id, house.house_type
带看表dk(经纪人带客户看房)
房源明细表house
3.2 计算分析-目标
1)开发效率:较快满足用户的需要
2)资源成本:计算效率高
3)数据质量:准确无误、数据实时
3.2 计算分析计算架构-Lambda
3.2 计算分析-Lambda架构-数据产出
3.2 计算分析-Lambda架构-问题
带看表dk(经纪人带客户看房)
3.2 计算分析计算架构-全量计算
方案:用实时引擎来计算所有的数据
3.2 计算分析-全量计算架构-问题解决
1.取最新“快照"
create view dk as select * from select ,row_ number()
over (partition by id order by utime desc) as rownum
from dk ) wherenums1;
问题：
如果08-12-条带看记录从审核通过变成未通过，如何解决?
2.计算
select date,staff_ id,house_ type,count(id) as dk_ cnt
from dk where udit_ statu, E1 group by date, staff_ id, house_
type
3.2 计算分析计算架构-全量计算问题分析
方案:用实时引擎来计算所有的数据
问题:
1）如何获取全量的原始数据?
（1）数据湖:实时性相对差
（2）CDC: log等数据?
（3）其他?
3.2 计算分析计算架构-架构选择
3.2 计算难点-全量数据获取-Hybrid Source
方案: Hybrid base(Hive) + Delta(Kafka)
3.2 计算难点-准确-处理去重&更新(Retract)
原始带看binlog变更数据(1-更新，2-重复)
处理后的数据
解决方法:
select * from (select *,cg over (partition by id order by time
desc) as rn from dk)where ;
3.2 计算难点-准确-join乱序问题场景
SQL
执行DAG
级联join场景
3.2 计算难点-准确-join乱序问题场景
T1 Left join T2
left join T3
3.2 计算难点-准确-join乱序问题解决
3.2 计算难点准确-join乱序问题解决
3.2 计算难点-计算效率-聚合
聚合函数批式处理，本质是延迟换吞吐
3.2 计算难点效率-Join
原始带看binlog变更数据(dk表)
原始房源binlog变更数据(house表)
3.2 计算难点效率-Join算子逻辑
关联触发:左右流互相关联触发
回撤来源(left join举例):
● 右表晚到
● 左右表本身的回撤
3.2 计算难点-效率-Minibatch Join
中间数据可抵消
Minibatch方案,抵消批次内的变更导致的中间数据
3.2 数据质量-任务稳定性
直接结果:消费堆积-MQ L AG
JVM: GC耗时、次数
资源: cpu、内存
算子:倾斜、反压
3.2 数据质量-数据持续正确性-监控比对
异构比对:实时VS离线
时间趋势:同环比
异常值占比
3.2计算总结 计算架构:开发效率
1）Lambda架构->全量计算:一套开发任务
数据源获取:全量能力
2）Hybrid Source(逻辑全量表，hive+kafka, 成熟存储方案)
计算:正确、效率，核心是算子选择+优化
3）正确
（1）处理更新/重复: rownumber +retract机制
（2）乱序: join reorder
4）效率
（1）时效性换效率: Minibatch (聚合、join)
5）质量:稳定性监控、数据监控
3.3 数仓建设
数仓建设:数据复用，减少重复开发
3.3 数仓数据组织方案
DWD明细宽表
DWM指标层key/val存储方案
3.3 数仓-元数据管理
Create table kafka_ dwm ( dimn varchar, key varchar, val bigint, ts bigint )with( cluster,topic); Select * from kafka_ dwm; || || || Select * from kafka.cluster.kafka_dwm
数据资产:管理查询
生产:免DDL
04.数据服务
04.数据服务架构
4.1 查询快引擎选择
指定key,查询value,类似HashMap
分析: join. Agg
4.1 查询快怎么做?
查询逻辑模型(简化)
select
Field1 , field2,field3.a)
From
{
select count,sum,max,avgbE)
from
table1 (left/right/inner join table2)(原始信息关联)
where field1 > XXX and field2 > XXX (原始信息关联)
group by group_ fields
}
查询优化分析:
● 关注目标:不需要的信息不关注，比如只查询带看量
● 计算处理:能不能足够快，比如count/sum/avg等聚合函数
● 原始信息:单表筛选够不够快、信息关联够不够快
4.1 查询快关注目标信息
select带看量，通话量from table(100+列)
行存:大量io,每行查找需要的列
列存:直接取出对应的列文件
4.1 查询快-筛选-分区
4.1 查询快-筛选-primary key构建
原始表数据 Primary key (house_ type,staff_ id) Order by (house_ type,staff_ id)
4.1 查询快-筛选- primary key查找
4.1 查询快原始信息关联-IO优化
4.1 更快的查询-计算向量化
CPU支持向量化指令，单指令多数据处理
4.1 查询快执行计划
RBO: 举例, Filter push down
4.1查询快应用优化
➢ 原始信息关联
1）Local Join:如计算带看量，带看数据和房信息按照house_ id分布 ，无shuffle io开销
2）预关联:直接生产“大宽表”
➢ 计算复杂度
1）预计算:提前聚合到特定粒度，如带看量聚合到经纪人+天+业务类型
2）提升信息密度: bit化
4.1 查询快应用-宽表构建
目标:减少查询现join,生产侧把相同粒度(如经纪人)指标及相关的维度数据关联成“宽表”
Flink聚合函数: MAP数据结构
4.1 查询快提升信息密度-bit化
Biz(业务类型):第1位代表是否有租赁(1/0)，第二位代表是否有买卖(1/0)
背景:
计算通话时长，业主既有租赁房又有二手房，选择看全部业务时，不能重复累加
要查询对应业务类型$requestBiz(1租赁,2买卖,3全部)
计算逻辑:
Select sum(duration) from table Where biz & ($requestBiz) > 0 Group by ...
4.1 查询快提升信息密度-bitmap
roaring bitmap:高效的交并等运算数据结构
场景:计算每天客户端uv数据
方案:可以将uid通过bitmap保存: 32 bits-> 1 bit
roaringBitMap:稀疏优化
-
分桶:高16位
-
低16位:数据稀疏用数组存储，否则用bit
4.2 稳定解决的问题
异常节点导致服务雪崩
4.2 稳定-如何解决
Source Hystrix
熔断触发策略:
-
比如错误率每秒超过10%
-
响应时间> 5s
动作:
1)直接返回失败
限流、降级
1)限流:根据查询客户端、接口等配置查询限额
2)降级:主备存储/服务集群，降级预案
4.3 查询-数据管理
管理&查询
维度:
● 天(date)
● 经纪人(staff_ id)
● 业务类型(biz_ .type)
指标
● 带看量(dk_ cnt): count(dk id)
● 通话时长(call_ duratition): sum(duration)
模型表
● 经纪人指标表: dwm_ staff biz day_ _rt
｜｜ ｜｜ ｜｜
查询:
Select count(dk_ id) ,sum(duration) from
dwm_ staff_ biz_ _day _rt
Where date between $[startDate] and date
between $(endDate]
And biz_ type- XXx and staff_ idin (1,2,3)
