2022年个推TechDay治数训练营《数据仓库与维度建模（下）》原创

你开了吗？啊，大家好，今天我们呃，进行下一。下一节的分享。那么分享之前呢，先看一下，回顾一下上一节的一个内容。上一节我们讲了呃，什么是数据仓库，为什么要建数据仓库，然后数据仓库怎么建设，提到了两，提到了呃两种建模方法。那上一节主要讲解了范式建模的。一些内容像呃一模型，包括呃123放式。那这一节呢，我们主要讲解维度建模。好，首先我们看一下维度建模的概念，维度建模是从分析决策的需求出发构建模型，重点是关注用户如何快速的完成需求。

同时具有比较好的一个大规模的复杂查询的一个性能。呃，也就是说呢，维度建模其实是以最终任务需求为导向的快速交付，敏捷迭代，不会对呃数仓架构做过多复杂的一个设计。那维度建模里面主要呃设计的两部分内容，一部分是嗯事实表，一部分是维度表，那我们从这两个呃方面来看呃是如何设计的？那设施表的一个设计过程，呃，主要分四步，那第一步呢是选择业务过程。那选择业务过程指的是啊，我们设计表的时候，是选择与需求相关的一个业务过程。

那业务过程指的是什么呢？是业务流程中的一个不可分割的一个行为事件。举个例子，比如说我们购物的流程，我们都在网上，呃，购物过吧，那我们购物的流程里面包括比如说加购啊，下单支付，然后是呃，商家发货，然后用户确认收货。这几个。业务过程，那整个业务业务流程里面。的业务过程就是嗯，比如说有下单，有支付，有发货这些业务过程。那第二个是声明力度。声明力度指的是。确定。去我们事实表里面每一行所表示的一个业务含义。

第三个是确定维度。选择能够描述清楚业务过程所处的环境的维度，比如说我们购物，购物所处的环境就是，呃，比如说某个用户在某个时间点买了某个商品，这就是。嗯，我们。这个。支付的这个业务。过程的一个环境。那第四个呢，是确定事实。事实就是业务过程的一个度量，比如说我们支付的这个业务过程，那他事实就是，比如说支付金额就是他的一个事实。设计事实表有以下几个原则，第一个是尽量选择最细力度，确保事实表有最大的灵活性。

因为选择最细力度以后呢，比如说后面你想要通过呃更粗力度的维度的统计的时候，就可以通过最细力度进行呃上卷来统计我们更粗力度的一个数据。那第二部分是，呃，第二个是分解不可加事实为可加事实，比如说不可加事实有像一些比率的。或百分比的一些事实，它就是不可加的。那可加的一般是比如说说嗯，像购买金额啊，这些购买数量啊，这些都是可加的事实。就是说这个事实可以根据不同的维度统计的时候，可以进行累加。

呃，第三个呢，是使用退化为保持试试表的一个易用性。那这里讲退化为其实就是，呃，我们后面会讲维表，嗯，就是维表里面的一个。维度属性会退化到测试表里面。那这样的好处是用户嗯，使用起来方便，不需要再使用事实表去关联维度表来去做一个统计。好。我们以。哪一个案例，呃，来看一下啊，以电商案例为例啊。首先业务需求，某电商平台业务系统中有用户商品下单等等业务数据，那需要统计呃，像商品每天的销售，商品类目每天的销售，店铺每天的销售，区域每天的销售，那么分析一下这个需求。

那这个需求主要是统计销售，那销售其实是在我们购物整个流程里面，呃，在支付。业务过程。他会有支付金额吗。那其实销售额是跟我们支付业务过程里面相关的，所以我们选择业务过程的时候，我们设计师表第一步选择业务过程，就是选择支付的这个业务过程。那因为上面要统计的是呃，商品包括商品类目，包括店铺，包括区域，不同维度的一个销售，那其实这些商品商品类目和店铺区域啊，它指的是不同的维度。那周期呢，是每天。

所以我。像商品类目，我们是可以通过商品维度来统计。那包括店铺区域都可以基于商品维度来进行统计，因为呃，你一个商品可以属于某个店铺嘛。那所以我们最细的维度啊，就选择商品维度，其他维度啊都可以从商品维度聚合得到。好，这就这是我们的一个订单支付的一个实时表。首先我们看第一步。选择业务过程，我们刚刚通过我们刚刚的分析，选择了订单支付的一个业务过程，那力度，力度表示的是，呃，这个事实表里面一行数据。

