文章目录

背景
组件
- HDFS
- - 为什么需要治理
  - 为什么难以推动
  - 需要做什么
  - 部分效果图
- SPARK & YARN
- - 为什么需要治理
  - 需要做什么
  - 部分效果图
计费
后记

背景

大数据平台早期是野蛮生长的，作业直接在终端提交运行，处于一种完全无管理的自由状态。在17年上线了内部的大数据平台后，用户开始逐渐在平台上进行数据管理，代码编写，作业管理等工作，但是资源治理依旧缺失。

随着业务及数据量的不断增加，集群扩容，存储和计算资源达到一定规模后，对大数据平台进行资源治理就非常必要了，本文是基于 HADOOP 生态的一个总结。

该项目大部分完成于18年，由于内容较多（人比较懒），几次提笔都搁置了，全文主要围绕为什么做/要做什么来展开，至于具体怎么做，方法有很多，大家就见仁见智了。

组件

HDFS

为什么需要治理

财务预算高

数据增长非常快，不干预的情况下日增能达到100T。在计算与存储没有分离的情况下，存储资源的不足就意味着需要购买新的机器，不仅成本非常高，还会造成计算资源使用率低下。
集群负载高

HDFS 虽然支持水平扩展，但是当集群到了一定规模，NameNode 就会成为瓶颈，其一为 NN 的内存瓶颈，其二为大量DN的心跳RPC请求带来的网络瓶颈，同时重启恢复时间也会变长。
运维压力大

频繁的扩容，即使有自动化工具的支持，也会给工程师带来一些低价值的工作。

为什么难以推动

在集群数据量级较小的情况下，以优先解决业务需求为主，增加机器远比开发一整套资源分析系统的成本要低。
平台需要推动业务部门删除一些”僵尸数据“，但业务部门人数较多，以开发业务为核心，删除数据在他们看来优先级非常低。

需要做什么

核心思想：控制增量，优化存量

冷数据

长期没有访问的数据，包括一些分析建模留下的中间数据，无用数据等。针对这部分数据，设计了一个资源浪费分的概念，根据数据目录大小绝对值和最后一次访问时间进行计算，该分数达到一定阈值后会对用户进行提醒，不操作则进行删除。
碎片文件

通过计算目录下每个文件的平均大小，平均大小小于某个阈值时会触发，进行合并压缩处理，可以参考 Spark 小文件合并优化实践
异常增长

数据目录增长异常，可能是业务存在较大的变动或是用户的误操作导致，这种情况需要对用户进行预警。
空间占用绝对值高

使用更高压缩率的压缩算法，例如zstd。统计出日增长绝对值最高或者月环比 / 季环比较高的 team ，发送邮件给相应 team leader，要求给出解决方案。
集群容量评估

根据集群历史数据增长情况，评估目前的容量多久后需要进行扩容。
数据生命周期

所有的数据进行表化，上大数据平台，强制填写生命周期，例如物化的临时表生命周期为7天，到期后会自动删除，不需要主动进行管理。普通的数据表/分区生命周期到之前7天给用户发邮件/钉钉，用户可以选择续期或者直接过期删除。

部分效果图

容量评估

用户资源使用趋势

用户数据日增量

SPARK & YARN

为什么需要治理

资源使用不平衡

比较常见的情况是集群中内存被申请满了，但是 CPU 还有剩余。
运行时间不稳定

同个作业多次运行时间波动幅度大。
资源滥用

每个业务方都希望自己的作业能尽可能快的完成，导致资源被滥用，带来一些不必要的资源紧张。

需要做什么

作业资源统计分析

现实的情况是大多数作业直接运行在大数据平台上，少数作业因为历史原因还在终端运行。
- 终端的作业都是独享一个 Spark Application ，从 submit 到 shutdown 有一个完整的生命周期。
- 大数据平台作业则分为独享和共享 Application 两种，独享和终端类似，共享的方式是一个作业由 Spark 的几个 job 组成。
对于独享的任务，直接计算整个 application 运行期间消耗的 mem_seconds/core_seconds ，共享的任务资源使用则是通过该任务结束时间获得的 mem_seconds/core_seconds 减去开始时间的值获得。

对于 Spark 作业，还可以通过 Listener 对 task 做进一步的分析，帮助优化应用资源使用。
集群资源统计分析

根据统计信息能获取当前 cpu/mem 使用较高的一些作业及用户，根据历史资源使用趋势可以更合理的安排作业的调度时间。
内存及 cpu 使用控制
spark on yarn cgroup 资源隔离(cpu篇)
使用 jvm-profiler 分析 spark 内存使用
作业数量/资源池限制

