从0到1搭建电商营销数据分析平台(三)——数仓新老架构

欢迎关注公众号——《数据三分钟》

一线大厂的师兄师姐结合自己的工作实践，将数据知识浅显道来，每天三分钟，助你成为数据达人。还有面试指导和内推机会。

​

01 why

一个扩展性强，灵活性高的营销数据分析平台必然离不开科学的数据分层架构，数据在数仓中经过层层清洗梳理转换，最后在应用层支撑整个产品的数据服务。那么对于一个实时性要求很强的产品，它的数据分层应该是怎样的呢？实时数仓和离线数仓如何巧妙的结合实现各个域数据的一致性，这是构建电商营销数据分析平台不得不思考的一个问题。

# 插一段历史

汉武帝刘彻年幼时，其姑姑馆陶公主刘嫖逗着他玩，指着一众宫女说要许给刘彻做媳妇，刘彻都是摇头拒绝，当刘嫖指着自己的女儿阿娇问刘彻时，刘彻回答：“若娶阿娇为妻，当铸金屋以藏之。”这就是金屋藏娇的由来。

02 传统LAMDA架构

传统的LAMDA架构可以很好的拼接实时数仓和离线数仓，实时离线的计算分在两个不同的链路，互不干扰，在产品端的展现是既有实时数据快速呈现能力，又有离线数据的精准修正能力。

在实时链路中，所有的数据存储介质都是消息中间件，因此实时数仓各分层之间的关系几乎都是读消息队列写消息队列。

实时数据链路中源头及中间层的处理结果都存储在消息队列中，结果一般存储在适合快速写入的存储中。但是这种LAMDA架构也会存在问题，那就是实时离线对源头数据分别拉取和存储，容易在存储层就出现数据不一致的现象，所以一般LAMDA架构可以稍作调整，这样可以有效屏蔽上述架构带来的潜在问题，一般可以改进如下：

这样的改动，离线数仓链路不在单独从业务层捞取数据，而是将实时的源头消息队列数据回流到离线存储中，构成离线数据的源头数据，也就是说在源头存储层，实时和离线的数据是一致的，也是从这一层，实时和离线的处理链路才开始分岔。

03 流批一体架构

但是传统的LAMADA架构不可避免的使用了两套计算引擎，其计算原理，代码语义都天然存在差异，这给开发带来极大的成本——不得不开发和维护两套代码，开发效率低。与此同时，两套不同的存储在产品搭建时要进行数据拼接，这给报表的搭建增添了不少难度，有没有一种更为简洁优美的架构可以支持电商营销数据分析呢，那就是下一代流批一体架构（KAPPA架构）了。

FLINK是一个支持流批计算的引擎，它的设计思想里把批的计算模式看作流的一种特例（流是无界数据流，批是有界数据流，因此有界是无界的一种特例）。这种架构的好处也是显而易见，它可以真正实现一套代码，两种计算模式，实时离线计算逻辑统一，运行模式可以灵活切换，数据研发效率大幅提高。

 

当然流批一体的实现，首先必然离不开FLINK引擎，同时流批数据统一层也是必不可少的，因为实时离线模式摄入的数据源头是不一样的。实时模式消费的是流式数据，它就像水流一样源源不断的进入引擎，引擎根据时间语义进行聚合等多种计算；而离线模式数据仿佛是一块一块的面包，引擎只要按需将分区摄入计算即可。因此，为了实现代码统一，一套对等的实时离线中间层就不得不设计出来。这样在启动实时或离线模式时，flink引擎可以自动去消费消息队列或者对等的离线表。

 

流批一体架构的好处诸多，可以前所未有的解放研发效能，这也是电商营销分析平台数据准确易维护的有力保证。