表示的含义，那我们一个订单里面可能会购买多个商品，那每个每个商每个购买的商品属于一个指定单，那其实我们选择力度的时候，是选择指定单的一个力度。第三个是确定维度。那维度就是所处的环境，就是某个用户在某个时间点购买了某个店铺的某个商品。呃，这些店铺啊，商品啊，类目啊，包括呃。这个。卖家，这些都可以认为是维度啊。呃，第四个是确定事实，确定事实我们支付里面有支付金额，当然如果呃复杂的还有像分摊的邮费或者是呃。

这个折扣或者是优惠券等等一些。那第五步是呃，其实这里第五步是呃。后面加的就是，就是我们之前提到的一个原则里面就是，嗯。可以使用退化为，那这里写的是冗余维度，就是将一些呃为表里面的一些属性可以退化到这个。事实表面，方便用户去使用。那像右边这张图呢，就是我们。订单支付的一个实时表，那中间这个是实时表，边上的这个是维度，那维度有店铺商品，包括地区、买家、卖家类目等等。

那我们，呃，实时表里面呢，它的这个度量油支付金额，分摊油费啊，折扣金额等等，还有其他的。那我们整体师资表的一个设计过程啊，就是按这四步或者是这五步。来设计的，那设置表。有常见的事实表有这么几类，第一个是事物型事实表。那事物形式表指的是，呃，一条记录是记录。时间点发生的一个事件。就是行为事件，呃，就像我们刚刚看到的支付的一个事实表，它就属于事务型的一个事实表。那第二个常见的一个事实表是周期型的快照表，它主要记录的是一个。

状态度量。主要描述的是一个啊，一段时间内。的一个状态度量。那比如说用户的一个积分，或者是用户账户的一个余额。它就属于一个周期性的一个快照表。那第三个呢，就是累计快照表，累计快照表一条记录啊，主要是记录整个业务流程。整个业务流程里面的多个业务过程。那一般会，嗯。用我们整个业务流程里面的。每个业务卧层的数据啊都会。写入一条数据里面，那主要的用途是。

啊，我们统计整个业务流程里面的流转节点的一个运转效率。周期性的快照表，我们周期性的快照表的设计步骤分两步，第一步是声明力度，那力度有呃。快照周期加采样的维度，第二步是确定事实，就是快照时间点的一个采样指标。那以我们账户余额快照四值表为例，那力度。是因为我们每天统计一个快照，那就是时间周期，是天。那我们一行的一行数据，他统计的是一个账户的一个余额。所以我们的采样的维度就是账户。

那这里有一个买家维度，因为一个买家。他可能有多个账户。可以，可以申请多个账户。第二步，确定事实，事实就是。账户余额，因为我们这边统计的就是账户余额的一个快照实时表。所以周期性的周期的快照试试表，它是描述一个实体啊，在一段时间内的一个状态的一个度量。好，第三种四时表，累计快照四时表，我们以交易累计快照四时表为例，在交易过程中。整个业务流程。会涉及到想下单、支付、发货、确认、收货。这些业务过程。

那。因为我们累计快照表里面的一行数据。会把。整个业务流程里面的业务过程会写到一条数据里面。所以我们选择业务过程的时候，是把整个业务流程里面的业务过程。选择。整个业务流程里面的业务过程第二步确定力度，那同样的跟事务形式表同样的是指定单力度。第三个确定维度，这个也是跟事物型实时表是相同的。有像店铺。卖家买家商品包括商品类目等等一些维度。第四步，确定事实。这里的事实是需要将我们前面确定的一个业务过程里面，每一个业务过程的事实都写入这张表里面。除了这些。

除了这些业务过程里面的事实以外，一般还会加入每个。业务过程的开始时间或者是结束时间。作为一个事务时间属性放在实时表里面。那累计快照表呢？一般就是用来统计节点，去分析节点间的一个运转效率。好，以上就是呃，事实表的一个设计过程。那第二块是维度表的一个设计过程。维度表主要分这四步，第一个是选择维度。选择维度表示的就是说呃。

