2018-10-28 架构 Spark Yarn

大数据架构背景介绍

架构

先来介绍下我了解到的公司spark相关的架构吧.后面的很多内容都是这些基础上的, 大部分只是业余时间的了解, 不够深入.

整套系统是基于Apache的发行版搭建的, 没有用CDH HDP MapR这些发行版,至于为啥这样选择, 为了更可控和灵活性吧, 毕竟CDH比较保守, HDP比较激进, Apache版本的缺点就是部署的时候麻烦点, 运维工具少一点, 团队的负责人毕竟是hadoop社区的committer, 加上巅峰时期整个团队有20多个人, 这些问题都不是大问题, 有两次还趁着迁移的机会顺便将版本升了. 事实上, 我们实际用到的也就是Hadoop HBase Hive Kafka Spark Livy这几种, 比如开发平台Hue 调度oozie 这类跟具体业务和公司基础架构比较相关, 复杂度又不高的系统, 本身还是需要结合公司的业务和基础架构来开发的,使用开源二次开发还是从头开发的成本还是需要权衡的.

关于使用哪个发行版本这类没有对错的问题就到此为止吧, 下面转入正题, 先介绍离线计算的整体架构

用户行为日志通过全站的nginx proxy打下来并收集到kafka, 大数据平台将kafka的日志通过基于HiveKa 改造的的交换工具,将日志数据定时交换到hive上.其他存储的数据, 比如分库分表后的mysql, hbase的数据是通过另一套基于Sqoop和Gobblin开发的统一数据交换工具HData dump一份数据到hive.

到现在应该可以看出来了,我司的离线数据仓库都是基于hive的,所有数据都交换成hive表, 底层存储使用HDFS, 再基于此之上提供统一的计算服务. 当然业务早期还有基于Mysql单库做OLAP, 去年还有幸接触过, 当时是因为数据量太大了, 撑爆了单机的硬盘, DBA需要删除旧数据, 但是删不动了, 必须要停止读写服务花费数小时来删除, 从这里看出在一定的量级下, Mysql做OLAP业务还是很容易限制于单机容量的.数据以Hive的规范存储在hdfs之上, 在这上面的离线计算框架有Hive TEZ、 Presto、 SparkSQL、SparkSession、 SparkJar. 对于内部的业务方(数据仓库工程师 算法工程师 数据分析师)提供的统一门面就是上文提到的类似HUE的开发平台.当然对于其他系统, 也可以基于开发平台提供的接口进行二次开发. 目前绝大部分数量的离线任务还是基于hive的,老大哥的位置暂时无法撼动, 今年spark运维小组将少数的大hive任务迁移到spark sql上, 在大sql的场景下据说性能提升了一倍. 新增的业务可以看业务选择逐步基于Spark Sql开发. 这里顺便提一下, presto在实际的使用体验来说, 基本满足OLAP的功能了,唯一体验不太好的地方就是需要严格得区分数据类型, 基础的udf基本和hive是不兼容, 还有一个硬伤是受限于内存大小, 大数据量下基本不能跑, 不过一般分析场景, 分析的数据量也不会有多大, 要的就是可以和mysql媲美的查询速度.

你可能好奇为啥spark为啥提供了这么多种选择， 这三种其实对应了spark bin下面的spark-sql、spark-shell、 spark-submit, SparkSQL只能写sql, SparkSession预先创建好了一些变量, 方便调用,用于在某些sql很难表达或者完全无法表达的场景,比如需要基于上一步的结果做下逻辑判断. SparkJar适合大部分业务逻辑都无法用sql表达的, 或者对特定业务进行抽象的程序.

这么多类型的任务, 该如何调度起来呢? 这类任务的调度背后是自研的作业调度系统实现的, 介绍可以看下之前的维护者对外进行的分享蘑菇街作业调度系统Jarvis的架构与实现.

作业调度系统主要管理的是任务的依赖关系和调度, 没有涉及到计算资源的调度,计算资源的调度还是用hadoop自带的yarn来进行的,目前spark hive tez的调度都是基于yarn统一进行调度, presto跟DataNode进行同机部署的, 但是和yarn的资源怎么隔离呢? 这点我还是要问下相关负责人之后再来补充吧. 早期的spark主要用于机器学习,对cpu要求比较高, 需要单独的计算资源, 所以Spark集群是通过不同的yarn集群来隔离的, 由于大部分源数据还是存放在hive集群的,所以这个集群的磁盘会比较充足, 运维做的一个操作是将一些冷数据迁移到这个集群进行存放.避免存储的浪费, hive通过修改元数据的hdfs路径即可, 查询的时候会自动重定向到这个集群.

Spark任务提交是使用Livy实现的,通过作业调度系统将不同版本的任务路由到不同的Livy服务器. 任务健康度分析是基于Dr. Elephant

Hive的底层格式默认都是orc, 关于这方面的选择是平台负责人综合考虑决定的, 这里有篇文章是说明怎么选择的 RC ORC Parquet 格式比较和性能测试

Hbase的话, 我了解的情况是支持多种部署方式来供业务来选择, 如果是业务上大部分是批处理任务的, 比如用hbase来进行数据的merge, 这样的话是和hive共享hdfs存储的, 如果是面向一些在线业务, 比如对象存储, 是使用单独的在线集群的. 如果有业务需要, 是支持部署一套独立集群的.

整个大数据集群的机器监控除了公司运维层面的统一监控之外, 还有一套基于Ganglia的监控, 主要是因为前期公司自研的监控还不够成熟好用.

版本

2018年10月28日

All content is licensed under CC BY-NC-SA

Buit with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents