一个 Blink 小白的成长之路

  • 时间:
  • 浏览:0

tips: 可能在消息这种中找能要能 分布均匀的字段,可不前要考虑给十根小消息加在另另一一三个时间戳,直接使用系统函数获取当前时间,为什么么让 再对时间戳进行哈希取模计算,得到分片地址。要花费强行在时间维度上对消息进行打散,你这种做法也被形象的称为“加盐”。

先来分析一下大伙的数据价值形式(核心字段)

biz_date, order_code, seller_id, seller_layer, order_status, industry_id

为什么么让 把你这种bucket_id层层传递下去,在每另另一一三个前要group by的地方前要后面 带上bucket_id,这种:

这里还想再延伸一下,讲讲我的学习最好的最好的方式。可能读者富含跟我一样的小白,可能会奇怪,同样是小白,为什么么你这么秀,一上来就搞压测,还能准确地分挥发性能的瓶颈在哪里。确实有两方面的意味,一方面是我有过storm的开发经验,对实时计算中会遇到的坑还是有一定的认识;当时人面,是我没说出来的几条个日日夜夜苦逼学习充电的故事。我的学习习惯是喜欢追根溯源,就找了统统介绍flink基本概念,发展历史,以及跟流式和批除理计算框架横向对比的各类博客。为什么么让 带着kpi去学习和哪些包袱都这么去学习,心态和学习效率是不一样的。前者确实效率更高,为什么么让 是以损害身心健康为代价的,可能学习过程中不可除理的会产生急躁情绪,为什么么让 就会不可除理的加班,熬夜,咖啡,再为什么么让 大伙的好大伙,黑眼圈,豆豆,感冒就全来了。后者确实轻松,为什么么让 哪些包袱都这么,反而会产生懈怠,这么压力就这么动力,这是人的天性,拗不过的。这统统矛盾的点,统统在阿里,时不时提到“既要也要前要”,确实宣扬的是这种学好平衡的价值观。至于为什么么平衡,嘻嘻,天知地知我知。对,能要能要能 当时人去领悟为什么么平衡,别人教不想的。

写过blink sql的同学应该前要体会,明明写的以前就很顺滑,小手一抖,洋洋洒洒三百行代码,一气呵成。结果跑的以前,吞吐量统统上不去。意味数据延迟高,消息严重积压,被业务方疯狂吐槽。这以前,老鸟就会告诉你,同学,该优化优化你的代码了,再丢过来另另一一三个链接,为什么么让 留下一脸懵逼的你。笔者统统这么过来的,希望本文能帮助到跟我有过同样困惑,现在还一筹莫展的同学。

在大伙你这种案例中,大伙选择了order_code你这种具备唯一性的字段。首先在源头把分片地址算出来,加到消息后面 ,代码如下:

上一段看下来,似乎只除理了数据倾斜的现象。以前还提到另另一一三个多hbase写瓶颈现象,你这种该如何解呢?

数据倾斜

在做单量统计的以前,统统以前前要按商家维度,行业维度在做aggregate,按商家维度,不可除理会再次时不时出现热点现象。

还是接着后面 的思路继续走下去,当大伙把bucket_id一路传递下去,到了sink任务的以前,假设大伙要按商家维度来统计单量,为什么么让 别忘了,大伙统计的结果还按订单号来分片了的,统统为了得到最终的统计值,还前要把所有分片下的值再sum一下才行,这要花费也是大多数人能想到的常规做法。为什么么让 大伙现有的hbase rowKey设计,也是每个维度的统计数据对应另另一一三个rowKey的,为了兼容现有的设计,前要在写hbase以前sum一下。

人事已尽,接下来统统关二爷的事了( ̄∇ ̄)。双十一零点倒计时刚开始,大屏数字刚开始飙升起来,随之同去的,还有我的肾上腺素。再看看数据曲线,延迟正常,流量峰值达日常的10倍。确实结果完前要在预期之内的,可能从最后一次的压测表现来看,100W的输入峰值(日常的333倍),5W的输出峰值(日常的100倍),都能稳稳的扛下来。出于数(懒)据(癌)安(晚)全(期)的宽度考虑,统统大屏和数据曲线的截图就不放出来了。

确实现在回过头再看,此时的内心是平静如水的。前要大获全胜后的傲娇,也前要退隐山林的怯懦。统统看待现象的心态变了。这么翻不过的山,这么迈不过的坎。遇事不急躁,走好当下的每一步就好,也何必 思考是对是错,可能每一步都算数,最后总能到达终点。

学习最好的最好的方式决定了我做哪些事,都可能一次成功。甚至有统统请况,我明知道另另一一三个做是错的,但我统统想弄明白为哪些行不通,而故意去踩你这种坑。不过也正是可能试了统统错,踩了统统坑,才捞出了更多的有价值的知识点,扩大了知识的边界。

数据倾斜确实有统统解法,这里我不展开讨论,只讲大伙你这种案例的解法。

倾斜的意味,无非统统group by的字段再次时不时出现了热点,少量的消息都集中在了该字段少数几条取值上。通常的解法是,在消息中选择具备唯一性,可能预估会分布比较均匀的字段。可能你这种字段是整型的,可不前要直接取模(模数一般是节点的并发数),可能是字符串,可不前要先进行哈希计算,再取模,得到另另一一三个分片地址(本文取名为bucket_id)。在接下来的所有aggregate算子中,前要把他作为group by的key之一。

