banner

mmTrix大数据分析平台的基本架构构建过程

作者: afenxi来源: afenxi时间:2017-06-17 12:52:290

摘要:在数据分析中,有超过90%数据都是来自于非结构化数据,其中大部分的是日志,如运维、安全审计、用户访问数据以及业务数据等,但随着互联网快速的发展,数据规模也是水涨船高,从早前的GB级到现在的TB级,甚至PB级也只是短短几年光景。而移动互联网的时代到来,可以说每个人无时无刻不在产生数据,几乎成爆发式的增长。

如此多的数据早已压榨完单机的性能,在性价比的驱使下,转向分布式也是多数互联网企业早就未雨绸缪的事。2016年恰逢Hadoop十周年,可以说Hadoop改变了企业对数据的存储、处理和分析的过程,并引燃了整个大数据生态圈,而构建企业级大数据分析平台也必不可少从它开始。

一、基石-Hadoop

Hadoop2.0之后,资源管理被剥离了出来,变成了YARN。虽然在集群规模小于200台的企业里,可能不能感受到YARN带来的过多优势,但是与MRv1相比,其已不再是单纯的计算框架(Mapreduce),而是一个框架管理器,可以部署多个计算框架(如Spark,Storm,Impala等),NoSQL存储(如HBase等)。

HDFS是Hadoop的分布式文件系统,多数的计算框架都支持直接从HDFS上读取数据,且可以无障碍的部署在低廉的服务器上,Replication机制也保证了数据容灾性。但有些场景也不适合使用,如低延迟数据访问、大量小文件存储等,但可以依赖其他框架解决,如HBase、Alluxio解决低延迟访问、FastDFS解决大量小文件存储的问题,mmTrix的真机监测就是通过FastDFS来解决存储真机客户端大量回传的几KB小文件。

二、快刀-Spark、Mapreduce、Storm、Spark Streaming

很多人觉得Spark的出现,可以完全替代Mapreduce,尽管Mapreduce很优秀,编程模型简单,但是真的太慢了(前公司的BI人员多次吐槽,敲完一条连表HiveSQL,他可以看一集火影)。Spark目前正朝着2.0大步迈进,从目前最新的1.6版本来看,上千个补丁完全可以看出Spark正如其名一般的火爆。Spark 1.6引入新的内存管理器,自动调整不同内存区域大小,根据程序运行时自动地增加或缩小相应内存区域大小,这意味着对许多应用程序来说,在无需手动调整的情况下,在进行join和aggregation等操作时,其可用的内存将大大增加。

尽管Spark如此优秀,但是在日级别、部分业务小时级的数据计算时,我们依旧选择Mapreduce,但对于分钟级的计算已经将这光荣的任务移交给Spark。

Storm作为开源实时框架的先驱,在提到实时计算的时候,会第一反应想到它,尽管twitter公司已经宣布弃用,改用Heron。从Twitter在SIGMOD 2015上发布的论文来看,Heron可以说有非常不错的提升,Twitter也表示在将来会开源。而阿里的JStorm在2015年10月份也加入了Storm的豪华午餐,应该会出现在下个大版本里。我们部署了JStorm2.1.0进行了测试,发现JStorm表现出非常不错的性能,仅从监控UI就能看出阿里对于JStorm的诚意,但最重要的是JStorm解决了Storm的几个问题,如过度依赖Zookeeper(频繁交互Zookeeper)、HA、多集群监控、资源硬隔离等。

而Spark Streaming则是目前我们正在过渡到的一个实时计算框架,Spark Streaming与Storm在处理数据的本质上有着很大的不同,Storm是逐个处理tuple,而Spark Streaming则可看成细粒度批处理(micro batch)的spark任务,但这也决定了其高吞吐量和较高的延迟。一般认为Storm的处理瓶颈是单条流水线20000Tuple/s(每个tuple大小为1KB),但在一些大数据量且延迟要求不高的场景下,其实Spark Streaming可能更适合,目前mmTrix也准备将静态CDN访问日志相关的秒级监控迁到Spark Streaming。

三、辅助-Kafka、OpenTSDB、Kylin

Kafka为LinkedIn开源的优秀分布式发布订阅消息系统,即便是廉价的服务器也能跑出单机10W/s的效率。Kafka解藕了服务的同时,对消费端消费能力不足的情况下,实现了数据缓冲,并且消费不删除和Retention机制也提高了其在实践中的高可用。即便在后端消费服务全部宕机的情况下,Kafka也能默默承载全部数据压力,并给予运维、开发人员修复的时间(取决于配置项log.retention.hours)。

由于mmTrix是主要做APM业务的,不可避免地会遇到时间序列的监控数据,如OS监控、Plugin监控、Server监控等业务。早期的做法,选择了Mongo作为存储工具,但最终我们还是选择了HBase,并配合OpenTSDB使用。OpenTSDB主要由Time Series Daemon (TSD)以及一系列的命令工具组成。每个TSD都是独立的,它们之间没有Master,没有共享状态,从而在使用的时候可以部署任意多个,且相互之间不影响。数据的存储主要依托开源的列存储数据HBase,按时间序列存储。与TSD之间的数据交互,可以通过简单的telnet-style协议,比如HTTP API或者内建的GUI。时间序列的数据是高密集的,如果设计HBase Rowkey时,只注重在时间尺度上的Scan且把全时间带入到Rowkey中,当大规模灌入数据的时候是极易引起Region热点问题的。

