📝 数据开发流程

其实数据开发中遇见的问题和我们应用层面的问题存在部分的相似之处，但是在进行数据问题排错的时候，又存在些许的不相似。总体上的感觉,得去做过和排查过,自身才能对问题理解到比较清晰

任务调度

任务调度,这个是有时序的,也是存在先后顺序的。一般最晚的时间点就是我们拉取最晚那批数据的时间了。

理想情况下(基于离线数仓): 比较理想的情况下,就是我们最好每一层的处理时间预算都是停留在一个小时左右,但是具体的时间量等情况，得看数据量和具体的业务需要了.

0点1点: 执行ods的数据,具体的调度周期就跟你业务上的数据变化或者数仓中的数据需要,来进行调度周期是天/周/月等情况的调度处理.

1点到2点: 执行dim或者dwd的数据,这个组织维度的数据,看是否有变化的调整(一般公司的人员组织或者集团下的预取,城市,项目之类的会存在有变化的调整).

2点到3点: dws 层的数据处理,一般dws的数据可以是由dim和dwd进行轻度汇总获取出来的. 其实到了这层的话,需要的指标对应的最小维度基本已经可以看到数据了。只是这个维度的数据,是最小的时间维度和组织维度汇聚出来的。

3点到4点: adm层的数据汇总,也就是我们的数仓最终给输出出来的大宽表数据.

有了大宽表后,看下数据还需不需要同步到mmp这类的数据库中,来进行一个高效率的查询(比如clickhouse,drios等).

表的设计

表的设计也是很关键的,目前虽然我们的数据设计来源于业务需求/报表需求/商业报表需求等场景,但是更好的联系起实际的设计也很重要的。

举个例子: 我们的组织维度, 存在组织1 , 组织2 ，组织3 (这三者的关系就是我们平常看到的树的概念,1是2的上级,2是3的上级),同时还存在时间维度的(月,季度,年). 此时,梳理完指标的计算口径,我们发现,1的数据由2汇聚,2的数据由3进行汇聚, 年由月汇聚,季度也是月汇聚出来的, 于是我们设计dws或者adm最后汇总的表样时候,可以冗余组织2和组织1对应到组织3,时间维度冗余最小的月份，于是在组织这个维度就可以清晰的看到，根据组织1和组织2进行sum和group的时候,就获取初对应组织的值了(冗余组织的关系,聚合的时候就可以减少去需要上下级之间的关系了).

前置条件: 数据汇聚的计算口径得清晰和明白,方案并不能适应所有的场景. 比如这里的组织得明确最多多少层,一般一个集团或者一个公司,不会出现很多级得概念.

数据重复

数据重复这个问题也是很常见的话,比如你拉取过来的组织怎么重复了呀? 我这个指标的字段怎么在帆软报表上也是重复的了啊? 比如有时候我们为了去冗余一些多余的字段进来的时候,并没有很明白该字段对应的场景或者说是业务变化的场景,导致重复的问题

举个例子: 更新时间字段, 我们聚合sum数据的时候,可能会考虑到冗余该字段进来,于是并没有考虑到时间变化可能会有不同的日期的时候的场景,group就会出现多条数据的情况

任务重跑导致的数据重复问题:

一般hive中,我们都会对表进行分区之类的操作. 我们在插入数据之前,会覆盖数据的. 什么意思呢? 就是insert overwrite 会在插入之前,删除对应分区的数据,再进行数据的插入. 但是有时候写漏掉了或者job跑的时候出现同时多跑的情况,就有可能出现数据重复的问题

实时数据接入

flink cdc : 待使用

canal: 正常情况下,我们会使用canal+kafka来进行与程序的结构,意思就是canal假装成mysql的重节点,获取mysql的binlog变化的数据,然后再对其进行解析,写入到kafka中. 数据到了kafka,后面的程序要怎么消费就怎么消费.

后面待更新

🤗 总结归纳

总结文章的内容

不论去做什么陌生的领域也好,我们一定要有自己的理解和分析技巧. 要有自己的韧性和耐心,去面对在你不知道的领域上的问题和难点.

保持冷静的思维,是面对未知的场景和难题.

保持好奇和坚持的心态和行为,去持续学习和成长.

📎 参考文章

💡

有关文章的问题，欢迎您在底部评论区留言，一起交流~