大数据平台

选型

大数据平台选型有三种选择:

使用云平台,优点是建设周期短、运维成本低,缺点费用贵、数据安全性;

使用商业化的大数据平台,优点搭建部署方便、稳定性好,缺点是成本高、不够灵活;

自己造轮子,优点就是根据需要定制部署,缺点周期长、成本高、坑特别多。

公司高层视数据如命,使用公有云平台是不可能的,大数据团队刚建成、预算不足,只能走向自主建设这条艰辛路。经历了大数据平台从有到无,功能越来越完善,稳定性和性能逐步提升,支持的业务越来越多。体会到自主建设一个生产级别的大数据平台,要踩了很多坑。所以记录一下大数据平台的技术演进历程,一来用于总结经验,二来也给其他正准备自己建设大数据平台的同学提供参考。

总体架构

数据源,支持多种数据源,可以实现对公司的各个业务线的数据进行接入整合;

接入层,业务mysql数据库定时同步和基于canel的实时同步结合,日志数据实时接入,互联网海量数据实时爬取清洗;

存储层,hdfs分布式文件系统实现海量数据存储,hbase提供数据实时读写,kafka消息队列实现数据缓存;

计算层,离线计算引擎用于数据挖掘和机器学习模型训练,实时计算引擎实现日志的实时分析和处理,深度学习引擎用于人工智能算法的运行;

分析层,实时SQL用于探索性分析和多维分析,机器学习算法用于商机的分类和推荐,NLP分析实现自然语言处理,深度学习算法用于图片水印和违禁图片识别;

数据服务层,对外提供数据服务;

数据应用层,个性推荐为PC端和单品通app端提供推荐服务;用户画像可以抽象出标签化的用户模型是提升会员质量的基础;用户行为分析对用户访问网站的规律进行分析可用于智能推荐;统计报表对数据进行挖掘分析,提供报表作为决策的依据,实现商业智能;运营支持对运营部门的需求提供大数据支持;数据大屏方便用户直观的了解运营情况,包括实时交易图、统计大屏和基地大屏。

数据采集

需要采集的数据有三类:

业务数据,主要存储是关系型数据;

日志类,主要存储是文件;

爬虫抓取类,主要存储是文件。

业务数据Sqoop阶段

公司业务数据库使用的mysql,最初业务数据同步使用sqoop定时同步,主要问题有三个:数据同步有延时,同步后的数据有串行、对业务库压力大。所以想找到更好替代方案。

Kafka Connect阶段这个时候confluent 的kafka connect 进入我们的视野,看完官网的介绍和原理,设计理念特别好,支持各种数据源,完全满足我们的需求,经过部署测试,稳定性太差,根本无法用到生产环境。Sqoop+canal阶段最后又把目光又回到了sqoop上,利用sqoop的job实现增量同步,同时对并行度进行优化基本可以满足要求。对业务数据库压力大的问题并没有解决,考虑专门创建一个mysql备库用于我们同步数据,这时候闪现了一个想法可以考虑直接读取mysql的binlog日志进行同步,先在github上找找有没有开源的轮子,在万能的github上找到了canal。最后的方案就是通过sqoop+canal的方案,sqoop用于第一次全量同步,canal用于增量同步。日志数据

可选的方案有三个:

flume、logstash、filebeat。最后的选择的是filebeat直接接入kafka,没有使用logstash原因是对服务器压力太大,flume更侧重数据传输。

爬虫抓取类

爬虫抓取集群和大数据集群网络环境差,爬取的文件格式复杂,这种情况是flume最擅长的。

平台管理

平台建设开始就要考虑的数据资源和计算资源的管理,避免使用混乱,否则后患无穷。

数据资源管理

hdfs、hive、hbase启用安全策略,开发了专门的元数据管理平台,对数据进行管理,包括数据所属人,数据的用途。

计算资源管理

引用账号和队列,每个产品线对应一个用户组,每个用户对应一个队列,针对队列设置配额。

性能优化硬件环境

系统盘和数据盘分开。避免使用一个磁盘的两个分区作为系统盘和数据盘,这样可以避免数据盘负载太高导致系统变卡。

数据盘不需要做raid,直接使用单个磁盘。使用raid0虽然性能高,但是单个磁盘损坏会导致整个raid磁盘不能使用,使用raid5数据可靠性高,但是性能不高。更重要的是,我们数据的安全性靠的是软件保证。

每台机器的磁盘数和磁盘空间尽可能一样。

系统盘一定要是使用单独的磁盘,最少200G空间以上

使用高转速磁盘,至少1000转以上,避免磁盘成为瓶颈。

集群机器之间至少10Gigabit(万兆)以太网。

内存、CPU、磁盘、带宽和磁盘io要保持一个合理的性价比。例如正常情况下内存越大越好,但是内存大到一定阶段,cpu和带宽就会成为瓶颈,如果加大cpu和带宽,最后磁盘io就有可能是瓶颈。

操作系统

禁用swap,使用交换分区会严重影响程序的性能。现在的内存已经不是很稀缺了,而且内存和磁盘速度相差太大。

增大操作系统的最大打开文件数。

设置数据盘的noatime属性。

文件系统选择ext4

部署建议hdfs

Namenode节点不要和datanode节点部署在一起

Yarn

yarn分配的内存是机器总内存的75%,剩余的内存用于操作系统、系统缓存、程序等使用。

nm节点和datanode节点部署到同样的机器上。

RM节点选择和namenode节点部署到同一个机器。

Zookeeper

zookeeper节点选择负载比较少的机器部署,不要和nodemanager部署到同一台机器上

zookeeper节点数3个

zookeeper数据最好存储到单独的磁盘上,不要和数据盘用同一个盘

sparkkafka

kafka最好单独部署一个集群,如果机器资源不够也需要有单独的磁盘

kafka尽可能部署到负载比较小的机器上

其它优化

shuffle相关参数调优

hdfs小文件合并

任务隔离

大数据集群的规模是随着业务发展逐渐增大,导致集群机器配置不一致,主要是有一批配置低的机器最初用来跑MR任务,一批配置高的机器使用跑spark任务,最好不同的任务能提交到指定的机器运行,所以引入了对NodeManager打标签。将配置低的机器打标签为MR任务,配置高分为spark离线任务和spark Streaming任务。同时对队列也设置相应的标签。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180130G0OPLN00?refer=cp_1026

扫码关注云+社区