实时数据中心建设思路与企业实践 | 青训营笔记这是我参与「第四届青训营」笔记创作活动的第15天！一、企业数据架构。

这是我参与「第四届青训营」笔记创作活动的第15天！

一、企业数据架构。

1.企业数据架构：

1.1 数据集成-业务数据收集-CDC：

数据流向：业务数据库->数据系统

数据集成-业务数据收集-Log：

数据流向：client/server log->数据系统

数据集成-系统间同步传输：

2.数据生产-离线&实时。

数据流向：原始数据->数据处理pipeline

3.数据服务

数据流向：数据系统->业务系统

二、数据中心案例。

1.房产业务介绍：

1.1 房产数据中心-核心数据指标；

供需(房子全不全?客户多不多?)
- 房源
  - 房增(新增房子的录入量)
- 客源
  - 客增(新增客户的录入量)
过程(工作做的怎么样?)
- 通话次数（经纪人和客户电话次数)
- 带看次数(经纪人带客户看房次数）
结果(结果好不好?)
- 成交量(成交合同量)

2.房产数据中心-数据查询要求：

数据中心看板查询条件

时间范围:今天前的任意日期范围
业务类型:租赁/买卖/全部

数据展示:

查询条件下的每个经纪人的汇总数据
支持下钻明细数据

技术要求:

300ms内返回结果
数据是实时秒级

三、实时数据生产。

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

2.计算分析-目标。

开发效率:较快满足用户的需要
资源成本:计算效率高
数据质量:准确无误、数据实时

计算分析-计算架构-Lambda：

计算分析-Lambada-数据产出：

计算分析-Lambada架构-问题：

计算分析-计算框架-全量计算：

计算分析-全量计算框架-问题解决：

问题：

如果08-12一条带看记录从审核通过变成未通过如何解决?

1.取最新“快照”
- create view dk as select * from (select*row number0over (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 audi Status - group by date,staff id, house type

计算分析-计算框架-全量计算问题分析：

问题:

如何获取全量的原始数据?
- 数据湖:实时性相对差
- CDC: 1og等数据?
- 其他?

方案：用实时引擎来计算所有的数据。

计算分析-计算框架-架构选择：

计算难点-全量数据获取-Hybrid Source：

方案：Hybrid base（Hive）＋Delta（Kafka）

计算难点-准确-处理去重&更新（Retract）：

解决方法:

select from (select, row number() over (partition by id order by time desc) as rn from dk)where rn=1；

计算难点-准确-join乱序问题场景：

级联 join 场景

计算难点-准确-join乱序问题解决：

增加ReOrder算子

计算难点-计算效率-聚合：

聚合函数批式处理，本质是延迟换吞吐

计算难点-计算效率-Join：

计算难点-效率-Join算子逻辑：

关联触发:左右流互相关联触发回撤来源(left join举例):

右表晚到
左右表本身的回撤

计算难点-效率-Minibatch Join：

中间数据可抵消
- Minibatch方案，抵消此次内的变更导致的中间数据

数据质量-任务稳定性：

直接结果：消费堆积-MQLAG
JVM：GC耗时、次数
资源：CPU、内存
算子：倾斜、反压

数据质量-数据持续正确性-监控对比：

异常值对比

计算总结：

计算架构:开发效率

Lambda架构->全量计算:一套开发任务

数据源获取：全量能力

Hybrid Source(逻辑全量表,hive+kafka,成熟存储方案)

计算:正确、效率，核心是算子选择+优化

正确
- 处理更新/重复:rownumber+retract机制
- 乱序: join reorder
效率
- 时效性换效率:Minibatch (聚合、join)
质量:稳定性监控、数据监控

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

四、数据服务。

数据服务架构：

1.查询快-引擎选择：

查询快-怎么做？

查询优化分析:

关注目标:不需要的信息不关注，比如只查询带看量
计算处理:能不能足够快,比如count/sum/avg等聚合函数
原始信息:单表筛选够不够快、信息关联够不够快

查询快-关注目标信息：

select 带看量，通话量from table(100+列)
行存:大量io，每行查找需要的列
列存:直接取出对应的列文件

查询快-筛选-分区：

查询快-筛选-primary key构建：

查询快-筛选-primary key查找：

查询快-原始信息关联-IO优化：

更快的查询-计算向量化：

CPU支持向量化指令，单指令多数据处理。

查询块-执行计划：

查询块-应用优化：

原始信息关联
- Local Join:如计算带看量，带看数据和房信息按照house id分布，无shuffle io开销
- 预关联:直接生产“大宽表”
计算复杂度
- 预计算:提前聚合到特定粒度，如带看量聚合到经纪人+天+业务类型
- 提升信息密度:bit化

查询块-应用-宽表构建：

目标:减少查询现join，生产侧把相同粒度(如经纪人）指标及相关的维度数据关联成 “宽表”
Flink聚合函数:MAP数据结构

查询块-提升信息密度-bit化：

背景:计算通话时长，业主既有租赁房又有二手房选择看全部业务时，不能重复累加
要查询对应业务类型SrequestBiz(1租赁,2买卖，3全部）
计算逻辑:
- Select sum(duration) from table
- Where biz & ($requestBiz)> 0
- Group by

Biz(业务类型):第1位代表是否有租赁(1/0)，第二位代表是否有买卖(1/0)