从0到1构建数据生态系列之五：让你的数据生态更高效

接这个系列的上一篇《从0到1构建数据生态系列之四：与研发的爱恨情仇》。

好像间隔的时间有点长了，中间插了好几篇其他主题的文章，我们再回归到这个系列。

从早期的数据迁移、数据上报体系的建立，再到数据多维分析BI体系的建立，再到后续的各种不同数据应用服务，诸如各种推荐服务、搜索服务、各种榜单数据的推送服务，整个数据生态已经逐渐丰满了。

随着内部数据业务的逐渐增多，我们对于这些业务服务的把控能力就越低，那么这个时候提升效率将是我们重点关注的问题。

例如：

• 数据分析BI业务从之前的简单几个统计报表，逐渐增加，越来越复杂，依赖的基础计算数据也越来越多，报表生成出错难以追踪来源，无法很好的建立不同层级的中间数据依赖关系。
• 数据上报是否正常，有没有异常波动的上报点位，是属于正常情况还是上报异常，比如重放攻击，机器点击。
• 上一篇提到的，如何提升埋点测试的效率以及准确性，进一步释放人力，减少这种重复性、建设性较低的劳动量。
• 业务部门大量的数据分析需求，数据提取需求，如何进一步降低这种重复性，建设性比较低BI分析工作，释放BI人员的人力。
• 各种五花八门的数据服务，如何能有效的监控起来，随时感知服务的故障，并且及时投入人力进行处理。

任务调度系统

在数据上报体系搭建的同时，我们同步开始进行各个业务团队的BI体系的搭建。

我们需要为运营、内容、电商、市场以及产品等各个业务团队提供天、月以及季度等维度的BI报表，以便各个业务团队进行数据化运营、决策。

单纯每天的BI报表多达数十个，每个报表内可能又包含N个维度的数据。

这些BI报表的基础数据来源为：上报体系提供的上报数据，业务方产生的业务数据，各种服务产生的服务数据。

先不说一些实时性的数据分析业务，单论上述的周期性的BI报表业务，我们来看一下整个业务体系的复杂程度：

• 数十个近百的业务表需要将数据进行周期通过sqoop迁移到大数据中心，进行统一计算。
• 而对于业务服务产生的服务log，我们需要进行log文件的周期迁移，迁移之后进行数据清洗规整入库，加入到数据中心的原始数据集中。
• 对于上报体系的数据，由于量大，我们同样需要周期性进行切分，规整合并，以减少HDFS的IO资源消耗。
• 计算方面，我们进行分层级计算，每个层级之间会有依赖关系。
• 对于最上层的BI报表，我们有详细的详情业务分析报表，也有汇总的概览报表，他们之间也有依赖关系。
• 对于涉及的业务类型，有shell脚本、python脚本、java服务、MySQL表操作、Sqoop迁移操作、MR计算任务、Spark计算任务，以及涉及最多的Hive计算。
• …

单纯的BI分析业务就涉及到各种复杂的任务依赖关系，一旦前面的环出现问题，后续的其他环节容易受到影响，甚至需要花费巨大的代价去追踪哪些数据是错误的，哪些数据是不受影响的。

对于各个任务的管理也是巨大的问题，他们执行结果的跟踪，依赖网络关系的管理等等。

所以，一方面提升整个业务体系的健壮性，另一方面提升业务体系的效率，有必要引入调度系统进行整个业务体系的调度。

简单服务内部级别的时间调度Timer，再高级点的ScheduledExecutorService，JCronTab等，当然也有系统级别的略微重度的Quartz。

但他们都是基于时间维度的调度框架，对于我们的需求来说，依然太过于轻量级，无法满足需求。

我们需要的是一个系统级别，能够进行任务进行调度，对任务依赖关系进行管理，对任务执行进行追踪等，具备这些复杂功能的调度系统。

我们曾一度调研过早期阿里开源出来的Zeus，并且在之前的工作经历中也曾一度使用过它。

首先宙斯出自于淘宝，品质相对有保障，应用于hadoop作业调度而生，对整个生态契合度高，支持MR、Shell、Hive等各种界面化调度，并且各种配置可视化，使用成本相对较低。

更多的优点就不多说了，感兴趣的可以查找一些资料了解，它还曾一度获得过热门开源项目的头衔。

但结合实际，我们最终还是舍弃了它，一方面我们整个集群使用的是CDH体系，想要嵌入宙斯需要改动的东西很多，二次开发的成本略大，并且实际部署略微复杂，BUG还不少，就目前这个状态，我们并没有太多的时间去折腾。

并且，整个项目好像维护的并不是很好，这意味着一旦上线了，风险还是蛮大的。

最终我们选择了oozie+Hue的方案。

CDH对他天然支持，能够与我们目前的集群体系无缝对接，省却了所有的部署成本，暂时阶段只需要把精力放到学习使用上即可。

通过oozie的工作流机制，加上hue的可视化配置，基本可以满足我们上述的那些问题。

使用oozie+hue的方案，进行各种服务的管理，hive依赖任务的调度，错误的报警，错误日志的追踪等，一站式解决问题。