呃，我们需要去生成一个什么样的维度表，比如说我需要生成一个商品维度表，那其实选择维度就是商品维度确定主维表，那主为表一般都是，嗯。来自于业务系统。表示的是一般来自于业务系统哪张表，比如说你要建商品维度表，那一般这里的主维度就是来自于业务系统的商品商品表。确定相关维度。这里的相关维度。嗯，说的是与主维度相关的一些维度。比如说商品为表。他可能是，呃，有。商品属于哪些类目？有类目的表啊，商品属于嗯。

哪些，呃，行业也也有相应的行业表啊，这个就是把主维度表的一些相关维度表先确定出来，那第四步确定维度属性。呃，指的是确定最终我们要生成的维表的属性，那这些属性一般都是来自于主维表和相关维表。将主维表和相关维表的呃一些属性进行集成，到最终我们生成的这张维度表里面。那维度表也有以下这三个设计原则，第一个是尽量生成丰富的维度属性。沉淀通用的维度属性，并且要考虑反规范化冗域。好，我们，嗯，以商品维度表举例，第一步选择维度。

就我们要生成什么样的维度表，那叫商品维度表。主维度就是商品表般来自于业务系统。第三步，确定相关维度，那商品由所属的类目，所属的行业，所属的品牌，包括所属的PU，那这里要说明一下商品表里面它的。力度。也就是说，每一行。它表示的是一个SKU，所以它有所属的s puu。第四步，确定维度属性，那就是主维表和相关维表按照需求合并维度属性。嗯，下面这张图。就是我们这个设计过程，比如说呃。商品维度表包括它的相关属性，在业务系统里面是是以这种关系存在的。那最终我们。

在出仓里面建设的商品维度表。就是把。我们商品主维表呢，包括它相关。为表的一个属性，全部。放在。我们数仓里面的商品为表里面，其实这里就是一个维度层次的一个扁平化。那当然我们维表它的属性并不是一直不变的，也会随着时间会发生变化。那一般随着时间发生缓慢变化的维度呢？我们称之为缓慢变化为。并且啊，把我们处理为表的历史变化信息的问题啊，称为处理。

缓慢变化维的问题，那缓慢变化维的处理啊，主要分这四种。方法。第一种是直接覆盖，嗯。可以看到这第一张图，首先第一个表是商品维度表。呃，第二个表是一个订单。支付表。那商品商品1000。它所属的类目是类目一，那我们2015年1月1号啊，支付了一条数据是商商品1000的。一条数据。那比如说2015年11月16号的时候，商品，这个商品从类目一变成了类目二。

那么11月16号的时候呢，又有一条支付记录。那这个时候。我们看到维度表，我们是直接覆盖。但是这样会有一个什么问题呢？就是我们11月16号的时候。如果我们去统计。我们类目一。他的交易金额。其实这里统计出来。类目一就没有了，那全部变成了类目二，因为这里商品K为1000的这个商品从类目一变成了内二，如果11月16号去统计的话，那么这这两条记录都会被统计到类目二里面。但是我们在10月11号如果去统计的话。

如果当时去统计的话，其实类目一是有交易记录的。但是11月16号去统计呢，就类目一已经没有了，所以。这样其实就是有问题的。所以也呃，我们之前讲到这个数仓有一个特性是可以反映历史变化的。那这里呢，其实反映的历史变化就是错的，因为他类目一的这个已经丢掉了。关联，如果去关联的话是关联不上。LA1。那第二种是添加属性列。去处理，缓慢变化为，那比如说一个商品从呃类目一变成类目二，那就。把嗯，使用一个新的。

一个字段来存储它新的类目。啊，这里呢，也会有一个问题。就是。你。你这个维度表它可能变化的次数你是没法确定的，就可能从内一变成内二，可能后面又会有变。那所以你你最终设计的字段，也没办法去确定你要设计多少个字段。并且。因为你没有对应的。对应的时间，所以呢。所以即使你把呃变化后。的一些信息存储下来了。但是最终你去关联这个我们订单表的时候，其实也没办法去确定我应该哪条数据去关联。

哪个类目？所以他会有两个问题啊，第一个是。只保留了历史固定数量的值。只是反映了最近的一个变化，并没有记录全部的一个变化。第二个是因为。变化的一个维度链，它没有对应的有效时间，所以没办法去回溯。之前的数据应该关联哪一个？所属类目。第三个是第三个是插入一个新的行来解决这个问题。那比如说我们商品1000从一变成一类二，我们插入一行新的叫1001。

