个推TechDay治数训练营直播回顾：基于Flink的实时数仓建设秘诀原创

呃，大家好，我是来自个推的小子，呃，本期课程是基于flink的诗书仓建设。那么本期课程主要分为四个部分，那么第一块是讲解为什么要建实时数仓。第二，呃，第二块内容是数仓架构的一个整体的一个演进，第三块内容是实时数仓的一个技术选型。然后最后一块内容是基于flink建设实施数仓。那么首先是第一块内容。呃，第一块内容就是讲解为什么要建实时数仓。那么呃，当今呃场景下，目前的实时计算和分析的一个需求是呃越来越多，那么常见的，比如说实时数据可视化大屏，比如说实时监控的告警，以及呃实时特征工程和实时推荐。

那么常见的一个场景，比如说啊，淘宝天猫在双11的时候，它的大屏会实时的显示当前，呃，比如说最近一分钟的呃成交量，那么这就是一个呃，典型的一个实时计算的一个一个场景。那么第二个就是实时呃离线数仓的一个高延时，呃往往往传统的一个实时数仓的一个时效性是七加一，也就是说昨天的一个数据指标需要隔一天，也就是第二天才能够计算出来，调度频率也是以天为单位的，那么这个时候是呃无法支撑一个实时场景的一个数据需求，那么即使呃能够把一个调度频率设置成小时。也只能解决大部分一些呃，时效性不高的一些场景，那么对于一些比如说像时时推荐，那么这些要精确到一个分钟级甚至是秒级的场景，那么离线数仓是没有办法去做做一个支撑的。

这也就是为什么要建一个实数仓的一个呃，需需求。那么实时数仓的一个定义，那么关于实时数仓，其实目前一个呃，没有一个标准的一个定义，那么我们可以从以下几个方面来理解实数藏，那么第一个。呃，实数仓是要去支持一个实时数据的处理，并且能够根据业务需求提供实时数据，那比如说刚才提到的实时推荐的业务场景，那么第二个就是整体的数据链路会采用一个实时的一个方式，比如说呃，数据归集，加工处理和一个和数据分发等等，那么第三个就是呃，数据生态会采用一个实施方式，比如说啊数据建设啊，数据质量以及一个数据血源，数据治理等等。那么第二个，呃，第二章的话主要是讲一下，呃，目前一个主流的一个数仓架构的一个演进。

呃，首先是一副关于呃，目前一个整体数仓架构的一个发展的一个图，那么。可以看到主呃基本上主流的是呃，一个是经典数仓架构，那么随后就是一个离线数唱架构。然后目前由于实时一个场景的呃需求，那么后来衍生出的lemon架构和卡帕架构。那么第一个。呃，主要讲一下为什么会有这些数仓的一个演进，那么回到我们刚才提到的就是经典的数仓架构，呃在可能时间会比较久远，比如说呃，可能是几年前啊，那个时候数据量是比较小的，那么我们去使用一些呃经典的一些数据库，比如说呃，MYSQL或者Oracle，其实就能够支撑这个整体的业务。那么随着一个。呃，时间的发展，那么我们的这个信息数据量是越来越大的，而且是成一个子数据的增长，那么这个时候我们的一个传统数据库的是无法支撑这个数据量的。

那么呃，后来也就有了我们的这个离线数仓架构，那么离线数仓架构呢，呃，最经典的就是哈杜普的一个呃数那个数据仓库。是基于哈多的数字商户。然后本身就是哈杜自从他的呃问世以来，它的一些分布式的一个数据存储，呃提供了一个就是理论上是一个数数据可以呃无限扩展拓展的一个能力。这样的话能够支撑一个大的数据量。但是呃，刚才其实也提到过，离线数仓有的延延时高的一个问题，那么这时候是无法满足一个实时业务性的一个低延时的需求，那么之后在离线数仓架构的基础上衍生出了一个LA架构。那么那架构呢，其实呃，就是。

简单来讲就是在离线数仓的架构的基础上，那么衍生呃，新增了一条实时的链路，用于支撑这个低延时的一个业务需求。呃，然后由于level的架构是呃两条链路，也就是说是实时链路和离线链路是各一条，那么就会造成一个问题，就是呃，我同一个业务代码，我需要有两套逻辑去支撑，那么这样的话维护是相对比较复杂的，而且我的数据因为有两条链路要去走，那么这样的话我的资源消耗其实是也是比较大的。那么基于此，那么后面也有迭代出了一个版本，一个架构叫做卡帕架构，那么它的相对于的一个区别就是，呃，是使用一套逻辑去做这个实时的一个计算。那么混合架构呢，其实是，呃，目前由于LA架构和卡架构本身都有自己的一些缺陷。那么。