而OpenTSDB的Rowkey设计巧妙的规避了这个问题,采用固定长度的Rowkey,让Rowkey包含尽可能多的检索信息。同时,其使用AsyncHbase而非HBase自带的HTable,且线程安全、非阻塞、异步、多线程并发的HBase API,在高并发和高吞吐时,可以获得更好的效果。

mmTrix大数据分析平台的基本架构构建过程-数据分析网

Kylin是eBay开源给Apache的OLAP平台,并于2015年12月8日成为Apache顶级项目。对于需要长期建立的数据分析仓库,在不同的时间弹性尺度上聚合结果是比较耗时的,而用户经常要求在秒级返回结果,OLAP平台正好解决这个问题。同时,mmTrix的技术支持和OP人员也需要快速的帮助客户排查一些问题或者快速制作分析报表。Kylin目前来看使用的限制较多,对于其依赖的组件Hive、HBase、Hadoop有一定限制,而且目前使用的公司还较少(京东云海分享过使用经验),mmTrix目前也在试水。

四、大数据分析平台实践

mmTrix大数据分析平台的基本架构构建过程-数据分析网 目前mmTrix整个大数据分析平台主要抽象成5层,包括数据源层、数据集成层、数据分析层、数据分析存储层、数据服务层,组件的监控则贯穿整个平台。

数据源层

数据源目前主要分3类,新增的外部数据、已保存的外部数据、已保存的内部数据。新增的外部数据,主要是非结构化的数据,由log agent,plugin agent(Redis、MySQL、Mongo等)、OS agent等上传的数据。已保存的外部数据,主要是由其他服务、采集整合的结构化数据,辅助构建数据仓库,同时存储部分元数据。已保存的内部数据 ,主要是数据落地备份和长期增量建立的数据仓库,业务主要涵盖全站加速、图片加速、网络加速、OS监控、Plugin监控等。

数据的规模,日新增数据量约1.5TB,其中网络加速日新增约20亿条,全站加速约1200万条,OS监控日新增约110GB。

数据集成层

数据集成层则是汇聚集成数据源,供各种组件使用(例如数据获取、数据清洗入库等)。目前,有kafka2hdfs、kafka2opentsdb服务分别落地新增的数据到HDFS、OpenTSDB,以多线程模式并行处理。Collector主要设计为数据收集、数据适配、数据分发,将上传的plugin数据收集后适配成OpenTSDB所需的数据格式,然后数据分发到TSD进行数据落地。

数据分析层

数据分析层则分为实时计算、离线计算、OLAP分析三块。

实时计算目前由Storm搭建,已运行的topology主要负责全站加速、网络加速的各项统计,计算结果在开启pipeline的情况下通过Codis写入(测试对比写入单机Redis,性能损耗约10%-15%),过期时效为6分钟。一些需要原语特性的实时计算,则使用Trident API,如实时监控报警(防止失败处理导致重复发送,继而引起误报,其实有时候误报比一两次的漏报更可怕)。

离线计算目前由MapReduce和Spark计算框架负责,Job调度由基于Quartz自研的JobScheduler定时调度,主要负责全站加速、网络加速、图片加速等各项业务的统计调度。JobScheduler是一个轻量级的调度系统,对任务依赖、补跑、失败重试等都进行了较好的实现,但也存在一些问题,目前也在借鉴阿里的Zeus系统进行完善,如分布式等特性。目前离线计算任务,仅定时任务月均13W左右。

OLAP分析是基于长期建立的数据分析仓库,对每日新增数据进行预计算,更新维度索引,提供弹性的数据分析,目前只是处于试水阶段。

数据分析存储层

数据分析存储层存储数据分析结果或者中间结果,由后续数据服务提供简单聚合等计算。目前,Redis负责实时数据的结果存储(过期失效),以及调度状态、任务成功失败标记等。MySQL主要负责时效性较长、数据量不大的计算结果,目前存储全站加速、网络加速、图片加速的报表数据,会对冷热数据(根据用户的查询频率)进行分离,对历史数据存入HBase,较新的数据存入MySQL。Hive和HBase主要负责时效性长、数据量大的计算结果,比如存入各种预计算的结果、中间表、长期保存的数据,包括监控数据、报表数据等。

数据服务层

数据服务层主要负责应用层的服务请求,由go语言开发,采用微服务的架构体系,Docker部署,服务不相互依赖或简单依赖,提供各种监控数据、报表服务。由于本文只注重对于平台的构建,对服务治理、服务监控等就不做过多赘述。

总结

本文详细介绍了mmTrix大数据分析平台的基本架构构建过程,基于Hadoop的大数据分析平台逐步实现mmTrix APM后端数据的存储、分析、挖掘,同时随着业务的更迭也加速驱动数据的平台化。

本文作者来自性能魔方大数据负责人朱昱强

原创文章,作者:张乐,如若转载,请注明出处:《mmTrix大数据分析平台的基本架构构建过程》https://www.afenxi.com/post/11964

banner
看过还想看
可能还想看
热点推荐

永洪科技
致力于打造全球领先的数据技术厂商

申请试用
Copyright © 2012-2024开发者:北京永洪商智科技有限公司版本:V10.2
京ICP备12050607号-1京公网安备110110802011451号 隐私政策应用权限