然后变成零二，但是这里要注意这里的商品key呢是。其实是一个。代理组件，那这里有个商品ID，这个其实是智能键，就是业务系统里面的那个商品ID，跟业务系统里面是一样的。那所以我们这个商品为表的时候。其实是不会去改变，像这些属性是不会去改变。我们业务系统里面的一个字段，我们会单独增加一个代理组件，一个呃，无意义的一个代理组件，去作为整个商品为表的一个。组件。那如果是11月16号。我们修改了NAME2。那我们这里。商品就是支付订单里面的商品，Key呢，就是使用我们最新的一条数据。

那这样的话，我们就可以对应上就是。我。什么时候支付的订单就去关联哪一个商品key，这样的话去统计内一和内二的一个。一个交易金额就是正确的。这样的话就可以反映历史的一个变化。并且也是正确的。那第四种方式是。使用分区表。每天一个快照，保留历史的状态。对于维度变化，我们一般会采用呃，重写维度值的方式啊，以日期作为分区，每个分区保存最新的维度值。那比如说像这里下面这张图。他的商品key是不变的。

但是呢，他每天一个分区，每个分区都是呃全量的最新的一个数据，那11月16号这个分区，那是对应的这个商品属于类目一但。呃，11月11号的这个分区对应的这个商品的类目属于类目一，那11月16号的时候变成了类目二。那同样的在订单里面，他就可以根据对应的时间去对应的分区，去关联对应的这个商品key，那这样使用上是比较简单的。但是呢，它有一个缺点就是存储空间会比较大，因为每天呢，你会需要保存一个全量的一个快照。以上是四种处理缓慢变化为的一个方法。

下面我们讲一下数据仓库分层。首先在我们数据仓库建设过程中，会对数据仓库进行分层，然后分层有以下这四个好处，第一个是呃，数据分层可以。因为每一层啊都有相应的一个作用域和职责，所以这样的话，整体数据仓库的结构会比较清晰。然后对于我们使用表的时候，使用数据仓库里面的表的时候，也会更加方便的去定位和理解，第二个呢是减少重复的开发。我们通常会在数据仓库去开发一些通用的一个中间层。那这些中心层数据通常被重复利用啊。呃，以。减少一些呃，重复的开发工作。第三第三个是统一数据口径，通过数据分层提供统一的数据出口，统一对外输出数据的口径。

第四个是复杂问题简单化。因为我们整个。比如说你要计算一个任务，他可能需要分很多一步，那么将这些每一步的可以将这些分解成，就是将一个复杂的任务啊，可以分解成多步来完成，然后在每一层去解决对应的一些问题。那数据分层一般是，嗯，可以分成这三层，一个是ods层，叫数据接入层，那第二个是DWDW层，这里就是我们讲的数据仓库层，嗯，第三个是APP层，主要是应用层，主要是呃，业务直接使用的这一层，那数据仓库层呢，里面又会细分，细分成DWD数据明细层，DWS数据汇总层和DWM数据集市层，当然还有DM层就是。

维度为表层还有一个temp。这个time层一般是在做呃，数据处理的时候，一个临时的一个存放数据的一个层。那我们刚刚讲的像这几种事时表，比如说像事务形式表，周期快照实时表，累计快照实时表，其实一般都是会放在DWD层，那我们讲的维度表一般放在DD层。那每一层的边界ods层一般是做数据接入的，那主要是同步业务数据。到我们数据平台里面，那么基本上也不会去做呃处理，而是直接做数据同步。

那DWD层呢，一般是，嗯，来自是通过对ods层的数据做一个清洗，标准化以后的数据，然后这一层的数据也是叫数据明细层，也是力度是最细的一层。DWS层叫数据汇总层，一般是通过DWD的明细层去做一定维度的一个统计汇总。然后最终落地到DWS层。那DWM层叫数据集示层，那一般像我们的宽表。就会放在呃DWM层，那这一层一般是来自于呃DWS层的一个数据的一个汇总，一般是跨多个业务场景，那DDWS层呢，一般是单个业务场景。

那DDM层是维表层，刚刚我们说的维度表一般都是放在这一层，那APP层是叫数据应用层。一般是个性化的一些，呃，数据直接被业务使用到的一些数据，一般会放在这一层，那数据分层，层与层之间，它的数据流向也是会遵照一定的原则。那我们从这张图可以看出，最下面是业务数据，我们从我们数据是从下往上流转的，业务数据流转到ods层，数据接入层，那数据接入层又流转到DWD层。