混合架构呢，其实是相当于融合的，这两个架构在就是说在一定业务场景上会有一个呃，Lada和KA的一个取舍。那么第二个是数仓工具的一个发展。呃，这是呃，一个数仓工具的一个目前的一个演变的一个过程，呃。我就不展开讲，那么整体的一个结论就是随着目前这个数数据语言的一个丰富和一个实时性的一些呃需求，那么现在的一个数据存储会越来越丰富，那么会呃，为了支撑一些数据分析场景，那么会衍生出一些比如说o lap引擎。呃，包括一些no的引擎，还有一些是数据，呃，搜索引擎，比如说ES之类的。那么这是一个数据，呃，收藏工具的一个发展。

那么回到我刚才提到的这个整体的一个数仓架构，我们从一个呃传统数仓架构呃开始。说起，那么传统智能架构呢？它主要存储的是一些结构或者是呃，半结构化的数据么？通过离线的一些ETL任务，那么定期加载到离线数仓，那么之后我们再通过一个计算引擎去取得结果，供前端展示去使用，那么这里提到的离线数仓和计算引擎，呃，通常是一些大型的数据库，我比如说我刚才提到的Oracle和MYSQL等等。那么离线储藏就是。呃，随着这个数据的规模增大，那么传统数仓其实已经难以去承载这个海量的数据。而且是随着一些大数据的一个技术的一个普及，那么已经有相关的技术去承载存储和计算任务，比如说常见的哈。

那么。呃，目前的话主要是一个基于一个数据库集群，比如说我的多节点的一个MYSQL。或者是一个MPP架构的数据库来完成。比如说常见的是哈加have或者是Spark。啊，或者常见的是还有一些GR的一个数据库。那么这里是有一个离线数仓的一个比较典型的一个架构。那么数据源往往就是我们一些业务数据库，或者是一些访问日志，比如说我的一些呃站点的一个访问，或者是一些订单信息，那么通过我的我的ETL，呃，任务会把这个数据去加载到我们的实时离线数仓。那么离线数仓的数据啊，通过一些呃计算，那么会把一些呃类似指标的一些数据，或者是一些呃汇总数据，那么去放到我们的一些数据应用里面，比如说常见的就o lap或者是一些呃搜索引擎去供呃外部去使用。

那么在数仓的内部往往还会有一个分层的一些设计，比如说像明细明细层，那么还有一些常见的事，像轻度的一些汇总层，那么这些数据的分成中间数据链路也一般也会通过这个离线ETL去加工生成。接下来的话是介绍一下LA架构，那么LA架构就是随着业务发展，那么企业啊对实时性有了更高的一个要求，那么在离线数上的基础上，那么我们会将呃高实时的一个部分的链路拆分出来，然后去增加一个实算链路，那与此同时，呃离线计算往往也叫做P计算。这个链路是依然存在的，然后最终有统一的一个数据服务层合并，然后给予前端去做一个展示，那么一般是以批量为主。

呃，实施结果，结果的话，主要是为了一些快速响应的一些场景。那么上面呃，图里面也可以看到，就是整个的两板架构是分成两条链路的去走的。呃，那架构详解呢，这一块呢，主要是讲一下就是两架构的经典的呃，一个设计，那么那架构设计的话，主要是分为三层，也就是批处理层，服务层和速度层，那么P处理层的话，主要是负责两块功能，第一个是处理数据。那么通常会保留一个数据的一个历史轨迹，那么类似于数仓的一个天元层的概念，那么第二个是根据原始数据知执行一些相关的业务，呃批处理运算，那么类似于呃数仓的一个中间层和汇总层，那么该层也可以达到一些数据修正的目的，第二个是服务层。

当我呃，当我们将一个批处理的数据，呃对外数据接口，然后可以提供一个呃低延时在线分析的一个数据服务。那么速度层，速度层的话，其实是类似于刚刚提到的实时链路，那么主要是一些呃实时数据的消费，然后并执行一些呃实时数据的处理分析，然后提供一个实时数据的查询能力。那么这个三层其实是呃，最开始由呃。创建这个lambda架构的一个。作者提到提到的一个整体的一个划分概念。然后这个概念的话，也是目前那么的架构的主要参照的一个一个，呃，类似一个。准则吧。呃，那么架构的优缺点，那么刚才其实提到了。

