北京注销网站备案,更改wordpress前缀,wordpress前台投稿插件,凡客生活官网写在前面
写过blink sql的同学应该都有体会#xff0c;明明写的时候就很顺滑#xff0c;小手一抖#xff0c;洋洋洒洒三百行代码#xff0c;一气呵成。结果跑的时候#xff0c;吞吐量就是上不去。导致数据延迟高#xff0c;消息严重积压#xff0c;被业务方疯狂吐槽。这…写在前面
写过blink sql的同学应该都有体会明明写的时候就很顺滑小手一抖洋洋洒洒三百行代码一气呵成。结果跑的时候吞吐量就是上不去。导致数据延迟高消息严重积压被业务方疯狂吐槽。这时候老鸟就会告诉你同学该优化优化你的代码了再丢过来一个链接然后留下一脸懵逼的你。笔者就是这么过来的希望本文能帮助到跟我有过同样困惑现在还一筹莫展的同学。
背景故事
先说一下相关背景吧笔者作为一个刚入职阿里的小白还处在水土不服的阶段就被临危受命改造数据大屏。为什么说临危受命呢首先是此时距双十一仅剩一个月再者去年的双十一这个大屏刚过零点就出现问题数据一动不动几个小时后开始恢复但仍然延迟严重。此前笔者仅有的实时计算开发经验是storm用的是stream API对于blink这种sql式的API完全没接触过。接到这个需求的时候脑子里是懵的灵魂三问来了我是谁我即将经历什么我会死得有多惨不是“此时此刻非我莫属”的价值观唤醒了我是老大的一句话在阿里不是先让老板给你资源你再证明你自己而是你先证明你自己再用结果赢得资源一席话如醍醐灌顶。然后就开始了一段有趣的故事
压测血案
要找性能问题出在哪儿最好的方法就是压测。这里默认大家都对节点反压有一定的了解不了解的请先移步典型的节点反压案例及解法。
一开始是跟着大部队进行压测的压测的结果是不通过一起参加压测的有三十多个项目组就我被点名。双十一演练的初夜就这样伤心地流走了(╯°□°╯︵ ┻━┻。西湖的水全是我的泪啊。不过痛定思痛我也是通过这次压测终于定位到了瓶颈在哪里。
瓶颈初现
数据倾斜 在做单量统计的时候很多时候都是按商家维度行业维度在做aggregate按商家维度不可避免会出现热点问题。
hbase写瓶颈 当时我在调大source分片数并且也无脑调大了各个算子的资源之后发现输出RPS还是上不去sink节点也出现了消息积压。当时就判断hbase有写瓶颈这个我是无能为力了。后来的事实证明我错了hbase的确有写瓶颈但原因是我们写的姿势不对。至于该换什么姿势请继续看下去。
神挡杀神
先来分析一下我们的数据结构(核心字段)biz_date, order_code, seller_id, seller_layer, order_status, industry_id
我们group by的典型场景有
CREATE VIEW order_day_view ASSELECTindustry_id,seller_layer,biz_date,count(distinct order_code) AS salesCountFROMorder_viewGROUP BY industry_id,seller_id,seller_layer,biz_date
;
总结下来就是按卖家维度行业维度什么的都非常容易出现数据倾斜。
数据倾斜其实有很多解法这里我不展开讨论只讲我们这个案例的解法。倾斜的原因无非就是group by的字段出现了热点大量的消息都集中在了该字段少数几个取值上。通常的解法是在消息中选择具备唯一性或者预估会分布比较均匀的字段。如果这个字段是整型的可以直接取模(模数一般是节点的并发数)如果是字符串可以先进行哈希计算再取模得到一个分片地址(本文取名为bucket_id)。在接下来的所有aggregate算子中都要把他作为group by的key之一。
在我们这个案例中我们选择了order_code这个具备唯一性的字段。首先在源头把分片地址算出来加到消息里面代码如下
SELECT
o.biz_date, o.order_code, o.seller_id, o.seller_layer, o.order_status, o.industry_id, o.bucket_id
FROM (select *,MOD(hash_code(order_code), 32) AS bucket_id from order_stream) o
然后把这个bucket_id层层传递下去在每一个需要group by的地方都在后面带上bucket_id例如
CREATE VIEW order_day_view ASSELECTindustry_id,seller_layer,biz_date,count(distinct order_code) AS salesCount,bucket_idFROMorder_viewGROUP BY industry_id,seller_id,seller_layer,biz_date,bucket_id
;
事实上我一开始想到的是用下面tips里的方法结果就杵进垃圾堆里了性能问题是解了但是计算出来的数据都翻倍了明显是错的。至于我是怎么发现这个问题并分析其原因再换了解法又是另一段故事了。可以提前预告一下是踩了blink撤回计算的坑后面会再出一个专题来讲述这个故事哒
这里还想再延伸一下讲讲我的学习方法。如果读者中有跟我一样的小白可能会奇怪同样是小白为何你这么秀一上来就搞压测还能准确地分析出性能的瓶颈在哪里。其实有两方面的原因一方面是我有过storm的开发经验对实时计算中会遇到的坑还是有一定的认识另一方面是我没说出来的多少个日日夜夜苦逼学习充电的故事。我的学习习惯是喜欢追根溯源就找了很多介绍flink基本概念发展历史以及跟流式和批处理计算框架横向对比的各类博客。而且带着kpi去学习和什么包袱都没有去学习心态和学习效率是不一样的。前者虽然效率更高但是是以损害身心健康为代价的因为学习过程中不可避免的会产生急躁情绪然后就会不可避免的加班熬夜咖啡再然后他们的好朋友黑眼圈豆豆感冒就全来了。后者虽然轻松但是什么包袱都没有反而会产生懈怠没有压力就没有动力这是人的天性拗不过的。这就是矛盾的点所以在阿里经常提到“既要也要还要”其实宣扬的是一种学会平衡的价值观。至于怎么平衡嘻嘻天知地知我知。对只能自己去领悟怎么平衡别人教不会的。
概念有了一定的认知下面就开始实践了。整个实践的过程其实就是在不断的试错。我是一开始连反压的概念都不知道的一直在无脑的调大CU调大内存调高并发数调整每两个节点之间的并发数比例。寄希望于这样能解决问题结果当然是无论我怎么调吞吐量都是都风雨不动安如山。现在想想还是太年轻呀如果这样简单的做法能解决问题那那个前辈就绝对不会搞砸了还轮的到我今天来解决。后来也是在无尽的绝望中想通了不能再这么无脑了我要找其他法子。想到的就是在代码层面动刀子当然试错的基本路线没有动摇前面也提到过我一开始是想到的“加盐”也是在试错。
学习方式决定了我做什么事都不可能一次成功。甚至有很多情况我明知道这样做是错的但我就是想弄明白为什么行不通而故意去踩这个坑。不过也正是因为试了很多错踩了很多坑才挖出了更多的有价值的知识点扩大了知识的边界。
此时无声胜有声送上几句名言与诸君共勉 塞翁失马焉知非福。---淮南子·人间训 一切过往皆为序章。---阿里巴巴·行癫 学习就像跑步一样每一步都算数。---百阿·南秋
tips: 如果在消息本身中找不到分布均匀的字段可以考虑给每一条消息加上一个时间戳直接使用系统函数获取当前时间然后再对时间戳进行哈希取模计算得到分片地址。相当于强行在时间维度上对消息进行打散这种做法也被形象的称为“加盐”。
佛挡杀佛
上一段看下来似乎只解决了数据倾斜的问题。之前还提到有一个hbase写瓶颈问题这个该如何解呢
还是接着上面的思路继续走下去当我们把bucket_id一路传递下去到了sink任务的时候假设我们要按商家维度来统计单量但是别忘了我们统计的结果还按订单号来分片了的所以为了得到最终的统计值还需要把所有分片下的值再sum一下才行这大概也是大多数人能想到的常规做法。而且我们现有的hbase rowKey设计也是每个维度的统计数据对应一个rowKey的为了兼容现有的设计必须在写hbase之前sum一下。
但是笔者当时突发奇想偏偏要反其道而行之我就不sum对于rowKey我也给它分个片就是在原来rowKey的基础上后面再追加一个bucket_id。就相当于原来写到一个rowKey上的数据现在把他们分散写到64个分片上了。 具体实现代码如下
INSERT INTO hbase_result_sinkSELECTCONCAT(businessRowkey, |, bucket_id) AS businessRowkey,cast(uopAcceptCount as DECIMAL)from hashBucket_view
这样一来API也必须改造了读的时候采用scan模式把所有分片都读出来然后求和相当于把sum的工作转移到API端了。 这样做的好处在于一方面可以转移一部分计算压力另一方面因为rowKey只有一个而我们写rowKey的任务(即sink节点)并发数可能有多个Java开发者应该都深有体会多线程并发对一个变量进行累加的时候是需要加锁和释放锁的会有性能损耗可以猜测hbase的写瓶颈就在于此。后来的事实也证明这种做法将输出RPS提升了不止一个两个档次。
赶考当天
人事已尽接下来就是关二爷的事了(∇)。双十一零点倒计时结束大屏数字开始飙升起来随之一起的还有我的肾上腺素。再看看数据曲线延迟正常流量峰值达日常的10倍。其实结果完全是在预期之内的因为从最后一次的压测表现来看100W的输入峰值(日常的333倍)5W的输出峰值(日常的400倍)都能稳稳的扛下来。出于数(懒)据(癌)安(晚)全(期)的角度考虑很多大屏和数据曲线的截图就不放出来了。
其实现在回过头再看此时的内心是平静如水的。不是大获全胜后的傲娇也不是退隐山林的怯懦。只是看待问题的心态变了。没有翻不过的山没有迈不过的坎。遇事不急躁走好当下的每一步就好也不必思考是对是错因为每一步都算数最后总能到达终点。
浮生后记
笔者写文章习惯带一些有故事趣味性的章节在里面因为我觉得纯讲技术即使是技术人看起来也会相当乏味再者纯讲技术的前提是作者具备真正透进骨髓去讲述的功底笔者自认为还相差甚远只能加点鱼目来混珠了。换个角度来看纯技术性的文章观赏性和权威性更强每一句都是精华这种咀嚼后的知识虽有营养饱满但是不是那么容易消化消化后能吸收多少还有待确认。所以我力求展示我的咀嚼过程更多是面向跟我一样的小白用户如果觉得冗长请各位读者姥爷见谅
原文链接 本文为阿里云原创内容未经允许不得转载。
