日志这一形式,从最初的面向人类演变到现在的面向机器,它发生了巨大的变化。诞生之初日志主要的消费者是软件工程师,他们通过读取日志来排查问题。现如今,大量机器日夜处理日志数据来生成可读性的报告,以此来帮助人类做出决策。在这个转变的过程中,数据采集Agent在其中扮演着重要的角色。 

作为一个数据采集的Agent简单来看其实就是一个将数据从源端投递到目的端的程序,通常目的端是一个具备数据订阅功能的集中存储,这么做的目的其实是为了将日志分析和日志存储解耦,同一份日志可能会有不同的消费者感兴趣,获取到日志后所处理的方式也会有所不同,通过将数据存储和数据分析进行解耦后,不同的消费者可以订阅自己感兴趣的日志,选择对应的分析工具进行分析。

基于业界现状Petabase重拳出击

目前业界比较流行的数据采集主要有Logstash、Flume、scribe等,其中flume可以通过监听目录将数据文件上传到大数据仓库来实现业务分析。而Petabase集合了flume组件以及消息队列组件kafka,从而大大的减少了整个数据文件采集和分析的复杂度。Petabase希望通过统一数据平台来降低整个数据采集接入的复杂度,假想下输入的数据格式比如有M种格式,数据采集Agent后端接入了N种存储,那么每一种存储系统需要实现M种数据格式解析的功能,总的复杂度就是M*N,如果Petabase采集数据文件实现了控制平台组件化统一,那么这种格式总的复杂度就变成了M + N。这可以大大提高实施人员开发能力,从而提高效率。

作为一个数据采集Agent在大多数人眼中可能就是一个数据“搬运工”,还会经常抱怨这个“搬运工”用了太多的机器资源,简单来看就是一个tail -f命令,再贴切不过了,对应到Petabase里面就是数据迁移插件。笔者作为一个亲身实践过数据采集Agent的实施者,希望通过本篇文章来给大家普及下数据采集Agent开发过程中的一些技术挑战。

1、如何发现一个文件?

当我们开始写数据采集Agent的时候遇到的第一个问题就是怎么发现文件,最简单的方式就是用户直接把要采集的文件罗列出来放在配置文件中,然后数据采集Agent会读取配置文件找到要采集的文件列表,最后打开这些文件进行采集,这恐怕是最为简单的了。但是大多数情况日志是动态产生的,会在数据采集的过程中动态的创建出来, 提前罗列到配置文件中就太麻烦了。正常情况下用户只需要配置一个数据采集的目录和文件名字匹配的规则就可以了,比如Nginx的日志是放在/var/www/log目录下,日志文件的名字是access.log、access.log-2018-01-10…..类似于这样的形式,那么在Petabase中可以在flume组件的agent配置spooldir类型来动态监控数据文件,当监控的目录有数据文件,就会自动将数据传输到你想要它去到的地方。

2、如何将一个文件变成一个消息队列?

传统的数据传输都是直接将数据发送给目的端,可是如果数据的发送端速度比接收端速度快,那么此时的数据传输就会出现堆积、膨胀,或许会出现丢失数据。这个时候要怎么处理呢?Petabase集合了kafak消息队列组件,当flume监控的数据推送出去的时候,他们要像列兵一样一个一个按照顺序在Topic里笔直的站好,直到下一站有能力接收他们。他们才会乖乖的走出去。这样Petabase就帮您解决了数据堆积膨胀丢失的问题。

3、数据文件想要包装自己变成表该怎么办?

前面提到Petabase已经是一个集大成的数据组合大数据平台,并且可以提供统一的控制台,去把数据文件中的列兵一个一个的按照既定表格式,表类型,分割符,字段名,转化为他们想要的表,这样一来,不管是BI还是什么展示平台,只要通过jdbc连接petabase库就能实现业务分析展现,从而让数据变得更加的易用和美观。

PetaBase-s是亿信华辰重磅推出的企业级实时大数据平台。它基于开源Hadoop框架开发,融合MPP、SQL on Hadoop、流处理等大数据技术,支持海量数据的高效储存和统一管理,为企业决策提供实时的数据支撑,欢迎前往官网申请试用哦~

文章来源于互联网,如有雷同请联系站长删除:数据采集都在用哪些“酷”技术?这有一个神器可以告诉你

发表评论