看大佬,人美技术牛! ( •̀ ω •́ )✧
二、实时数仓基本架构
以下是菜鸟作为物流扛把子,它对于数据的需求,主要有以下四点:
实时的数据,它存在的计算难点如下。我们知道,实时消息存在很多不可确定性,例如社交媒体,可能一个爆点,就会带来数据的流量峰值;而且有的消息也会存在迟到的情况,大佬今天主要分享的就是对未到达消息的处理。
Flink 将动态的消息转化为动态的表,对于表的操作就是 Continuous Query ,理解为对一张张静态的表的处理。Flink 从框架的精妙的设计,都在追求高吞吐和低延迟的平衡。 对未到达的消息,可以用CEP和TimeService这些功能API进行处理。
以下是菜鸟的实时数仓架构:
实时计算:两层分层计算,相对离线层次较少,主要是基于实时计算的低延迟的考虑,层次越少越好,以降低延迟。
数据存储:NoSQL 非关系型数据库 + ALOP 面向在线分析型数据库
数据服务:主要是屏蔽掉物理数据库查询的语法差异,数据库的设置差异,直接提供查询接口
明细层:主要是耦合各个业务系统/模块,多流Join 将已经解耦的各个模块再耦合在一起,再通过关联静态维表来补充属性字段。
汇总层:尽量减轻OLAP存储的压力
三、难题:实时超时统计
菜鸟刚开始的解决方案,但是存在以下的缺点:
很明显,这个方案是不可行的,需要在Flink就解决问题。
四、解决方案
双流Join的原理,人为制造出超时消息,让它去触发它对左流原始消息流的查询,再触发它的计算。
完全基于Flink,用三个Job就可以解决问题,得用到Flink最底层的API TimeService .全局定时器,这是一个比较完美的方案。
类似时间序列的正则匹配
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**