大数据日志分析系统-介绍 二-整体架构介绍

    首先说：技术为了需求而服务，公司的需求就是进行日志分析。

    

    公司现状：CDN公司（可以百度一下），边缘节点服务器会产生很多用户请求日志，要对日志进行各种分析和原始日志打包，最终分析结果进行收费、让客户可以获取请求日志各种分析结果、为客户进行原始日志按域名按天按小时分割打包。

 

    先说满足这样的大数据实时计算需要的几个基本组件（一定要注意版本问题，java大数据机器间通信用的是RPC 而不是restful_api,如果版本不对应很可能出现版本间的兼容问题）：

1.日志收集    -从CDN边缘节点服务器进行日志收集

2.日志缓存    -收集上来的日志存储到一个缓存设备

3.数据计算    -对收集的日志进行计算，域名请求数分析、地区统计等等

4.计算结果存储    -对各种分析结果进行存储，要方便查找

5.日志打包结果存储    

 

 

首先说公司刚开始的日志系统分布：

logstash-forward (边缘节点日志收集，上传到有logstash的机器)       -》

kafka  强大的数据缓存组建          （由logstash收集日志到kafka）    -》

elasticsearch (分布式、可扩展、实时的搜索与数据分析引擎)  (用logstash从kafka取出数据存到es)  ->

spark（大规模数据计算引擎，从es取出原始日志然后通过spark计算结果）    -》

elasticsearch （进行计算结果数据存储），hadoop（原始日志打包存储） -》

nginx  + django服务  进行反向代理、负载均衡、地址隐藏            django进行界面展示-》

可客户直接访问观看

说一下版本（zookeeper 3.4.7        kafka_2.11-0.8.2.1   logstash-2.2.2    elasticsearch-2.4.6   hadoop-2.6.4  spark-1.6.1）

       现在这样的系统由于经常出现问题，es报红，或者计算有问题等，这是由于刚开始一个人做完还没完全稳定就直接撤人了，转了几次到了我手里（因为我懂java，android但是部门基本上是以python为主）。到我手里了是个挑战也是一个机遇嘛，然后就开始了填坑之旅。。。。。。。。。。。。

        还有一点是这样不能够很好的保持数据的实时性。

 

再次说公司原技术上改进：

    简短几句心酸路程，刚开始接手什么也不懂：不懂spark hadoop 还有 scala(线上的spark统计用scala写的).

    其中遇到也解决了各种问题，就举例最主要的两个。

    1.线上的客户投诉获取不到原始日志，没那么多时间弄懂了再改进所以解决是 --》 写python脚本（到了这家公司开始用与部门统一的python）---》功能是从elasticsearch获取到某个域名原始日志然后写入本地文件（虽然不会写，但是这么多年编程scala的大概对日志的处理逻辑还是能看懂的），本地压缩，然后python调用hadoop本地命令行将日志上传到hadoop，先临时解决了问题

    2.elasticsearch报红、kafka堆积

    不知道怎样解决，只能看日志了，尝试用elasticsearch升级到了5.5.2，发现不会出现这样的问题。  但是又出现了新的问题：spark不能兼容这样的es版本，  给老大反映情况（提了 我倾向的用python脚本计算这一条路和对es降级尝试的路），听命于领导就先对原来的elasticsearch-2.4.6进行了配置改动-但是发现还是偶尔会出现es报红的情况。    只能用另一条路用python脚本代替spark，使用es自身的聚合功能进行计算，这样就解决了问题。

    总结：所以最后的解决办法是 去掉spark        先用python脚本直接聚合统计方式请求es获取结果,这样也满足线上要求，就先这样了。

 

 

logstash-forward (边缘节点日志收集，上传到有logstash的机器)       -》

kafka  强大的数据缓存组建          （由logstash收集日志到kafka）    -》

elasticsearch (分布式、可扩展、实时的搜索与数据分析引擎)  (用logstash从kafka取出数据存到es)  ->

python脚本（调用elasticsearch的resultful_api获取统计结果，同时打包原始日志到本地上传到hadoop）    -》

elasticsearch （进行计算结果数据存储），hadoop（原始日志打包存储） -》

nginx  + django服务  进行反向代理、负载均衡、地址隐藏            django进行界面展示-》

客户直接访问观看

说一下版本（zookeeper 3.4.7        kafka_2.11-0.8.2.1   logstash-2.2.2    elasticsearch-5.5.2      hadoop-2.6.4   python以及python elasticsearch库）

 

最后再说一种现在的架构：

    公司在我刚开始接手的同时已经公司招聘了一个大数据人员（但不是本部门的），本部门也要有新项目有更大的数据量要计算需要跟他对接，但是等了好几个月仍然没有啥成果，老大忍不住了让我去看看他的大数据代码、提改进建议催进度（他主要用spark最终结果存到hbase，java写的代码），然后发现代码写的比较烂（因为java基本的静态变量 方法封装 继承多态等一看就是新手），业务逻辑也有点问题-跟老大反映，但是不同部门管不着也不能说啊，细节不说了，最终又开始了新架构的尝试之旅。

 

1.filbeat 边缘节点日志收集，上传到有logstash的机器（或者可以用flume)    -》

2.kafka  强大的数据缓存组建          （由logstash收集日志到kafka）    -》

3.spark（大规模数据计算引擎，从kafka取出日志，通过scala编写的spark代码把计算结果存入es）    -》

4.elasticsearch （进行计算结果数据存储） -》 

5.nginx + django   界面展示或接口让客户获取服务

 

同时并行的原始日志打包   （刚开始日志打包考虑到了用spark或者flume直接上传到hadoop，但是后来发现现有机器这样的速度赶不上实际需要，）

3.flume(自定义sink插件，filter插件 从kafka的另一个topic中获取日志数据，把日志按域名，按小时打包到本地）     -》

4.python 调用hadoop命令行上传本地打包好的日志到hadoop ->

5.nginx + django   界面展示或接口让客户获取服务

 

版本信息

apache-flume-1.6.0-bin  hadoop-2.6.4   kafka_2.11-1.0.0  spark-1.6.1-bin-hadoop2.6
elasticsearch-5.5.2     hbase         jdk1.8.0_144  logstash-6.1.1    zookeeper-3.4.5

jdk1.7.0_45(刚开始hadoop使用 后来spark要求更高就用了1.8版本） 

 

当然每个阶段都需要增加监控，这里用的是zabbix监控配合脚本监控