模型设计框架(业务过程驱动)还是在经典的三层数据模型架构下去进行,概念模型、逻辑模型、物理模型
首先概念模型其实是业务过程(流程图),其中需要考虑到几个方面:
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.架构设计能力
数据质量:
检查机制
规则类型 技术 业务
覆盖面
检查周期 粒度
评估体系 评分卡
闭环机制
环境:
架构 选择相关数据源
上游数据 流入规模
下游数据 应用准入、应用服务模式、数据链路
生命周期 监管、平台、应用需求
模型数据全面性:
潜在需求满足的能力
历史数据追溯
满足上层应用的准入原则
模型数据准确性
业务与数据关系
加工逻辑正确
下游时效性
模型数据可访问:
方便查询和使用
技术人员易理解表间关系
模型数据时效性:
满足业务需要
模型设计加工不是时效性的障碍
上游时效
供数给下游的时效文章来源:https://www.toymoban.com/news/detail-498959.html
文章来源地址https://www.toymoban.com/news/detail-498959.html
到了这里,关于数仓工程师理解复杂业务的思考方法论的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!