58同城离线计算平台设计与实践.docx

? ? 58同城离线计算平台设计与实践 ? ? 编者荐语： 58离线计算平台基于 Hadoop 生态体系打造，单集群4000+台服务器，数百 PB 存储，日40万计算任务，面临挑战极大。本次分享将聚焦大数据平台离线计算和大家一起系统的探讨58在离线计算平台建设实践的思路、方案和问题解决之道。 分享嘉宾：余意 58同城?高级架构师 编辑整理：史士博 内容来源：58大数据系列直播 出品平台：DataFun 导读：58离线计算平台基于 Hadoop 生态体系打造，单集群4000+台服务器，数百 PB 存储，日40万计算任务，面临挑战极大。58大数据平台的定位主要是服务数据业务开发人员，提高数据开发效率，提供便捷的开发分析流程，有效支持数据仓库及数据应用建设。通常大数据平台通用基础能力包括：数据存储、实时计算、离线计算、数据查询分析，本次分享将聚焦大数据平台离线计算和大家一起系统的探讨58在离线计算平台建设实践的思路、方案和问题解决之道。 本文主要内容包括： 58在集群快速增长的过程中遇到的问题以及解决之道； 58大数据集群跨机房迁移的相关工作，如何在5个月时间快速完成3000台集群服务的迁移工作。 ▌数据平台部简介 数据平台部是负责58统一大数据基础平台能力建设。平台负责的工作主要包括以下几部分： 数据接入：文本的收集，我们采用 flume 接入，然后用 kafka 做消息缓冲，我们基于 kafka client 打造了一个实时分发平台，可以很方便的把 kafka 的中间数据打到后端的各种存储系统上。 离线计算：我们主要基于 Hadoop 生态的框架做了二次定制开发。包括 HDFS、YARN、MR、SPARK。 实时计算：目前主要是基于 Flink 打造了一个一栈式的流式计算开发平台 Wstream。 多维分析：我们主要提供两组多维分析的解决方案。离线的使用 Kylin，实时的使用 Druid。 数据库：在数据库的这个场景，我们主要还是基于 HBase 的这个技术体系来打造了出来，除了 HBase 提供海量的 K-V 存储意外，我们也基于 HBase 之上提供 OpenTSDB 的时序存储、JanusGraph 图存储。 我们综合以上技术框架支撑了公司上层的业务：如商业、房产、招聘等核心业务。?此外，整个数据平台部打造了统一的运营管理平台，各个用户在整个数据平台上 ( 包括离线平台、实时平台等 ) 使用的是同一套主账号在管理平台上做数据方面的管理，包括：元数据管理、成本预算、数据自助治理、以及运营监控的一些细节。 在上图的右半部分我们简单的介绍了几个数据平台的指标。Flume 每天的日志采集量 240T，Haddop 单集群服务器台数4000+，Flink 每天进行超过6000亿次的计算，Druid 已经构建超过 600?亿条实时数据索引。 ▌Hadoop 平台建设优化 我们的 Hadoop 集群从17年的1600台-18年的2800台-19年的4000台。可以看到集群的增长速度还是非常迅速的。在整个集群中：HDFS 存储数据150P+，YARN 每天调度超过8000万的 Container， MR/Spark 每日计算任务总数40万+、中间处理数据量超过 14P。在此基础上集群规模也在不断增长，集群稳定性能和效率对我们来说是一个比较大的挑战。下面我将给大家介绍在上述背景下，我们关于 Hadoop 平台建设以及优化的具体实践。 我们将从以下几个方面来做介绍： 1.?规模扩展 首先，对于大规模 HDFS 集群可扩展性这一块，我们采用的解决方案是 HDFS Fedoration。HDFS 最大的痛点的话是 NameNode 单点瓶颈的问题，这其中包括内存的问题以及小文件的问题。通过 Fedoration 使用多个 NN 来缓解元数据内存的压力以及均衡元数据访问的 RPC。 其次，通过 ViewFileSystem 对业务做统一。ViewFileSystem 有一个好处是它在客户端实现，这样它的稳定性和性能就有保证。当然，社区原生版本有一些缺点，就是不支持跨 mount 点 mv，这一点我们对它做了修复。另外，它的维护成本比较高，在58我们是通过控制用户规模来保证低维护的成本，具体如下：通过58数据平台运营管理一套主账号体系，我们给每个业务一个大的根目录，在第一层子目录下只分配四个目录，通过这种方式来管控目录的数量来保证低成本维护，同时这样做在发生业务变更时影响也非常小。 2.?稳定性杀手 虽然有 Fedoration 机制来均衡各个 NN 的压力，但是对于单个 NN 压力仍然非常大，各种问题时刻在挑战 HDFS 稳定性，比如：NN RPC 爆炸，我们线上最大的 NS 有15亿的 RPC 调用，4000+?并发连接请求，如此高的连