每个年末都要进行总结，并对来年进行规划。
老梁说，你要不也贴到社区？
所以做了一个相当于摘抄式的总结。
一、2015年
工作：带领团队成功实现从传统BI到大数据BI的转型
生活：和小孩、自己父母都生活在一起，其乐融融
做了管理，很多事情都需要从全新的角度去处理，手下的兄弟们也成长很快，很多事情都放手直接让他们自己去思考和完成了。
去外部学习了很多次，认识了不少的朋友。
比较遗憾：
生活：陪老婆孩子的时间变少，爽约的次数增加了
在整个年度中，看书是一件略感欣慰的事情。购买书几十本，每周阅读技术博客20+;
收获：看的越多，感觉自己懂的越少。
2015重要工作
集群数据仓库建设
微信轨迹基础建设
分布式数据库集群建设
轨迹跟踪分析系统
支撑从几亿页面数据进行查询
支持多个App的监控、统计和分析工作
从渠道、订单、资源、上下级、页面多级路径等方面为业务提供更加准确的数据
完成App轨迹的实时数据解析架构，将数据丢失率降从12%降低到2%以内
数据存储：
从数据使用热度方面来考虑：
1.极热数据使用elstaticsearch集群来存储。测试过solrcloud和elstaticsearch的性能，还是elstaticsearch好很多。
2.一般热度数据使用redis+hbase来存储。
3.冷数据采用hadoop+GreenPlum来存储。
不同的存储介质支撑不同的系统应用。
2016年的规划
1.建设性能强悍、满足多方需求的大数据BI系统
2.围绕集群来建设DW和CUBE
3.深入优化GreenPlum+hadoop，让性能更加优越
4.hive on spark的系统性运行
5.db与nosql、消息队列等之间的数据依赖和数据调度
技术方面继续保持当前的学习模式，一步一步向前，构建最贴合自己实际的系统组件。
1.spark生态学习，包括spark集群、spark sql，spark streaming spark mlib等
2.kylin的线上运行
3.hive udf的系统化开发
4.elstaticsearch集群的线上使用
以上是几个重点的工作内容。
其实在移动互联网公司，数据是最麻烦的一件事情。很多公司都有类似的问题：业务上线后再通知数据中心：赶紧给我提供数据，我要统计和分析。
在业务为导向的团队中，数据团队在收取消息方面是非常滞后的。
这就会产生一个两难的选择：
要想体系化做数据仓库和产品建设，就没法响应业务的临时诉求；
如果新业务发展太快，那体系化建设就严重滞后。
作为负责人，压力也是巨大的。因为同事最想的是系统化建设，但是上峰是业务优先。不想伺候业务是吧？那KPI就要收紧。
这样的一个夹心层，是很不容易的。
所以，我们的工作可以想象为在高速行驶的车上进行换轮胎的工作。
经历过这些，也有一些总结和收获：
1.移动互联网公司的UBT团队一定要好，用户行为数据及相关的收集、统计、分析系统一定要够强。
大部分的部门都是在进行内容的制造。最灵活的内容载体是H5。它既能在App打开，又能在Touch站打开，还能嵌套在微信，彼此之间还有可能是跨域收集。
将这些页面的用户行为数据进行区分统计，给业务部门提供最精准的流量、转化率数据 是我们的一个重点工作。
线上各种名目繁杂的活动、广告位、ABTest等都是要在后端做好实时监控、统计分析。
这一切都是需要一个团队专职去跟进完成，涉及前端埋点、收集组件的研发、实时计算系统、后台统计系统等
在这个方面我觉得我的团队收获很好。
2.业务数据的清洗和仓库建设。
我们之前都是在关系型数据库来完成仓库建设。但是业务发展过快，如果不维护，那半年后就不能用了。
而且数据增长过快，只能选择采用集群来完成。
我们从零开始，经过一系列的加班加点，让现在的hadoop数据仓库进入了系统化的阶段。
这其中涉及到数据同步组件的研发、数据流任务的调取组件研发等等
二期我们将深度优化仓库，使用spark来补充hive计算慢的问题。
算了，先写到这了。
如果有兴趣的朋友，可以随时私聊。个人资料中有联系方式