呃，他解决的主要问题是。呃。支持一个实时数据的一个能力，那么方式呢，是通过一个增加实时链，呃链条链路。那么它存在的问题是它的一个逻辑，那么需要用两套代码，那么维护起来相当复杂。那么第二个。多条链路意味着我的资源消耗是增倍的，那么消耗也会非常的严重。那么第三个。呃，实时电路和实时电路往往会有不同的技术，比如说常见的啊，我的离线会用MR，或者是实时去使用flink，那么这会有存在，就说不同的开发体系，那么使用组件会比较多，那么开发起来会难度也会比较大。然后第四点就是数据会散布在多个系统中，我们难以形成统一的数据标准。然后往往的话，实时的话数据数据的话可能放在卡夫卡，那么离线的数据的话可能就是放在have，那么数据这样的话就是存储的话是分离的。

就很难形成一个数据标准，比如说这个，举个例子。那么这里是一个LA架构的一个典型应用，那么下面就是一个，呃，经典的一个离线的一个应用，那么中间数据存储是使用的have的一个作为一个数据存储，那么中间。呃，是使用一些ETL任务做一个数据的一个加工，那么整体分层的话也是从呃原始层。一直到最后的一些汇总成。那么不同于呃，离线那个链路，实时链路的话，它的中间的数据存储往往是使用像消息队列，比如说像卡夫卡这样的数据存储引擎。然后中间的一些计算引擎的话，呃以Spark和flink为主，目前主流的话是呃是flink。

I。那么的架构。的演进，那么也就是开发架构。那么开发架构是在的基础上面去做了一些优化，那么他已经删除了。这个批处理层的一个架构，那么将数据通道以消息队列进行替代。然后，它既能够实现数据的处理，也能够在业务逻辑更新的情况下，重新处理前处理过的历史数据。呃，从这个架构图里面可以看到，不同于量架构，它已经把实时电路和离线电路整体整体划分到一个电路去。呃，接下来讲的是卡巴架构的一个优缺点，那么首先解决的问题。呃，那的架构本身是需要维护两套逻辑，那么一部分数据是在批量引擎做一个计算，那么还有一部分会在呃，流失引擎做一个计算，本身这个维护成本是相当高的，然后资源消耗也比较大，那么为了解决这个问题，开发架构在数据需要处理或者数据变更时。

去通过历史数据重新处理请求来完成，方式就是通过上游重放完成。也就是从数据源拉取数据，重新计算。那么目前存在的问题就是这个开发的一些相关技术是还不是很成熟，还有一些问题是需要解决的。呃，这是一个KA发架构的一个经典的一个示例，那可以看到和lemon架构的一个区别是在于。它的离线和实时的数据都是通过消息队列进行一个存储，也就是说他已经没有了这个离线和实时间的一个概念。

呃，和那么一个。区别主要就是这个链路的一个统一。那么。可还可以看到，就是它的内部分层其实和呃量架构还是比较类似的，也是一个明细呃到汇总的一个过程。那么这里讲解一下lab和KA的一个对比，那么对比的话会主要从实时计算。计算资源重新计算时的吞吐、开发、测试以及运维成本去做一个综合的一个对比，那么首先实时性上面。呃，首先LA架构和卡巴架构都是呃，对呃，为了解决这个实施的一个问题而产生的。所以两者的实施性都是比较高的。第二个计算资源，那么由于LA架构是批流链路同时存在。资源的开销相对会比较大，而开发架构的话是只有流处理。

那么仅针对一个新需求开发阶段运行两个作业，那么资源的开销是比较小的。呃，第三点。呃，重新计算时的吞吐，由于量架构在重新计算时是采用一个批次的存量处理，吞吐较高。而开宝架构，那么他需要去对一个呃数据。做用用流式的一个处理方式做一个全量处理，那么吞吐是相对比较低的，那么常见的场景就是比如说呃，我需要去对昨天的。呃，一天的数据，那做一个重新计算，那么首先呃，我需要去设置一个卡夫卡的一个offset。然后在设置卡outside之后，那么我需要用这个流失的这个程序从这个outside开始重新计算。那么这个相对于P任务而言，那它的吞吐是相对比较低的。

