【沉淀】一张表的设计优化节省了两百万,客户不断盛誉……,这背后他究竟做对了什么?——记访谈阿里云汪建明

【沉淀】一张表的设计优化节省了两百万,客户不断盛誉……,这背后他究竟做对了什么?——记访谈阿里云汪建明

《沉淀》是云栖社区展示专家风采的人物栏目。它呈现每个专家独一无二的人生经历、认识和感悟的同时,也能帮助你沉淀技术,收获对技术和人生的判断。我们的想法是:“若你想精进为一个很厉害的人,不妨细细品味这些技术牛人背后的沉淀。”如果你想了解这些云栖专家更多分享时,请点击云栖专家频道,当然我们也欢迎你往前走一步,成为我们的云栖专家(https://yq.aliyun.com/expert),与技术大牛一起“煮酒论英雄”。

“客户第一”是阿里巴巴“六脉神剑”中排名第一的价值观,它除了要求阿里人服务好客户之外,也要求阿里的同学时时刻刻去了解客户的所思所想,不断地挑战自己,用不同的视角给客户创造更多新的价值。

在阿里云数据库DBA专家服务组里,就有一位技术人是“客户第一”的典范。因为他的存在,有客户放心地说:“我们才安心地把业务放在云上。”;也是因为他,客户非常感激:“如果没有他的帮助,可能会出现更加严重的问题。”

在服务态度上,有客户称赞他高效、负责;也有人对他的敬业动容:“感谢汪建明经常利用自己的休息时间来帮助我们查找和解决问题”。在专业上,有人赞赏他有高手风范,接手后不仅迅速找到了问题发生的原因,在半个小时之内还提出了解决方案,并帮他们完成了大部分的调优工作,及时阻止了问题向更加严重方向发展……

对于这些称赞,他没有一丝一毫地骄傲,反而不断地总结和反思,提炼出客户服务三步骤:了解客户诉求、做到情绪沟通以及坦诚方案风险。面对一时情绪上难以平复,“刁难任性”的客户,他真正做到:客户虐我千百遍,我待客户如初恋,问及乐观心态的原因,他笑称:“客户虐我们,恰恰说明他们爱我们,离不开我们。”

尤为值得一提的是他的技术,在上一家公司,他仅仅对一张核心表的设计优化,就为公司节约了30TB的SAN空间开销,带来的直接经济成本节约是两百多万人民币。为此,公司直接把他调往美国总部。

他,就是阿里云数据库专家服务组的汪建明,花名“风移”。第14期《沉淀》人物栏目,用时半个多月的时间,去走近这位在SQL Server数据库行业钻研十年的技术专家,将他的沉淀和别具匠心呈现给大家。

技能和职场快、准、狠的背后

【沉淀】一张表的设计优化节省了两百万,客户不断盛誉……,这背后他究竟做对了什么?——记访谈阿里云汪建明
汪建明说,数据是公司的生命线,而数据库是数据的最后一道防线,你对自己的所有操作的后果、风险一定要心中有底。

汪建明,目前在阿里云RDS负责数据库管理、运维、产品设计、研发,以及专家服务等。上一段工作经历,他是在新蛋(Newegg)成都公司做DBA。因为工作出色,几年后,他就被调到美国新蛋加州总部,负责集团数据库管理、运维、设计、性能调校,以及大数据平台建设。后者中,包括Hadoop、Hbase、Hive、Prosto和Phoenix等。

回顾这段较为顺利的职场经历,他把原因归结为四个字:“先知先觉”。他说,自己读大三时,就已经在企业里实习,摸爬滚打,锻炼自己。大四,更是几乎没在学校待过,一边自学大四专业课程,一边公司实习。

他说:“自己虽然累点,但是知识的吸收速度,和对社会、职场的贴近程度更快、准、狠。”在大四所有人都在为找工作东奔西走、忙里忙外时,汪建明已经在实习单位转正。

在转正后的四年里,汪建明做了无数的项目,也开始带领8个人的团队。随后,他转到美国总部。然而初到美国后,却让他有种一夜回到*的感觉。

问题体现在口语表达、文化差异、同事相处等方面。为了丰满自己,适应新环境,汪建明白天上班,晚上上语言社区大学语言课程,结束之后,再回家上在线英文课程。这是犹如孩童一般,从头开始一点一滴的重新学习:“如何打电话、如何点餐、如何与人沟通,甚至如何写英文邮件……”汪建明感慨到,文字表达有点苍白无力,其中滋味五味杂陈,只有自己才能体会。在这样的状态下,汪建明坚持一年后,也慢慢适应了新环境和工作节奏。

带来的I/O压力减轻和应用内系统的性能提升,很难用数字去表达

回首在新蛋的工作,汪建明称,因为做的项目太多,有很多都已无法记得特别清楚,唯独有一个记得十分清晰。

那是他发起并领导的一个项目,工作的内容是对一张核心系统表的设计优化。就是这张表,却为公司节约了近30TB的SAN空间开销。这个是直接空间节省,因此带来的I/O压力减轻和应用系统性能提升,很难用数字去表达。而这30TB的空间直接的经济成本是30万美金左右,也就是200万左右人民币。

他指出,这个项目是典型的利用技术手段,为公司节约经济成本投入的很好佐证。项目的背景是关键业务系统大表,表结构的设计有很大问题。具体体现在表字段类型的设计有问题和表主键设计不合理,比如好几个字段的数据类型被设计为CHAR(100), CHAR(800),CHAR(2000)这种数据类型,而表主键则是CHAR(25),这种设计导致的严重问题包括:
  1. CHAR数据类型存储了很多无用的空格信息,主键长度过宽,导致表聚集索引、非聚集索引空间占用过大 
  2. 查询语句性能会消耗更多I/O资源,I/O利用率下降
  3. 索引维护工作超时,更进一步导致了查询语句性能低下
  4. 过大的表空间甚至导致备份超时,影响备份策略
问题的解决之道,也许并不是特别难,但让汪建明头疼的是:如何在完全不修改现有系统,不影响现有业务系统,在用户业务毫无感知的情况下,把这个项目按时按质量顺利进行;其次是,该表为大表,仅仅是这一个表记录数近1亿,表空间占用近700GB,数据源头同步到近60个数据目的业务子系统中,业务系统错中复制,盘根错节,千头万绪。

基于以上的同步关系,加之该表为公司关键业务系统表,公司里的技术人难以抉择。“我们不会也不可能直接在表数据同步源头直接修改表结构。如果这么操作会导致一个超大的事务,影响到所有业务子系统,对公司业务来说是致命的。” 汪建明道出难以抉择的原因。

这位在大三就在企业摸爬滚打的技术人,并没被问题吓住。他开始着手解决问题,先是理清楚所有业务子系统,该表的数据同步关系;接着,制定好详细的操作步骤,验证方法,不断在测试环境验证这些步骤和方法的可行性。

而当他不断探索,验证方案时,解决思路也就有了:在数据源头库新建一张中间表,中间表的表结构是已经优化好了,最终希望的表结构(CHAR数据类型修改为VARCHAR),不再存在数据类型的问题→在数据源头建立到中间表的Replication→确保正式表和中间表数据一致性→中间表上Update截断CHAR数据类型右边空格→在中间表基础上,参照正是表的同步关系,建立一摸一样的同步链→切换所有下游中间表,将中间表和正式表名字对调(这个过程很快,不到1秒即可完成)→最后切换最终源头表的名字。

当项目成功实施后,统计所有实例上该表空间占用情况,已然从700GB降低到200GB,空间占用降低了近70%,总共节约了近30TB的存储空间。项目总结时,所有人都对他竖起了大拇指。

技术不是僵硬的:“你仿佛看到了客人迎面而来,热情地紧握着你的手,满面微笑不断地说——谢谢。”

在美国待了三年后,汪建明意识到云计算的发展的巨大潜力和未来,他决定回国,并加入阿里。

来到了阿里云后,汪建明担任类似于“救火员”的角色,为客户解忧排难。对于他而言,每天面对的客人从之前的内部用户变成了外部用户,每天也都经历各种稀奇古怪的问题,管理数据实例的规模从几百到成千上万……正是这样异常复杂的环境,却逐渐让这位不善言辞的技术同学逐渐得到客户的认可,以及增强了他们对阿里云的信心。

正如文章开头提到,他受到多家客户表扬,包括复方科技、飞利浦中国、问卷星……等。令汪建明印象最深的是后来遇到的一家A公司。因为CPU持续100%,影响到公司业务无法正常开展,导致A公司的高层非常愤怒,几个工程师已经到了快要被开除的边缘。客户觉得阿里云RDS SQL不行,内部已经在准备着手应用下云或切换为MySQL。

而在他介入之后,通过分析“病原”。包括,闻:电话听取客户的抱怨、激动、怒吼和倾诉;问:询问“病状”表象,进一步确认“病原”;切:有针对性的实地考察,再次肯定“病原”。一系列组合拳后, 很快定位到CPU 100%的根源,开出治病良方。从索引缺失、索引碎片、Non SARG查询、数据类型隐式转化等角度,快速帮助用户解决问题,CPU也从100%降低到15%,查询语句时快时慢、卡顿和超时现象消失,应用恢复稳定正常。而更重要的是,那几个技术员不用被老板开除了,客户重新建立了对阿里云RDS SQL Server的信心,对阿里云充满感激,并发来热情洋溢的表扬信。

这次“行医”也颠覆了汪建明对技术的看法,他原以为技术是僵硬的,是死的,没有任何情感和情怀。“但从这个Case,我感受到了技术之外的魅力和情感。”他进一步述说,“在我看来‘简单’的技术问题,可能会要了客人的‘命’,也有可能要了技术人员的‘命’。而我们善用平时总结的技术知识点,运筹帷幄,一整套组合拳下去以后,客人反馈给我们的是有情感、有温度、有画面感的具体形象(你仿佛看到了客人迎面而来,热情的紧握着你的手,满面微笑的不断说,谢谢)。”

“这个或许就是技术带来的魅力,技术带来的情感,技术带给我们的成就感。”说完之后,他头转过来,从他的眼神中,云栖社区的编辑也看到了亮光。

如何炼就火眼金睛

如何做性能优化,汪建明表示,性能优化是数据库综合能力的体现。它涉及到数据库方方面面的知识和理论,比如:数据库设计(包括很多方面的设计)、查询语句写法、索引优化等。他觉得举一个实例比较好理解:“很多用户对于高CPU使用率问题是束手无策,我们可以从索引缺失、索引碎片、数据类型转化、non-SARG查询、统计信息、参数嗅探等角度多管齐下,很快就可以解决CPU高使用率的问题。”

而对于如何像他一样炼就一双火眼金睛,他也从以下角度给了两个诚恳的建议:

1.端正态度,不要操之过急。遇到任何问题,多想,多测试,多问为什么,要和问题死磕到底,不找到问题的根源死不罢休。多向高手学习,学习他们对数据库的理解、学习他们对问题的思考方式和解决方法;
2.多总结。按照类型总结,吃透一类问题(比如高CPU使用率的问题),那么涉及到这类问题的方方面面做到烂熟于心,信手拈来;

对于从事数据库行业的同学,他也给出一个忠告——和数据库打交道,一定要打起十二分精神。他说,数据是所有公司的生命线,而数据库是数据的最后一道防线,你对自己的所有操作的后果、风险一定要心中有底。

“试着问自己,如果这个操作导致了XX严重后果,有办法把数据救回来吗?数据会丢吗?丢多少?比如:我们经常遇到的Case是用户一个Update语句下去,忘记写WHERE条件,导致所有数据被Update,又或者是删除测试环境的数据,不小心连接到了产品环境等。”他说,类似的情况比比皆是,所以一定要小心再小心。

客户服务的三个有效步骤

每次帮客户解决完问题,汪建明并不是就此结束,而是会反复揣摩和进一步思考:如何能做的更好,如何能帮客户进步,让他们自己能避免一些问题发生。

在如何做的更好上,他提炼出客户服务三个有效步骤:
  1. 清楚客户需求:了解客户的诉求、需求点、痛点在哪里,客人迫切需要解决什么问题?如果客人是头痛,你却医脚。医术再高明,也解决不了客人的痛点。
  2. 情绪沟通:稳定客人的情绪,缓解客人的抱怨,控制客人的影响,做好舆情防范。在严重问题面前,最好能够当面和客人沟通,其次电话,再次即时聊天工具。
  3. 风险管理:坦诚解决方案的风险,让客人清晰、明了、理解问题解决方案的风险点,给足客人心里预期。
他还说:“我们不能要求客户,拥有像阿里云DBA那么牛逼的组合拳来面对问题。所以,有的时候,看到客人对我们产品的误解的时候——RDS SQL不行啊,要下云啊,又好气又好笑(这里笑没有贬低的意思,是苦笑)。气的是客人对RDS SQL产品本身研究不够深入,而武断下结论,甚至因此开除自己的员工;苦笑的是实际是一个不难的问题,却把我们的客人逼的焦头烂额,无从下手。”

为了让客户也能进步,汪建明哪怕是在客户服务结束后,也会对每一个问题都刨根问底,希望找到客户经常犯的问题的共性。他接受云栖社区访谈时,给出了自己的思考:
  1. 一切数据库技术问题的“祸根”或者说根源,可以归结为数据库的设计问题。比如:数据库架构的设计、分库分表的设计、读写分离的设计、表结构的设计、表字段类型的选择、索引的设计、索引维护策略的设计、统计信息维护等等;
  2. 对如何写出高性能的SQL语句没有感觉,开发人员往往是功能优先而忽视性能。比如:确保比较运算符两段的数据类型一致、WHERE字句中使用函数、Non-SARG查询等;
  3. 对SQL Server商业数据库能力边界没有信心。很多客人会问,SQL Server是不是不行了啊,是不是处理不了啊,是不是已经达到处理的边界了啊,Hold不住了啊等等问题。汪建明认为,这些类似的问题是很可笑的。如果SQL Server数据库用的好的话,PB级别不在话下。他之前的公司,单台实例的SQL Server数据量达到20TB以上的数据量,照样稳定高效运行。“现在公有云用户没有谁达到了这个量级吧?”他反问。
至于如何实践,汪建明说:“除了自己不断学习,不断总结,也可以多看看云栖社区上的技术分享和总结。”他说,站在前人的肩膀上,总会站得更高,看得更远,少走弯路,更快成熟。为此,他还把自己十多年的沉淀和针对性的总结,做成专题,详情参见链接:https://yq.aliyun.com/topic/98

他也指出:“当然,作为阿里云RDS这个角色,如何将我们的经验、总结,以及我们对数据库本身的理解,沉淀出产品来,使得用户入门的门槛更低,运维、设计、管理更为方便,也是我们必须要突破的重点和难点。目前也有一些服务出来,包括专家诊断、专家服务和个性化的培训服务等,详情参见专家服务:https://promotion.aliyun.com/ntms/act/clouddba.html。”他也表示,自己实际上不是一个人在“战斗”,背后也有一排排同样专业的技术大牛,这么多人构成了ApsaraDB专家服务多样化、个性化、全面和周到的服务体系。

结束语:知行合一

在最后,我们聊到对技术的理解。他说,不论是技术人,还是技术型公司,都需要对技术的执着追求、对任何问题死磕到底的工匠精神,戒骄戒躁;以技术解放生产力问题,用技术提高生产率,优化产品质量。

“这就是我对技术和对技术从业人员需要具备的特质的理解。”说完后,汪建明又补充,这里还想借王国维人生的三个境界,进一步来阐述他对技术的认知。

第一层境界:昨夜西风凋碧树,独上高楼,望尽天涯路。他解读,但凡活好,技术牛逼的技术从业人员都有明确目标,执着的追求。“独上高楼”,登高望远,讲的就是对目标和方向的明确,一旦找准方向,哪怕独自前行,风雨征程,也绝不退缩,永不放弃;

第二层境界:衣带渐宽终不悔,为伊消得人憔悴。任何成大器者、大学问者,都不是轻而易举,唾手可得的。坚定信念,一番辛勤劳动,废寝忘食,孜孜以求,直至“衣带渐宽终不悔”。汪建明还描述到:“此刻,我脑海中浮现这样的画面:在无数个孤独的夜晚、夜深人静、唯有码农还在挑灯夜战,陶醉在代码的世界里,醉心于诗一般美妙的代码逻辑中,为着对技术的追求苦战到底。”他说,所以你会发现现实中的码农都是骨瘦如柴、满脸倦意、不修边幅、睡眼惺忪,邋里邋遢(汪建明笑称这里都是贬义词褒用啊,哈哈),这是“为伊消得人憔悴”的体现;

第三层境界:众里寻他千百度,蓦然回首,那人却在灯火阑珊处。最后一个境界,可谓是苦尽甘来,在我们持续专注、沉下心来、潜心研究、下足功夫、融会贯通、有所发现、有所成就,我们自然会达到浮躁渐去,成就、成果自然就会在“灯火阑珊”处。这是我们坚定信念、戒骄戒躁、执着追求的必然结果。

言之至此,笔者想起,访谈中多次在钉钉上找他,他无一例外的都说:“晚上回答你,现在在撸代码。”用“撸串”中的那个“撸”来形容代码,从字面就可以感受到那股欢快劲。当然,我们也可以想象出,那个时候或许他正干劲十足地死磕某个技术问题。

技术之外,笔者也翻出其中有一位客户写给汪建明的夸奖邮件:

“今天如果没有你的帮助,我们的RDS可能会出现更加严重的问题。风移同学接手后,迅速找到了问题发生的原因。在半个小时之内,不但提出了解决方案,还帮我们完成了大部分的调优工作,及时阻止了问题向更加严重方向发展。调优完成后,他还持续观察了很长一段时间,确保问题得到了解决。他又将处理步骤和思路发邮件给我们,并通过电话给我们详细讲解。交流过程中,我们的同学也向风移同学咨询了一些日常工作的疑惑,他也不厌其烦的为我们的同学一一解答。无论从技术的专业程度和工作敬业程度上风移同学都是无可挑剔的。”

从上段表扬信,我们不难看出,他是如何践行客户第一——那是真的全身心投入,解决客户的每一个小问题,急客户之急,想客户之想。像他这样,客户怎么会不放心,怎么会不感动,怎么会不成为阿里云的忠实Fans,并用他们自己的行动来为阿里云站台。

不论是技术,还是服务上,汪建明都无一彰显着四个字——知行合一。知行合一,是天底下最容易,也是最难的事。而这点,你能做到吗?(本期接受访谈的云栖专家/风移;文/我是主题曲哥哥)

上一篇:【沉淀】实例迁移、Insert和写入性能——数倍,甚至数十倍提升,HybridDB for MySQL负责人王骞谈自己经历和收获


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