分析产品需求背后，程序员引发的思考
今天产品提了个需求，要把亿级的业务数据进行清洗、建模。
1. 解读需求背后
首先带着兄弟们深入了解了一下需求背景，需求简单的几句话，看似不难。做过数据的都清楚，凡是涉及到数据，都多多少少比较难搞。
再三思考，我主要把这次需求划分为：数据获取、数据清洗、数据关联、落地洗好的数据四个大步骤。
数据获取方式能统一吗？
在梳理需求过程中，得知有同事已经实现部分数据采集的功能，内心还是有一股欣喜的狂热，这应该会省不少工作量。于是乎开通 git 权限，开始看看功能实现到了那一步。这一看不当紧，内心奔溃至极。由于不同程序员的代码，实现方式也不一样，一个是直接读数据文件，一个是直接访问数据源。虽然鲁迅说过"不管啥代码，实现功能就是好代码"，但是这让后人该如何去抉择呀（大哭）？
数据清洗实现能统一吗？
看完数据的获取方式，再深入一下数据的清洗实现。“庆幸”的是也有部分已经实现了，还是深入了解一下代码吧。惊奇的发现，一部分数据清洗功能是用 shell 脚本 + python；另一部分是用 Java 程序实现；更可悲的是另一部分是人工手摇来实现。道路千万条，我该选择哪一条去扩展，我该部署哪一套到线上（痛哭）？
数据关联如何实现好呢？
面对亿级别的程序，用普通的 SQL 关联，够呛能够顺利完成。于是乎就快马飞奔到程序员的丽景院，来到虽然老了但风韵犹存 Apache Hadoop 的门前，Hadoop 说我适合于离线的批量数据处理适用于对实时性要求极低的场景，磁盘级计算，进行计算时，数据在磁盘上，需要读写磁盘；听着听着，就走到了 Storm 的门口，只见 Storm 正在实时、快速的接待每一位客户，不得不说如果一个大数据应用系统，它就是纯粹的实时计算，不需要在中间执行 SQL 交互式查询、复杂的 transformation 算子等，那么选择 Storm 是比较好的选择；思索之见，又被拽到了 Spark 的门前，Spark 上来就说我是内存分布式计算框架，试图吞并 Hadoop 的 Map-Reduce 批处理框架和 Storm 的流处理框架，争当头牌。其实面对这么多大牌，各有各的用途，内心还是比较难以选择的，最终决定采用 Spark 来试试水。
如何落地洗好的数据呢？
洗好的数据量级不会太大，可以采用关系型数据库存储，也可以用文本文件进行存储。
2. 写在最后
作为一个想进步的程序员，一定要有架构师思维。实现功能的同时，能否可以多想一步、实现的功能是否可复用、代码实现是否可以好扩展、后人是否好维护。
做一个与人方便的程序员，做事不要留尾巴。如果你开发的功能，留个小小的尾巴，接手你工作的同事，在工期特别紧张的情况，依然需要全盘通读你的代码。所以可以考虑能否把自己实现的功能，当做一个黑盒子，只要给输入，程序就给你良好的输出。
做一个技术多涉猎的程序员，没必要逐个技术深入了解，但求各个技术都知道使用场景，这样再面临技术选型的时候就不会不知所措。
好了，今天就讲这么多吧。希望对你有帮助，如果感觉有用，就多多分享给你的朋友吧。