那么第四点。呃，开发和测试，那么由于他们的架构，它是有两套代码。那么看到它的开发和测试上线难度相对是比较大的，而卡巴架构的话，它是只需要实现一套代码。那么这个时候他的开发和测试上线的难度是相对比较小的，那么最后一个运维成本。Le架构需要去维护两套系统引擎，那么成本是相对比较高的，而卡化架构的话，它可以只需要维护一套系统引擎，成本较低。那么这是一个呃，LA的架构和卡布架构的一个综合的一个对比情况。那么混合架构。那么在真实场景里面呢，往往是呃，没有那么规范的。也就是说我的一些业务场景，呃，可能用没有办法统一的，只用一个架构就能实现它的一个所有的需求，那么往往会呃，会混合使用一个LA架构或卡发架构。

那么比如说呃，我的大部分的一些实施指标，我可以使用呃卡帕架构去完成一个计算，但是一些少量的关键指标，比如说呃金额相关的一些呃需场景。那么我可以使用Le架构，呃，用批处理去重新计算，那么增加一次校对过程，那么保证这个这个金额的一个准确性。啊，最后是介绍一下数据库，那么数据湖是呃，近几年来一个是比较呃。新的一个概念，在这个实时场景下，那么数据库是一个以原数据存储数据的一个存储系统，那么它是按照原样存储系统。而不需要事先对数据进行一个结构化处理，那么数据库是可以存储结构化数据的，比如说呃，关系型数据库的一个表，那么还有半结构化数据，比如说CSV日志叉ML和这份数据，以及非结构数据，比如说电子邮件，文档，PDF，还有就是二进制数据，那么比如说啊，图形，音频、视频。

呃，可以看到就是。在囊括的这些，呃，所有的一些数据类型的基础上，那数据湖还会去做一些集成的一些处理，比如说像数据治理啊，像安全管控，那么像一些质量检验的一些。呃，数据应用。那么。有了这个基础上面，那么会更好的就是帮助用户做一些数据的一个价值的一个探索。那么这里把数据库和数据数据仓库做一个对比。那么首先就是数据库是能够。处理所有类型的数据的，比如说结构化数据和非结构化数据，以及呃半结构化数据等等。

那么数据的类型是依赖于数据源系统的原始数据格式的。而数据仓库的话，往往是处理一些历史的、结构化的数据。那么往往这种情况下，他还需要有与一个事先定义的表的相吻合。那么第二个目的，呃，数据库的话是比较适合于一些数据深度分析，因为它拥有一个足够的计算能力去用于处理和分析所有类型的数据，那么分析后的数据也会被存起来。呃，供用户使用。那么数据仓库的话，主要是处理一些结构化数据，或者是将他们转化为一个多位数据或者是报表，那么满足后面的一些数据分析需求。那么最后是特点，那么数据库的话是比较便于探索创新，那么它的灵活性会比较高一些，那么数据仓库的话，它是主要的是一个优点是呃高性能，那么可重复性，那么主要是用于一个重呃重复持续使用。

那么这是一个，呃，目前一个常见的一个数据库事例，那么可以看到。呃，除了最开始的一个数据引擎之外，呃，数据存储就是消息队列卡法之外，中间的一些数据存储其实都是以数据湖为核心的做一个数据存储，那么中间会使用一些比较。流行的一些，呃，计算引擎，比如说link。然后数据在呃数据库做一个存储和计算，那么最终会产生一些呃一些指标性的一些数据，或者是一些汇总数据，那么可以去存到一些呃分析的一个数据库，比如说像ju的或者是之类的去做供外部的一个查询使用。

那么第三部分，那么主要讲一下实时数上的一个技术选型，那么这一块主要介绍的是一个。实时计算引擎。那么目前主流的一些计算引擎的话，主要是storm Spark和flink。我现场下面讲解一下，针对这三个数据引擎，然后如何做一个选型。那么这里是有一张表，那么是主要列的是主流的一些计算引擎呢，在各个方面的一些呃特性。那么可以看到，首先是storm storm，然后还有是Spark和flink。这块我就不一一列举。那么可以看到一点就是。呃，Storm和flink和streaming是都是拥有一个低延时的一个特性的，以及一个高高吞吐。那么呃，相对相对于一个STEM和Spark而言，Link会具有一个更丰富的一个API，以及一些更好的一些容错机制，一些更多的一些API支持，比如说像window和mark。

