自古典互联网以来,人类就没有停下对数据处理追逐的脚步,并且随着数据量的几何倍数的增加,处理数据的方式以及平台不断的更新迭代,其中以批处理为代表的自然非 Hadoop 家族莫属,后来随着技术的迭代,实时计算变得流行起来,又出现了以 Storm,Flink 为代表的流处理框架,然而我们今天说的是由阿里巴巴将 Flink 框架改进而衍生出来的 Blink 框架。
对于喜欢剁手的妹子来说,每年的双十一都堪比狂欢节,特别是剁完手,对着双十一晚会的 GMV 大屏,看着不断上涨的成交额,心里美滋滋:我也是参与过上千亿的项目的人了。然而,如果她的男朋友恰好是程序猿的话,他眼中看到则是非常典型的实时计算,每条交易数据经过聚合展现在屏幕上。从 DataBase 写入一条数据开始,到数据实时处理写入 HBase,最后展现在大屏之上。
然而,这就引出了一个问题,为什么阿里不直接使用 Flink 框架,而是投入大量的人力去改进,最后研发出 Blink 框架。
首先,要知道,作为 Apache 软件基金会下的顶级项目,Flink 有许多的优点,比如
Flink 很好地引入和设计了 State,基于 State 复杂的逻辑计算如 join 能得到很好的描述
Flink 引入了 Chandy-Lamport 算法,在此算法的支撑下可以完美实现 Exactly-Once,并能在低延迟下实现高吞吐量。
然而,虽然 Flink 在理论模型和架构方面有很多创新,但在 State、Chandy-Lamport 算法等方面还有很多缺陷,特别在工程实现上还有不少问题。尤其是在大规模使用上,要知道,阿里的业务场景极其复杂,很多问题在一般的公司、一般的场景是很难接触到的。
为此,相较于 Flink,Blink 主要解决了大规模部署的问题,这在工程中极为重要,Flink 中一个 Cluster 只有一个 JobMaster 来管理所有的 Job。随着 Job 的不断增加,单一的 Master 无法承接更多的 Job,产生了瓶颈。因此,Blink 重构了架构,使每一个 Job 拥有自己的 Master。
除此之外,Blink 的优点还有以下几点:
Flink 架构升级,插件化原生支持不同调度系统,并实现了原生运行在 Hadoop YARN 上
Failover 稳定性改进,优化了 Task/TaskManager 以及 JobManager 各种组件 Fail 的场景处理
提出并实现了增量式 Checkpoint 的架构,使得 Flink 的 Checkpoint/Recovery 速度大幅提升,成本明显下降
提出并实现了 Async Operator,通过异步方式,让 I/O 密集型计算节点的性能大幅提升
提出了大量 Table API 的全新设计,以及流和批在 SQL 层面的统一概念和方案目前 Blink 已经在阿里巴巴内部达成共识,成为阿里巴巴统一的实时计算引擎,从以往的技术发展规律来看,一项技术是否能有长远的发展,除了技术本身外,还要看在其背后是否有社区以及大企业的支持,可以说这几方面 Blink 已经具备。
如果想对 Blink 有更深入的了解,请关注 2018 年 4 月 23 日至 24 日,我们在北京国际会议中心举办的 QCon 深度培训。在会上,阿里巴巴的高级技术专家王绍翾和邓小勇将为大家带来阿里巴巴 Blink 流计算平台介绍与实践,讲述阿里巴巴在超大规模和复杂实时业务场景下,如何基于 Blink 引擎打造流计算平台,干货满满。现在 报名立享 8 折优惠,点击 “阅读原文” 即可了解更多详情。
想看更多这类文章, 请给我们点个赞吧!