共计 4656 个字符，预计需要花费 12 分钟才能阅读完成。
本文由天猫数据负责人黄晓锋分享，次要介绍流批一体技术在天猫双 11 的利用。纲要如下：
1、流批一体架构
2、天猫双 11 实际
3、将来布局
一、流批一体架构
本文次要跟大家分享流批一体化的相干技术在天猫的利用。此前，在较长的工夫里 Lambda 架构根本能满足业务诉求。但当业务倒退到肯定阶段后，在数据品质、研发效力、稳定性上产生了局部新诉求，须要通过流批一体技术计划来解决。
往年 7 月份，咱们开始进行流批一体化的尝试，而后双 11 全副利用上线了，以后流批一体架构体现十分稳固。
1. 传统数仓架构（Lambda）
下图为传统的 Lambda 架构，包含业务层、存储层、计算层、服务层和应用层。传统的架构很灵便，流和批之间没有互相耦合，然而也会带来几个问题。
效率层面。流批底层数据模型不统一，导致应用层须要做大量的拼接逻辑（同比、环比、二次加工等），搭建效率低，且容易出错。
老本层面。流批存储系统隔离（面向不同写入场景），提供的数据服务不统一，保护老本高。同时，手工创立数据同步工作，减少了开发成本和存储老本。
品质与资源层面。首先，一个业务逻辑，两个引擎两套代码，SQL 逻辑不能复用，数据一致性和品质难以保障。其次，不同平台和引擎间切换，开发体验割裂，容易呈现变更脱漏。并且，批处理 & 流解决集群无奈做到错峰，资源利用率较低。
2. 流批一体架构（Kappa+Lambda）
基于 Lambda 架构的痛点，咱们设计了流批一体的新架构。如下图所示，流批一体的架构并不是替换原来的 Lambda 架构，它是 Kappa 和 Lambda 联合的架构。批处理和批存储仍然存在，实质上是在流的场景中寻找批场景。
● 流批逻辑层，这是最重要的局部之一。业务层和存储层依然不变，在此之上构建一个流批逻辑层来进行流存储和批存储的映射。有了这个逻辑层，就能够基于 Flink 引擎面向对立的逻辑层做业务逻辑表白，并且输入是对立的。
● 计算层，做流批对立解决。首先，一套代码，两种计算模式，逻辑对立，灵便切换，能够实现研发效率大幅晋升。其次，流批计算资源混部，资源利用率晋升。
● 服务层，做流批对立存储，无需手工同步，无反复存储。
● 应用层，进行产品组装，流批存储透明化，查问逻辑完全一致，利用端接入老本大幅升高，点查 / OLAP 剖析对立反对。
3. 流批逻辑层示例
这外面最外围的关键在于流批的逻辑层，如下图所示，是流批逻辑层示例。
在此列举外部的一张逻辑镜像表的例子。右边是 MaxCompute 表，及其表名和 schema。左边是 DataHub 的表，也有其表名和 schema。平台的次要性能在于把两个表名的字段进行镜像化、映射。比方，右边有 100 个字段，左边有 50 个字段，他们的交加可能是 30 个字段，而后将 30 个字段进行镜像化，并将其关联关系映射到一张逻辑镜像表下面去。平台还提供了智能映射，当字段名称、类型一样时，能够主动判断做映射。当然，也能够做一个人工的辅助映射。如此，流批一体的 Flink 工作就能够进行业务表白了。
4. 典型流批模式举例
以下将分享咱们外部反对的一个典型的流批模式。比方 Kafka 的流表，同时也有盘古的 MaxCompute 表，通过下面的模式映射到流批逻辑表。两头须要编写一个 SQL 业务逻辑的表白。业务逻辑的表白与流批是没有关系的，它只是表白了整个计算的逻辑。在计算逻辑之上，有纯流模式的配置，如流模式的并行度、所在的集群等，这些信息都是流模式相干的。
同时在下面也能够进行一个批模式的撰写，批模式更多依赖调度，是纯批模式，同时也会进行批的参数优化。这样的话，同一套 SQL 就面向两套配置了，而且两套配置能够同时开启。也就是说，这外面有三种模式，包含纯流模式、纯批模式、流批混合的模式。联合业务场景，能够进行灵便的切换。纯流模式能够间接写当天的分区，批的模式能够写历史分区。这种状况下，流和批之间的代码和业务逻辑齐全能够做到统一。同时在对立的模型汇总表中还能够做对立的存储，应用层搭建仅需关怀报表的表白逻辑即可。
5. 新老研发模式比对
上面是对新老研发模式的一个比对。
● 第一个场景，批工作周期调度 ，流批工作因为输出源汇合不统一会导致差别，须要批工作周期调度勘误流输入后果。老模式的批处理工作须要在 MaxCompute、Hive、Spark 等解决零碎编写一套代码，而流是在 Flink 上编写，导致两套代码。在新的模式下面，齐全能够做到一套代码。Flink Batch 工作每天周期调度勘误流产生的历史数据。劣势是解决逻辑统一，一套代码实现流和批的调度，研发效率晋升一倍。
● 第二个场景，批工作按需调度（回刷场景），流批工作计算结果完全一致，不须要批工作周期调度勘误。老的模式还是不变，在新的模式下，Flink Batch 工作每天空跑调度，当呈现口径变更时再启动手工工作。长处是解决逻辑统一、研发效率晋升一倍、批空跑调度， 计算资源节俭 50%。
6.Dataphin“流批一体”：新一代数据处理框架
Dataphin 是一个智能数据构建和治理的平台，明天次要分享平台中跟流批一体相干的性能。
首先，提供全面的数据源治理，把数据源的信息接到 Dataphin 中做对立的数据源治理。同时，也提供惯例的数据集成的形式，离线实时都反对，而后把在线的数据导入数仓的数据系统外面去。
基于这两个点，咱们在 Dataphin 研发和运维下面做了一些性能的迭代。这一套性能在以前都是基于 Flink Stream 去构建的，当初有了流批的对立逻辑层，所有的性能能够复用到批的场景上。平台提供的十分残缺的一套数据中台的根底性能，都能够被流批一体架构应用。如图所示，右边会翻译成流计算，进行实时写入。左边会翻译成批计算，进行离线周期的调度，而后将二者放到对立的存储层。有了对立的存储层，就能够面向不同的场景了。
二、天猫双 11 实际
1. 双 11：“营销流动剖析”外围挑战
上面讲一下天猫双 11 的实际，首先跟大家介绍一下营销流动剖析外围的挑战。
● 第一，高时效性。多维度数据分析体系，业务诉求全面实时化。
● 第二，高准确度。大量同比和环比场景，实时和离线数据口径须要完全一致。
● 第三，高稳定性。洪峰和海量数据挑战，高 SLA 要求，双链路保障。
● 第四，高灵便度。流动周期跨天累计，实时多维度排行拆解。
2. 业务流批架构
上面的数据采集还是以前的 Lambda 架构。流的模式有相应的分层，批的模式也有相应的分层，这一套模式是咱们以前惯例用的模式。在这套模式之上，有大量的明细数据，咱们会在明细数据下面构建流批的逻辑层。有了这个逻辑层能够进行对立维度的形象。比如说，天猫这边有很多大盘，再从大盘下面拆解到行业下面。还有很多业务下面的一些维度，就不开展去讲了。
咱们再往上来看具体的一些维度的对立逻辑层的设计。
如下图所示，这里举了几个数据，有流量、交易、加购、预售等，是对后面流批一体的架构的细化。比如说，从流量的角度，有两张表，一张是整体的商品 pv 表，一张是整体商品的疏导 pv 表。每一个数据都会有自身数据的最明细数据，还有自身数据的疏导数据。在这个根底上，咱们做了一个镜像表的映射，流的流量表也会跟批的流量表进行一个字段的映射，做成对立的模型层。有了模型层之后，能够进行很多面向业务场景的尝试。咱们须要看每一个行业上的实时数据，还须要跟历史数据进行比照。整套体系就是天猫惯例的大促外面的一些剖析体系了。
在双 11 降临之前，大家能够看到预售的数据，预售的过程中，还有预热的数据，比方加购、珍藏。再到正式期的领取、红包、券等。面向整个营销流动剖析体系进行数据的建设，这外面所有流批一体的数据都会放到 Hologres。Hologres 提供两个能力，一个是点查能力，另一个是 OLAP 的剖析能力。最上层是通过 Quick BI 的数据展现层。因为有了对立的 Hologres 存储，Quick BI 就能够做很多货色。咱们常常有一些同比、趋势图、柱状图等，咱们在 Quick BI 下面能够构建面向 BI 场景的一些组件。
3. 挑战
这里次要讲三个挑战。
■ 挑战一：流批资源错峰应用
第一个既是机会也是挑战，错峰。同一个引擎上，流和批人造是在同一个集群或同一批集群中运行。如下图所示，天猫的业务在流解决上，流数据来自于在线零碎，0~8 点是非常低的。批处理局部，集群水位由周期调度决定，0~8 点属于高峰期。这刚好是错峰的场景。咱们外部进步集群资源利用率的路径有两个：
● 在线离线混布。比如说 Flink 和 MaxCompute，流和批的零碎进行混布，通过对立调度形式，能够达到比拟高的资源利用率。
● 通过同一个引擎，流批引擎对立。
同时，也会带来一个问题，尽管资源利用率高，但在资源隔离下面会有比拟多的挑战。所以咱们还做了集群 CPU 物理水位的管制，防止单集群 CPU 的水位达到 70% 以上。当 CPU 的水位 70% 以上时，对在线的实时计算的业务会产生比拟大的影响。另外，咱们还做了集群的优先级划分，按优先级做集群负载平衡。通过以上两点，能够防止离线影响在线。
■ 挑战二：批实例数据写入
第二个挑战是批实例的数据写入形式。
● 计划一，间接写正式表对应分区。它带来两个弊病，一是写过程对线上不通明，造成秒级或分钟级影响。二是流批主键值个数不一样，存在脏数据。
● 计划二，写长期表，Sink 完结后，Rename 成正式分区表。Rename 过程的示意代码如下图所示。这种计划的长处是，写过程不影响线上，Rename 过程毫秒级。
■ 挑战三：分钟 / 小时累计指标
举例说明，在天猫营销流动剖析中，BI 产品很多是看分钟的趋势图和小时的趋势图。以前咱们在流外面的实现的形式，对累计指标取分钟快照，存在三个弊病：
● 第一，雷同逻辑，批模式只输入 1 条数据，流批后果不统一。
● 第二，追历史数据状况下，分钟趋势图不残缺。
● 第三，严格意义上，趋势图不精确，数据归属分钟谬误。
引入了流批一体技术之后，因为流批要统一，咱们须要采纳另外一种形式，计算分成 4 步：
● 第一步，首次购买工夫。
● 第二步，分钟增量买家数。
● 第三步，分钟累计买家数。
● 第四步，分钟数据开展。
这种形式有三个长处：
● 第一，流批两种执行，后果完全一致。
● 第二，追历史数据状况下，后果完全一致。
● 第三，趋势图和业务体现完全一致。
咱们看一下最终在天猫的业务成果，与最后流批一体架构想达到的目标是完全一致的。
● 在时效性上，面对 583000 笔 / 秒的交易峰值，上亿 / 秒的无线流量洪流，所有工作秒级延时，峰值 TPS 达 40 亿条 / 秒。批工作错峰执行，机器资源利用率大幅晋升，单任务解决数据量超千亿，重要基线提前 4 小时产出。
● 在准确性上，流批工作的业务口径完全一致，0 数据品质问题，成为大促期间重要的业务雷达。流批模型齐全对立，产品搭建效率晋升 400%，丰盛了数据展现模式。
● 在灵活性上，只须要一套代码，需要迭代效率晋升 2 倍，大促当天紧急需要承接效率晋升 5 倍。实时数仓与 OLAP 场景联合，变更老本大幅降落，满足分析师按需取数的场景。
三、将来布局
最初讲一下将来的一个布局。现阶段，从数据架构上来看，咱们实现了计算层面的流批对立。通过逻辑表、镜像表做异构存储之间的 schema 的对立。下一个阶段，应该是计算和存储相加的对立，才是真正的流批一体。
所以在整个平台建设上，咱们会寻找能够做到流批对立的存储系统，进行整个解决方案的构建。同时，流批一体在大规模应用后，产生了局部新的需要，批计算稳定性已达标，四周的工具仍须要花精力构建和投入，如此才能够达到真正更好的生产成果。咱们也会投入精力与计算平台技术团队一起单干，也借助社区的力量，共建流批一体架构。