然后。在这个图里面还可以看到，就是steming和link，其实呃，它的一些功能和一些实现的一些特性其实是比较接近的，但是因为star目前呃，它的一个使用度和它的一个。呃，成熟度其实目前相对还有没有那么高，所以目前呃，在实时的计算引擎选择方面，那么以弗林会为主。然后STEM因为它的整个的一个开发的一个难度，然后他的一些特性的一些不支持，目前是已经逐渐被淘汰了，那么Spark streaming它的因为它本身的一些，呃，开发的一些多一派的一些支持，他的一些高吞图。

然后他的一些相对于呃一个低延时。那么。他的目前的一个基于历史原因，那么他在公司的一些使用方面还是相对是比较广的。那么在实呃实际的一个计算引擎的选型过程中，那么我们会主要是从延时和实时场景两个方面去做一个考虑，那么首先是延时的一个。要求，那么首先是延时要求是否低？那如果说延时要求是比较低的，那么是可以使用Spark streaming的。呃，因为SPA界面的话，它的APS相对比较丰富，而且它是使用一个VP的一个方式去做一个处理。它的吞吐量也是非常的高，而且目前呃，Spark的话发展的话，其实已经有。很长时间了，他的生态社区的生态是比较成熟的，那么如果说我们的延时要求是非常高的，那么会推荐一个使用一个flink，那么fli的API也是相对比较丰富的，而且呃目前的社区是非常的活跃的，尤其是在呃中呃国内。

相关的这个生态迭代比较迅速。那么最后还有一个是可以选用的，其实是STEM，刚才其实也提到过的，就是目前这个STEM的推广其实比较少，它的发展是相对是比较慢，不太成熟，所以使用的人也不多。那么第二个主要的一个考虑是实时场景的一个需求，那么如果说呃，实时场景的一些需求会比较特殊，比如说我要求一个窗口或者是wordmark之类的，那么我会推荐使用一个link。那这个flink对一些时场性的一些，呃，特殊的一些需求，那么知识的会比较完善，那最后聊聊就是storm，那么STEM刚才其实也提到了，他对于一些新的一些资源引擎的话，在很多方面其实没有一个明显的优势，而且它的开发是相对比较复杂的。

所以目前使用率较较低，而且是也基本上已经快被淘汰了。那么最后一部分，那么主要是讲一讲如何基于link去建设实施受伤。呃，首先聊一下就是为什么呃在刚才的计算引擎选型中去去选择一个flink，那么主要是呃，基于flink的一些一些常见的一些支持的一些特性，那么比如说呃，它的高吞吐，低延迟，以及它的高性能。然后还有就是它的一个。呃，高度灵活的一个流失窗口的一个支持，那么还有就是它的状态计算的exactly once予以支持。他的轻量级的一个容错机制。然后支持一般time以及一个乱气事件。然后最后还就是他的一个do统一的一个引擎的一个支持。

那么这些是呃link的它的一些特呃特性，那么其中有一些比如说像一般times这些呃窗口之类的。他的对一个实时场景的话，是有比较大的意义的。那么刚才提到那么FNK它的一个流PT体的能力，那么流批利体简单来讲就是我的流式计算和我的呃P计算，我可以使有一套代码去做一个支持，那么目前F的话，流B的话在SQ上面是相对是比较一个呃完善了。然而呃，他在一个API的一个。牛皮上面目前还在一个发展中。那最后就是讲一下这link的一个丰富的一个组件支持。

那丰富的组件支持，也也就是意味着啊，我这我用link可以去对应对接啊，多种的一个数据源，或者是数据的一个引擎，呃，常见的话就是在这个表格上面。呃，他其实是已经包括了我们一些常用，常用的一些主流的一些。呃，组建了，比如说常用的像消息引擎卡夫卡。然后搜索引擎像，呃。Lets search。还有一些，那么还有一些就是常见的像呃。JDBC，比如说像MySQL Oracle之类的数据仓库。呃，同时他flink是其实是一个统提供了一个统一的一个组建的一个API，然后去方便我们做一个呃，Connect的一个拓展。

