成为数据工程师
去年10月左右，高管对我们BI团队的定位有所转变，团队不再需要过多的Java工程师，我们开始被定位成数据工程师。
过去
第一阶段 Apache Nifi
早在实习期间，部门就让我潜心投入到Apache Nifi的功能和源码研究中去。这个大数据交换平台的数据模型、流式处理、容错、背压等技术都有自己的一套理论，高度组件化和可定制化非常吸引人，但对高速磁盘的依赖和cdc组件挥之不去的OOM隐患也为部门同事所诟病。
研究几个月下来，写了上万字的文档，增强了几个组件的功能，还给社区贡献了一个小feature，算是意料之外的一点小成就。
第二阶段 数据分析
这不是我擅长的，当时我对此一无所知。
新产品需要定价，但没人敢拍板公司新产品的定价规则。一开始他们在业务端寻找答案，但业务只能给出历史的状况，没人敢说历史一定是对的，这个问题就找不到一个可以依靠的基石。
在deadline前的最后一个月，他们开始意识到这件事需要数据部门的支持，即便无法直接给出一套规则，至少也能给出一些信息，比如现在的定价规则是不是对的？
时间太紧，deadline巨大的压力从高管直达我们这些干活的小兵，我们开始没日没夜的工作，每天都是一点钟回家，偶尔还通宵几晚。
我们用图形展示出了各个用户的体量和我们对他们收的费用，从各个角度来定义我们从用户身上所得的利润单价：单张开票收费、开票金额每万元收费、年度开票量收费、年度开票金额收费等等。历史价格体系的不合理在这些图形中是清晰可见的，但以前从没有人发现，也许他们模糊地感受到了，但没有这么直观。
这次他们都认同了这种不合理。但合理的体系应该是什么样的？
开始向预测和评估的方向走时，就已经不是数据分析要做的事了。但我的领导冲的太靠前，导致他成了完成这件事的唯一希望，也是唯一值得施压的人。以前公司对数据部门建设的忽视让整个公司找不出一个数据分析师和数据挖掘工程师，但在这短短的一个月公司全都要。于是做java的，做etl的，做报表的我们都变成了数据分析师和数据挖掘工程师。
我用大学里简单的机器学习算法做用户分类和预测，贫乏的特征工程知识和实践经验让我调参的手段极其野蛮：遍历。三层for循环一套，整个python脚本就像个老牛车，鬼都不知道它什么时候能跑完。
好在数据量不大，它终究是跑完了。
有亿点不优雅，但总算完成了业务线提出的各种猜想的预测，期间实现了几个类似于个税的价格机制，复杂到我跳脚。
好在是有收获的，不在于技术，每每看我那些粗鄙的代码都想把它们删掉，而是我对如何把一件不知道该怎么做的事情一步步变得让自己知道怎么做有了些许心得：拆解细分永远是不过时的，这个世界上很多大问题都是小问题的集合。
第三阶段 数据开发
虽然干了一个数据分析项目，但我向来没把自己当数据分析师。这岗位离技术远了些，而且很多时候数据分析都是在说明问题，而不是解决问题。解决问题是很重要的。
在分析项目之后，我干的都是数据开发的工作，取数、etl、数据建模、排查问题，偶尔写一些脚本自动化处理一些东西。慢慢开始负责一些比较重要的项目，涉及到一些大公司如蚂蚁金服和沃尔玛。也许以后会记录下这些项目的心得。
忧虑
也许是作为一个技术人，思维也受限于技术，我始终担心公司的技术栈可能会制约我未来的发展。受限于数据量和运维成本，我们做数据仓库用的是Greenplum+Kettle，与外面大厂的Hadoop等技术体系格格不入。
我曾寄希望于年初所计划的实时数仓。我参与了技术调研的整个过程，对深入使用Flink和解决kappa架构下实时数仓的各种问题都非常有兴趣。还兴致勃勃地下载编译了flink代码，用编译的文件搭建了一个flink集群。但高管对我们的计划又做了调整，整个上半年都在做传统的数据仓库、数据分析和报表项目。
在最近的某次讨论中我意识到实时数仓的项目应该是遥遥无期了。
其实经过近一年的数据工作，不难发现技术对数据工作的重要性其实远低于业务知识，但工作和找工作的要求有区别的，只要jd的要求上写着hadoop，这种忧虑就一直存在。
做一个项目
在github上发现了一个数据仓库项目TitanDataOperationSystem，从需求分析到结果展示都非常完整。于是我也产生了做自己的数据项目的想法，也许是用大数据体系的技术重做公司的数仓项目，也许是用一些开源的数据集。终极的目标应该是看看把公司现在的传统数仓项目放到大数据技术体系下会是怎么样的吧。
