写个了个清洗数据脚本

由头

  今天写了一个清洗数据的脚本,将感悟整理一下

正文

清洗数据模块要与业务模块分开加载

  清洗数据脚本需要在生产上跑,功能写完之后,想了一下应该为是否加载清洗数据模块加个配置参数,比如在生产上不应该加载节省资源也更安全,如果做不到最好确保脚本是幂等的),而在和正式环境对等的影子库(使用使用相同的数据源)上加载,为了避免与生产数据操作冲突,可以在公共配置上加标记锁,这样在无法线性处理数据时会起到保护作用(但根据锁的实现,会对生产系统的体验造成一定影响),另外清洗系统需要在处理完成之后去除锁,不过让清洗系统做这件事有些风险(清洗系统挂掉了,就没有有机会去除锁了),为避免风险解决方式也很简单,设置手动命令去除锁,或者将清洗系统的状态汇报给监控系统,配置监控逻辑,达到条件(比如一定时间监控不到清洗进城)就解锁。

清洗数据逻辑需要自动测试来保障

  另外就是测试,前几天看到有人说自动测试到底有没有用,我发表了自己的意见,在数据清洗任务中我觉得最好有(当然端自动测试好写些),因为人工测试 1 很难覆盖所有情况; 2 构建测试环境很麻烦,可能给执行人员留下短路机会。
  由于需要在生产上直接运行,风险很高,加上后期可能调整业务逻辑(生产上运行前常有的事),有自动测试会更安全和轻松。当然没有完美的事情,写测试脚本和因需求变化调整很麻烦,不过至少可以将验证工作交给一般程序员或者测试人员来处理,这也算是个折中方案吧。

如何写出更易测试的程序

  对于什么样的代码更方便测试,我的建议是,要对代码逻辑不断拆分到方便逐个测试为止,这与实现功能过程有些相反,实现功能一般都是自上而下的,而方便测试需要自下而上,所以先按一般思维实现,即自上而下,过程中或重构时不断的将功能细分,举个简单例子(非最恰当),处理数据需要循环,在循环里有各种加工逻辑,这是可以将每个加工逻辑拆分成子功能,子功能参数是父功能循环中的一个实体,以此类推,做出来的子功能就方便测试了。

最好将获取数据和处理数据过程分开

  最后数据处理需要注意 就是尽量避免慢速操作,就是将数据先拿到(是否全部得看具体数据和机器情况),然后进行计算密集型操作,这个也与常识,我们习惯拿一条处理一条。当然集中处理也有弊端,比如需要自行处理主外键,要做数据缓存等等,这就又回到了前面关于测试的描述,有自动测试能好很多,可以说有了测试做保障我们就能玩更花的活儿。