前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >聊点数据开发和心态的事儿~

聊点数据开发和心态的事儿~

作者头像
Sam Gor
发布2020-03-26 00:52:27
3910
发布2020-03-26 00:52:27
举报
文章被收录于专栏:SAMshareSAMshare

hello~大家好我是SamGor~

写在前面

最近工作上有蛮多困难的地方,每天都揪心地很,归根到底还是心态不够强大,心态崩了,自然事情也很难去很好的完成✅了,还好最近有老婆和家人的陪伴,也算是熬了过来,也是让大家担心了?,愧疚。

其实问题的根本,就是没有调整好自己的心态,但今天我并不想在这里讲怎么调整自己的心态,遇见前所未有的挑战以及耽误项目计划的风险如何去面对,因为在这块我只能说是勉强度过“难关”,还不能说达到给大家讲“大道理”的程度。今天我更想总结的是一些数据开发上的一些开发经验,这些内容也可以算是对自己过去3周的一些痛苦内容的总结了。

数据开发前

数据开发前,当然就是要详细阅读需求了,这里面如何阅读好标签需求,我觉得有几点需要明确的:

标签定义的明确

有些标签,需求方往往只是简单的描述内容,业务口径,逻辑口径都是给的不周全的,这个时候千万不要自己就下判断了,不然很可能你会重新开发代码。

数据提供方式的确认

数据服务提供同时要考虑计算资源、传输效率,因为我们本次主要还是考虑ES接口的方式,按照以往的经验来说可能不太支持本次的需求,主要就是传输的瓶颈问题,因此提前做好技术咨询然后进行扩容准备。

标签值的确认