那DWD层又通过一定的数据维度，维度的一个汇总会落到DS层。那DWS层。DWS层的数据也会流转到DDWM层，最终流转到B层那维度。维度表DM层，它是可以用在各个层之间的，那总体的原则呢是？我们一般是禁止逆向调用的，就是一定是从下面往上面的，不能说从上面往下。调用啊，不是不能从上往下去流转。然后第二个是。避免跨层的一个调用。最好是能避免跨层的一个调用。

好，以上就是我们呃维度建模的一些常用的一些内容。那最后一个部分，我们会讲一个简单的案例。我们以零售行业为例啊，呃，首先下面这张图可以看到下面这张图是零售行业的一个业务流程，那整体是比较复杂，首先我们看有三个角色，第一个是。零售商。第二个供应商和消费者，第三个消费者，那么零售商去向供应商采购商品，那供应商生产商品以后运输到我们零售商的一个仓库，那么零售商。会从仓库里面将商品分发到各个线下门店，那么消费者可以通过去线下门店去购买商品，或者是在线上去购买商品。

那整个流程是比较复杂，那我们下面会以消费者到线下门店购买商品的这个。这个过程为例来讲解我们维度建模里面的一个使用。首先简单介绍一下业务，嗯，比如说某大型连锁超市有几十个分布在不同城市的一个分店，用户购买商品都是通过收银机录入购买的一个商品信息和结算，比如说像右边这张图，大家应该都到过超市买东西，应该都见过这样的一个小票。那信息信息系统中，一般零售商的信息系统中会存储用户啊商品，包括门店的一些信息，那最常用的就是我们的呃，用户购买商品的一个呃流水。

这些信息。那比如说我们，呃，零售商他有一个这样的一个业务需求。啊，对于零售商。商店来说，一般它最大的。他最大的最终的目的啊，主要是实现利润的一个最大化，那利润又是怎么来的，主要是从商品去赚取商品的一个差价，尽可能赚取一个更大的差价。并且呢，又要降低商品的一个成本。所以在呃管理方面，一般都是考虑价格与促销这两个方面。那比如说。

因为我们利润是呃，每件商品的差价乘以销售销售量，那你差价越高，销售量越高，那利利润就越多，那所以一般我们会从呃。价格和销售量去考虑，那比如说像销售量一般我们可以。大幅降低商品的价格，这样是最直接最有效，可以去增加销售量的一个方法。但是呢，降低价格。又会降低。我们。每件商品赚取的一个利润，并且占。降低价格也是很难维持的，因为可能是整体利润会下滑，并且也可能是亏本销售。所以我们促销，我们需要对促销去做一个分析。

我们分析怎么样的促销方式是可以实现我们的利润的最大化？那如何判断促销是否有效？主要有以下五个方面。第一个促销商品。他在促销期间。是否有大幅度的？销量是否有大幅度的增加？那第二个呢，是促销商品在促销后与促销期间的一个对比，是否会在促销后。降低了。这个销售，那这种情况下，就是其实是。在促销后，其实是他的降低，其实抵消了促销期间的一个销售争议。第三个是。

促销分类中所有产品是否获得了销售方面的净利润？尽准争议。我们将会考虑促销前和促销间和促销后的一个时间段。那这个反应是市场是否增大了，促销后销售是否增加了？第四个是促销产品在销售方面表现良好。但是与它相邻的一些产品。如果销售降低了。那最终也不一定是利润是。增加了，那这种情况下就属于销售的一个侵蚀，那其实最终我们还是想要这个利润的最大化。那所以从这几个方面我们去看促销是否有效。

那我们就需要去呃，做一个数据统计和分析，那从这几个方面去统计和分析，我们可以看到基本上会涉及到的一些统计分析点。首先第一个。我们需要统计促销商品在促销前和促销间的一个销量。的一个对比，那第二个。我们需要统计的是促销商品啊，在促销期间和促销后的一个销量。那最后我们还需要统计，比如说像总的利润，那总的利润会涉及到销售，销售量包括价格，包括你因为你促销可能有打折的价格。然后。包括成本。

