【沉淀】访谈阿里孙伟光:多行善事莫问前程的他,将计算集群的CPU利用率从30%提升到70%+

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 做事情不能单单盯着KPI,不是KPI的事情不做。
a4480bf840f4232751cb1576f82251270c4ff5bc
《沉淀》是云栖社区展示专家风采的人物栏目。它呈现每个专家独一无二的人生经历、认识和感悟的同时,也能帮助你沉淀技术,收获对技术和人生的判断。我们的想法是:“若你想精进为一个很厉害的人,不妨细细品味这些技术牛人背后的沉淀。” 如果你想了解这些云栖专家更多分享时,请点击云栖专家频道,当然我们也欢迎你往前走一步,成为我们的云栖专家(https://yq.aliyun.com/expert),与技术大牛一起“煮酒论英雄”。

提到程序员三个字,有些人的固有印象里会立马冒出如下标签:屌(码)丝(农)、不修边幅、没情调……

而光哥,哦,不好意思——应该是“光戈”,在内网的18个标签中,被以下三大类占据:

  1. 富二代她父亲…
  2. 身材非常棒…
  3. 会做肉松,有点2的光光…

在技术上,2014年转型做大数据,他研发的产品,在不增加任何投入的情况,将计算集群的CPU利用率从30%多提升到70%以上,极大地提高了服务器的利用率;与此同时,他在内网的技术社区上(ATA),活跃度在全集团前十。

是的,这是一位事业有成,生活有质量,也有品位的技术人。如果把时钟往前拨,回顾他的整个技术生涯,你会发现,今天处之泰然的背后,也有艰辛:

1. 因为工作,三年间几乎跑遍整个河北省和河南省;
2. 因为想成为一名DBA,于是他把市面上的相关书籍都看了,并且写了几百篇Oracle的文章;
……

光戈是谁?做什么工作?究竟是怎么样的一个人?他的人生经历和技术思考能给大家带来什么样的启发?第13期《沉淀》人物栏目专访了这位阿里专家。

三年时间,跑遍了整个河北和河南省

c90089d5a65fd696ceb30f1c79769c932e75c8c4
照片背后的故事:“这种(照片)行么?”如果你是最想放这种照片,是可以的。“好,就这个!”

光戈,真名孙伟光,他是阿里数加平台数据集成产品的负责人,工作内容是领导阿里集团内专有云、公有云环境的数据采集,以及传输和分发。目前经他保障集团和公有云的实例每天有数十万,数据同步将近千TB。

孙伟光2004年毕业于沈阳工业大学,毕业后就加入了东软,负责社保软件的开发。这是一份负责医疗保险软件的开发和实施的工作,包括社保中心端和医院(药店)医保系统。看似是份普通的开发工作,然而工作内容很杂,他要负责包括开发、部署、维护、签合同以及收合同款……等等的工作。这样的工作,他硬生生地做了三年,而与之伴随的则是三年的时间,他也几乎跑遍了整个河北和河南省。

对于这段经历,孙伟光最难忘的是在邢台。在那,他差不多待了将近一年的时间。这一年,他与同事承担起整个邢台医保中心软件的开发和实施,以及全市上百个医院和药店的维护工作。在他人看来,这段疯狂的出差经历,是十足的苦差事,但在孙伟光眼中,他却看到了“收获”二字。“这段经历让我学会如何与人沟通,推进事情;也学会如何承担责任。”在采访中,他澄沙汰砾地回复云栖社区。

2007年,孙伟光加入阿里巴巴B2B。之所以选择阿里B2B,是因为他想成为一名DBA,而当时的B2B在整个中国DBA领域有着巨大的影响力。

为了实现这个梦想,他开始每天泡ITPUB,并把市面上所有关于Oracle的书籍都刷了一遍。对于当时的疯狂,他回忆:“每天都在电脑上做测试,为了沉淀所学,甚至还写了几百篇有关Oracle的文章。”

理想和现实总是会有些许差距的,有的人会叹不如意,就此自怨自艾;而有的人则视为是一个新的起点,不断上进。孙伟光是加入了阿里,并且部门也是B2B,然而岗位却是数据仓库。但这位乐天派的技术人显然是后者,丝毫不以为意,他觉得岗位跟DBA是有些区别,但好在总是跟数据相关。

从开发转做数据仓库,颇有些挑战。一个挑战是工作环境,东软基本都是Windows开发,而阿里则是Linux……总体来说,这个挑战还好,只要稍微用点时间就能适应。最大的挑战是数据仓库的工作一半是技术,一半业务,需要投入很大的精力来理解业务,并且要思考如何通过数据来提升业务。

“一半是技术,一半是业务,你是如何应对这个挑战的?”

“经常到财务那边,与业务同学‘亲密’接触。”他很认真的说到。

将计算集群的CPU利用率从30%多提升到70%以上

2014年,孙伟光加入阿里云ODPS团队,开始做HBO。

HBO(History-Based Optimization)是基于任务执行历史的优化,通过对任务历史执行情况的分析,根据优化规则生成更加高效的执行方式。简单点,则可以理解为:任务执行历史+集群状态信息+优化规则→更优的执行配置。

为什么要做HBO,孙伟光说:“当时开发的背景是整个ODPS的集群利用率比较低,而ODPS的任务优化又是专业度比较高的事情,用户很难自己进行优化。”因此,孙伟光被委以重任,负责开发这样的一款产品。

实际上,在HBO开发之前,是没有可以参照、对比的竞品。在独自摸索的情况下,孙伟光终于把HBO开发成功,不仅成功,而且成绩斐然——HBO在不增加任何投入的情况,将计算集群的CPU利用率从30%多提升到70%以上,极大地提高了服务器的利用率。

将计算集群的CPU利用率从30%多提升到70%以上——这是如何做到的?孙伟光在访谈中剖析:“简单来说,问题的根本是ODPS默认的资源分配规则并不适合集群的现状,而HBO除了会分配更多的资源给大任务,加速其运行;也会分配较少的资源给小任务,在保证其执行效率的前提下节省更多的资源。”

轻描淡写的背后,则埋藏着一个又一个的难解问题。其中一个难题是:每次HBO的规则变化都需要在线上和生产环境中验证。那如何减少对线上任务产生不良影响的前提下,推动规则的优化和发展?

“我的解决方法是:与当时公共层的ETL开发任务一起合作;其次对每次的规则优化采取渐进式的手段,控制影响范围,并详细记录优化前后的数据变化,及时对优化前后的效果做回收。”正如他回答中一贯的干练形象,对于难题的解决究竟都经历了啥,孙伟光并没有铺垫其他东西,而是说出答案直指问题。

针对产品本身数据的分析和挖掘,往往能带来意想不到的提升

在ODPS,孙伟光虽然只工作了三年,但他一直在做数据相关的工作,并经历了一些部门和岗位。

因此,这位和数据打交道的技术人沉淀了不少心得,他和云栖社区提到其中一点:“虽然周围人都是做数据的,但是大家其实对本身产品的一些数据并不那么在意。然而针对产品本身数据的分析和挖掘,往往能带来意想不到的提升。”

他怕笔者不理解,就举了一个例子:“拿阿里集团内部的数据集成产品来说,印象中离线的数据集成任务都是同步数据量相对比较大,同步时间比较长。”

孙伟光进一步叙述他的发现——通过对历史数据的分析发现,大部分离线的任务也是执行时间比较短的任务,所以对整个传输流程中的优化是比较重要的,这样能极大的提高同步外的时间消耗,提高同步效率。

“在设备非常多的今天,数据越来越大,也越来越杂,在如何保障数据采集、传输和分发更加高效、稳定上,你是否有一些心得?”云栖社区追问。

孙伟光的回答一如既往的干练,他认为想要保证数据采集,传输和分发更加高效,稳定,一定要对整个数据集成的过程都有深刻的理解。他接着进一步阐述该如何去做:“你需要了解每种数据源的特性,需要了解网络传输的底层原理,只有这样才能做更有针对性的优化和提升。”

最后,我们也聊到数据采集、传输和分发的未来趋势,云栖社区总结了他回答中的两个关键词:“成本低”和“智能”。具体来看则是,未来用户使用成本会越来越低,对他们而言未来只需要关注任务配置,而其他的事情全部交给产品本身;同时,产品会越来越智能,通过对执行历史的学习,根据优化规则,自动的对整个数据传输过程做智能的优化。

结束语:多行善事,莫问前程

回顾自己整个技术生涯,孙伟光觉得自己最重要的是技能是,通过对产品相关数据的学习和分析,快速理解一款产品在各个方面的状态。对于即将毕业的计算机系同学,他给了一些技术发展建议:思路要尽可能的开阔,提高技术的广度。

这位喜欢举铁的技术人,每周都会坚持健身,他说健身的时候比较放松,一些工作上的思考放在这个时间,往往能有意想不到的收获。

他最喜欢的一句话是——多行善事,莫问前程。

“能说说你的进一步理解吗?”云栖社区想挖一挖背后的缘由。

“做事情不能单单盯着KPI,不是KPI的事情不做。”他的简洁和直指问题本质的能力又出来了。他知道当下各大互联网公司KPI的管理弊端,以及互联网人的本位主义、急功近利和本末倒置。

隔了一会,他复又在回复中敲了如下几个字:“多做些有意义的事情,别太在乎得失。”

想起他为什么能将计算集群的CPU利用率从30%多提升到70%以上,也想起他为什么能发现——“针对产品本身数据的分析和挖掘,往往能带来意想不到的提升。”

至此,一切都明了(本期接受访谈的云栖专家/ 光戈;文/我是主题曲哥哥)。

相关文章
|
6月前
|
人工智能 并行计算 PyTorch
【PyTorch&TensorBoard实战】GPU与CPU的计算速度对比(附代码)
【PyTorch&TensorBoard实战】GPU与CPU的计算速度对比(附代码)
333 0
|
3月前
|
C++
C++ 根据程序运行的时间和cpu频率来计算在另外的cpu上运行所花的时间
C++ 根据程序运行的时间和cpu频率来计算在另外的cpu上运行所花的时间
43 0
|
2月前
|
KVM 虚拟化
计算虚拟化之CPU——qemu解析
【9月更文挑战10天】本文介绍了QEMU命令行参数的解析过程及其在KVM虚拟化中的应用。展示了QEMU通过多个`qemu_add_opts`函数调用处理不同类型设备和配置选项的方式,并附上了OpenStack生成的一个复杂KVM参数实例。
|
2月前
|
算法 C++
如何精确计算出一个算法的CPU运行时间?
如何精确计算出一个算法的CPU运行时间?
|
3月前
|
算法 Windows
CAE如何基于CPU最佳核数和token等计算成本
【8月更文挑战第26天】在使用CAE(计算机辅助工程)进行分析计算时,需综合考虑CPU核数和token对成本的影响。CPU核数越多,虽能加速计算,但过多核数会因通信开销和内存带宽限制导致性能提升放缓。成本计算需考虑硬件租赁或购买费用及云服务收费标准。Token作为软件许可,需分摊到每次计算中。通过测试优化找到性能与成本的平衡点,实现最低成本下的高效计算。
|
4月前
|
并行计算 API 数据处理
GPU(图形处理单元)因其强大的并行计算能力而备受关注。与传统的CPU相比,GPU在处理大规模数据密集型任务时具有显著的优势。
GPU(图形处理单元)因其强大的并行计算能力而备受关注。与传统的CPU相比,GPU在处理大规模数据密集型任务时具有显著的优势。
|
5月前
|
Prometheus 监控 Cloud Native
grafana展示的CPU利用率与实际不符的问题探究
观察到`mpstat`命令显示单核CPU的`%usr`和`%sys`分别持续在70%和20%,而Grafana监控数据显示较低。问题源于Grafana表达式计算的是CPU时间增量而非利用率。`mpstat`通过`/proc/stat`获取数据并计算CPU利用率,而`node-exporter`直接导出原始数据。调整Grafana表达式以匹配`mpstat`的计算方式后,两者结果一致。解决方案是修正Grafana查询以准确反映CPU占用率。
239 1
grafana展示的CPU利用率与实际不符的问题探究
|
5月前
|
Python
python3获取内存和cpu利用率记录日志文件psutil
python3获取内存和cpu利用率记录日志文件psutil
66 1
|
5月前
|
弹性计算 安全 前端开发
阿里云服务器ECS通用型、计算型和内存实例区别、CPU型号、性能参数表
阿里云ECS实例有计算型(c)、通用型(g)和内存型(r)系列,区别在于CPU内存比。计算型1:2,如2核4G;通用型1:4,如2核8G;内存型1:8,如2核16G。实例有第五代至第八代,如c7、g5、r8a等,每代CPU型号和主频提升。例如,c7使用Intel Ice Lake,g7支持虚拟化Enclave。实例性能参数包括网络带宽、收发包能力、IOPS等,适合不同场景,如视频处理、游戏、数据库等
139 0
|
5月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之在一个集群上创建多个数据库实例,是否可以做cpu和内存的配额指定
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。