蘑菇街实时计算平台-起源篇

今日正在我默默工作时，HR小姐姐突然找到我了，让我把《实时计算平台》搬到内网，好吧，谁让HR小姐姐太漂亮了呢，只能恭敬不如从命了，既然公司内网都已经发布了，那这里也搬一次吧。

想着想着思绪又回到了一年半前~~~，大约是2018年的12月份

数仓的申X 同学兴奋的跑过来：我这边有个需求，要用到实时计算，你们帮忙写一下

我们：哦，这个需求么，要写2周吧，

申X：WHAT？这么点破需求，你要写2周？

我们：咋的？不服你来写？

申X瞬间认怂：好吧好吧，2周就2周吧

旁白：这个真的不怪我们，当时实时计算这边只支持Strom, 用过的同学都应该知道，他只做了数据流转，至于窗口定义，数据统计，过期处理，他什么都没做，都需要开发人员编写代码去搞定，而且写完还要到线上环境去测试，2周真的算常规时间了

申X同学心里怨气不平，跑过来说：能不能弄个跟离线平台一样的东西，我们写SQL就能搞定一切，也不用你们出马了

我们：嗯，行吧，听起来应该不难实现。。。帮你们弄个吧，也省的你们再来烦我们（当年还是太年轻，后来才知道申X同学的BT）

之后调研了一下，业界的实时计算框架，除了第一代的实时计算引擎Storm, 第二代的实时计算引擎Flink, 也开始慢慢流行，我们对比了一下

Storm：
1.只提供最基本的数据流转能力，通过基本Spout和Bolt 进行数据处理和输出，
2.只支持 at last once 语义，对窗口处理能力较弱，
3.对SQL支持不友好（目前只有华为提供了一种类SQL模式），
4.需要自行进行数据限流，数据量过大会导致集群不稳定。
5.任务崩溃后无法自动恢复, 数据也会丢失

Flink：
1.支持 exactly once 语义，具有窗口处理能力，
2.支持SQL意义，
3.通过反压机制自动进行输入限流
4.高可用可基于checkpiont, savepiont恢复任务,
5.Flink也可以方便地和Hadoop生态圈中其他项目集成，可运行在Hadoop YARN上
6.Flink当时最新的版本是Flink-1.7，由于发展时日尚短，他存在一些BUG和功能不全的情况

果然第二代的实时引擎就是比第一代要强一些，那底层就用他了，上面搭建一个平台，提供给数仓他们写SQL，看上去好像还行，嗯，就这么办了，顺手划了一下架构图

嗯，就这么招吧，Coding…Coding…Coding… 好啦上线了，

我们：你们数仓自己玩去吧

申X: ok, ok 我们来了。。。然后兴奋的开始了SQL编码工作

申X: 咦？不对阿，时间窗口输出怎么差了8个小时？

我们：哦，这个是因为flink当时设计的时候，根本没考虑过中国时区，你把结果时间修正8小时就行了，

申X: 不对，这个结果时间不对…

我们：都说了是时区问题，现在没有解决方案

申X: 不对，这个结果时间不对…

我们：你自己去看看阿X云，他们也是加个UDF，修正了8小时，整个业界都是这样玩的

申X: 不对，这个结果时间不对…

我们：#￥%……%*#（！&& 滚！！！

旁边：好吧其实我们认为他说的也有道理，不过Flink发展历史比较短，有些问题也是在所难免，虽然业界都是通过UDF修正了结果时间，但是确实不够优雅

回来默默的翻起了Flink源码，看了半天，发现了原因：Flink依赖了SQL解析引擎 Calcite，由于Calcite中对时区的处理不够完美，所以导致了中国时区会出现这个问题，因为这个并不属于Flink的代码，所以这个问题也迟迟没有修复。好吧，官方没修自己来吧，修改的主要类和方法如下：

嗯，好了解决战斗。。。

我们：好了吧？

申X：嗯，好了好了，继续开心的编写SQL

申X：咦？为什么按天窗口的时间是一天的8点到第二天的8点？不应该是0点到0点吗？

我们：。。。这个也是中国时区问题，

申X：按天窗口时间不对。。。

我们：。。。整个业界都这样的，不信你去看阿X云。

申X：按天窗口时间不对。。。

我们：&￥&%&@#（￥！#。好吧，你赢了，，等着。。。