不过，我们在使用的过程，依然遇到了一些坑，以及解决了一些坑。

例如中文编码的问题，又例如如何处理日渐壮大的依赖树，一旦底层依赖出现故障会造成大片上层依赖任务的中断等等。

我们把部分的依赖判断回归到程序中，而不是统统交给oozie的依赖树来管理，避免部分底层依赖错误造成大面积上层任务中断，这样可以做到部分任务可以继续执行，进行依赖分拆，减少大范围任务重跑的风险。

数据上报体系的监控

这里其实有个故事。

曾有一天，业务人员反馈BI分析报表数据好像有问题，整个数据对不上。

数据测马上启动了对问题的排查，通过一顿的各种数据查询，汇总计算，才发现早在三四天前数据就开始异常了，再进行跟踪，发现那天刚好更新了新版本。

再跟踪问题，发现客户端很多模块进行重构，而之前的相关埋点点位受到了影响，客户端方面没有进行知会， 在测试时又没有进行这部分抽查回归测试。

于是，随着版本的更新覆盖，丢失了很多基础数据。

这是一个惨痛的教训，随后，我们一方面制定埋点测试的方案、进行埋点完整性质保方面的梳理，另一方面数据测启动了对数据上报体系的监控。

于是就有了如图，我们对每天，一些重要维度的上报进行了数据统计可视化，检测点位的数据量波动，每天可以随时查看上报情况，此外，根据实际情况建立异常报警模型，一旦发生上报异常进行主动邮件预警，及时跟进。

趋势图是使用echarts画的，页面是spring boot+jsp框架，数据部门从此又多了前端技能，哈哈。

整个检测体系很简单，很粗暴，但是确实有效，对于内部使用，实时掌握上报动态，足够了。

此外，我们还简单的通过守护脚本进程，替代了ganglia+nagios的系统性方案，对各个节点的服务进行监控，进行图表可视化监控，主动预警等。

足够的节省人力，足够的敏捷，以有限的人力解决阶段性的需求为出发点。当然，在一定的阶段之后，必然还是会回归到系统性监控方案中去的。

数据上报完整性测试的痛点

在上一篇中，我们描述过数据上报完整性测试的痛处。

我们需要花费巨大的人力去保证整个上报体系的健壮，因为对于H5页面还好，但对于客户端埋点，客户端一旦发布，出现故障只能通过发布紧急修复版本进行解决，但一样会耽误很多时间，因为整个发布周期至少都是好几天的。

出现如上故事之后，我们着手进行埋点完整性测试机制的搭建。

我们通过测试账号注册的机制，来分离正常账号的流量以及测试账号的流量，通过时间将点位轨迹进行串联，再打通整个实时流程，并且进行点位访问轨迹界面化展示。

基本实现一边点击点位，一边看到上报轨迹，完全同步，一改往日通过日志拦截的方式进行点位测试，根据埋点的编码表，普通的测试人员都可以介入。

数据上报测试机制的完善，大大降低了埋点故障率，确保了上层BI分析业务的健壮性。

开放自助查询体系

即使我们每天为业务部门提供了数十个BI分析的报表，但依然避免不了，我们的BI童鞋每天为各种BI需求奔走。

诸如，电商活动的各种数据调研，产品端各种调研性的数据提取，运营方不同运营位不同运营活动的跟踪等等，这些都是很难做到常规化BI的数据分析提取需求。

但是很多又确确实实是重复性工作，只是因为变量太多，无法做到自动化。

于是，我们开始着手尝试，是否能将部分查询分析的工作转移到业务人员身上，让他们自己去获取自己需要的数据，降低数据团队的压力呢？

我们开始逐渐完善以HUE为核心的自助查询系统，健全自助数据分析体系。

我们对一些Hive的表权限进行隔离，对不同的业务方定制查询模板，模板上注明详细的使用方式，让不懂SQL的业务人员也能根据模板进行一些数据的查询提取等。

例如，运营人员根据查询模板就可以很愉快的改改URL变量，改改时间变量等，拿到他们所需要的对应运营位的各种活动数据，对于我们数据的依赖程度大大降低。

不过，讲真。HUE的整个体系对于那些一点SQL基础的业务人员还是有些使用成本，所以在时机成熟的情况下，还是有必要封装一套高度界面化的自助查询分析系统。

此外，就是我们需要对权限进行严格的隔离，对使用频度进行限制，不然大批量错误的查询会让我们的机器资源过度浪费。

不管怎么样，开放自助查询定然是一个需要去做的事情，将数据童鞋的人力进一步释放出来，放到更有意义的方向上去。

结语

在数据时代，效率至上，所谓效率，不单纯是整体业务的效率，同样也是对应于内部效率的提升。

所以，在不同的阶段下，我们都需要随时反思如何能够进一步的提升效率，结合阶段性的成本投入，进行灵活的健全自己的数据生态效率体系。

不需要说足够完整，在有限的资源下，能够有限解决当前的问题，能够提升一定程度的效率，就是可执行的方案。

下一篇，我们将会把目标放到最上层，即数据从底层一路流转，最终到上层的价值体现。

来源：数据虫巢，作者：blogchong