心血来潮，写篇文章记录下个人大数据方面的经历。
0X01 背景
在2016年初，开始接触大数据，那时候对大数据完全一篇空白。在此之前做了4年多的JAVA，主要负责互联网电商订单、清结算等系统。
某日，Leader 喊我去办公室私聊，商量由我接管大数据平台，征询我的意见。
我呢，内心自然是不乐意，一是没经验，二是对大数据自有一套技术栈，从零学成本高，是个苦逼的活。以我对他的了解，每次私聊都是确定让我做干了，只是以商量的语气通知我罢了，与其反抗，不如硬着头皮扛下来，以体现我的大无畏精神。
认为我合适的理由
- 现有大数据平台成立快2年，走了2波人，到目前为止报表的数据还是不准，被用户投诉。
2.负责过清结算系统，对各业务熟悉，对数据完整性比较敏感。
- 说我有工匠精神（嗯，有眼观）
给我一个季度时间，没有任何KPI考核，按我的方式折腾，需要其它团队配合，由他协助推荐。
0X02 从零开始
初到大数据团队，还剩2个人，略有凄凉。原负责人据说不堪压力跑路，也跟着跑了些。剩下当中，一个已提离职，跟我交接两三天也跑了，剩下了一个在公司5年的老员工（并肩作战2个月后也跑了.....）哈哈...
- 第一阶段
根据平台现状，继续完成一些新报表需求，顺便熟悉下情况，原团队做法HIVE清洗数据，前端通过 HIVE JDBC连接，导出excel，之前运营吐槽好几次速度慢还不准。也是首次体会到hive背后跑MR多么慢。一个月时间开发了二三十张报表后准备向领导汇报成果时，产品经理突然说原来报表都不要了，特意招了数据分析师，定义了上百个指标，要求报表查询秒级响应。除了离线报表灵魂查询，还要用户行为的实时分析需求...内心万千草泥马呼啸而过...
- 第二阶段
浪费了一个月时间之后，我认真思考一个问题，为什么过去的数据团队花了一年多时间做的东西不能用？Hadoop,hbase，hive等组件也有用到，原来的大数据工程师个别技术也不错，表示很好奇，我想先找到原因，并不急于着手新需求开发。
经分析，原因如下
- 源数据不准，不全，缺失
- 电商业务迭代变更快，埋点数据维护不及时
- 数据上报格式缺乏统一规范
- Crontab定时调度无法保证DAG调度准确性
- 数仓未做分层，重复清洗
- 其它团队直连使用相关大数据组件，占用资源
- 人手问题
- 其它
另外，除了公司内部的需求，还有一些外部合作伙伴的报表需求，尤其是一些银行，态度强势...这也可以理解之前同事为嘛跑路...
经思考，解决方案如下：
- 确保源数据质量
我想说的是，这是最最最重要的环节，源数据质量得不到保证，后面所有的努力都是瞎折腾。
对这方面感触之所以比较深，就是之前做清结算的时，三方对账，各种对账单数据准确问题摧残了很久，银联/支付宝/微信/几十家银行对账文件什么乱七八糟格式，哥啥没见过，写了多少解析规则，也是一段辛酸史，尽可能保证数据准确性达95%，一些异常数据还是需要人工去修复。
定义统一的json格式，含公共部分及data部分，后者内部可以差异化的业务字段。
用户行为类数据，由前端负责人提供android,IOS,PC端sdk进行采集上报，后端右各项目组代码埋点，主要设计订单，支付，退款，商户，门店，供应商，会员，营销，商品等业务数据，邮件周知各位负责人，由总监牵头推进，限一两周内整改上线，并要求自查或补充已发现某逻辑部分缺埋的地方。如此，也给自己争取了时间搭建数仓。
- 设计数仓模型
前文提到过，之前新招的一个大数据工程师，试用期不到一个月就提离职，他跟我交接时间不到1周就走了，唯一留下有价值的信息就是：建议数仓分层，其它公司一般这么做。让我有这方面的意识。经过一段时间摸索和实践，数据分层模型也搭建起来了，详见我另外一篇文章 《数仓分层模型》
- 第三阶段
重新组建数据团队
- 招人
由于之前团队人员的流失，向CTO申请资源，批准招人，于是自己就去面试，由于还是小白，接下来基本上连续几个月都在加班，一是不断补充学习Hadoop生态体系常用的框架组建的原理及使用。如Hadoop/Hive/Hbase/Sqoop/flume/Kafka等。如果你想在某个领域里成为专家，就必须对相关领域的技术广度和深度都有触及。由于我的时间非常有限。只能通过迭代式的学习方式，今天看hadoop/明天看flume，了解每个组建都能解决什么问题，并不做太深入。
其次，在招人的过程当中，也是向应聘者学习的过程，了解对方公司大数据平台架构如何，从前面几个人那里吸收到经验，再问其他候选人。面试多了再回去看一些官网资料，这段时间颈部很大，甚至觉得比对方工作两三年内的还内行一丢丢。看着对方架构，甚至可以短时间指出可能存在的问题。最后找到2个比较合适的。由于大数据人力成本比较高，HR和CTO建议招工作2年左右或者内培养。另外抽调了2个从应届生过来，1个是刚毕业就一直跟我做项目的，另外一个其它项目抽调过来。这两个小伙子学习能力很强，用的很放心。后来又来2个刚毕业的研究生，加老员工规模七八个人左右。
- 分工
首先，hold住外部压力。
安排1个同事专门写python从线上导报表(
mongo和mysql)，数据都是准的，确保统计口径正确即可。还有一个目的，就是让其他几个安心做事，不受干扰。
其次，梳理所有报表需求。
安排2个同事与各业务线及项目组对接，梳理和确认表，字段，含义，枚举类型，数据类型及说明要求的上报规范等。这也是后面数仓做准备。后期参与清洗脚本编写。
第三，梳理线上资源使用情况及清理
让1位有hadoop集群搭建经验的哥们，梳理现有平台的使用情况，确认哪些不用的组件及陈年老旧的java 应用，定时脚本没用的都删了。另外一个任务，评估未来3年数据增长情况，及需要的硬件配置，申请采购新服务器，并研究CDH的安装与使用。
第四，实时分析模块维护
安排2个同事负责实时模块的维护和新需求开发，由于这块实时分析的基本上是日志类，如PV,UV，用户行为相关的，虽然个别统计口径不准确，但也能用，暂时不做重构，降低了优先级。
第五，WIKI经营
主要由我负责编写各类文档，本人习惯用markdown编写，使用艺图EDraw画各类架构流程图。
在WIKI上主要内容如，需求管理，接入规范，消息格式，数仓模型，大数据平台架构，部署架构，安全管理等等。个人后期也编写了大量清洗脚本。
差不多1个月左右，数仓工作基本完毕，也通过测试。
0x03 进阶- 平台升级
- 新服务器采购
- 将原生apache hadoop集群迁移CDH
新服务器采购
缘由：
- 生产环境Hadoop集群配置都是8core,32G内存,4T存储
- 测试环境Hadoop集群配置都是4core,8G内存,100G ，还是虚拟出来的
- 生产环境除了Hadoop集群跑了很多JAVA应用，比如用Kafka+JAVA多节点实现实时分析处理等，有时候出现资源使用过高，运维预警。
- 使用原生的apache hadoop集群，没有HA,也没有类似ambari集群管理工具，纯手工配置。
还遇到的问题：
- SecondNameNode有配置，却没有生效，hadoop集群出现不可用。
- flume1.6版本，sinkHdfs没问题，sinkKafka时，若channel中没有数据，有个while无限循环bug导致CPU%.
- 当升级flume1.7后，又出现kafka版本0.8太低，flume sinkKafka失败，于是由升级到Kafka1.0.
*当kafka升级到1.0后，又悲催了，有其它团队消费我们平台的kafka集群，我也不知道。由于对方客户端版本比较低，无法消费数据，一周才发觉。后商定然对方自建Kafka集群自用。 - Hive 使用的时Hive1,意味着只能所有的HQL脚本只能串行执行，不能并发。由于有个项目直连我们Hive，导致我们contab的定义的脚本没有按时执行。
- 缺乏一个可是化界面，每次跑脚本都是通过命令行，有的脚本跑3个小时，等的很痛苦，看的心累。
- 还有各种奇葩问题..不展开讲了....
迁移旧集群到CDH集群
测试环境配置太low ,CDH跑起来，于是拿了3台原生产环境机器用于测试环境。安装完毕后生产环境也部署了一套。
将原hadoop集群迁移到CDH上，另外也迁移了Kafka集群的数据。由于历史的上传的数据很多不准不全，没有多大价值，除了行为日志类的，基本全删。通过拿去生产业务库数据全量初始化一次。
使用Hue 可视化工具极大提升了开发效率。已经使用Hue上workflow(ooize)编排DAG，跑了一年很稳定，比crontab靠谱的多。另外通过sqoop做些数据的导入导出。
其它方面遇到的痛点和坑，会再写文章分享出来。
码字不易，自从跳进这个坑，连续苦逼加班几个月。唯一欣慰的是，年会时，获得年度优秀员工奖，有几K奖金，就当作加班补偿吧。
Over.
