|
目前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后端数据的存储、分析、挖掘，同时随着业务的更迭也加速驱动数据的平台化。
（编辑：大连站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