又把Flink-1.7的源码拿出来，看了一遍，问题主要在于创建窗口时间对开始时间和结束时间的规整问题，这个问题如果在美国时区也不会出现，没办法，谁让时间戳0在中国时区就是 1970-01-01 08:00:00，这样一个8点的数字呢。。来把baby，改源码就是了，下图是改的主要类和方法

我们：好了吧？

申X：嗯好了，好了，继续开心的写SQL

申X：对了，我想维表JOIN，怎么玩？

我们：对于flink-sql的维表JOIN的问题，社区的呼声也比较高，目前官方已经考虑开发了

申X：啥时候能有？

我们：大概要1到2年之后吧。

申X：不行，我现在就要用

我们：大哥，讲点道理好吗？

申X：直播业务有需求！

我们：（连尚方宝剑’直播’都拿出来了）那我们讨论下你的的维表是啥维表

申X：Raptor维表和 Tesla维表（备注：Raptor是我们公司自研的分布式数据库中间件类似与阿里的TDDL, Tesla是我们公司自研的RPC框架类似于阿里的HSF）

我们：#@*#￥&￥%&！滚！！！

没办法这家伙把 [尚方宝剑’直播’] 都拿出来了，我们还是屈服了，最终选定了方案，通过对原始SQL重组，来满足此需求
1.将原始SQL解析，抽离维表
2.原始表上追加维表信息
3.将拆解后的sql重组，再执行，但是保证结果上的一致性
4.加载维表信息采用异步IO，保证加载维表信息时，主处理流程速度不受影响，提高执行效率
下面举个例子吧，加粗的就是维表，原始SQL
select t.old, t.class from
(select t1.old as old, t2.class as class from table1 as t1 left join sideTable as t2 on t1.name = t2.nm where t1.old < 10) as t

拆解后的执行顺序
1.[SourceTable] table1 add fields: class as class by [SideTable] sideTable

2.flink_auto_named_table1: SELECT t1.old AS old, t1.class AS class
FROM table1 AS t1
WHERE t1.old < 10

3.flink_auto_named_table2: SELECT t.old, t.class
FROM flink_auto_named_table1 AS t

我们：好了好了，维表JOIN也有了，自己玩去吧

申X：嗯嗯嗯。。。

申X：对了flink-sql我想控制输出频率怎么办？

我们：调整窗口大小，当数据打到窗口end边缘时，会触发计算

申X：窗口大小不能动，我就是要控制输出频率！

我们：目前flink-sql不支持自定义触发器语义，无法实现

申X：你别骗我，我可是看了阿X云，他上面flink-sql支持自定义触发器的

我们：阿X云用的是Blink，是他们在Flink原版上改出来的一个版本，原版的Flink不支持

申X：不行，他们有的我都要，那什么直播…

我们：停停停停停，你是老大，你说啥就是啥，好了吧

他们又要拿尚方宝剑了，怎么办，Blink这玩意也没开源阿，不知道他怎么实现的阿，算了无所谓了，我们自己看着来了，功能上实现就行了，为了保证兼容性，我们设计的追加的SQL 从语法上跟阿X云一致（万一哪天Blink也开源了呢？），追加了新的SQL语义：EMIT WITH DELAY ‘1’ MINUTE，用于控制窗口的计算输出频率，涉及到的主要类和方法如下：

我们：好了好了，自定义触发器语义也有了，想怎么触发就怎么触发去了

申X：好来好来。。。

申X：咦，这个SQL的输出结果好像不对，哪里写错了？

我们：呵呵（一脸鄙视），拿来看看。。。

我们：卧槽，2000多行的SQL？？？？？

申X：嗯，哪里的逻辑有问题？

我们：爱哪！哪！！！不！知！道！

申X：哪里的逻辑有问题？

我们：这样吧，我们给你做一个数据DEBUG功能，对于复杂的嵌套SQL，输出每一层的数据结果，这样你就可以根据每一层的结果来判定到底是哪一层的逻辑有问题了

说干就干，主要的做法如下
1.将原始SQL拆分，拆层一层一层的基本SQL
2.开启DEBUG模式后，会对每一层的SQL结果做输出，
3.开启DEBUG模式后，自定义UDF里加锚点输出处理结果数据
下面是一个示意图

我们：可以了吧？

申X：嗯，嗯，剩下的交给我们吧。

申X：我的任务正常吗？

我们：？自己看阿！

申X：怎么看？

我们：。。。让我头疼一会

好吧，我们给你做一个完整的任务状态的监控页面，自己慢慢看去吧

