实时数据中心建设思路与企业实践｜ 青训营笔记

Iekr
55 阅读7分钟

实时数据中心建设思路与企业实践｜ 青训营笔记

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

企业数据架构

image-20220819224234079

  • 企业整体数据架构：基础引擎、数据集成/生产/服务、开发和治理工具

  • 关键模块及数据流向

    • 数据集成
      • 业务数据收集：数据库变更数据收集(CDC)、业务日志收集(业务数据->数据处理系统)
      • 大数据系统内传输：基于Flink丰富的connector体系 (数据系统内)
    • 数据生产：实时和离线生产pipeline (数据系统内)
    • 数据服务：统一数据服务架构(数据系统->业务系统)

数据集成

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

image-20220819224552221

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

image-20220819224640197

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

image-20220819224808394

数据生产

数据生产-离线&实时

image-20220819224853558

数据服务

image-20220819224916905

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

数据中心案例

房产业务介绍

  • 以房产业务举例说明数据中心建设目标和要求

  • 房产业务介绍：房产服务平台、经纪人、客户

  • 数据中心核心指标分析：供需、过程、结果

  • 数据中心查询要求：查询条件、数据结果、技术要求

image-20220819230141738

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

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

房产数据中心-数据查询要求

数据中心看板查询条件：

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

数据展示：

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

技术要求:

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

实时数据生产

  • 案例生产方案分析：数据探查、明确指标口径和产出粒度、生产架构、计算难点

  • 数据探查：分析数据信息是否齐全，即基于原始数据计算指标可行性

  • 数据架构：lambda架构和全量计算架构比对，确定合适的生产架构方案

  • 计算难点解决

    • 全量数据获取：hybrid source
    • 精确计算
      • 去重&更新处理：基于retract机制
      • 乱序问题解决：流join乱序问题方案
    • 计算效率
      • MiniBatch-聚合计算
      • MiniBatch-join

  • 数据质量

    • 任务稳定性：消费LAG、JVM、资源、算子
    • 数据正确性：和离线比对、趋势比对、异常值占比

  • 实时数仓

    • 数据分层：数据复用，减少重复开发
    • 数据管理：格式、元数据

数据分析

数据分析-数据产出目标

用户要什么数据？ 根据日期、业务类型(买卖、租赁)查询经纪人汇总数据

目标数据产出粒度：经纪人+业务日期+业务类型

image-20220819230729599

数据分析-数据生产可行性

image-20220819230814343

生产逻辑:

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

计算分析

计算分析-目标

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

计算分析-计算架构-Lambda

image-20220819231131784

计算分析-Lambda架构-数据产出

image-20220819231201913

计算分析-Lambda架构-问题

image-20220819231637267

image-20220819231647992

计算分析-计算架构-全量计算

image-20220819231925160

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

还是原来的问题

image-20220819231951435

image-20220819232022470

计算分析-计算架构-全量计算问题分析

问题:

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

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

目标Lambda架构全量计算架构
开发运维效率效率低: 存在实时离线开发任务和merge逻辑,效率高:只存在一套实时任务
资源效率计算资源占用高：离线全量(例行任务)+实时增量状态存储成本相对高：全量(首次冷启动)+增量
数据质量实时、准确符合要求符合要求

全量计算框架有一定的优势

计算难点

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

方案: Hybrid base(Hive) + Delta(Kafka)

image-20220819232432232

计算难点-准确-处理去重&更新(Retract)

image-20220819232654433

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

image-20220819232805748

为什么会产生乱序问题

image-20220819233027023

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

image-20220819233846979

image-20220819233859577

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

image-20220819233927799

image-20220819233936105

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

计算难点-效率-Join

image-20220819235347708

image-20220819235354749

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

image-20220819235558244

关联触发：左右流互相关联触发

回撤来源(left join举例):

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

计算难点-效率-Minibatch Join

image-20220819235648284

中间数据可抵消，MInibatch方案，抵消批次内的变更导致的中问数据

数据质量

任务稳定性

image-20220819235746674

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

image-20220819235926268

image-20220819235945219

计算总结

计算架构：开发效率

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

数据源获取：全量能力

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

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

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

数仓建设

image (4)

数仓建设: 数据复用，减少重复开发

数仓-数据组织方案

image-20220820000539450

image-20220820000544741

元数据管理

image-20220820000704346

image-20220820000713003

数据服务

  • 整体架构：查询引擎、查询优化和执行、稳定性、元数据

  • 案例查询方案分析

    • 如何更快的查询
      • 原始信息筛选和关联效率
      • 计算处理效率
      • 只关注目标所需数据

  • 关注目标信息

    • 列存

  • 原始信息筛选效率

    • OLAP引擎索引方案

  • 原始信息关联

    • join方案及优化

  • 计算效率

    • 向量化

  • 执行计划优化：RBO、CBO

  • 应用层优化

    • 宽表构建
    • 提升信息密度：bit化、bitmap

  • 查询稳定性

    • 熔断、限流、降级

  • 元数据管理：指标口径管理、查询生成

数据服务架构

image-20220820000756881

查询快-引擎选择

  • 指定 key 查询 value, 类似Hash Map
    • Redis等kv数据库
  • 分析: join、agg
    • ClickHouse、Doris等OLAP分析

查询快-怎么做？

image-20220820001005561

查询优化分析:

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

查询快-关注目标信息

03516787-826a-40cb-acc3-b3edba82fb64

clickhouse

b130949b-db8b-4bfb-b75a-cbcb9ba1fedd

select 带看量，通话量from table(100+列)

  • 行存：大量io，每行查找需要的列
  • 列存：直接取出对应的列文件

查询快-筛选-分区

image-20220820004700737

查询快-筛选-primary key构建

image-20220820004801325

查询快-筛选- primary key 查找

image-20220820004905140

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

doris

image-20220820005505711

更快的查询-计算向量化

image-20220820010841903

image-20220820010852894

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

查询快-执行计划

image-20220820010952581

查询快-应用优化

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

查询快-应用-宽表构建

image-20220820011304148

查询快-提升信息密度-bit化

image-20220820011334038

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

查询快-提升信息密度-bitmap

image-20220820011622269

稳定-解决的问题

image-20220820011654674

image-20220820011706576

异常节点导致服务雪崩

稳定-如何解决

image-20220820012048970

熔断触发策略：

  • 比如错误率每秒超过10%
  • 响应时间>5s

动作：

  • 直接返回失败

Source Hystrix

限流、降级

  • 限流: 根据查询客户端、接口等配置查询限额
  • 降级：主备存储/服务集群，降级预案

查询-数据管理

image-20220820012232734

avatar
文章
阅读
粉丝