这些最终这些都是我们需要统计的，那最终我们是如何去设计这个我们交易的这个事实表。我们看一下。首先我们按照前面讲的事实表的一个设计过程。第一步是选择业务过程。那其实这里就是我们的POS机的一个交易过程，那力度就是。POS机交易的整个。那个订单里面的单个商品，其实就是我们前面讲到一个子订单，那维度就是有像日期，门店商品促销等等。首先日期维度，因为不同时间去促销，它效果不一样，比如说工作日，节假日啊，或者是不同季节，它去促销，它的效果是不一样。

那比如说门店，门店因为你不同门店，它所处的地域可能不一样，比如说南方北方，它可能促销不同的商品，它的。效果是不一样的。因为每个地区的用户啊，对他所兴趣，所感兴趣的商品也不同。那还有就是因为我们要统计商品的促销情况嘛，所以有商品维度啊，包括促销的维度。那这个就是我们创建的这个设施表的一个设计过程。那么这里主要提一下的是呃日期维表，呃日期维表它其实是一种比较特殊的维表，那几乎会出现在所有实时表里面。它跟其他维表有有所不同，因为日期维表它是可以提前建立的。

业务一般可能会通过不同的时间维度去统计分期，比如说像有工作日、节假日，或者是按周去统计，或按季度去统计。所以看到下面这张图就是。会常用的一些日期为表的一些属性。可以提前创建出来，提前生成好。那第二个为表，商品为表，这个是跟我们前面讲的一样的。就是商品主维度跟相关维度扁平化处理，最终商品为表的力度是以SKU为力度的，然后通过这个最细的力度可以去上卷到品牌或类目的一些分析。那门店为表，一般门店主要包括呃像公司的内部组织，或者是呃地理维度。因为。

每个地域维度，它促销每个区域啊，比如说华华东或者是华南，他每个区域它促销同样的商品，它可能效果不一样，因为每个地域的人，他对商品的，对感兴趣的商品不同。那最后一个维度是促销维度。那这个也比较简单，就是一些。促销的一些。相关信息，包括开始、结束时间。那上面我们讲的是其实是创建事务性的一个实时表的一个应用，那比如说。嗯。我们商店的库存也是需要优化的，商面库存的一个优化水平，其实对连锁店的获利也会产生巨大的影响，因为你如果一个商品卖的比较好，但是你缺货的话，那其实就是降低了我们的整体的一个利润。

或者是商品积压过多，比如说像一些食品，如果过期，也会导致我们的整体利润会下下滑，那商品的一个库存表。也就是说，嗯，每天可以去统。每天杂事。去我们商品每天的一个库存的一个现状，那像这种情况一般就是使用周期快照表。像下面这张图。那他的事实是一个商品的库存量，那他维度有时间店铺商品，那就。某一天，某个线下门店，它某款商品的一个库存量是多少？

那第三个。是我们累计快照表的一个应用，那比如说我们想要跟踪一个商品入库的一个进度，或者是效率，比如说商品入库，它涉及到有这么几个过程。有接收、检验、打包、托运等。一些过程，那么我们需要将整个过程，整个业务流流程里面的所有业务过程都放入一行数据里面。那么并且把每一个业务过程的时间也放入到。呃，一行数据里面，这样的话，我们就可以统计每个节点它的一个。运转效率。啊，这边是一个库存。

库存的一个表的一个。一个一个大致的一个情况，首先看第一行，首先我们第一个业务过程是接收。接收商品啊，接收商品有他的事实是接收数量，呃，第二个业务过程是。验收有验收日期，然后包括验收的一个事实。第三个业务过程是入库，还有入库时间，包括入库的一个事实。那这样把整个业务流程里面的业务过程都放到一条数据里面，这样的话，我们可以通过它节点之间的一个时间，可以去统计它节点之间运转的一个效率。好，以上就是我们对零售行业的一个呃简单分析，并且在过程中应用到我们讲的维度建模里面的常见的三种。

维度表，事物型的事物型呃维度建模中的三种事实表有事物形式表和。这个周期快照试试表，还有累计快照试试表。那最后大家如果有兴趣的话，也可以，呃，参考一下以下的一些链接，包括书籍啊，那以上的一些内容的一些。也是参考以下的一些资料。好，最后感谢大家，嗯，百忙之中抽出时间来听。分享。

最后这边有一个二维码，大家可以扫一下呃，如果想要关注后续的一些分享内容，或者是一些技术干货的一些资料，可以扫码关注一下。好。