那么接下来聊一聊实时书上的一个架构的一个整体设计。那么目前。呃，实时数仓的一个整体设计基本上是和离线数仓一致的，也就是采用一个分层的设计思想，那么可以看到图中么，一般去对接我们这个那个原始数据的话，也就是我们的ods原始层。那么ods原始原始层之上，那么会做一些数据的一些转换，那么形成我们的DWD的一个明细层，那么。呃，包括其中的有一些数据，那么一些维度数据，那么会形成我们的一个DM的维度层。那么通过数据转换，最后会生成一个DM的一个汇总层。那么这是一个实仓实施上的一个整体的一个呃，分成思路，这个基本上和离线数仓的话是一致的。那么时间数实时数仓的一个整体架构设计，那么会与离线数仓的设计会有一些区别，首先就是层次不同，那么实时数仓的话，为了减少这个延时，那么它的层层次会更少。

那第二个就是数据源存储不同，那么离线的话，我们这是离线仓库的话，主要是使用一些，呃，像have。这样的数据。存储。那么像实时的话，目前的话主要是用一个。呃，消息呃中间键，那么常见的话就是卡夫卡。那么像一些维度数据的话，主要会存在一些数据库，那么比如说h base或者Q。呃，我这里是分享一个，呃长一个实施书上的一个架构的一个整体设计案例。那么首先是ods层，那么ods层的话是常见的一些是一些我们的业务日志，或者是日志数据，那么业务数据的话，比如说我们的呃，电商场景下，那么比如说呃一些订单。

数据，那么日志数据的话，常见的话就是像比如说像web系统里面的一些买点日志，比如说呃，页面点击。或者是一些页面的一些访问的一些日志。那么在ods之上，那么就基于这个业务日志做一些处理，那么形成我们的这个呃，明细数据层，那么明细数据层的话是会基于这个数据的一个域或者是维度进行划分，那么常见的话也是经常也是经常场景下面，那么常见的话会有像流量，呃流量。或者是用户，那么或者是交易评论，那么按照这个主题域做一个划分的一个明细层。那么除此之外还有一个维度数据，那么维度数据的话，常见的话，呃，是像比如说门店项目页面，那么还有一些是一些呃，像比如说省市的一些位置这样的一些维度数据，那么主要是用于一些字段的一些扩充数据，有些丰富。

那么数据汇总层，那么就是基于刚才的明细数据层做一些数据处理，然后形成我们的这个多维的一个明细宽表。这样的话，他会把我们的多维度的数据统一放在一个表里面。然后数据汇总成生成的这个多维的一个数据宽表之后，那么我们会继续出，呃，生成一个应用层的一个数据，那么应用层数据其实主要是一个。这个对外的一个数据服务，那比如说呃，一个实时特征的服务，或者是实时O服务。那么到这一阶段，其实这个数据主要会用于对一个外部的一个用户提供一个使用。那么接下来呃，聊一下，就是具体的分层里面该怎么建设，那么首先是ods建设，那么ods建设，那么尽量要去保证这个数据源的一个统一，其次。

是需要用分区去保证这个数据的局部有序，那么常见的数据源，刚才提到的像呃，流量日志，系统日志以及这个业务的B。那么第二个是DWD层的一个数据建设，那么这一层的建设核心是解决这个原始数据的一个数据噪声，那么不完整，以及数据行驶形式不统一的一个情况，那么去形成一个规范统一的数据源，那么如果可以的话，就尽可能跟呃离线数据去保持一个一致。那么这一块的主要工作内容的话，就是数据解析，呃，业务整合。以及以及一些呃，脏数据的兴起，还有一些比如说常见的是模型规范化。

那么除了数据本身，那么我们还会在一些。数据上面去额外补充一些信息，那么以去应对一个实时数据，数据生产环节的一些常见的问题。那么比如说我一件。那么为了解决，主要是为了解决这个重复数据的问题，那么我们会呃给每一个数据打一个标记，去标记为一条数据，那么第二个是组件，那么也主要目的也是标记为一个一行数据，去保证这个分区的数据有序，那么第三个是版本。版本的话主要是呃，去应对这个表结构的变化问题。这样的话，我的每一个版本其实可以对应一张的表的，这样的话就避免了这个表结构变化存在的一个不匹配的问题，那么第第四个是一个。呃，批次。那么批次的话，主要解决问题就是数据重导的问题。呃，也就是当数据发生重导时，我可以更新一个批次。

