分析产品需求背后,程序员引发的思考

今天产品提了个需求,要把亿级的业务数据进行清洗、建模。

1. 解读需求背后

首先带着兄弟们深入了解了一下需求背景,需求简单的几句话,看似不难。做过数据的都清楚,凡是涉及到数据,都多多少少比较难搞。

再三思考,我主要把这次需求划分为:数据获取、数据清洗、数据关联、落地洗好的数据四个大步骤。

数据获取方式能统一吗?

在梳理需求过程中,得知有同事已经实现部分数据采集的功能,内心还是有一股欣喜的狂热,这应该会省不少工作量。于是乎开通 git 权限,开始看看功能实现到了那一步。这一看不当紧,内心奔溃至极。由于不同程序员的代码,实现方式也不一样,一个是直接读数据文件,一个是直接访问数据源。虽然鲁迅说过"不管啥代码,实现功能就是好代码",但是这让后人该如何去抉择呀(大哭)?

数据清洗实现能统一吗?

看完数据的获取方式,再深入一下数据的清洗实现。“庆幸”的是也有部分已经实现了,还是深入了解一下代码吧。惊奇的发现,一部分数据清洗功能是用 shell 脚本 + python;另一部分是用 Java 程序实现;更可悲的是另一部分是人工手摇来实现。道路千万条,我该选择哪一条去扩展,我该部署哪一套到线上(痛哭)?

数据关联如何实现好呢?

面对亿级别的程序,用普通的 SQL 关联,够呛能够顺利完成。于是乎就快马飞奔到程序员的丽景院,来到虽然老了但风韵犹存 Apache Hadoop 的门前,Hadoop 说我适合于离线的批量数据处理适用于对实时性要求极低的场景,磁盘级计算,进行计算时,数据在磁盘上,需要读写磁盘;听着听着,就走到了 Storm 的门口,只见 Storm 正在实时、快速的接待每一位客户,不得不说如果一个大数据应用系统,它就是纯粹的实时计算,不需要在中间执行 SQL 交互式查询、复杂的 transformation 算子等,那么选择 Storm 是比较好的选择;思索之见,又被拽到了 Spark 的门前,Spark 上来就说我是内存分布式计算框架,试图吞并 Hadoop 的 Map-Reduce 批处理框架和 Storm 的流处理框架,争当头牌。其实面对这么多大牌,各有各的用途,内心还是比较难以选择的,最终决定采用 Spark 来试试水。

如何落地洗好的数据呢?

洗好的数据量级不会太大,可以采用关系型数据库存储,也可以用文本文件进行存储。

2. 写在最后

作为一个想进步的程序员,一定要有架构师思维。实现功能的同时,能否可以多想一步、实现的功能是否可复用、代码实现是否可以好扩展、后人是否好维护。

做一个与人方便的程序员,做事不要留尾巴。如果你开发的功能,留个小小的尾巴,接手你工作的同事,在工期特别紧张的情况,依然需要全盘通读你的代码。所以可以考虑能否把自己实现的功能,当做一个黑盒子,只要给输入,程序就给你良好的输出。

做一个技术多涉猎的程序员,没必要逐个技术深入了解,但求各个技术都知道使用场景,这样再面临技术选型的时候就不会不知所措。

好了,今天就讲这么多吧。希望对你有帮助,如果感觉有用,就多多分享给你的朋友吧。

原文发布于微信公众号 - 一猿小讲(yiyuanxiaojiangV5)

原文发表时间:2019-05-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券