为什么这个要单独拎出来说呢,因为有的时候可能需求方本身也没有对数据有很深的了解,因此对于标签值的定义可能都是“拍脑袋”决定的,有些比较明显的问题可能没能考虑到的。比如:缺失值的填充方式是否符合实际意义,是否存在矛盾冲突的情况(比如把一些“距今X天的XXX标签的缺失填充为0,那么容易和当天的数据冲突(因为当天就是距今0天)。还有就是枚举值的确认,明确实际数据中,是否这个字段的枚举值就是需求的那几种,在这些之外的如何处置。等等等。

更新频率的确认

在你初步对需求进行分析的时候,可能会发现其实有些指标在计算上存在比较困难的情况,每天更新数据会比较消耗资源,这个时候可以再次和需求方确认需求情况,了解对这些字段的更新频率是否比较敏感,这样子对于数据部门的资源利用也有很大的帮助。

数据开发ing

终于到了数据开发的环节,这个时候考验一个数据开发工程师的技术来了~但我个人的小小经验就是养成一个条理性的开发习惯真的对我们开发效率有很大的帮助!

比如说,项目文件架构的管理,创建不同的子文件夹来管理我们的项目文件:如需求文件、data、测试code、上线code等,同时我也建议要新建一个开发进度记录excel,用来记录在开发过程中的操作,比如:

  • 开发过程中遇见的问题,记录下来,后续追踪是否解决;
  • 开发测试的过程代码和测试结果,方便后续回溯;
  • 记录调度上线的操作,了解整体的开发进度。

上面的只是一些开发习惯了,不同的开发同学可能都会有适合自己的一套办法,只要能够有条理的记录留存便于回溯,最合适自己的才是最好的!

此外,还有一点就是想和大家说的,就是进行数据开发前,一定要先设计好相关的开发概要文档,内容包括数据库表的结构设计,表字段命名方式,更新方式等等,同时在开发前和组内同时进行评审,了解是否有缺陷或者不符合开发规范的地方,及时进行修正!正所谓“磨刀不误砍柴工”~

那么进行正式开发了,我们是需要对我们的底层数据进行探索的,了解数据的质量、数据分布、数据更新方式、数据分区情况、是否存在重复数据、字段的使用方式等等,不要太相信直接的表的描述和他人的转述,有什么想法还是需要自己去进行验证。

数据测试

这一个环节是十分重要的,我们写的代码跑得通并不代表就是对的,很多时候,指标的逻辑可能就没能写对的,所以才会引入测试的环节,而且最好就是有个“局外人”同事进行测试,从一个多维交叉的角度以及抽样调查的方式来进行数据测试。

当然了,一个合格的数据开发工程师,这一块的工作还是需要自己也做一遍的,而不是说完成了代码开发就完事了,然后就等着测试同事来给你发现问题!自己需要对结果进行多角度交叉检验,也需要抽几个用例进行计算结果的核对,校对其逻辑是否正确。港真,这一块的工作确实是枯燥乏味,但是却很重要!!

交付

交付前,其实还有很多工作要做的,我这里也不一一展开了,比如代码评审、上线评审、发布评审等等,但是记住这些都不能省,而且项目文档记得也要做好整理和归档。

开发小记录

这一块只是针对最近一次的开发总结出来的一点点小经验,防止后续忘记了。

1、多留意多对多情况

很多时候我们会直接对数据进行join关联了,但是如果数据中存在主键重复的情况,而你又没有合理地去重,那么数据将会被错误的“膨胀”,有的时候比较明显你会发现,有的时候你发现不了那就隐患大了。所以我建议大家在进行关联前,都应该对数据进行一次“重复主键”检验。

2、小心数据倾斜

我们有的时候发现自己写完hive,感觉逻辑什么的都没毛病,但是就是跑得很慢,那么这个时候就要考虑一下是否有数据倾斜的情况了,这个概念我就不展开说明了,百度一下有很多的解释以及解决办法,这个大家也可以看看我之前的旧文《一文带你搞清楚什么是“数据倾斜”》

3、注意空值的处理

我们对于空值的提前预判以及处理,对于我们后续的数据质量会有很大的帮助和控制,这里有一个函数还是很好用的,叫NVL函数。

其格式如下:NVL(expr1,expr2)

含义为:如果第一个参数为null(空值)那么显示第二个参数的值,如果第一个参数的值不为null(空值),则显示第一个参数本来的值。

还有一个升级版的函数,叫Coalesce函数,大家感兴趣也可以去了解一下。

4、大计算量指标的提前拆解

这一块确实是一个比较头疼的地方,有些指标你直接用常规的逻辑去写hive是死活计算不出来的,我距一个例子:近2年内最近一次通话(主叫)的手机号码

我们假设一下我们的客户有10个亿,然后过去两年的通话记录明细,假设每个客户每天至少打1个电话,每天有20%的客户有打电话,那么一天的数据量都会有2亿行。然后我们需要计算上面那个指标,正常逻辑下,可能就是说我们把过去2年的数据都拿出来,然后根据客户ID、手机号码,按照通话时间进行排序,取最新的一条记录就好了。但是一般情况下,是算不出来的~

那么,我们可以怎么办呢?其实问题就在于我们需要对一个大数据进行排序操作,然后计算资源不够导致无法排序成功,那么我们就可以进行“时间窗口”的拆解,比如按月的数据来排序。比如:

  • 取20180101-20180201的数据,根据客户ID、手机号码,按照通话时间进行排序,取最新的一条记录,写入一个临时表,我会命名为 XXXX_loan,其分区为pt_date = “201801”
  • 接着取20180201-20180301的数据,同样的逻辑进行计算,写入 pt_date = “201802”分区
  • 一直写,写到最近的1个月,然后对 XXXX_loan表进行一次最终版的排序去重,按照客户ID,分区字段(pt_date)进行排序,最后保留每个客户一条最新记录,写入目标表。
  • 最后就是设置调度任务,每天增量地去计算每天客户的最新一条记录,用来更新目标表的标签值。

这种比较折中的办法,也是没有办法里的办法了,仅供参考哈哈。

最后我还是觉得我们的心态真的很重要,千万不要因为一些小的困难就打击到自信,慌了阵脚~稳住,冷静思考,这才是我们可以持续成长的关键!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-03-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SAMshare 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 写在前面
  • 数据开发前
    • 标签定义的明确
      • 数据提供方式的确认
        • 标签值的确认
          • 更新频率的确认
          • 数据开发ing
          • 数据测试
          • 交付
          • 开发小记录
            • 1、多留意多对多情况
              • 2、小心数据倾斜
                • 3、注意空值的处理
                  • 4、大计算量指标的提前拆解
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档