那么。接下来是一个DM建设的一个。过程，那么主要分两块，那DM政策的话，主要第一块是这个变化比较频率比较低的一个维度数据，比如说常见的像地域信息，那么我们可以通过将离线中的维度数据同步到呃缓存，或者是通过一些公共服务以及维度服务进行查询，然后在缓存中进行访问，因为这块数据的话，呃，比如说地域信息，它的变化频率是非常的低的，那么。对于我们我们一个开发而言，其实是可以把这些数据做一个缓存使用。那么对于一些频率比较高的维度数据，比如说商品的价格信息，那么这个时候我们其实需要监测这个它的数据的一个变化的，那么这个时候往往是需要创建一张呃，价格变动的一个拉链表。那么下面两幅图其实也是在这两个场景下的一个常见的一个使用的一个案例，呃，事例。

那么DM建设的具体的一个使用方式，那么常见的就是一个呃，维表关联的方式，那么第一种方式就是维度交易。那么一般就是将我们这个维度表去全量的预加载到内存中进行关联，那么这样的实现方式呢？时间是比较简单的，但是问题在于它只支持一些小数这的维表。而且微表更新时是必须要启动任务的。整体而言它就是呃，总结下来的话，维度交易适合于小维度，同时变化频率比较低，对变更其实要求性比较低的一个场景，那么第二个外部存储关联。那么外部部存储关联的话，主要就是实时的一个程序，或者说一个链路，基于外部存储，比如说red ES或者是h base等，呃，维度数据的一个。

呃，数据库去做一个关联，那么同时使用一个开去减呃，减缓这个数据仓库的一个访问压力，那么这种方式下的维度数据是不受限于内存的，那么这个时候是可以支撑呃更多的维度数据。呃，但是呃，这个存在的问题在于。他的。维度的更新，呃是反馈到数据延迟，也会存在一定的延迟，那么这个是适用于数据量比较大，同时可以接受数据更新有一定的延迟的场景。呃，第三个是呃广播维度，广播维度的话，呃就是利用这个broadcast state将为表数据流广播到下游的呃task做一个交易操作，那么这种情况下可以及时呃观察到这个维度数据的更新，但是数据是保存在内存中的，所以也是仅支持少量的一个数据量。

呃，适用于一个需求实时感知维度数据变更的一个场景。那么最后是呃，DM汇总成了一个建设，那么这一块的话，其实。主要就是对一个共性指标的做一个呃统一的加工，同时根据主题进行多维度的一个汇总操作。啊，最后。呃，分享一个关于link的一个实时数仓的一个案例，那么这下面这幅图是一个整体的一个数据，从采集到最后一个。呃，展示的一个过程，那么首先是数据的一个采集，那么数据采集的一个数据源，那么主要分为两类，那么一个是业务数据，第二个是日志数据，呃，业务数据的话一般会存在DB中，那么常见的有是比如说像登录订单用户数据。

然后会存在一个MYSQ中，那么数据往往是通过一个变更信息的一个推送。去呃，完成这个数据的一个更新。那么第二个是是日志数据，常见的比如说像系统日志，比如说像操作日志，点击日志等等，那么这些数据往往是通过一些实时那个web服务，或者是或者是一些定时的一个服务去推送到卡夫卡。那么通过这一个两种，两种数据的一个采集，就完成了我们的一个原始层的一个建设。呃，在原始层建设之后，那么主要是利用一些我们的呃计算引擎。做一个数据的加工，那我们其期间会结合一些维度数据，比如说呃，刚才提到的一些像城市信息啊，像一些价格信息之类的一些数据。

作为一个关联去丰富一下，我们丰富一下我们的数据。呃之后会形成一些比如说像DWS层的数据，或者是adds层的数据，那么这些数据呃，一般会存在一些呃搜索引擎或者是一些ola引擎之内。主要是用于提供一个服务接口。那么这之后，呃，在一些呃，Web前端的页面上面，那么我可以去通过调用这个接口去展示一些我的一些指标型的数据，或者是呃，通过一些olab引擎，那么我可以对之前已经产生的一些没形成的数据。再做一个数据的一个加工。这样的话就是，呃，整个数据下来之后，我会拥有一个比较丰富的一个数据的一个能力。呃，不仅支持一些指标的一些计算，同同时能够支持一些自定义的一些呃数据的一些需求。那么这是一个呃，基于flink的实时数仓，那么从数据采集到一个最后的一个数据的一个呃，分析加工的一个案例。

那本期课程就。到这里。好，谢谢大家。