摘要： 本文整理自抖音集团电商数据工程师姚遥老师在 Flink Forward Asia 2024 分论坛中的分享。内容主要分为五个部分：
1、业务和挑战
2、电商流量建模架构
3、电商流量流批一体
4、大流量任务调优
5、总结和展望
01.业务和挑战
第一部分给大家介绍一下流量到底是什么？流量是用户在各个产品当中进行一系列行为活动的数据集合，其数据载点是的买点，买点经过采集分发到达了数仓的建设，再经过数据的归因以及指标的统计会被分别在应用在各个场景当中，分别为用户、主播以及商家带来各自的数据价值。消费者可以买到更好的产品，主播可以根据其带货的实时数据反馈来调整其带货的策略，商家可以根据主播的带货效果去选择跟对应的主播进行合作。
在建设时遇到了不少的问题与挑战，这些问题与挑战可以主要总结为以下三个方面效率、质量、成本以及稳定性。
对于效率，需要同时去支持十多个不同的独立业务并且这些业务由于迭代迅速，可能随时会新增。这就要求数据首先建模规范并且具备一定的灵活性且具备横向的扩展能力。对于质量与成本，其实是在有限的人力以及有限的资源下去达成实时和离线，数据递付率可以保持在千分之一以内。对于稳定性，需要每天去吞吐千亿级的数据并产出分钟级的指标波动的指标趋势同时还要避免对于维表百万级的数据请求的压力。
上述问题分别从三个视角来去解决。
02.电商流量建模架构
这张图是目前抖音电商的流量数据架构图。流量的重点建设核心在于流量公共层数据明细层。对于明细层建设思路主要有两个，其中是横向的根据用户动线进行行为建模，在纵向进行职责分层。对于横向的建模，将数据分成内容互动与搜索域、页面域以及商品交易域。这么分的原因是因为通过的内容互动进行吸引用户搜索，搜索之后页面会进行承接并展示商品。当用户进入商品详情页之后，就会最后达成的交易。
相对来说，数据的建模方式可以让流量数据进行横向解耦避免流量 KPS 过大导致处理的压力，以及同时对应 ODS 数据的各个不同的接入源。
从纵向的视角来看，将数据分层分为了参数解析层、公共扩维层以及主题扩维层。参数解析层主要是负责 ODS 数据的接入以及买点信息的统一规范命名。业务公共扩维层主要负责的是一些公共的逻辑的、维度的信息的扩展以及公共的归因逻辑的实现。对于主题扩维层，更加倾向于将每一个业务主题独立建设。每个业务主题可以独自进行各自的业务扩维以及相应的逻辑运算。一旦出现一个新的业务场景，就可以在业务主题扩维层额外的新增一个主题层，可以敏捷的去支持业务的需求。
上面讲述的建模较为宏观，以商品为例，主要介绍单个数据域里面是怎么建设任务。
首先进建设思路主要有两点：第一点，按计算进行任务的拆分，按存储进行业务的拆分。对于任务来说，着眼于解决提升任务、提升运维以及容灾止损的一个效率。对于业务拆分，更加专注于让数据进行更加细粒度的解耦并且简化业务的逻辑，进而提升开发的敏捷性以及效率。
接下来分别展开到底是怎么做的。对于任务财团来说，主要可以有三点。第一，统一运维、机房混布以及灰度发布。统一运维可以理解为是所有的任务都会将一个任务拆分成多个子任务，但是这些子任务都会由交由统一的副任务进行运维，对任务的进行开发以及上下线的一些工作，全部都交由副任务进行操作，然后所有的子任务都会去消费同一个 Kafka 的 Topic。但是，消费使用了相同的 Group ID 每一个任务的消费的分区并不一致，这样的好好处是所有的任务不会出现重复的运维的成本的问题。第二点，对任务这些子任务的进行不同机房的部署，优势是由于任务的 QPS 大概在在百万级以上，会出现如果所有的任务都部署在单个机房会出现严重的机房压力倾斜问题。在对于这些机房进行一个较为均衡的部署之后，可以实现整体的集群的负载均衡，同时会还可以提升一定的容灾能力。当单个机房出现问题时，首先它不会影响到全局的数据产出只会影响到部分。当异常时可以进行通过副任务一键进行数据迁移避免恢复的效率过慢。第三点是灰度发布，针对灰度发布来主要是应用于增量场景，在一些增量业务迭代时，如果在大 QBS 下单个任务启停会造成短期内的数据尖刺。如果灰度发布以此任务为力度逐个发布，可以避免这种数据监测的问题。
接下来是业务拆分。业务拆分主要是的建设思路是，在数据逻辑上模型是统一的，但是物理存储上会进行隔离。再具体一点来说使用相同的模型的 Schema 的数据由于其应用的场景不同会将其分别存储于不同的 Kafka 的 Topic 当中。根据其应用的稳定保障程度将其进行资产达标。对于核心的场景，会将其相应的任务部署在高优的队列，也会对其进行高敏监控。这样对数据进行更精细化的运维可以大幅的降低运维压力并且它还会有两个优势：可以去简化单个任务的处理逻辑，可以去降低运维成本，并且任务间是独立解耦的可以提升开发的效率。
上述建模解决了效率问题，接下来通过流批体可以去解决实时离线数据统一以及数仓在建设当中的建设成本问题。
03.电商流量流批一体
目前对于流批一体的建设方向主要是包含计算一体以及存储一体，并且其分别可以在物理以及逻辑两个维度进行去探索。综合下来，会有四个主要的方向。
在抖音电商看来主要认为最终的终态包含，代码跟 SQL 的统一，计算引擎的统一以及数据模型的统一，最后存储引擎的统一。分别在这些方向其实都是会有做努力不过受限于存储引擎目前无法满足大流量下的稳定性诉求，所以重点建设了前三者并且近期也在探索存储引擎统一的方向。接下来主要介绍一下流量在流批一体的建设架构当中的情况。
首先对于存储一体，主要致力于实时跟离线的模型上的 Schema 的统一，以及期望能做到并且也做到流量的基建的公共层实时和离线模型一一映射。对于计算统一，受限于实时跟离线的维表的差异，有实时离线，他们会存在时效性差异以及存储引擎的差异在解析层以及扩维层分别做了独立的计算一体的实践。对于解析层，使用 FLINK 以及 Flink SQL 做到计算。物理计算以及逻辑计算的完全一体化并且将产出实时 Kafka 数据进行同步，做到了实时离线数据，在解析层可以做到 0 Deep 的效果。对于扩维层，受限于执行引擎的差异，通过将公共的逻辑注入到公用的实时离线 UDF 做到统一，两者虽然执行引擎存在差异但是最后产出的数据、数据递付率非常低，可以接近保持数据的一致性。接下来将从介绍如何在这两层去实现。
首先在解析层，主要是实现了物理的计算一体。在计算一体，刚才也提到了将实时的数据通过同步任务写给了离线会出现一个问题，在写给离线的时候可能出现漂移，丢失以及如果离线数据口径出现变更它就无法进行一个数据回溯。因此，充分利用 FLINK 的 Batch 的流批作业的能力并且复用了之前离线的 ODS 将其完全搭建成一个数据被列，当出现数据异常的时候，可以使用容灾监控能力将启用 Flink Batch 的背链将离线的 ODS 数据重新回写到离线的 DWD 明细层以避免数据的丢失。以及在一些回溯场景可以直接快速的覆盖历史的分区。同时，离线的迭代效率会比实时快很多，因为当前实时在迭代的时候都需要双跑一个 Flink Streaming 的任务企业需要执行一段时间才能看到效果 Flink Batch 可以快速的经过批任务去验证一些增量场景当中的业务，迭代逻辑变更。只要是在验收完成之后 Flink Batch 的逻辑已经是正确。那只需要做到能通过一键同步，可以让实时也可以执行一个快速上线的能力进而避免刚才提到的在 Flink Streaming 当中的双跑链路的成本。整体下来计算成本可以节约将近 40%，开发人力会节约 50%。
在扩维层受到计算分离的影响其实想要做到逻辑的计算一体。刚才也提到，主要是通过公共逻辑分别注入到 FLINK 的 UDF 以及 Have 的 UDF 当中，然后在执行虽然两者计算分离。但是可以保障最后的数据结果从逻辑上是完全对齐。最后的数据递付其实是可以控制在千分之一以内，并且千分之一是由维表差异引入的，而不是自己的逻辑引入的。是怎么实现的？公用逻辑是有多种形式，可以通过 SQL 以及 Java 代码，还有外置的一个归因平台来实现。对于公对于 SQL 来说主要是复用了 FLINK 的 Kill Set 翻译执行的功能。这样 SQL 可以兼容一些历史上没有做成流批体的逻辑，可以直接做一个水平的迁移。java 代码主要去适用于一些增量的场景，增量简便为了更加敏捷的开发，可以用 java 代码来实现。对于归因平台主要是面向的是一些迭代频繁的归因逻辑，这样迭代，由于迭代频繁，人力有些时候是受限的并且这些迭代频繁的逻辑变更，往往都是比较的具有统一性的将这部分的变更逻辑托管给归因平台。由数据分析师进行无代码可视化的逻辑数配置进而通过归因平台更新到的 UDF 当中。同时产运也可以在归因平台上快速的去查询其想要的这些归因逻辑。也可以大幅的去减少答疑成本。接下来对于大流量任务会面临很多稳定性的一些挑战。由于这些稳定性挑战的问题来源非常的多，因此就对大流量任务分享一些调优的经验。
04.大流量任务调优
首先大流量基建的数据任务特点比较明确，流量的 KPS 比较高。经过的建模优化之后，单个任务可能还会有 100 到 200 万左右的 KPS 并且任务的计算逻辑是十分复杂的。大概会单个任务可能会有一两千行的一个 SQL 的长度,并且由于是公共层基建所以维度扩围也是特别多的.大概会有 20 多张尾表单个任务，并且在基建上是不存在任何聚合动作。基于上述特点按 DAG 进行拆分，将已有的任务，已有的问题主要拆分成了消费层、计算层以及生产层三点，并且在计算层对算子进行了更精细化的拆分。
主要是负责计算的 CP 算子以及负责为表扩维的 Join 算子。并且在这些算子间如果开启了 Key By，可能会出现一些算子间通信问题。对这些问题进行了标续，主要有几点，在消费侧的话是在反序列化的性能压力会比较高在生产车的话主要是对类似于 Kafka 以及其他的一些 Sink 组件的压力会比较高。在计算侧，会开个算子引起过多的计算复杂问题。网络间通信会导致任务的 SHUFFER 网络开销比较大并且开启 Key By 之后数据会存在严重倾斜的问题，然后在 Join 算子当中会存在几个。首先由于关联的维表非常的多维表的缓存会被使用满导致了任务频繁的 Full GC 并且维表访问的 QPS 压力也会变得非常大。针对上述问题，按序给了相应的适用场景以及对应的解决方案。这样为了方便大家在会后进行快速快捷的查询。
接下来大家介绍一下对这些任务的问题的优化的思路以及解决方案。首先，针对消费成本高的问题其比较适用的场景是去消费较大的流量在消费当中会存在着不少的无效数据。如何去识别这些无效数据以及如何去避免这些无效数据的反序列化是需要考虑的问题。
无效的数据的识别，每个任务是并不相同的。可以通过各自任务的 Source 算子下游的 KO 算子当中的 select 以及 VR 条件分别去识别的无效数据以及有效数据当中的这些无效字段并且将其经位置下推下推至 Source 算子以处理，进而去处理避免反序列化的问题。如何实现反序列化？其实针对上述的两种无效数据有独立的处理方案，对于 VR 条件对应的无效字段，无对应的无效数据可以利用 Kafka Header 的性能将需要的外条件当中的字段配置索引并且写入到 Kafka Header，当中的数据在拉取之后优先先反序列化 Header 逻辑并进行根据索引进行过滤，过滤之后再进行相应的反序列化操作，这样可以避免的无效无效的数据进行反序列化。同时，为了避免那些有效数据当中的无效字段，在最后一步会有反序列化的压力。Kafka 采用 PB 的存储格式，并经过位置下推对 PB 的存储文件进行一些逻辑上的裁剪只保留需要的字段。经过上述两点的优化之后，整体的任务的 CPU 使用率可以下降 20%。针对维表访问压力问题，主要在于维表访问压力过大。
QPS 高主要解决思路其实是在避免无需访问维表的数据然后从进行访问，第二点在于避免已经访问过为表的数据进行重复访问的动作。
因此，相应也会有对应的解决方案，Join 的逻辑当中进行一个对于 Join 算子条件进行位置下推。比如说在图中示例其实是不需要圆形的数据进行一个维表的关联，在关联的条件当中会配置它，它的尺寸不能是圆形。在执行的时候可以在关联之前进行一个维表的一个过滤。
其次，可以去通过提高一些的缓存命中率，提高缓存命中率可以降低相同的数据重复去对维表的访问。主要解决方案是由对在之前对数据按进行 Hash Key By，让数据提升缓存命中率。第二点，比如说 AB、比如说对 H Base 对于 REDIS 的 Connector 当中的缓存组件将其组由谷歌的 Guava 替换成了 Caffeine，Caffeine 有一个更好的一个缓存命中策略经过上述优化之后，单个的任务对于维表的访问，KBS 从 400 万可以降至 40 万。其实 Key By，很好的去解决了缓存命中率的问题但是不可避免的会引起的数据倾斜问题。
因此，在数据倾斜问题上比较适用的场景采用了 Key By 动作并且由于业务的影响会存在的数据严重倾斜问题。解决思路其实是做到一个 Join 算子负载均衡。因此，对于已有的场景进行数据分析对于上算子的 BA 状态进行分析，如果算子是百分之百 BZ 或者说超过一定阈值之后会对上游算子进行一个负载反馈，让上游算子进行一个 Key By 的 Hash 的策略调整。因此最后提出了一个非完全一致性的 Hash 策略。一旦出现了负载反馈会对负载过高的算子的相应的数据进行调控，进而保障所有的 Join 算子尽可能的做到一个负载均衡。通过上述的能力将在一些严重的数据倾斜场景，数据吞吐能力可以上涨 50%。无论是 Key By 也好，WeakHash 也好，它都无法去避免一个问题，在网络 IO 上会有吞吐，吞吐就不可避免会 SHUFFER 网络通信对外的内存会有压力。同时，在还有一个另外的对外内存问题在写入 Kafka 当中 Kafkaclient 的频繁的访问也会出现压力。针对上述两个问题分别进行了调优，首先对于网络 IO 问题每一个 Sub Task 都是需要为下游的所有并发提供一个单独提供一个缓存的队列，由于并发越多缓存的队列也就越多。
为了更加好的去是执行吞吐这么大的 QPS 或并发程度可能会提升到上千或者说几百在这种情况下，单个缓存的被使用的被用满的可能性就会变低，会立刻达到最大的等待时长然后进行网络 IO 的吞吐。因此的解决思路通过延长 Network Buffer 的等待时间去以降低整个网络 IO 的访问频率，来提升任务的执行效率对于高吞吐的 Kafka 的问题其实是一个相反的动作。所有的数据会快速的去填满的 Kafka 的 Buffer 的缓存池，然后频繁的去访问 Kafka Client。为了解决问题，其实通过调大的 Kafka Buffer 池来降低访问的写入的频率。整体下来 CPU 的使用率可以大概下降 10%左右。
刚才也聊了对外的调优，最后聊一下在堆内的 JVM 的上面的调优。调优主要是有两点，也根算子来拆分。对于 Kimi 算子来说，其实会出现单个方法特别大的情况，由于 Java 是有一定的解释性语言的，需要逐条进行解释整个 CPU 的资源损耗量会极大。但是，Flink 在执行的时候又没有办法对这么大的方法进行 JIT 优化。因此，和字节的引擎团队 Flink 引擎团队协作把这种大的方法进行识别然后识别之后通过 JVM 的 JIT 优化成本地方法，加快了的执行效率。第二点，是在 Join 算子当中会出现 Cash 频繁失效导致不断的有 Full GC 出现并且 JDK8 默认的垃圾回收器是 PARAMM 的垃圾回收器，其 Stop The Word 的时间过长会导致整个任务主要的耗费时间在于去处理的 Full GC，而不是去专注于处理的数据。因此的话，对于该问题，其实是通过升级的 JDK 版本并且去采用更高级的 G One 的垃圾回收器来提升整体的垃圾回收效率以及降低 Stop The Word 的时间进而去提升吞吐的能力。综合下来，通过上述两点的优化，整体的数据吞吐能力可以提升 20%。
05.总结和展望
接下来我将进行一下最后的总结与展望。经过数据的建模，流批一体的建设，以及最后的大流量的任务调优在效率、质量、成本以及稳定性性上都拿到了不错的收益。数据质量和规律达到了 99%以上，然后人效节约 20%消费成本，对人效提升 70%，消费成本节约 20%，以及任务的处理性能综合来看平均提升了 70%。
在接下来的工作当中核心动作是降本以及增效，对在增效方面，期望能把数据建设做得更加自动化、更加配置化，以及做的数据可以做成可视化的动作。
未来，我们希望探索变更、发布、盯盘的一些自动化操作，并在某些配置化场景中实现低代码化，以实现标准化的自动配置。我们希望能够使现有的数据、资产以及归因逻辑更加可视化。在成本优化方面，目标是降低 CPU 和内存的使用。关于降低 CPU 的策略，主要分为两个步骤：首先进行优化，然后进行治理。优化阶段旨在减少任务的 CPU 使用率，通过治理不断调整任务的资源申请量，以降低任务的分配量。在存储方面，我们计划探索流批一体化的解决方案，以解决实时与离线双重存储的压力。