从0到1搭建电商营销数据分析平台(五)——流批一体架构

Bertha 。 2022-11-10 14:29 336阅读 0赞

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

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

![20201223224329689.jpg][]

传统的LAMDA架构取得了辉煌的成就，大大小小的公司几乎都以LAMDA为模版构建了自己的数据仓库，但是LAMDA架构的缺陷也一直被数据人诟病——由于实时链路和离线链路采用不同的计算引擎，在数据研发的过程中，不得不开发、维护两套代码，不仅开发成本高，而且得时刻保持口径的一致，不然就会造成严重的数据质量问题。在传统的LAMDA架构中，实时与离线数据，一般由两班人马开发维护，很难保证数据口径、代码逻辑的严格一致，研发效能受到了很大的挑战。而千呼万唤始出来的流批一体技术，从根本上解决了这个问题，实时离线真正意义上合并统一，用一套代码跑出两套数据，最大程度上提高了开发效率。

### **0、插一段历史** ###

汉初，开国大将周勃铲除诸吕之乱，准备新立一个皇帝，选了又选，决定让傻白甜刘恒即位，可谁知刘恒却是个聪明人，正是多年来在吕雉面前装傻卖乖才免于一死，平安在代地做诸侯王。周勃在都城外迎接刘恒时，想套个近乎，提醒一下刘恒自己的功劳，于是对刘恒说想借一步说话，却直接被刘恒怼了回去：“所言公，公言之；所言私，王者无私。”刘恒就是后来的汉文帝，开创了中国历史上第一个盛世——文景之治。

### 1、LAMDA的前世今生 ###

首先介绍一下，为什么会诞生LAMDA架构。在大数据领域，从谷歌的三篇论文：Google FS、MapReduce、BigTable，诞生出了后来的Hadoop，Hadoop是一种批处理框架，简单来说，数据是一批一批处理的。这就会导致一个问题——慢！假设你要分析满300减30的红包对消费者购买成交的拉动效果，结果告诉你数据要一天后才能产出，那么电商决策分析角度来看，显然是不可以接受的。但是批处理也有一个天然的好处——准！因为在批处理的时候，数据都是已经全部ready的，你只需要把数据拉取过来进行shuffle并计算就可以获得最终的结果。所以这里就出现了一个矛盾：你是要准，还是要快？LAMDA架构就是解决这个问题的。

![445d33178f71fdba1d446bf2475f6f64.png][]

上图展示的就是一个经典的LAMDA架构，它的批处理层的基础上增加了一个流处理层。流处理常用的框架有storm、spark、flink等。流处理层的计算延迟很低，譬如flink可以做到毫秒级的延迟，但是快也会带来问题，那就是不准。譬如你计算满300减30的红包对成交的引导效果，而消费者在上午8点使用了这个红包，你将成交数据计算到了结果里面；后来这个消费者有后悔了发起了退货退款，那么数据就要变动了，过了一会，这个消费者又用满300减30的红包重新支付了一笔订单，这一系列的操作都会最终的结果造成影响。而离线的批计算就不存在这个问题，因为计算的数据源头都是订单的最终状态。因此实时和离线的数据一般会存在一定的GAP，但是可接受范围内的GAP并不影响决策分析，因此LAMDA架构即满足了决策分析对时效性的要求，又满足了数据最终状态的准确性要求。

### 2、流批一体架构 ###

LAMDA架构由于是采用两套引擎实现，因此不得不维护两套代码，而且数据口径和代码逻辑语义很难保证强一致性。如何使用一套代码，计算出实时离线两套数据成为了流批一体架构的核心目标。

![a00ae00904c5cf8f1d55ccbc7bd4b25e.png][]

流批一体架构如上图所示，在计算实时数据时，引擎从消息中间件里拉取数据消费计算，同时引擎会用相同的代码周期性调度最终落盘的源头表，计算出最准确的数据（T-1），并用准确的数据覆盖实时数据。

### 3、流批一体的实现 ###

前文所述中，流批一体之所以能够用一套代码计算出实时离线两套数据，有这样几个必不可少的因素：

一、对等中间层

我们知道实时离线消费的源头是不一样的：实时链路的数据源头一般是消息中间件（譬如KAFKA），而离线链路的源头一般是分布式存储中的表，我们假设实时的源头是KAFKA的topic，名字叫source\_table\_ri，而离线的源头是HADOOP中的表sorce\_table\_di，那么为了实现流批一体，source\_table\_ri和source\_table\_di就必须拥有对等的特性。这里的对等包括字段名相同，字段类型相同，记录数在误差范围内相同，然后在开发层面，可以将source\_table\_ri和source\_table\_di用一个逻辑表source\_table进行关系映射，那么计算引擎就可以在计算层根据不同的计算模式拉取相应的数据源头进行计算。

二、支持流批计算的引擎框架

Flink在设计的时候就认为，流是无界数据，批是有界数据，批式数据是流式数据的一种特例。在这样的设计思想驱动下造出来的Flink天然适合做流批一体架构的计算引擎。

三、结果层的统一

这个因素倒不是必备因素，但是却可以给流批一体设计增加更好的简洁美，说白了，不是雪中送炭，而是锦上添花。实时模式下，Flink消费KAFKA中的数据，并写入到有主键更新的结果表中；离线模式下，Flink拉取HADOOP中的表，计算准确结果，并用准确结果去覆盖T-1天实时数据计算的结果。

流批一体技术在天猫双十一中完美landing，收获到诸多好处，不仅解决了LAMDA架构的痛点，也为我们走向新一代的数据架构注入了更多的信心和勇气。

[20201223224329689.jpg]: /images/20221022/9f9ee5122a5242e1adbe4d762c7cf52a.png
[445d33178f71fdba1d446bf2475f6f64.png]: /images/20221022/4850b484ff774665bf1a740cfb0b730a.png
[a00ae00904c5cf8f1d55ccbc7bd4b25e.png]: /images/20221022/3fd9d0205f6a4cbcbab7b628171b2d9e.png