数仓和数据中台
📌 数据仓库
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,甚至毫秒级实时响应。
📌 实时数仓
🚁 优先建设实时数仓的场景
如果企业面临的问题纯粹是“速度”问题,而非“管理”问题:
- 业务场景单一但时效要求极高:如量化交易、网络安全监控、工厂设备预警。
- 数据量大且需要即时查询:运营人员需要秒级查询当天的多维分析数据,传统数据库查不动。
- 不需要跨部门复用:数据仅供特定部门使用,不需要封装成API给其他系统调用。
🚁 优先建设数据中台的场景
如果企业面临的问题是“效率”和“混乱”问题:
- 多业务线重复造轮子:A部门和B部门都在开发“用户画像”,浪费资源。
- 数据口径打架:CEO看到的报表和财务看到的报表数据对不上。
- 业务系统交互频繁:前台应用(App/Web)需要频繁调用后台数据,且需求变更极快。
🚁 融合建设
在建设数据中台时,直接引入实时计算引擎flink,构建实时数据中台。
解决数据标准统一的问题(中台属性),又具备毫秒级业务响应能力(实时数仓属性)。
📌 宽表
在数据分析中使用的一种特殊反范式表,通过足够的数据冗余,让用户可以以单表方式了解业务。
比如,订单系统多表left join查询,联合在一起形成一张超多列的宽表。
从业务角度来看,宽表是一个高度内聚的业务实体全景视图,把复杂的技术关联屏蔽在底层,向业务交付高可读、即开即用的“数据产品”。
🚁 优势
- 规避分布式系统的join新年瓶颈
- 适配列式存储引擎,相比传统的行式存储,在数据分析时前者效率更高。
- 降低业务侧数据门槛
- 统一指标口径
🚁 应用
- 客户数据平台(CDP):用户画像大宽表
- 业财一体化与精细化运营:全链路交易宽表
- 实时风控与异常检测:流式事件宽表
🚁 劣势
- 数据冗余引发的更新异常与运维灾难
- 灵活性陷阱与敏捷悖论
- 超大宽表的数据治理黑洞