首页 > 代码库 > 2016年总结
2016年总结
毕业后步入社会已经第四个年头。
首先我要对2016年的自己进行检讨!在年初3月份得到一家互联网上市公司的offer,没想过其为自己提供的职位与福利是否真正符合自己的需求就屁颠着过去就职。入职后才发现此上市公司福利几乎为零,且不说工资福利是偏低的,单从其死板的管理制度,有等级的上下级关系和各种开发不规范来看,此公司就是一个远被潮流替代的所谓的“龙头”公司。
公司的种种坑爹手段就不提了,毕竟是自己选择的,我也不埋怨太多,只是这一年来的工作经历让我懂得了一个道理:要勇敢say no,既然确立了目标,就要自信地迈出步子!
三月初,公司确立做一个公司各产品(交易系统)的数据中心(PDC),打算将各系统数据集中整理、加工、汇总到PDC,采用Informatica作为ETL工具实时调度。
立项之初,我向公司提出此产品的不可行性,可领导为了自己年底述职有话可讲,无视了我的意见。PDC的大概架构如下,各源库有日志监听器,同步数据到ODS层(数据操作层),按系统分库存放,然后经过关联汇总到模型层。每层都用Informatica来同步数据库
领导的要求:
- 数据从源库更新,要求数据毫秒级到达模型层。
- 源库支持异构数据库(也就是可以为Oracle、Ms sql、Mysql等等关系型数据库)。
首先不排除市面上真的有符合此要求的同步软件。就我们用的Informatica的PowerExchange(Informatica的同步组件)来抽取源库日志同步的话,是没办法在如此分层情况下达到秒级传输的,特别是Oracle利用Logminer来分析日志特别慢,串行写日志这一机制就限制了不能在高并发的情况下达到如此性能。
既然是数据中心,就应该舍弃实时(因为风险大),个人认为老老实实地设计成数据仓库比较保险。因为如果按上述机构实施将会面临:
- 如何保证性能?分了层,又要通过日志同步,怎么可能达到毫秒级查询?
- 实时的情况下,如何能保证业务的一致性?ODS层下关联不同的库的表时,如何保证已经同步完?如何保证每秒查询的数据都是最新的?
而有一个硬需求就是,如果数据中心达不到秒级查询,那数据中心将没有意义!
现在Informatica的PowerExchange已经证实不可能达到秒级同步,而且Informatica价格昂贵,如果我们的产品基于它来设计底层同步,那么我们的产品会绑死在Informatica上,到最后肯定很多客户因为要自己另掏钱买Informatica而放弃使用本数据中心。我尝试通过各种数据库优化方式优化同步速度,但是因为Informatica读取日志本身有一定的速度限制,优化效果以不佳告终。于是想到了让厂商,本来选择Informatica是因为其相对于开源的同步软件多了技术支持,但由于Informatica公司没看到咱们这个数据中心的“价值”,在合作方面一直消极应对,这也怪不了他们,因为即使是开发者的我,也认为此产品不现实,无卖点。果不其然,最后Informatica没提供相应的技术支持,导致开发周期一再延后。我真心希望能做成这个产品,孩子还在襁褓中的时候就应该要想好接下来要面对的春夏秋冬啊。可惜。
另一方面,项目组在实践大数据产品之路早在我进公司之前已经有了一定成效。开始在某项目中率先提出用Greenplum+Hadoop Spark来解决实时数据分析问题。而我进公司的时候,经理要求我搭建一个Hadoop+Hive+Hbase+Spark的环境。由于之前有安装Cloudera Hadoop的经验,上班后第一周就已经完成了环境的搭建。记得因为公司不能上外网,我每天都得记得自己要回家下载哪些搭建环境所需要的软件,遇到了问题也只能手机查。很多以前认为很容易得到的东西,在这个公司真的举步维艰。
公司要打造一个基于客户群体标签作计算的分析平台。开始其实是用Greenplum做的,客户对性能要求也满意,但后来貌似GP越跑越慢,多次优化无果后将其上负担较重的模块迁移到Spark上去计算。
但继安装完Hadoop环境后,我在大数据开发这条路上就停了脚步,因为公司要安排人手先搞上面所述的数据中心。而我进这家公司的目的,只有一个,就是做Hadoop开发,做数据分析。招我的经理在我进公司没两三个月便离职了。真的有点被骗的感觉。不过我却从未停下学习的步伐(最近在学习Spark+Scala)。
那些坑坑洼洼我就不说了,我只想说,坑爹公司改变不了我的初心。
我应该要越挫越勇,再接再厉!
我相信经过这一年的掉坑之旅,让我意识到自己真正想要的是什么,让我意识到我内心深处一直在渴望着找到自己的一片天。
2017,我们再接再厉!
2016年总结