mmtrix大数据分析平台构建实录.pdfVIP

mmTrix 大数据分析平台构建实录 本文详细介绍了 mmTrix 大数据分析平台的基本架构构建过程 ，基于 Hadoop的大数据分析平台逐步实现 mmTrix APM后端数据的存储、分析、挖掘 ，同时随着业务的更迭也加速驱动数据的平台化. 在数据分析中 ，有超过 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在SIGMOD2015 上发布的论文来看 ，Heron可以说有非常不错的提升 ，Twitter也表示在将来会 开源。而阿里的JStorm在 2015年 10 月份也加入了 Storm的豪华午餐 ，应该 会出现在下个大版本里。我们部署了JStorm2.1.0进行了测试 ，发现 JStorm表 现出非常不错的性能 ，仅从监控 UI 就能看出阿里对于JStorm的诚意 ，但最重 要的是 JStorm解决了 Storm的几个问题 ，如过度依赖 Zookeeper （频繁交互 Zookeeper ）、HA、多集群监控、资源硬隔离等。 而SparkStreaming则是目前我们正在过渡到的一个实时计算框架 ，Spark Streaming与 Storm在处理数据的本质上有着很大的不同 ，Storm是逐个处理 tuple ，而 Spark Streaming则可看成细粒度批处理 （micro batch ）的 spark 任务 ，但这也决定了其高吞吐量和较高的延迟。一般认为 Storm的处理瓶颈是 单条流水线 20000Tuple ／s （每个 tuple大小为 1KB ），但在一些大数据量且 延迟要求不高的场景下 ，其实 Spark Streaming可