type
status
date
slug
summary
tags
category
icon
password
这里写文章的前言：
一个简单的开头,简述这篇文章讨论的问题、目标、人物、背景是什么？并简述你给出的答案。
可以说说你的故事：阻碍、努力、结果成果，意外与转折。
📝 简介
在公司的数据平台上,进行一些简单的指标开发也有一段时间了,对于是否有预期的成长的还是取决于个人的欲望以及行动,不排除我是行动的巨婴.
也简单的记录下自己这段时间的一些总结语录以及如果我下次还在数据方面的项目上怎么处理?
需求和调研
由于目前的项目都是在乙方的场景,所以需要去与甲方进行沟通了解他们的需求以及系统,并且同时还要去推动相关需求指标的进度。这里涉及到的东西其实很多。
需求以及调研: 这个阶段一定要好好梳理该对行业或者同样类似的系统,进行梳理，最好是能明白业务场景。 就举个例子: 财务系统,这是目前大公司都会具备的吧,那换个角度去思考的话,如果我只晓得了财务系统的话，那我是不是在梳理相关场景或者相关指标的情况下，是不是就轻松很多了呢？ 然后在整理需求和调研阶段的话，对应的坑以及客户的业务痛点就会很清晰和明白了。
也就是说句直白的话: 对应业务场景和需求痛点,不论是不是站在产品的角度或者开发的角度视角，一定要对其进行吃透，而不能模糊二口，特别是在调研阶段，如果你存在很多业务场景不是很清晰的情况,就会非常容易出现你在梳理需求的时候,吃不透业务痛点,对应客户需要的真是东西很难把握，甚至说，你可能就把握不住。
指标梳理
指标梳理这步很关键的,根据你目前的需求等场景进行指标的梳理,梳理出来的结果就是你想要的或者业务方想要的.
指标梳理这个步骤中,我们一定要吃透或者理解透目前业务方或者需要梳理的指标的系统里面的一定业务场景,这会关系到你接下来的取数以及数据要怎么聚合的操作和设计这块.
维度梳理: 最基本的维度梳理,也就是业务场景下,需要梳理的维度是有那些场景的. 比如:时间维度,汇总维度,组织维度等.
每种不同的维度,都会对你的sql产生很大的影响,比如你的组织维度是一层一层的,那你在组织维度进行汇总的时候,你是不是还要考虑到时间的维度? 月到季度?月到年等这种时间维度的概念汇总.
基于上面,业务需求+指标的梳理,这些都昨完了的话,那其实业务调研和指标梳理要做的事情,就已经做完了，于是就可以放开了的去设计接入数据源的时间维度，sql进行汇总的逻辑操作.
其实,你的指标梳理到好的话,你开发后的工作会舒服很多
指标文档: 这里的调研,对应要输出出来的,你每个指标对应的时间维度或者是其他的维度,同时也要一并输出出来的是:业务口径和计算口径
数据核算 & 数据字典输出
再根据需求或者业务方提供了相应的指标之后,那么我们紧接着要去做的事情就是,通过数据源去查看,去查看数据之类的东西是否符合预期。 比如财务指标: 不同的记账科目编码,那你就要去梳理下是否有科目编码这个字典表。
然后你在核算数据的同时，还要去输出一个比较关键的文档.
数据字段文档: 这个数据字段文档的话,其实就是已经设计到数仓方面的数据。
ods / dwd / dws / dim / adm
设计到这五层的数仓建模的字典表的输出,每一层的表怎么接入,全量还是增量? 触发时间是什么时候(也就是调度周期)？如果是增量的话,依赖的增量字段是什么？还是利用类似flink cdc这类的框架来进行实时数据的接入?
这个文档输出后,还要与客户进行确认.
开发注意点
全量: 如果数据是全量每天或者每月拉入进来的话,要涉及考虑的问题是数据量的大小(避免数据量太大影响到可能在凌晨运行的job).
伪增量: 是否有可信的更新字段,来进行伪增量的获取. 比如更新时间, 我每天或者多久的时间范围内,我就去更新时间是在这个范围的数据.
实时增量: 类似flick cdc 或者 cancl去监听mysql的binlog这样的功能来实现实时增量的功能.
开发规范
这个地方其实对应的就是无规矩不方圆, 也就是开发之前要定义好规矩,这样不仅仅对程序很有益,对后面来的同事或者随时看你程序的涉及等方案的时候,也是一目了然的.
🤗 总结归纳
📎 参考文章
有关文章的问题，欢迎您在底部评论区留言，一起交流~