大数据浪潮下——数仓数据时效性分析和解决方案

        近些年随着大数据的火爆，尤其是数据实时性需求越来重要，我们原来那套已经捉襟见肘了，流行的方案是kafka+streaming+redis+mysql实现准实时，但是其实在大多时候由于技术框架和应用场景限制，时效性的问题归根到底还是管理和规范的问题。先就不改变应用和技术架构的情况就这些场景的改进做个总结吧：

一 资源

1、调度资源

        调整资源数和作业调度优先级。Job运行的先决条件是按序检查包括incondition(条件)、时间窗口、并发资源、互斥资源、host资源等，即当incondition都拿到之后，时间窗口到了，才会去争抢并发资源，处于wait condition状态的作业是不会参与并发资源的分配的。

        ETL系统（涉及调度、交换平台、数据库服务器等系统）会有个资源池，配置了这些资源的总数。wait condition状态的作业依赖等全部到达，作业会根据配置的优先级，先去资源池检查和竞争池内所剩资源是否满足当前资源需求，要么满足则分配获取全部资源，且资源池减少相应资源；否则将置wait resource状态并等待资源。

         虽然交换平台的DataStage服务器采用集群部署，但机器个数还是有限，ETL作业基于负载均衡机制，由前置机将作业分配给其中一台机器（获取机器的host）运行，因此在host有限情况下，作业也会根据优先级争抢host，抢到则运行，否则则置为wait host状态等待机器资源。

2、环境资源

        环境是作业正常运行的前提，未准备好会影响作业的及时上线。仅涉及到新库时才需要注意这些问题。即需要提前验证库环境可用性，网络连通性，从而保证环境可用，同时将环境信息提交开发人员进行ETL网络和作业环境的配置。

二 依赖

1、依赖上游作业

        由于一个作业通常涉及到很多数据源，因此配置了很多前置依赖，若上游依赖未到位或者依赖设置错误，都会影响Job的运行。如上游作业延迟、报错等。

2、依赖配置

        依赖配置错误是比较常见的，对作业正常运行和时效性也影响较大。其中不易发现和影藏比较深的是开发人员不细心设置了循环依赖或需要手工触发的作业，就需要进行逐级追踪和分析才能发现问题。

三 人为

1、建表

        源表错误无法select（出仓无法抽取），联机库未及时建表，表结构被修改等，这些都是需要开发人员细心和通过严格测试来得到保证的。

2、SQL质量

        SQL质量至关重要，低效的SQL会导致执行超时、日志告警等；错误和逻辑不严谨的SQL会导致数据量扩散；因此开发编码时除了严格自测，更需要在自测后组织相关代码检视等，从而在保证数据质量的同时，可以发现潜在的语法和逻辑问题，保证代码开发质量。保证了数据质量和脚本质量，即间接地保证了数据的准确性和时效性。

7、数据维护

        通常的ETL都是一种比较严格一致导数工具，精度不足、类型不对等都会导致失败。导数迁移时未正确处理数据，前台人员对数据表的录数不严谨（如在mysql中指定为timestamp字段，当复制0000-00-00 00:00:00时，ds抽取即会报错）是导致数据不及时的直接原因，而这些问题通常在调度系统并非显而易见，需要去服务器分析对应的日志文件，这种分析甚至还需要相关人员具有一定的经验和能力。这种数据即使走运能及时成功完成ETL，但数据不可用，依然是做无用功。这实际上也有一点数据质量的味道。

        然而这种情况目前没有一种统一可控的处理办法，解决方案主要是：对前台录入人员培训数据录入标准；对开发人员要根据业务和表结构定义严格处理数据。

8、设计不合理

        设计方面其实和时效性并没有直接关系，在DW开发中，设计通常也不是一蹴而就的事情，因此开发反复返工和上线也在所难免。但是鉴于太频繁的反复，因开发测试和上线都有需要时间和严格执行流程，还是对数据的及时产生有影响的。

四 平台

        平台问题通常是比较难定位和及时处理的，主要涉及到多方协作及流程性的东西，因此这个对数据时效性还是影响比较大的，幸好成熟的DW一般很少出现这种问题。

1、作业僵死

        Job僵死一般指长时间处于executing状态，这个长时间有多长没有严格定义，且一些大数据表的load时也可能会有长时间处于executing状态的，因此还是需要相关经验判断。

Job僵死通常属于系统级问题，调度是无法处理的，只能由管理员进行后台查杀。

2、平台升级维护

        一般指数据库升级维护等，通常会造成作业延迟，异常，少数情况可能会有报错。像这种情况一般及时重跑即可。