数仓和数据中台
📌 数据仓库
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，构建实时数据中台。
解决数据标准统一的问题（中台属性），又具备毫秒级业务响应能力（实时数仓属性）。