导读:58离线计算平台基于 Hadoop 生态体系打造,单集群4000+台服务器,数百 PB 存储,日40万计算任务,面临挑战极大。58大数据平台的定位主要是服务数据业务开发人员,提高数据开发效率,提供便捷的开发分析流程,有效支持数据仓库及数据应用建设。通常大数据平台通用基础能力包括:数据存储、实时计算、离线计算、数据查询分析,本次分享将聚焦大数据平台离线计算和大家一起系统的探讨58在离线计算平台建设实践的思路、方案和问题解决之道。
本文主要内容包括:
数据平台部是负责58统一大数据基础平台能力建设。平台负责的工作主要包括以下几部分:
我们综合以上技术框架支撑了公司上层的业务:如商业、房产、招聘等核心业务。 此外,整个数据平台部打造了统一的运营管理平台,各个用户在整个数据平台上 ( 包括离线平台、实时平台等 ) 使用的是同一套主账号在管理平台上做数据方面的管理,包括:元数据管理、成本预算、数据自助治理、以及运营监控的一些细节。
在上图的右半部分我们简单的介绍了几个数据平台的指标。Flume 每天的日志采集量 240T,Haddop 单集群服务器台数4000+,Flink 每天进行超过6000亿次的计算,Druid 已经构建超过 600 亿条实时数据索引。
我们的 Hadoop 集群从17年的1600台->18年的2800台->19年的4000台。可以看到集群的增长速度还是非常迅速的。在整个集群中:HDFS 存储数据150P+,YARN 每天调度超过8000万的 Container, MR/Spark 每日计算任务总数40万+、中间处理数据量超过 14P。在此基础上集群规模也在不断增长,集群稳定性能和效率对我们来说是一个比较大的挑战。下面我将给大家介绍在上述背景下,我们关于 Hadoop 平台建设以及优化的具体实践。
我们将从以下几个方面来做介绍:
首先,对于大规模 HDFS 集群可扩展性这一块,我们采用的解决方案是 HDFS Fedoration。HDFS 最大的痛点的话是 NameNode 单点瓶颈的问题,这其中包括内存的问题以及小文件的问题。通过 Fedoration 使用多个 NN 来缓解元数据内存的压力以及均衡元数据访问的 RPC。
其次,通过 ViewFileSystem 对业务做统一。ViewFileSystem 有一个好处是它在客户端实现,这样它的稳定性和性能就有保证。当然,社区原生版本有一些缺点,就是不支持跨 mount 点 mv,这一点我们对它做了修复。另外,它的维护成本比较高,在58我们是通过控制用户规模来保证低维护的成本,具体如下:通过58数据平台运营管理一套主账号体系,我们给每个业务一个大的根目录,在第一层子目录下只分配四个目录,通过这种方式来管控目录的数量来保证低成本维护,同时这样做在发生业务变更时影响也非常小。
虽然有 Fedoration 机制来均衡各个 NN 的压力,但是对于单个 NN 压力仍然非常大,各种问题时刻在挑战 HDFS 稳定性,比如:NN RPC 爆炸,我们线上最大的 NS 有15亿的 RPC 调用,4000+ 并发连接请求,如此高的连接请求对业务稳定影响很大。针对这个问题,我们使用"拆解+优化"的两种手段相结合的方式来改进。拆解就是说我们把一些大的访问,能不能拆解到不同的集群上,或者我们能不能做些控制,具体案例如下:
经过这种拆解就可以降低单个 NS 的压力。
对于 RPC 的性能瓶颈还有很多,本文主要介绍以下几种典型案例:
核心链路优化:我们对线上出现的一些问题对核心链路做的优化,主要思想是提高并行度,比如:
对于 NS 间负载均衡,提供了 FastCopy 工具来做数据的拷贝,因为 Fedoration 已经做到了很好的数据本地化,没有必要去做跨集群拷贝,通过 FastCopy HardLink 的机制可以直接将 block 指向到目标 block。当然这种方案在做 NS 之间元数据拷贝的时候,还是有一些迁移的成本,这时候就需要业务来做一些配合。
在 GC 这块,NN 线上最大堆内存达到了 230G,GC 调优我们使用的 CMS GC,这是一个比较成熟的调优方式。主要通过下述手段:
慢节点问题是我们遇到典型问题之一,主要有三个场景:
慢节点问题一:DN IO Util 100%
我们线上集群在业务快速扩增的过程中,曾经出现过大量 DN IO Util 100%的现象,而且 DN IO Util 100%的持续时间很有可能会超过二十分钟甚至半个小时,这会导致业务读取数据非常缓慢,甚至超时、失败。对我们核心业务的影响是非常大的,比如对于某个有很多业务依赖的上游业务,如果这个上游业务的延时比较长,那么所有的下游业务的延时将会不可控。针对这个问题,我们分析主要是由以下三个操作会导致这个问题的出现并做了改进,改进整体效果良好,改进后计算任务的执行时间提速了 25%。
慢节点问题二:读数据
慢节点问题三:写 pipeline 无限重试
客户端写一个块的操作会在三个节点上都一个块,我们线上遇到的一个比较严重的问题:在写的过程中如果一个节点出现故障,会去不断的重试将集群中所有的几点重试一遍然后失败,这种情况社区也有对应 issue ( HDFS-9178 ),原因是在做 DN 的 pipeline 恢复的时候把异常的节点当成了正常的节点来做 pipeline 恢复的对象。
Yarn 调度的优化主要是两个方面:一个是稳定性,另一个效率方面。
稳定性:
① 服务稳定性:
服务稳定性主要针对于系统的核心模块,下面介绍下线上易出现的核心问题:
② 计算稳定性:
③ 过载保护:
YARN 调度吞吐保证:
持锁时间优化:
通过 Profiling 发现调度进程在排序操作的过程种需要消耗90%的 CPU 时间,而且在做排序的时候基本上只是读的操作,没有必要去拿锁。另外调度的三个线程没有必要都用排他锁,我们可以做一个锁降解,对于更新线程 updateThread 用读锁就可以了,另外我们需要做一个加锁顺序的保证来避免死锁的情况。
核心计算逻辑 Profiling:
核心逻辑 Profiling 的几种思路:
整体优化完成以后调度系统提高到 3000 container/s,基本上满足了我们的需求。
接下来我们来介绍下关于计算引擎方面的优化,主要是下面几个方面:
云窗 Hive –> SparkSql:
云窗是 58 使用非常广泛的 Sql 查询平台,主要用在即席查询场景。之前一直存在一个痛点问题:查询引擎只有 Hive,因此查询效率很受局限。17年底的时候我们开始将查询引擎由 Hive 转向 SparkSql,在做即席查询引擎转换升级的时候我们做了一些调研,对比了 Impala,Presto 等等,结合 58 现状我们最终使用 SparkSql 来替换了 Hive。 当时 Spark 最新版本为 Spark 2.2,基于稳定性考虑没有激进的选择使用最新的版本而是选择了比较稳定的版本 Spark 2.1.2。另外支持 SparkSql 引擎,也对 SparkThriftServer、Zeppelin 等解决方案做了调研,综合以下几个方面我们选择了 SparkThriftServer:
一是由于云窗 Hive 主要是和前端 JDBC 的使用方式,这时候用 SparkThriftServer 改造起来就非常简单; 二是需要在应用性上做些保证,比如业务可以实时查询执行进度,可以组取消等相关操作; 三是云窗 Hive 是提供给多个用户使用需要,所以需要支持多租户。
SparkThriftServer 多租户:
多租户的问题主要在权限这一块,需要把各个业务的权限打通,这样各个业务在做查询的时候做到安全隔离;此外在计算方面,由于 SparkThriftServer 业务使用公共资源,也需要把重点业务的资源做隔离。
SparkSql 兼容 Hive 的实现:
我们需要保证云窗 Hive 用户的查询和 SparkSql 的查询做到一致性。主要用到下面四个问题:UDF 支持问题,语法兼容性问题,数据质量问题,参数兼容问题。这块的解决方案比较简单,当时是把云窗 Hive 的所有语句迁移到 SparkSql 来做测试,根据测试的结果来修复相关的问题,最后修复了50+个 issue 把成功率提高到95%以上。
SparkThriftServer 平台稳定性建设:
SparkThriftServer 平台稳定性建设也做了比较多的工作,重点说以下几点:
SparkSql 上线运行后发现的一些问题:
比如在云窗上 Hive 和 Spark 默认情况下使用了同样的配置,在云窗上用户不会关心使用的是 Hive 还是 SparkSql,这样存在一个问题就是很难对业务做一个针对性的调优,这里我们做了一些优化,优化过程中主要参考了 Intel SparkAE 的一些特性。
对于大规模的集群,运营能力还是很重要的,否则集群开发人员会花费大量时间来做运维。运营主要在存储和计算。
海量存储一站式运营管理:
存储运营有很多要做,比如目录配额管控,权限控制,告警机制,成本的优化等。我们主要是通过 FSImage + EditLog 的方式拿到需要分析的数据存储信息,集群运营者分析获取到的信息然后做相应的存储优化策略。使用 FSImage + EditLog 一个好处就是对 NN 无影响。我们集群运营每天可以对4000万+目录做冷热、增长等方面的分析;运营用户可以根据数据目录的冷热情况自定义生命周期等策略来管理数据目录,通过目录增长信息用户可以知道数据的增长情况是否正常。我们也提供了自动化目录压缩的接入,业务想做数据治理的化可以一键接入;自动化压缩有以下几个特点:冷数据使用 GZIP 压缩,热数据使用 LZO 压缩;提供数据完整性校验机制。数据压缩带来效果还是比较明显的,以19年实践为例:通过压缩数据累计节省了 100P+ 空间,相当于千台服务器的节省。
海量计算自主运营分析:
海量计算自助运营分析平台可以避免很多重复工作,减少资源的浪费,提高业务开发以及集群运维开发的工作效率。
我们是基于 LinkedIn 开源的大象医生 Dr-elephant 做的扩展改进,在改进过程中主要解决几个问题:
下图是我们运营管理的界面,其中左半部分是存储方面,右半部分是计算方面的。
跨机房迁移
下面给大家介绍下数据平台部在19年下半年做的跨机房迁移这方面的事情。
迁移背景:
方案预研以及选型结果:
常用方案——多集群多机房
58方案——HDFS 单集群多机房
跨机房网络
下面介绍迁移具体方案和实践:
1. 单集群跨机房 HDFS 数据迁移
数据从老机房迁移到新机房主要用到了 HDFS 的 Decommision 特性。这里我们针对 decommision 存在的一些问题做了一些改进,改进后性能提升超过6倍,具体问题与方案如下:
不可指定机房:decommision 的数据目标节点是不确定的,如果直接使用 decommision 会产生较多的数据冗余,所以我们在数据路由上做了改进,让 decommision 可以支持指定机房,这样下线的时候就可以将数据直接 decommision 到新机房。
性能:decommision 本身性能较差吞吐量小且对 NameNode 的压力较大,在这里做了如下的改进:
稳定性:decommision 存在一些稳定性问题,比如:不能正常结束,这里我们参考社区 issue(HDFS-11847),做了 decommision 的监控工具,分析 decommision 不能结束的具体原因然后做针对性的处理。另外在 decommision 的执行过程中可能会出现块丢失问题,线上曾经出现丢失几百万个块,还好后来数据做了及时修复,此处参考 HDFS-11609。
此外,我们是在低峰期执行 decommision 以降低影响。为保证服务稳定下线速率保持在每天下线50台,基本在5个月的时间内完成集群迁移。
2. 网络
在实践过程中,我们发现网络急剧增长,最大到 1.8T 接近上限,非常危险了,针对这个问题我们做了如下分析。
在网络降低带宽方面的优化策略:
3. 新机房磁盘倾斜
在迁移过程中,遇到第二个比较大问题: 新机房磁盘倾斜比较严重,大量机器存储超过了95%,此时节点出现 unhealthy 情况。由于机器在计算方面做了标签隔离,如果存储占满对重要业务运行稳定性影响非常大,需要有一个快速均衡方案来均衡高负载节点。这里我们使用 HDFS Balance 作为一个解决方案,同时优化了 HDFS Balance 的几个痛点问题:
通过以上方案,日支持 PB 级数据 balance,线上975台90%水位 DN5 个工作日完成均衡。
4. 计算迁移
计算服务更像是一个无状态的服务,也不需要做单集群跨机房,做起来就比较轻松。只需要在新机房部署一个新的 YARN 集群就可以,也可以保证计算任务不会跨机房。在整个迁移过程以队列为粒度,根据队列映射机房,在迁移初期给任务更富裕的资源以保证任务运行更加稳定。迁移期间会做一些灰度检验,此时需要业务配合,同时也会对迁移前后任务的运行情况做分析对比以确保迁移不影响业务的正确性。
整个迁移过程如上图所示,期间由业务与平台相互协作。业务主要评估迁移前后的差异,包括性能、成功率等。其他任务都是由平台来做,分为离线、实时、Hbase 等部分,其中离线部分流程为:
新机房资源准备,业务梳理 -> 测试新机房性能 –> 业务一队列粒度切换新机房 ->回收老机房资源 -> 搬迁至新机房扩容
实时任务迁移参考离线部分,大同小异;Hbase 集群迁移请参考另一篇关于58 大数据平台分享第三期:Hbase 专场。
整体迁移过程:先迁移计算和存储再迁移 HDFS 等核心服务,核心服务通过域名化变更来迁移,这里在源生 Hadoop 做了改进增加了对异常捕获的处理。
后续规划主要对两个方面,一个 Hadoop3.X,一个是云融合。
① Hadoop3.X
Hadoop 现在版本是在 CDH-Hadoop 2.6 做的定制,后续计算对 Hadoop 升级到 3.X。主要对 Hadoop3.X 两个特性比较看好:
② 云融合探索
目前公司私有云主要支持在线的业务,大数据平台主要支持离线的业务。在线业务一般晚上资源比较空闲,离线业务晚上资源比较繁忙,因此考虑是否可以错峰相互借用资源以降低成本。
1. 批流统一怎么做?
答:目前在58 已经在将 Storm 迁移到了 Flink,这个具体方案的文章已经发布在 58 技术公众号上,感兴趣的同学可以去公众号查看。另外 Spark Streaming 我们也建议业务可以迁移到 Flink 上,根据部分迁移业务来看,资源的使用有比较大的提升,而且在流方面整理来看 Flink 比 SparkStreaming 更有优势,无论是功能方面还是架构方面,这些都有大量的文章介绍。
我们已经基于 Flink 开发了一栈式实时开发平台 Wstream,支持使用 Sql 开发实时程序,支持 DDL、Join,关于这些会在58大数据平台分享第二期做具体介绍。
2. OLAP 选型怎么做?
答:在58 OLAP 场景目前是使用 Kylin 来支持离线的业务,比如 BI 报表,Kylin 的话建议维度不要超过50维度,超过维度支持的会不友好;另外 Druid 来支持实时的场景,比如广告效果的评估,用户行为分析等。
Kylin 和 Druid 都是预计算的思想,因此查询场景比较受限,而且对其他组件依赖较重导致维护成本较高,目前业界也有一些新的优秀解决方案,比如 ClickHouse 这些没有对其他组件的依赖相对来说比较轻量。这些组件性能上基本上都是采用列式存储的思想,提高硬件使用效率等。
Kylin、Druid 目前从使用上来看是比较成熟的 ( 包括对 Sql 语法的支持等 ),58数据平台目前也在做 OLAP 相关的调研,争取尽早落地,届时再与大家分享。
本次的分享就到这里,谢谢大家。
作者介绍:
余意,58同城高级架构师。
58同城数据平台部负责人,负责公司统一大数据基础服务能力的建设,包括海量数据收集,离线计算,实时计算,OLAP,Hbase平台等,支持58各大业务线高效稳定数据平台服务能力需求。
领取专属 10元无门槛券
私享最新 技术干货