离线数据构建任务

 最近给我们的广告系统的搭建了一个离线的数据流平台，主要逻辑是为线上广告系统的提供特征数据；主要的思想还是lambda架构；原始的lambda架构如下：

来自于：https://towardsdatascience.com/a-brief-introduction-to-two-data-processing-architectures-lambda-and-kappa-for-big-data-4f35c28005bb

主体思想是如此，我们的细化架构如下

离线数据流架构

三种数据流

实际上我这边包含三种数据流：

1、纯日志数据流，即接受原始日志的数据处理流

2、flink数据流，在这里flink的数据来源也是数据流，通过flink完成数据的二次加工

3、离线日志流，这里主要通过spark任务，主要处理的是天级别或者T-1级别的日志数据

纯日志数据流

    这类数据来源主要是web服务打印的访问日志或者接受的mysql的binlog流，原始或者经过一些简单过滤分解的数据流，依赖一些中间件完成同步到kafka；此类数据流的特征是实时性较高，但是也会存在数据量较大的问题：

1、并发量很难控制；因为是访问决定的，访问量的增加在业务端不再使用端，也就导致存在访问量巨大，瞬间堆积的情况

2、数据量较大；数据没有复杂的过滤，各个业务在使用时，需要承接这个的大量日志，然后根据自己的需要做进一步过滤

3、使用方法受限；因为是简单的日志流，如果不借助一些中间件（主要是计算类中间件），只能进行一些访问记录类的统计

flink数据流

    flink的数据流也是基于纯日志数据流，在此基础上完成以下计算，例如：频度、比率等；为了节省资源，flink只是完成一些准实时类的统计（秒、分钟级别）；flink在任务在使用时主要的问题在与更新时的问题，因此借助与kafka来解决掉这种问题，但是会带来时效性差一些（kafka转发耗时和kafka数据消耗耗时），但也在分钟级左右（业务可以承受）；

    使用kafka的原因主要在于

        1、削平波峰，flink瞬间更新量较大，如果直接对接存储，会导致存储需要应对较大的瞬间访问

        2、数据可靠性，使用flink不太好做访问存储错误导致的数据丢失类的容错，使用kafka队列来保证数据可靠性

离线日志流

    按照lambda架构的原则，此日志流主要处理非实时的数据任务；在这里主要使用的spark来完成；对于存储的访问，为了保持访问逻辑一致（离线写入和实时查询），会提前封装对应的访问组件；现在提供的主要java版本的逻辑，因为在容器中部署的consumer是主要使用方，也是使用java编写；