摘要：本文整顿自快手实时数据开发工程师冯立，快手实时数据开发工程师羊艺超，在 Flink Forward Asia 2022 实时湖仓专场的分享。本篇内容次要分为四个局部：
- 快手实时数仓的倒退
- 实时数仓建设方法论
- 实时数仓场景化实战
- 将来布局
点击查看直播回放和演讲 PPT
一、快手实时数仓的倒退
作为短视频畛域的领头羊，快手 APP 始终致力于视频、直播技术的迭代，其背地对数据实时性、准确性的要求十分高，这对于数仓体系的构建也提出了新的挑战。
上面是快手实时数仓倒退到当初经验的几个阶段：
- 在第一个阶段，快手的实时数仓起始于春节、国庆、快手之夜等大型流动场景。在这些流动场景下，实时数据次要用于满足流动大屏、经营看板、流动成果监控等实时需要。在这个阶段咱们基于屡次流动场景的实时化建设，积淀了流动流量、用户激励等流动通用的数据。
- 在第二个阶段，实时数据被利用于公司外围指标的实时化场景。此时实时数据次要服务于公司的外围数据产品，不便公司领导层实时理解以后公司产品的用户规模等外围指标。在这个阶段咱们基于流量的通用性，建设了用户域、设施域的实时化数据。
- 在第三个阶段，咱们专一于业务数据域的实时化建设。在此阶段实时数据开始基于快手各大业务状态如直播、视频、搜寻等业务数据，构建各个 FT（FeatureTeam 简称）的实时数仓建设。此阶段实时数据次要服务于各个业务 FT 的外围实时指标，利用于各个业务 FT 的外围看板。
- 在以后阶段，随着各大业务 FT 实时数仓建设的欠缺和稳固，咱们开始重点裁减实时数据的应用场景。目前，实时数仓开始间接服务于线上举荐场景、产出用户画像标签、产出实时指标等举荐场景。在这个阶段咱们逐步完善了各个业务 FT 的底层数据，晋升了各个 FT 数仓数据的覆盖范围，更好的来满足业务对实时数据的需要。
在整个实时数据的倒退阶段，咱们的实时数据覆盖范围越来越广，数据应用场景越来越简单。期间在每个阶段咱们也面临了很多的挑战，积淀了在一些特定场景下的解决方案。
首先是第一阶段的大型流动和公司级外围指标的计算场景，在这个场景典型的特点是数据流量大、业务对数据指标的品质要求高，咱们面临的挑战概括的讲是数据品质的保障问题。为了保障实时指标的快、稳、准；
- 指标的实现计划上会抉择缩短指标产出链路从而保障指标及时产出；采纳以窗口为外围的解决方案来实现指标，从而来反对数据的可回溯。
- 在架构上会依据指标的不同等级构建多机房容灾、双链路，来保障数据的继续可用
第二个阶段，咱们专一于晋升数据实时化，晋升服务迭代效率。该场景的特点是产品迭代快、实时需要多。这个阶段咱们面临的挑战概括的讲是开发的高效性问题。为了保障实时需要的疾速稳固交付；
- 咱们在指标的实现计划上重视积淀经典场景的解决方案，从而保障在经典场景下组内的技术计划是统一的，这样能够极大的晋升开发效率。
- 架构上咱们开始积淀各个 FT 的数仓数据，重视模型治理、数仓分层、防止烟囱开发，从而来晋升数据的复用性。
第三个阶段，咱们次要服务于线上举荐场景。这个场景下工作呈现断流、重启都会间接影响到线上模型训练的准确性。这个阶段咱们面临的挑战详情的讲是数据高可用性问题。为了保障实时数据的高可用；
- 引擎层面上咱们自研了反对工作 slot 级本地疾速复原，当单 slot 工作异样时，独自重启以后异样 slot 以及其对应的上下游工作，防止整个实时工作的重启，从而避免出现断流。
- 架构上咱们采纳了全链路多机房容灾、工作双链路部署、主工作部署高优队列等措施，来预防物理层面导致的工作断流。
二、实时数仓建设方法论
2.1 实时数仓技术架构
上图是快手实时数仓的技术架构图。从图中能够看出，整体采纳 Lambda 架构，实时链路次要应用 Flink+Kafka。
在维表的实际中，咱们依据维表的数据大小、拜访维表工作的 QPS 等来抉择用 Redis 或其它 KV 存储来作为底层存储引擎。
在数据服务层，咱们会依据不同的场景，抉择不同的数据存储引擎服务数据产品。比方在比拟灵便的剖析场景，咱们会把 DWD 层数据间接导入 Clickhouse，借助 Clickhouse 的物化视图、二次开发能力、高性能 OLAP 剖析能力，提供数据查问服务; 在实时指标须要传给 C 端等高查问 QPS 的场景下，会抉择将 Flink 计算完的指标间接导入到 Redis，用服务化接口的模式提供给数据产品；在人群特色等须要多流拼接的场景下，咱们借助 Hudi 来反对多数据源合并写入，最终用离线数据服务于业务。
在离线局部，实时数据会同步导出至离线数据。该数据次要用于减速离线链路，如减速离线小时指标的产出等。与此同时，同步的数据也会被用来进行实时数据的准确性校验，反对长周期实时指标的回溯等。从而保障实时数仓的数据和离线数仓的数据一致性。
上图是快手实时数仓的整体架构图。ODS 数据次要来自于快手主 APP、快手极速版 APP、快手 PC 端等产品。数据最终以服务端日志、客户端日志、Binlog 日志等模式，进入实时数仓。
在 ODS 层，咱们会对超大 QPS 日志进行拆分，对加密数据进行解密。在 DWD 层，咱们依据快手的业务划分，从数据上划分出视频 FT、直播 FT、搜寻 FT 等。基于各个 FT 的业务过程构建出各个 FT 在多业务过程对应的 DWD 表、DWD 扩大维表。通过灵便的 DWD 层建设来反对各主题域下丰盛灵便的实时业务场景。
在 ADS 层，咱们基于不同的利用场景，采纳不同的技术计划，反对对应的实时需要。
- 在外围指标场景，咱们基于积淀的典型场景技术计划，采纳以 Window 为外围的解决方案;
- 在 AB 试验多维度大流量场景下，同一份数据通过多试验后，流量会被放大 N 倍。此时首先会通过构建对应的 DWS 层来缩减对应的 QPS，并且会采纳 Flink 1.13 以上的版本，借助引擎自身自带的本地聚合个性来晋升工作整体的性能。
- 在垂类业务个性化场景下，咱们会采纳更细粒度的划分业务过程，拆分出特定场景下的 DWD 数据、DWD 扩大维表数据，从而间接把对应 DWD 数据导入到 Clickhouse 或用 Flink SQL 计算对应的实时指标。
2.2 实时数仓 ODS 建设
上面会针对实时数仓分层中各个分层的特点，具体讲一下对应分层中积淀的一些思路。
ODS 层间接对接原始数据。该层的数据有流量大、多业务共用、日志格局嵌套深的特点。在该层的实际中，除了解密日志、日志格式化等操作，还会重点关注数据复用性和上游口径一致性的问题。快手的客户端日志是全站对立、业务共用的，针对这种超大 QPS 的 Topic 咱们进行了流量拆分。依据各业务主题域不同的拆分逻辑，拆分出专属于以后主题域的 Kafka topic 数据，从而加重上游解决繁多业务主题域的数据量。这样不仅节俭了资源，而且从源头保障了主题域上数据口径的一致性。
针对拆流工作，咱们反对动静配置。通过动静配置，防止繁多业务主题域的新增以及口径的批改，造成对整个工作进行重启的问题。如上图所示，咱们把客户端的曝光日志进行流量拆分，从而拆分出视频曝光、直播曝光、流动曝光等繁多主题域的曝光数据。
2.3 实时数仓 DWD/DWS 层建设
DW 层是数仓建设的外围，其丰富性和稳定性间接关系到数仓的丰富性和稳定性。DW 层的建设思路整体遵循维度建模实践。
实时数仓的 DWD 层首先要确保涵盖所有须要服务的业务过程和剖析维度。其次为了保障工作的稳定性，会存在同时建设多个有雷同业务过程的 DWD 表的状况。咱们会根据特定场景来决定具体应用的 DWD 表或 DWD 扩大维表等。
在 DWD 层的实战中，DWD 表须要进行维度扩大是十分常见的需要。在咱们的实战中，维表扩大会基于维表的具体情况抉择不同的关联形式。
- 在大多数状况下维表变动比较稳定，咱们会抉择借助第三方 KV 存储，应用 UDF 间接拜访 KV 存储来实现维表扩大。但在抉择第三方 KV 存储时，当维表内容特地大时抉择 kiwi、当 QPS 较高时抉择 Kcatch。
- 当维表变动频繁且对时效性要求较高时，抉择 interval join。借助 interval 工夫范畴的个性来达到正当管制状态大小的目标。
- 当维表关联逻辑比较复杂，为了工作的稳定性和扩展性，咱们会通过自定义维表进行关联，手动保护状态治理的过程，实现 DWD 维表的扩大。
实时数仓的 DWS 层只有在数据量特地大且聚合后的数据量有显著缩小的场景下才会构建。如果 DWD 层的 QPS 比拟小，个别会间接省去 DWS 层的建设。这样的做法不仅能够保证数据的及时性，同时也缩短了指标产出的链路，进而保障了工作的稳定性。
2.4 实时数仓 ADS 层规范计划
在 ADS 层的方案设计时咱们须要根据具体的需要场景设计不同的实现计划。在上线指标时，咱们不仅要思考满足以后的指标需要，而且要思考指标的可回溯性和工作稳定性。比方在上线时须要思考指标实现过程中是否拜访了内部存储、上线后状态是否超大、指标异样后以后计划是否反对数据回溯等。
在快手的 ADS 实际中，常常会遇到绘制指标曲线图的需要。针对这种场景，咱们基于需要自身以及反对指标可回溯会抉择以窗口为外围的解决方案。
- 在针对当日累计的场景，即要求每分钟实时产出从当天 0 点开始到以后统计工夫分钟截止的总指标值的需要，咱们会抉择 cumulate window。
- 针对流动累计场景，即流动个别会继续 n 天，则需要要求每分钟实时产出从流动开始到以后统计时刻为止的总指标值。咱们会抉择 infinity_cumulate window。
- 在针对散布类的指标需要时，即需要指标会随着工夫的推移呈现稳定。同一粒度下咱们需先拿到最新的数据状态，再进行下一步汇总的统计。咱们会抉择 unbounded+infinity_cumulate window。
- 在针对单直播间累计的场景下，咱们会抉择 dynamic_cumulate。
2.5 单直播间累计指标
接下来以 dynamic_cumulate 为例，展现窗口在理论场景下的应用。需要的背景是基于直播流每分钟统计从直播开始到直播完结期间，各个直播间总的观看人数和观看次数。直播间的特点是每个直播间可能存在直播跨天的状况、不同直播间完结的工夫点各不相同、直播间完结后直播间统计数据不会再更新。
通过剖析需要的实际发现，如果间接采纳 Flink 自身的 session window、cumulate window 都无奈满足需要，为此咱们开发了 dynamic_cumulate window。通过该计划，不仅能分钟级产出所有直播间的统计指标，并且状态可控数据可回溯。dynamic_cumulate window 的用法如图所示，函数对应的三个参数别离是：time_attr 指定数据流的工夫属性;step_interval 定义窗口触发计算的工夫距离;gap_interva 标识最新一条数据达到后，多长时间内没有数据达到就能够认为统计窗口完结。
以后函数实质是一个窗口函数。当直播间完结后，满足第三个参数设置的时长后，指标数据就不会更新就不须要统计以后直播间的指标值，此时能够从统计工作的状态中删除直播间对应的状态。最终达到了实时工作状态可控的要求。
2.6 实时数仓资源治理
实时业务需要暴增、实时队列资源应用长期处于超过平安水位线运行、公司提倡降本增效、平台资源申请各种受限等，上述场景广泛产生在各个实时数仓的建设阶段。线上实时工作对列应用凌乱，没有辨别队列优先级。高优工作和个别工作混合部署，不同工作间资源抢占时有发生。
在面对上述实时资源的背景和现状，咱们从存量工作、新增工作、集群队列三个方向总结了一些实时资源的治理办法。
- 存量工作方面，根据工作血统确定出无上游援用的实时工作，而后确定实时工作对应的数据集是否还在线上应用，从而对无用工作进行下线；其次通过梳理各个数据主题域的数据模型，确定出烟囱工作，对其进行合并下线；最初针对超大资源应用的工作进行计划评审，通过优化计划缩减大资源应用的资源量。
- 针对新增工作，在上线工作时会组内评审工作的实现计划，确定计划最优后能力上线。其次每个上线的实时工作都须要进行压测，根据压测后果设置正当的资源方可上线。
- 针对集群队列，咱们对集群队列进行优先级的划分，依照不同工作的优先级部署到相应的队列中；在整个实时工作的监控方面，咱们开发了实时工作的资源应用衰弱评分机制。通过定期的统计实时工作的资源应用状况，将后果发送给实时工作列表评分比拟低的 owner。从而保障在线工作的资源应用解决在正当的程度；咱们针对实时队列的资源使用率进行监控。当超过队列平安水位线后，零碎会及时报警揭示管理员进行队列扩容。
通过上述计划，咱们目前高优队列长期处于平安水位线以下，很好的解决了资源适度节约的问题。
三、实时数仓场景化实战
3.1 业务实时利用场景的特点及挑战
如上图所示，这两个场景别离为 S 级别流动大屏以及 AB 试验多维成果数据。S 级别流动大屏是快手在举办节日或盛典流动时，高管或产运同学必不可少的一种用于监控流动整体成果的重要工具，其中的指标通常都是大盘指标，而这类指标的加工链路的特点就在于上游的数据量是十分大的，通常为百万级 QPS，而在这么大的数据量下，业务又有 3 点强诉求，别离是算的准，不能因为数据乱序而丢数；算的快，要保障秒级别的数据更新速度；算的稳，如果呈现故障，要在分钟级别的进行数据的复原，所以对于 S 级别流动大屏来说，实时数仓的建设面临的挑战次要是外围场景的保障问题，而解决思路也很清晰，别离是以开发生命周期为根底的正向保障思路和模仿故障注入为根底的反向保障思路。
第二个业务利用场景是 AB 试验多维成果数据，置信大家对于 AB 试验并不生疏，AB 试验是举荐策略同学用于来验证策略是否无效的重要工具，而要评估 AB 试验的成果天然离不开 AB 试验成果数据，然而传统的离线链路加工的形式产出时延达会达到 t – 1，导致举荐策略同学调整试验策略的周期很长，试验迭代效率低，因而实时产出分钟级别的 AB 试验成果数据目前正在成为实时数据的一个重要价值场景，举荐策略同学依赖实时的 AB 试验成果数据可能极大的晋升策略调整的效率。接下来咱们看看 AB 试验指标的特点，它和 S 级大屏有相似的中央，AB 试验关注的往往也是大盘数据，因而计算指标的 Flink 工作的入口流量通常也是百万级别 QPS 的大流量，除此之外，在近百个试验同时在线的状况下，会进一步造成计算数据量的收缩，对于数据量的收缩起因咱们将在后续详细分析。除此之外，AB 试验指标还有另一个重要特点，因为业务迭代速度快，因而业务须要对 AB 指标进行剖析的维度也是十分丰盛的，不止如此，维度也会常常变动和更新。而联合下面这两个特点，在 AB 试验成果实时数据的落地过程中，咱们面临的挑战次要就是大数据量下的 Flink 工作性能问题以及疾速业务迭代中 AB 维度扩大的灵活性问题。针对这两个问题，咱们给出的解决思路是通过建设用于 AB 维度扩大 DWD 层晋升维度扩大灵活性并通过建设多维 DWS 层压缩数据量的形式来晋升工作的性能。
在理解了这两种场景的各自的业务特点以及咱们的解决思路之后，接下来咱们详细分析每种场景下的建设计划以及保障计划的细节。
3.2 S 级大屏的保障思路
首先是 S 级别流动大屏。如上图所示，这类场景中的指标通常都是同时在线数据和当日累计数据，也就是 tumble 和 cumulate 两类窗口的指标。指标自身的解决逻辑并不简单，重要的是保障。保障的诉求是算的准、算的快、算的稳，针对这三点，咱们提出了横向和纵向的切分的保障计划，在横向切分中，将算的准和算的快归类到以开发生命周期为正向的保障领域，将算的稳归类到了模仿故障注入为根底的反向保障范畴，在纵向切分中，咱们是以大屏指标的整体生命周期为思路开展的，次要分为开发、测试、服务 3 个阶段，在这每个阶段针对每种保障诉求别离提供了对应的解决方案。
对于算的准来说，在开发阶段，会应用快手外部积淀的标准化解决方案，并且因为快手对于数据曲线可回溯的诉求特地强烈，所以 allowLateness 机制能够说是大屏场景必用的一项配置，在测试阶段，咱们会通过多轮数据内测来保障数据的准确性，在服务阶段，咱们会别离使用同环比的实时稳定率 DQC、实时时序算法 DQC 以及实时离线比照的准确性 DQC 来及时监控数据品质。
对于算的快来说，为了保障数据产出尽可能的低时延，咱们通常会将窗口计算的频次提频到 10s，并且尽量缩短指标的产出链路来升高指标产出的时延，在测试阶段，通过压测检测工作是否有数据歪斜问题以及其余的性能瓶颈点，并在测试阶段全副解决，在服务阶段，通过配置规范的性能监控，比方数据处理提早，单节点解决提早，输入输出 QPS 等监控项来监控工作是否处于失常的数据处理状态。
对于算的稳来说，在开发阶段，针对这种外围高优指标，咱们会进行多机房部署，并针对一些可能呈现的异常情况做故障复原的预案，在测试阶段，会通过数据回溯的性能测试来保障工作在满足 SLA 的前提下疾速将数据回溯实现，同时会通过 Flink 引擎侧提供的限流以及 watermark 对齐等能力来保障工作在回溯过程中不会因为回溯压力过大而导致工作失败。
接下来，具体介绍算的快、算的准以及算的稳中的具备快手特色的解决方案。
首先是算的准，在 S 级流动大屏的利用场景中，当日累计类的指标简直占据了一半的江山，而咱们晓得在 cumulate 窗口利用中，只有在整个大窗口内，乱序的数据都不会被抛弃，这看起来尽管好，然而面对重大数据乱序的场景时，cumulate 只会将乱序数据记录到最新处，而这就会导致呈现图中红框中圈起来的问题，其中绿色的线是在没有数据乱序时正确的趋势图，而当产生数据乱序后，cumulate 理论计算失去的后果是上面蓝色的曲线。
而针对这个问题，咱们天然会想到 tumble 窗口中提供的 allowLateness 机制，然而目前的 cmulate 窗口并没有这种机制，因而咱们针对 cumulate 的场景开发了 allowLateness 机制来实现雷同的成果。首先来看 cumulate 的执行机制，cumulate 窗口在执行时会蕴含两局部状态数据，别离是 merged state 和 slice state，当窗口大小为 1 天，步长为 10s，最大乱序工夫为 30s，以后的 watermark 为 9 分 10 秒时，merged state 中蕴含的数据范畴是 0 分到 9 分 10 秒的数据，而剩下会有 3 个 slice state，其中状态中的数据别离为 9 分 10 秒到 9 分 20 秒，9 分 20 秒到 9 分 30 秒，9 分 30 秒到 9 分 40 秒，随着 watermark 的推动，slice state 会一一合并到 merged state 中，而后将 merged state 中的后果输入，这时如果有一条 5 分 23 秒的数据来了之后，就只能记录到最新的 slice state，这就呈现了咱们刚刚提到的问题。而为 cumulate 实现 allowlateness 的思路并不简单，仍然是下面这个案例，当咱们设置了 5min 的 allowLateness 后，从 4 分 10 秒始终到 9 分 40 秒之间中所有的数据都要保留到 slice state 中，而 merged state 中只蕴含 0 分到 4 分 10 秒之间的累计数据，如果这时 5 分 23 秒的数据来了之后，就会将这条数据放入到 5 分 20 秒到 5 分 30 秒的 slice state 中，而后在输入数据时，能够将 4 分 10 秒到 9 分 10 秒之间的数据从新输入一遍，通过这种形式就能够将重大乱序场景中的不合乎预期的曲线给主动修复。这个性能在快手理论的利用场景中能够做到在大流量的工作中设置 30min 的 allowLateness 来解决最近 30min 内的数据乱序问题，在小流量工作中，会设置 1 天的 allowLateness 来解决最近 1 天以内的数据乱序问题。
接下来是算的快的中的数据歪斜问题解决的优化计划。数据歪斜对于 Flink 工作的危害是十分大的，通常咱们会应用图中的 SQL 来作为罕用的数据歪斜解决方案，在 SQL 的内层，通过对 user_id 取模将数据打散，而后通过 SQL 的外层将打散的数据进行合并。然而这种常见的解决方案仍然会存在问题，问题在于因为 Flink 引擎在计算每一个 key 所属的 key_group 时，仍然会有一层 hash 策略，而这就使得每一个 key_group 中解决的 key 的个数不同，仍然导致存在肯定的数据歪斜。举例来说，SQL 内层聚合算子的 key 总共有 3 个，别离为 0，1，2，接下来假如这个 SQL 对应的 Flink 工作的中聚合算子的并行度以及最大并行度都为 3，那么 key_group 也就有 3 个，咱们也别离记为下标为 0，1，2 的 key_group，然而因为 key 和 key_group 之间存在 hash 策略，则会导致呈现 key 为 0 和 1 的数据只会被发送到下标为 0 的 key_group 中，key 为 2 的数据只会被发送到下标为 2 的 key_group 中，其中下标为 1 的 key_group 一条数据都不会接管到，最终就呈现了数据歪斜的问题。而咱们冀望的成果为 key 和 key_group 最好可能一一对应，key 为 0 的数据只会被发到下标为 0 的 key_group 中，key 为 1 的数据只会被发到下标为 1 的 key_group 中，key 为 2 的数据只会被发到下标为 2 的 key_group 中。
接下来是解决方案，解决方案其实是一种通过 key_group 的下标去找该 key_group 的 key 的思路。其中次要的步骤有两个，第一步，须要保障 key 的个数和 key_group 的个数雷同，举例来说，如果 key 为 0，1，2，那么 key_group 也必须为 3 个，第二步，应用 key_group 的下标通过 key 和 key_group 的 hash 策略去被动的寻找这个下标的 key_group 对应的 key 的值，并保护出一个 key_group 和 key 的 map，举例来说，假如下标为 0，1，2 的 key_group 找到的 key 别离为 15，18，19。接下来，当工作中理论的 key 为 0 时，咱们就会通过保护的这个 map 将其映射为 15，而后 Flink 引擎拿到 15 之后通过 hash 策略计算后就能失去这个 key 要发往下标为 0 的 key_group，这就实现了 key 和 key_group 之间的一一映射，防止因为 Flink 引擎的 key 和 key_group 之间的 hash 策略导致的数据歪斜问题。最初来看看这种优化计划在咱们理论利用中的成果，这种优化计划非常适合在 DWD 拜访维表的利用场景，只有 key 自身没有歪斜，Flink 工作就不会呈现数据歪斜的问题。
最初是指标算的稳的保障思路，最无效的办法莫过于指标产出全链路的双机房热备部署，如图所示，从输出的 Kafka Topic 到 Flink 计算工作、依赖的维表存储的 Redis 引擎，始终到产出的 Kafka Topic 以及最终的 OLAP 服务引擎都部署了双机房。当 Kafka 或者 OLAP、Redis 引擎呈现故障时，依赖于快手基础架构的主动容错能力，在开发人员无需任何干涉的状况下，就能实现主动的机房切换。当 Flink 引擎单机房呈现故障时，首先咱们会判断 Flink 工作是否可能在 SLA 的工夫内疾速复原，如果无奈疾速复原，在验证了热备机房产出数据正确性的前提下，咱们会切换为热备机房产出的数据集。当然了，主备链路的切换是一个须要上下游联动能力做出决策的高老本操作，所以咱们仍然会对每一条解决链路做压力测试并预留 buffer，保障在没有呈现重大故障问题的状况下，单个机房的工作也能疾速复原，持续提供服务。
3.3 AB 试验多维数据建设思路
接下来剖析第二个利用场景，AB 试验多维数据整体建设过程，AB 试验多维数据的指标和第一个场景中相似，指标自身并不简单，以直播曝光为例，那么最终的 Flink 工作就是图中的 SQL 展现的 tumble 窗口，其中多维体现在 SQL 中 group by 的维度多，比方会应用直播间、主播等多个维度穿插进行剖析。
如图所示，AB 试验多维数据的外围诉求和建设难点分为两局部。
第一局部的外围问题是业务迭代的灵活性问题。业务侧迭代速度很快，通常察看的都是直播间、主播的一些个性化维度，均匀 1~3 个月就新增或者下线 2 个维度，而这些维度又是来源于多个不同的维表，比方 author_dim1 来自表 A，author_dim2 来自表 B，最初会通过 hive2redis 导入到 redis 中以便 Flink 通过 lookup join 将维度数据关联到，然而如果每一张表导入一遍 redis，将会导致 redis 资源的节约，并且 Flink 工作也得须要屡次 lookup join，会导致肯定的性能瓶颈，除此之外越来越多的维度也会导致 Flink 工作计算性能的急剧下降。针对这个问题，咱们从开发以及治理两个角度给出了对应的解决方案，首先是开发计划，咱们会首先将多张维表合并，对立构建一个 AB 专用的 Hive 维表以及一个 AB 专用的的 DWD 维度扩大工作，通过一次拜访就能将同一个粒度下的所有维度数据拜访到，即便维度有新增，只有粒度不变，仍然能够增加到原来的维表中，除此之外，因为近百个试验中，不同的试验关注的维度组合是不同的，所以咱们也会将试验依照维度进行分组归类，而后别离构建不同维度组合的 ADS 层工作产出数据，避免出现一个 Flink 工作计算过多的维度组合。除此之外，因为维度不能有限扩大，所以咱们会通过定期监控 OLAP 数据服务引擎中维度字段的拜访频次来判断维度是否曾经没有在应用，从而下线有效的维度。
接下来是 AB 试验多维数据的第二个建设难点。这个难点的外围问题工作的性能问题，用于计算 AB 试验的 Flink 工作的入口流量是百万级别的 QPS，而且同时在线的试验个数也是近百个，所以这里就会呈现数据的收缩问题，如图所示，一个 user_id 同时在 30 个试验中，那么一条蕴含 user_id 的直播曝光原始数据就会被收缩为 30 条数据，那么百万级别的 QPS 通过数据收缩之后就会变为千万级别的 QPS，这对 Flink 工作的性能是一个极大的挑战，而针对这个问题咱们也从开发以及治理两个角度提出了对应的解决方案。开发计划的外围思路就是删减数据和压缩数据，从删减数据的角度登程，因为不是每一个试验都须要观看实时数据，所以咱们会对计算实时数据的试验通过配置核心进行管控，只计算须要的试验的实时数据，除此之外，从压缩数据的角度登程，在加工链路上，咱们构建了 uid 粒度的多维 DWS 层对数据进行压缩，在 ADS 层还利用了 tumble 窗口两阶段优化对数据进行了无效的压缩优化，除此之外，当一个工作达到性能瓶颈时，咱们还会对计算工作进行横向扩大，依照试验拆分为多个工作进行解决。在治理计划上，次要是对试验的上线的审核和试验下线的治理监控。
最初，用一张整体的 AB 试验多维数据架构图来将上述介绍到的解决方案进行阐明，其中整体能够分为四局部。
- 第一部分为左上，将所有的维度合并到同一张 AB 专用维表中
- 第二局部为左下，构建 DWD 工作关联 AB 的个性化维度，并构建 DWS 工作依照 user_id 对数据进行压缩
- 第三局部为右下，通过配置核心管控计算 AB 实时数据的试验，并通过工作横向扩大和维度纵向切分将单任务计算的压力摊派到多个工作上
- 第四局部是右上，在 ADS 工作中，通过 Tumble 窗口的两阶段优化无效的压缩上下游算子传输数据量。
四、将来布局
快手实时数仓的将来布局分为夯实基建、降本提效和价值场景三局部。
夯实基建蕴含三点：
- 实时资产的对立治理。目前实时数仓资产的服务进口并没有对立，而是扩散在每一个开发人员的手中。实时资产的查问和应用的老本绝对比拟高，将来咱们会将实时资产的进口通过平台进行对立的治理和收口。
- Flink SQL 的精细化配置。比方对算子并行度进行独立设置，防止资源节约。除此之外，Flink SQL 降级后的状态兼容是一个难题，后续打算对 Flink SQL 算子的 ID 实现配置化，让 Flink SQL 工作可能更加轻松的进行降级。
- 实时工作的异样阻断。次要指实时维表工作呈现问题时，关联的 DWD 层和 ADS 层工作进行及时阻断，防止产生谬误的后果。
降本增效蕴含两点：
- Flink 工作的动静扩缩容，实时工作和离线工作的波峰波谷正好相同。在波谷时，咱们打算升高 Flink 工作的并发度，将这部分资源预留给离线加工工作，从而达到较高的资源使用率。
- Flink 工作的问题的智能诊断。接下来，咱们会将常见的问题进行归类，并联合对应问题产生时的指标异样进行联合，实现自动化。智能且高效地判断出问题的可能起因，从而升高运维老本。
针对价值场景，咱们会摸索湖仓一体化。目前，Flink 联合 Hudi 的增量计算场景，在快手外部曾经有落地。接下来，咱们会深入增量计算场景的拓展。除此之外 Table Store 也是咱们十分感兴趣的一个方向，接下来会尝试摸索利用，让实时计算和增量计算在业务场景中表演更加有价值的角色。
点击查看直播回放和演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc