数仓工程师理解复杂业务的思考方法论

模型设计框架（业务过程驱动）还是在经典的三层数据模型架构下去进行，概念模型、逻辑模型、物理模型

首先概念模型其实是业务过程（流程图），其中需要考虑到几个方面：

1.数据 业务覆盖 业务感知、全业务流程图

2.过程 建模过程 实操      

3.服务 服务流程 流程把控

4.环境 数据架构 集成架构、分层架构、技术架构

5.组织 组织架构 项目团队分工合作

逻辑模型：深入懂业务

1. 主题覆盖 业务总线矩阵划分、设计主题

2.过程 过程管理

3.环境 上游系统

物理模型：落地

1.数据 主数据、参考数据、交易数据、数据质量

2.环境 下游系统、生命周期

3.组织 组织的实施能力

组织

合理配置：

第1种:针对数据处理流程的技术栈 做分工 -> 抽数、清晰sqoop、flume->建模 hive、impala、spark等 -> 集成，落地到CK、API（JAVA）-> 展示BI（Finereport、tableau）

第2种: 围绕模型团队细节  需求拆解 业务、产品经理  、模型设计 数仓工程师、 数据质量 运维工程师 按角色分工。

人员的能力评估矩阵：

1.业务理解能力

2.需求拆解能力

3.模型设计能力

4.全链路优化能力

5.数据治理能力

6.架构设计能力

数据质量：

检查机制

规则类型 技术 业务

覆盖面

检查周期 粒度

评估体系 评分卡

闭环机制

环境：

架构  选择相关数据源

上游数据  流入规模

下游数据 应用准入、应用服务模式、数据链路

生命周期 监管、平台、应用需求

模型数据全面性：

潜在需求满足的能力

历史数据追溯

满足上层应用的准入原则

模型数据准确性

业务与数据关系

加工逻辑正确

下游时效性

模型数据可访问：

方便查询和使用

技术人员易理解表间关系

模型数据时效性：

满足业务需要

模型设计加工不是时效性的障碍

上游时效

供数给下游的时效