在平台层面对用户/应用账号不同类型作业（schedule/dev/etc.）进行提交数量限制，对不同的应用分资源池进行约束。

部分效果图

集群资源使用及作业 Top

集群当前状态

Spark任务诊断

计费

对于普通用户来说，提供诸如 core_hour / mem_gb_hour / disk_gb_day 之类的单位过于抽象，很难意识到自己真正使用了多少资源，所以根据算法直接将物理资源折算成人民币，可以具体到每个任务运行花了多少钱。

Spark 计算时会同时申请 mem 和 cpu 资源，如果一台物理机内存被申请完了，cpu 资源也是无法使用的，所以根据物理机的配置折算成计算单元更为合理 1cu = (1C,5G)，最后会根据 cu 和存储占用进行综合计费。

通过计费的方式可以对资源进行更直观的展现：

从用户的角度，可以知道自己的某个任务计算花了多少钱，某个表存储花了多少钱。
从公司的角度，能清晰的从报表上看到哪几个部门用了多少钱，哪个Team用了多少钱。
从业务的角度，根据资源的使用可以更好的评估投入产出比以及业务价值，让其更有动力去优化业务代码。

任务维度的计费

后记

18年上线后进行了四个月的跟踪观察，存量数据绝对值降低了20%，文件数量降低了 35%，增量数据增速降低了80%，集群整体的内存使用率提升了20%，同一作业的多次运行时间波动范围下降了50%。

在整个治理过程中，技术只是其中的一小部分，同时还需要从行政上进行辅助，否则效果将会大打折扣。

大数据平台资源治理经验总结相关推荐

AllData一站式大数据平台【三】
" AllData通过汇聚大数据与AI领域生态组件,提供细分领域AllData数字化解决方案:大数据平台[数据中台]集成.大数据平台[数据中台]湖仓分析.大数据平台[数据中台]开发治理.大数 ...
扫盲系列-大数据平台多租户方案设计
什么是多租户? 多租户是一种软件架构模式,通俗来讲,就是构建一套应用来服务多个用户,但又能确保一定的隔离性.区别于用户的概念,用户是资源的使用者,而租户一般对应一个组织或一类用户.通常数据权限.计算资 ...
京东EB级全域大数据平台的演进与治理历程
讲师介绍包勇军,目前在京东任职数据基础平台部.广告质量部.推荐研发部负责人,同时担任京东集团技术委员会委员.京东零售数据算法委员会会长.负责大数据平台基础架构的建设和产品开发.AI算法平台建设.AI ...
研究 | 健康大数据平台的“区块链治理”
个人健康数据,是一个私密性领域,此类数据的挖掘和应用,以前传统的计算机平台技术方式已经不足以支撑.文章着重探讨了应用区块链技术进行治理的一些方法,但是并没有过多的从区块链"去中心化" ...
信息安全-数据安全-字节大数据平台安全与权限治理实践
导读:本次分享题目为字节跳动大数据平台安全与权限治理实践,文章会围绕下面四点展开: 字节大数据安全体系现状和难点细粒度权限管控和治理资产保护能力数据删除能力分享嘉宾|许从余火山引擎数据平台 ...
提升60%基础资源利用率！中国联通的容器化大数据平台实践
中国联通数据中心总经理王志军在Rancher举办的ECIC大会上的演讲实录,分享了中国联通为何开始进行平台容器化并如何运用Kubernetes对9000台的服务器数据节点进行最大化利用和合理调度,进而 ...
解决计算治理问题，详解微众银行大数据平台中间件Linkis架构和应用
7月9日,由微众银行(WeBank)开源的一站式金融级大数据平台套件WeDataSphere(WDS),举办了第二期开发者社区的线上meetup,来自中国电信天翼云.艾佳生活.MobTech等WeDa ...
阿里十年经验输出，大数据平台“数加”的前世今生
2016 年1月20日,在云栖大会上阿里云发布了一站式大数据平台"数加",该平台集合了阿里巴巴十年的大数据能力以及上万名工程师实战检验,该平台是一站式的解决方案,首批亮相20款产品 ...
大数据平台下的数据治理
文章目录什么是数据治理难题大数据平台下的数据生命周期数据治理关键场景数据治理面临的挑战数据治理关键问题 1. 海量系统规模 2. 复杂存储 3. 复杂采集数据治理目标数据治理平台与周边 ...

大数据平台资源治理经验总结

文章目录

背景

组件

HDFS

为什么需要治理

为什么难以推动

需要做什么

部分效果图

SPARK & YARN

为什么需要治理

需要做什么

部分效果图

计费

后记

大数据平台资源治理经验总结相关推荐

最新文章

热门文章