当前位置: > >10亿笔Log分析靠SDACK架构,趋势3度翻转资安大数据平台架构

10亿笔Log分析靠SDACK架构,趋势3度翻转资安大数据平台架构

03-12,IT资讯10亿笔Log分析靠SDACK架构,趋势3度翻转资安大数据平台架构最新消息报导,口袋科技网(http://www.juren5.com)IT资讯
图片来源: 

趋势科技

在2008年时,趋势科技就已经开始拥抱大数据平台Hadoop,利用它检查数十亿个网站,检查其中是否有可疑的恶意程式,他们也发展出自家的Hadoop版本TMH(Trend Micro Hadoop)。但是到了2015年,日益猖狂的APT攻击,并没有固定的判断特徵,趋势得要从系统每日收集的Log资料中,寻找是否有被渗透的蹤迹。

但若继续使用Hadoop,储存分析过程中暴增的的资料量,得让趋势付出许多硬体投资成本。单凭人力,更不可能解读每天数十亿的日誌事件,势必要透过新的大数据平台,探寻其中的线索。

设计大数据平台时碰上的4V挑战

不过,负责设计这个资安大数据平台时,趋势科技资深工程师陈煜伦第一个挑战,就是大数据界俗称4V的考验:多样性(Variety)、资料量(Volume)、资料流(Velocity),以及真实性(Veracity)。

他解释,此平台所要分析的Log数据多样性繁杂,企业内部每个员工的一举一动,都会在AD伺服器、Proxy代理伺服器中留下Log纪录。

第2个挑战则是庞大的资料量,陈煜伦举例,每日光是单一类型Log资料,就会产生超过10亿笔的纪录。

再者,因应即时串流分析需求,平台必须具备快速分析、整理资料的能力,否则只会留下堆积如山的未处理数据。最后,资料在流动的过程中,难免因网路传输等因素而产生毁损。为了不让这些异常数据造成分析準确率降低,必须筛选、过滤出具代表性的资料。

大数据平台得能水平扩充和即时分析

而陈煜伦所设计的平台,并非一次到位,而是历经3次架构翻新,才找出目前最合适的SDACK架构。他表示,此大数据平台除了要具备弹性水平扩充、即时串流分析能力,也要能处理大量Log资料。

第1个版本的大数据平台,主要由Kafka、Flume以及Spark三大核心元件所组成,利用Kafka及Flume进行资料前置处理,最后则是透过Spark进行资料处理与分析。

陈煜伦解释,当资料流进入平台时,第一关会通过Kafka,利用它储存Log资料,作为缓冲层。他表示,Kafka是一个分散式资料串流平台,除具备执行即时运算、处理高吞吐量资料的能力,也能根据线上环境需求,水平扩充新的Kafka丛集。此外,Kafka也有提供副本複製(Replica)的功能,增进系统可用性。

下一步,资料则经由Kafka,传送至Flume,进行ETL处理(Extract-Transform-Load,萃取、转换及载入)。透过Flume,开发者可以自行设计、实作Log资料的逻辑。而它也提供相容于Kafka的资料传输介面,「可以很轻易地从Kafka捞取资料」,在完成资料萃取的处理程序后,Flume则再将资料流导入Kafka,「让后续分析不需要进行前置处理,藉此增进演算法运算效率。」

而核心演算法则是布建在Spark平台,「除了具备水平扩充能力,最重要的是,它能同步支援即时串流分析及批次处理。」

另外,Spark也具备方便资料科学家使用的工具,例如,开发者可使用机器学习模组MLib,将演算法实作于Spark之上。而图像API模组GraphX可用于分析相异类型Log资料间的关係,让资料科学家判读各数据的相关性。

最后,系统产生的分析报告,除了储存在PostgreSQL资料库中,陈煜伦也透过Node.js搭建的网站入口,提供用户查询服务。

趋势科技资深软体工程师陈煜伦表示,建构大数据平台并没有标準答案,「重要的是了解问题的本质,在使用过程中,慢慢地进行调整。」。

系统得随需求不停改变

第1版的架构设计看似足以应付用户的需要,「但是需求是不断改变,必须持续增加新功能」,像是前端接收资料的Kafka平台,它并没有相容常见的Log资料传输协定,例如TCP、Syslog等,必须额外在客户端也架设Kafka才能传送资料,「这样是多此一举。」

再者,平台除了即时串流的能力,也不可忽略批次处理程序的重要性。陈煜伦表示,要透过统计分析、机器学习,产出有价值的统计、分析模型,「必须累积一段时间的Log资料,而非不停一直进行即时分析。」而趋势科技内部的资料科学家也提出需求,想利用Spark执行更多的批次处理工作。最后,Log资料肇因网路传输,使传送过程延迟,导致资料完整性不足,「得要确保演算法不因此而準确率降低。」

靠Fluentd解决资料传输介面问题

第2版本的架构中,陈煜伦则导入双资料流架构,支援即时及批次处理工作,并引进开源Log收集器Fluentd及Redis。他表示,别于Kafka,Fluentd则提供更多资料传输介面套件,可以支援TCP、UDP及Syslog等协定。

此外,Fluentd也可以作为资料传输的缓冲,等待延迟的资料都传送完毕,再一併引入下个处理流程,「确保Spark在特定时间区间内,收集资料都是完整。」

第2次翻修后的架构,「其实仍旧不足。」陈煜伦苦笑着解释,他原本盘算利用Fluentd解决资料传输延迟,但是第2版的设计仍然无法解决,「究竟缓冲时间要设定多长?」他举例,假设开发者设定缓冲时间1小时,但资料却晚了2个小时才送达,还是会造成资料完整性不足。

不仅如此,第2版架构中,他也结合了Kafka、Fluentd及Redis,想要通吃批次、即时处理,「但这违反Kafka的初衷,它的目的并不是用于处理批次工作。」

结合Kafka、Akka,取代Flume资料ETL功能

面临2度修改架构的需求,陈煜伦的朋友便建议他,不妨参考近年火红的SMACK架构(Spark、Mesos、Akka、Cassandra、Kafka)。

这次,陈煜伦结合了Akka Stream以及Kafka API模组Kafka Stream,用来取代原本Flume元件的资料ETL功能。他解释,Akka Stream与Fluentd的功能类似,利用领域特定语言(DSL)进行开发,处理资料流程也更方便。而利用Reactive Kafka,则可以方便开发者与Kafka沟通,或是捞取资料。

Akka Stream的功能还不如此,在资料传输过于火爆时,它也可做为缓冲层。他解释,当系统后端处理资料碰上瓶颈时,Akka Stream会发出请求,要求前端系统放慢传输资料的速率,「防止过度负荷,导致系统当机。」

而分散式NoSQL资料库Cassandra则可以让使用者根据需求,自订Data Schema架构。陈煜伦表示,Cassandra不仅和Spark整合完全,它也会储存完整的Log纪录,「可以存取任意时间点的资料,就可以解决资料传输延迟的问题。」

用Docker快速部署大数据平台

原本在SMACK架构设计中,使用了Mesos来管理丛集。不过,陈煜伦表示,由于趋势的大数据平台得部署于企业客户端的环境,要他们建立一套庞大的运算丛集并非易事。因此他就利用Docker取代Mesos,一举再把SMACK翻转为SDACK架构,可以更容易在开发环境、客户端部署大数据平台。

在SDACK架构中,所有的元件都具备水平扩充的特性,当某功能的需求突然增加,可以透过Docker Container打包,建立新运算丛集,应付新增的工作流量。

另外,陈煜伦也把相关Docker映像档都上传至Docker Hub,方便企业用户可以直接下载,就地完成部署工作。同时,Docker Compose也利用Yaml文档,定义应用程式运行需要的元件,「企业用户可以很快速的建立系统。」

在3度翻新系统架构后,陈煜伦表示,建构大数据平台并没有标準答案,「重要的是了解问题的本质,在使用过程中,慢慢地进行调整。」他认为,开发者不应屈就于时间压力,而胡乱拼凑出解决方案,「这些都将成为技术债,未来要花更多时间解决。」

声明:

·凡注明为其他媒体来源的信息,均为转载自其他媒体,转载并不代表本网赞同其观点,也不代表本网对其真实性负责。如系原创文章,转载请注明出处。

·您若对该稿件内容有任何疑问或质疑,请即联系,本网将迅速给您回应并做处理。

邮箱:mail@kotoo.com

+1 已赞
已有8人赞过
评论13

发表评论请 登录
  • 最新
  • 最热
评论举报

请选择举报理由

17 13

已收藏
去我的收藏夹 >

已取消收藏
去我的收藏夹 >