先说一下相关背景吧,笔者作为另另一一三个刚入职阿里的小白,还存在水土不服的阶段,就被临危受命,改造数据大屏。为哪些说临危受命呢,首先是此时距双十一仅剩另另一一三个月,再者,去年的双十一,你这种大屏刚过零点就再次时不时出现现象,数据一动不动,几条小时后刚开始恢复,但仍然延迟严重。此前,笔者仅有的实时计算开发经验是storm,用的是stream API,对于blink你这种sql式的API删改没接触过。接到你这种需求的以前,脑子里是懵的,灵魂三问来了,我是谁?我即将经历哪些?我会死得有多惨?前要“此时此刻,非我莫属”的价值观唤醒了我,是老大的得话,在阿里,前要先让老板我能 资源,你再证明你当时人,而有你在先证明你当时人,再用结果赢得资源,一席话如醍醐灌顶。为什么么让 就刚开始了一段有趣的故事~

要找性能现象出在哪儿,最好的最好的最好的方式统统压测。这里默认大伙都对节点反压有一定的了解,不了解的请先移步典型的节点反压案例及解法。

此时无声胜有声,送上几句名言,与诸君共勉

塞翁失马,焉知非福。---淮南子·人间训

一切过往,皆为序章。---阿里巴巴·行癫

学习就像跑步一样,每一步都算数。---百阿·南秋

一刚开始是跟着大部队进行压测的,压测的结果是不通过!!!同去参加压测的有三十多个项目组,就我被点名。双十一演练的初夜,就另另一一三个伤心地流走了(╯°□°)╯︵ ┻━┻。西湖的水,前我想要 的泪啊。不过痛定思痛,我也是通过这次压测终于定位到了瓶颈在哪里。

另另一一三个一来,API也前要改造了,读的以前采用scan模式,把所有分片都读出来,为什么么让 求和,要花费把sum的工作转移到API端了。

另另一一三个做的好存在于,一方面可不前要转移一要素计算压力,当时人面,可能rowKey只另另一一三个多,而大伙写rowKey的任务(即sink节点)并发数可能有多个,Java开发者应该都深有体会,多线程 并发对另另一一三个变量进行累加的以前,是前要加锁和释放锁的,会有性能损耗,可不前要猜测,hbase的写瓶颈就在于此。随后的事实也证明,你这种做法将输出RPS提升了不止另另一一三个另另一一三个档次。

概念有了一定的认知,下面就刚开始实践了。整个实践的过程,确实统统在不断的试错。我是一刚开始连反压的概念前要知道的,时不时在无脑的调大CU,调大内存,调高并发数,调整每另另一一三个节点之间的并发数比例。寄希望于另另一一三个能除理现象,结果当然是无论我为什么么调,吞吐量前要都风雨不动安如山。现在想想还是太年轻呀,可能另另一一三个简单的做法能除理现象,那那个前辈就绝对不想搞砸了,还轮的到我今天来除理。随后也是在无尽的绝望中想通了,能要能 再这么无脑了,我我想要 找许多最好的最好的方式。想到的统统在代码层面动刀子,当然试错的基本路线这么动摇,前面也提到过,我一刚开始是想到的“加盐”,也是在试错。

笔者写文章习惯带许多有故事趣味性的章节在后面 ,可能我确实纯讲技术,即使是技术人看起来也会相当乏味,再者纯讲技术的前提是作者具备真正透进骨髓去讲述的功底,笔者自认为还相差甚远,能要能要能 加点鱼目来混珠了。换个宽度来看,纯技术性的文章,观赏性和权威性更强,每一句前要精华,你这种咀嚼后的知识虽有营养饱满,为什么么让 前要这么容易消化,消化可不前要吸收几条,还有待确认。统统我力求展示我的咀嚼过程,更多是面向跟我一样的小白用户,可能确实冗长,请各位读者姥爷见谅~

为什么么让 笔者当时突发奇想,偏偏要反其道而行之,我能 不sum,对于rowKey,我也给它分个片,统统在另另一一三个rowKey的基础上,后面 再追加另另一一三个bucket_id。就要花费另另一一三个写到另另一一三个rowKey上的数据,现在把大伙分散写到6另另一一三个分片上了。

具体实现代码如下:

本文作者:王科,花名伏难,先后经历国内三大电商平台,苏宁,京东,阿里,电商大战宽度参与者。现任职阿里巴巴供应链事业部,从事业务平台化改造、实时计算相关工作。信奉技术自由平等,希望通过简单形象的语言,打破上层建筑构建的知识壁垒,让天下这么难做的技术。

大伙group by的典型场景有

hbase写瓶颈

当时我在调大source分片数,为什么么让 也无脑调大了各个算子的资源以前,发现输出RPS还是上不去,sink节点也再次时不时出现了消息积压。当时就判断,hbase有写瓶颈,你这种我是无能为力了。随后的事实证明我错了,hbase的确有写瓶颈,但意味是大伙写的姿势不对。至于该换哪些姿势,请继续看下去。

事实上,我一刚开始想到的是用下面tips里的最好的最好的方式,结果就杵进垃圾堆里了,性能现象是解了,为什么么让 计算出来的数据都翻倍了,明显是错的。至于我是为什么么发现你这种现象,并分析其意味,再换了解法,又是另一段故事了。可不前要提前预告一下,是踩了blink退还计算的坑,后面 会再出另另一一三个专题来讲述你这种故事哒~

总结下来统统,按卖家维度,行业维度哪些的,都非常容易再次时不时出现数据倾斜。