数据研发实践
数据处理架构
最早数据仓库的计算只支持批处理 通常是按天定时处理数据 在后期逐步进化到准实时，本质上还是批处理 只是处理频度上得有提升，到小时级，或者15分钟这种
- lambda架构
后期演化出一条新的流处理链路 这个链路和之前的批处理分别处理 然后在服务层面利用大数据的计算能力进行合并 向外提供离线+实时数据服务
- Flink流批一体化
在接入层统一采用流式接入 计算层采用统一套框架支持实时计算+离线计算 批处理仅仅作为流处理的一个特殊场景进行支持 整体上可以做到流处理、批处理的自由切换
流批处理区别
- 流计算
用于支持线上业务场景（比如互联网的推荐、搜索、风控等）
- 批处理
更多是支持离线统计分析
业务数据层（ODS层）
- 原始数据
原始数据经过缓冲层（STG）的加载 会进入数仓的业务数据层 这一层采用范式建模 基本保持与数据源完全一致的结构
好处
1、一次性接入数据源结构，针对需求的变动不用频繁去与数据源对接 2、便于业务研发更好地理解数据，同时是也是公司的原始数据资产
- 变化的数据
使用数据拉链加工与存储
好处
1、保留历史数据的同时，尽可能少占用存储空间 长期来看，拉链存储比起每天全量保留历史节约大概90%空间 2、快速、高效地获取历史任意一天业务系统的快照数据
公共数据层（包括公共明细层DWD，公共汇总层DWS）
公共数据层是数据仓库的核心层，是整个数仓中使用率最高的 采用维度建模思路 类型包括事务事实、周期快照、累积快照 方便下游对数据的使用设计一系列的宽表模型 在调用分布来看，宽表的使用占到70%以上
将不同业务过程中的事实进行统一整合，包括纵向整合&横向整合
- 纵向
对于商品、用户主数据类可能分散在不同的源系统中采用纵向整合
- 横向
横向整合主要包括交易、内容等行为数据不同业务过程的整合 比如：用户（用户信息、注册信息）购买（下单、支付、结算、覆约、完成）商品（商品信息，商家信息，等） 会把订单流转业务过程整合放到一张明细表里，同时会研发一些基于用户、或者商品视角的轻度汇总宽表
劣势
1、数据冗余较多，在存储、计算、调用较为占资源，建议尽量还是按场景去使用 2、宽表整合的信息较多，数据权限不好控制。建议可以根据需求，在有限范围内开放整体宽表权限，或者通过视图或者子表的方式建立不同权限的数据范围，适应不同组织的需求 3、宽表通常依赖比较多，会影响数据的产出的时效。
应用数据层（DWA层）
偏向应用的数据加工 也叫集市层 按维度建模思想
主题分类
- 数据主题视角
主题是将企业的业务进行宏观数据抽象 是数据仓库里数据的主要组织形式 1、参照波特价值链，分析企业本身经营的业务（基本活动、支持型活动），分别对应哪些数据 2、参照业界通用模型，例如像IBM、TD等针对大型行业（如电信、金融、零售）有一些数据主题的通用划分方法 3、对企业的内部数据（线上数据模块、数据字典）进行摸底，确认对应到哪些主题
划分结果会按照三个层级：主题域—》主题—》子主题
1、第一级是主题域，针对相对稳定的主题进行合并，归拢到主题域，利于数据的理解与建立全局的数据资产目录 2、第二级是主题 3、第三级是子主题，主要针对有些主题下分类较多，比如供应链主题下会包含采购、仓储、配送等子主题 数据主题划分建议完全互斥，不建议重复
- 数据业务视角
数据业务域是根据企业经营的具体业务 结合企业的组织架构进行划分 层次和分类可以相对灵活，子分类可以允许重复 因为两条不同的业务域可能经营相同的业务，例如电商、内容下都有会员这个业务
内容+电商的数据主题与业务分类
一横一纵两个视角，将数据进行更好的归类，在数据模型设计中会打上相应分类标签，从而让数据研发&数据使用人员统一认知 以上两种分类方式主要应用于核心的公共数据层 业务数据层、应用数据层并不需要遵循以上分类规则，比如业务数据层（ODS层）是按照数据源进行分类，应用数据层（DWA）
