实践：大数据平台1.0总结和2.0演化路线

从3月份到如今2个月过去了，整个数据平台从0到1，算是有了一个基本的样子，跌跌撞撞的勉强支撑起运营的一些基本业务，固然这仅仅是开始，下一步还要从零打造本身的UBS系统，想一想都兴奋呢!接下来总结下本身这段时间的得失，以及下一阶段的演化目标。

　　关于产品架构的原则能够查看这里，我分了两篇来写：

　　https://www.cnblogs.com/buoge/p/9093096.html

　　目前的架构方式是这样的:

　　从使用Sqoop 定时从MySQL中同步数据，数据量大只能小水管的去fetch每次5-10W条记录，避免数据库压力过大

　　Flume tailagent 每汇总一小时而后传递logcenter,经过Python过滤后批量的Load到hive中

　　每日的报表在Hive的基础上会跑一些 MR 的Job, 做为每日的固化查询。

　　目前的缺点和不足：

　　问题： 日志读取,Hive入库和完成后删除log日志原始文件没有作完整的事务控制，load失败或是任务失败，原始日志已经删除了，尴尬:sweat:，目前解决方式是保留15天的原始日志

　　解决方案 ：后续引入Kafka的日志回放功能，它有机制保证写入一次后在返回

　　问题 ：各类crontab 飞起没有统一的调度平台，crontab 之间有依赖关系，可是crontab并无作先后的依赖检查和重试

　　缘由 ：数据就我一我的，平台架构和业务要同时搞，老板在后面催没有这么多时间允许我慢慢的搞的这么精细

　　解决方案 ：引入azkaban任务调度平台，统一管理

　　问题： Hue还没安装，神器不解释了，把各个集群的指标汇总在一块儿，HDFS，Yarn, MapReduce都能在一个页面直观的看到，并且还有个方便的功能就是Hive的web客户端，不用每次都去终端敲ssh命令，公司网垃圾ssh总是断浪费时间

　　问题： HDFS数据不能修改，只能删除重建，这里其实更适合日志类的信息，像订单分析和会员分析，须要作增量更新的记录则不合适，就几万条记录须要更新，可是把上亿级别的表删除在重建绝对是有问题的

　　问题： HDFS 同步有24小时的时间差，这期间线上的订单和会员信息已经发生了百万级别甚至更多的变化，而hadoop集群却无法及时的同步，从Hive出去的报表也不会包含这个空档期间的数据，准确性和实时性有待提升