跳转至

数仓和数据中台

📌 数据仓库

data warehouse,将企业内不同业务系统(如erp、crm)的数据,通过etl(抽取、转换、加载)过程清洗后,按预定义的模型加载。

目的:解决数据孤岛问题,为报表(report)和商业智能(bi)提供标准化的数据源。

侧重于“存”和“看”,供分析和宏观决策。

目标用户:决策者、数据分析师。

输出内容包括:静态报表、可视化大屏、bi仪表盘。

时效性通常为t+1。

note

crm - customer relationship management

erp - enterprise relationship management

scm - supply chain Management

oa - office automation

bi - business intelligence

📌 数据中台

data middle platform,强调资产化、服务化。在数仓基础上,通过统一的数据标准、服务接口,将数据封装为api等形式,快速响应前台需求。

目的:解决重复造轮子问题-解决数据复用、业务响应速度的矛盾,实现数据对业务的直接赋能(如实时推荐、精准营销)。

侧重于“用”,数据复用,要求数据能快速转化为业务所需的内容,强调敏捷和实时性。

目标用户:业务人员、前台应用、运营系统。

输出内容包括:数据api、标签服务、实时推荐算法。

时效性通常为t+0,甚至毫秒级实时响应。

📌 实时数仓

🚁 优先建设实时数仓的场景

如果企业面临的问题纯粹是“速度”问题,而非“管理”问题:

  1. 业务场景单一但时效要求极高:如量化交易、网络安全监控、工厂设备预警。
  2. 数据量大且需要即时查询:运营人员需要秒级查询当天的多维分析数据,传统数据库查不动。
  3. 不需要跨部门复用:数据仅供特定部门使用,不需要封装成API给其他系统调用。

🚁 优先建设数据中台的场景

如果企业面临的问题是“效率”和“混乱”问题:

  1. 多业务线重复造轮子:A部门和B部门都在开发“用户画像”,浪费资源。
  2. 数据口径打架:CEO看到的报表和财务看到的报表数据对不上。
  3. 业务系统交互频繁:前台应用(App/Web)需要频繁调用后台数据,且需求变更极快。

🚁 融合建设

在建设数据中台时,直接引入实时计算引擎flink,构建实时数据中台。

解决数据标准统一的问题(中台属性),又具备毫秒级业务响应能力(实时数仓属性)。

📌 宽表

在数据分析中使用的一种特殊反范式表,通过足够的数据冗余,让用户可以以单表方式了解业务。

比如,订单系统多表left join查询,联合在一起形成一张超多列的宽表。

从业务角度来看,宽表是一个高度内聚的业务实体全景视图,把复杂的技术关联屏蔽在底层,向业务交付高可读、即开即用的“数据产品”。

🚁 优势

  • 规避分布式系统的join新年瓶颈
  • 适配列式存储引擎,相比传统的行式存储,在数据分析时前者效率更高。
  • 降低业务侧数据门槛
  • 统一指标口径

🚁 应用

  • 客户数据平台(CDP):用户画像大宽表
  • 业财一体化与精细化运营:全链路交易宽表
  • 实时风控与异常检测:流式事件宽表

🚁 劣势

  • 数据冗余引发的更新异常与运维灾难
  • 灵活性陷阱与敏捷悖论
  • 超大宽表的数据治理黑洞