我们：完美了吧？

申X：嗯，完美，完美

申X：咦，任务好像出问题了

我们：哦，看日志去

申X：怎么看？

我们：好吧，当我没说，给你弄个页面，只查看最近7天的日志可以了吧？

申X：不行，我可能要看几个月之前的日志

我们：…日志硬盘上只保留7天。。。。

申X：不行，我可能要看几个月之前的日志

我们：￥#%@￥！￥%

好吧，这个BT的需求怎么整呢？这时候我突然想起来了我之前写的一个大数据存储引擎-bigstore，这玩意速度块，压缩比高，占用硬盘小，节省机器，支持水平扩展，支持主从同步，还申请了专利，公司也奖励了2000块钱（这里纯属王婆卖瓜自卖自夸），嗯对了，就用这个吧。Flink用的日志框架是log4j，为了实现这个功能，要扩展他的log4j的日志模块，也就是重写LogAppender，当产生日志时，一份落盘写硬盘，一份上报大数据存储引擎-bigstore

然后再配上界面，提供检索，下载等功能

我们：OK了？

申X：OK，OK

而我们：随时待命着~~~

以上故事情节，来源于生活，却又高于生活，如有雷同，纯属巧合，概不负责

分享PPT也上传到我的资源里了，有兴趣的可以下载看看

蘑菇街实时计算平台-起源篇相关推荐

Flink从入门到精通100篇（二十三）-基于Apache Flink的爱奇艺实时计算平台建设实践
前言随着大数据的快速发展,行业大数据服务越来越重要.同时,对大数据实时计算的要求也越来越高.今天会和大家分享下爱奇艺基于Apache Flink的实时计算平台建设实践. 今天的介绍会围绕下面三点展开 ...
flink sql udf jar包_flink教程flink 1.11 集成zeppelin实现简易实时计算平台
背景 zeppelin不提供per job模式实时平台开发周期长基于zeppelin开发一个简易实时平台开发zeppelin Interpreter 提交sql任务提交jar任务背景随着f ...
2021年网易云音乐实时计算平台发展和挑战
网易云音乐从2018年开始搭建实时计算平台,经过几年的发展已经渗透到云音乐的各个业务当中.本文是大愚老师的一篇实践分享,将从一个日常运维问题出发,带领大家了解云音乐实时计算平台的一些工作进展和未来规划 ...
马蜂窝实时计算平台演进之路
MES 是马蜂窝统一实时计算平台,为各条业务线提供稳定.高效的实时数据计算和查询服务.在整体设计方面,MES 借鉴了 Lambda 架构的思想.本篇文章,我们将从四个方面了解 MES: 1. 关于 L ...
【硬刚大数据】Flink在实时在实时计算平台和实时数仓中的企业级应用小结
欢迎关注博客主页:https://blog.csdn.net/u013411339 欢迎点赞.收藏.留言 ,欢迎留言交流! 本文由[王知无]原创,首发于 CSDN博客! 本文首发CSDN论坛,未经过官 ...
基于Apache Flink的爱奇艺实时计算平台建设实践
导读:随着大数据的快速发展,行业大数据服务越来越重要.同时,对大数据实时计算的要求也越来越高.今天会和大家分享下爱奇艺基于Apache Flink的实时计算平台建设实践. 今天的介绍会围绕下面三点展开 ...
SLA 99.99%以上！饿了么实时计算平台3年演进历程
来自:DBAplus社群作者介绍倪增光,饿了么BDI-大数据平台研发高级技术经理,曾先后就职于PPTV.唯品会.15年加入饿了么,组建数据架构team,整体负责离线平台.实时平台.平台工具的开发和 ...
唯品会实时计算平台的演进之路
来自:DBAplus社群本文根据王新春老师在[2018 DAMS中国数据资产管理峰会]现场演讲内容整理而成. 讲师介绍王新春,唯品会高级经理.数据平台实时团队高级架构师,主要负责实时计算平台.实时 ...
克拉克拉(KilaKila)：大规模实时计算平台架构实战
克拉克拉(KilaKila):大规模实时计算平台架构实战一.产品背景: 克拉克拉(KilaKila)是国内专注二次元.主打年轻用户的娱乐互动内容社区软件.KilaKila推出互动语音直播.短视频配音 ...

蘑菇街实时计算平台-起源篇

蘑菇街实时计算平台-起源篇

蘑菇街实时计算平台-起源篇相关推荐

最新文章

热门文章