美团外卖流量数据的采集加工和应用
编辑整理：史士博
出品平台：DataFunTalk
1. 美团外卖流量数据采集历史
先介绍下我们团队做流量数据的历史演进过程，我们是从2015年开始做流量数据建设，早期的需求比较简单，主要是分析一些用户行为的 PV/UV。对此我们定义了一些code埋点，它是一种客户端和服务端联合的日志，同时在客户端实现了链路追踪，整体实现还是比较简单的。
2016 年开始，我们业务整体发展迅速，需要深入分析用户行为，所以我们在服务端定义了一套完整的日志采集规范，定义了page（页面）、block（模块）、item（元素）、source（来源）、target（目标）等采集内容， 并且在数仓层面完成了归因统计的数据建设。
到了 2017 年，我们的数据采集使用集团的流量体系，这套体系是客户端日志，主要有下述三个部分：
埋点管理：按照业务通道隔离，埋点统一注册、管理，业务字段管理，需求管理等
开发者平台：主要是面向RD，包括：客户端&前端 RD 使用的埋点 SDK 手册，QA 使用的埋点验证工具，数据 RD 使用的埋点数据表、数据服务接口等
事件分析工具：主要是一些分析工具提供基本数据分析能力，可以支持事件和页面的埋点数据分析
下面简单介绍下埋点在技术上的分类，一般埋点分为前端埋点和后端埋点两种。
前端埋点：
将采集的 SDK 集成在终端上，主要有三种：代码埋点；可视化埋点；无埋点。美团使用的是代码埋点，它比较明显的优点是：
高度定制、控制精准、采集的数据丰富准确
比较方便、灵活，能方便手机到用户在界面上的行为数据
可视化埋点和无埋点原理差不多，PM和运营同学可以在管理平台配置需要的埋点，然后SDK定时检测识别埋点的的控件，获取埋点数据。相比而言可视化埋点实施成本很低，但是埋点质量上我们觉得代码埋点远高于可视化埋点，如果场景简单或者业务处在初期阶段，建议使用可视化埋点或者无埋点这种成本较低的方案；如果业务比较复杂，公司研发规模比较大，而且对数据建设有比较高的要求，代码埋点是最好的选择。目前业界内，神策数据这几种方案都支持，GrowingIO主要是支持无埋点。
后端埋点：
现在很少单独使用，基本是和前端埋点搭配使用。它的优点是内网传输，即时性强，丢失风险小 。
2. 埋点信息与事件介绍
埋点采集的信息可以分为环境信息和业务信息两大类。
环境信息：环境信息包括一些常见的地理、设备信息，应用的信息，还有 SDK、事件生产信息等。
业务信息：业务信息主要是和当前用户行为有直接关系，比如说：操作的模块中业务字段，用户操作的页面的信息，还有唤起的信息等。
埋点事件分类主要分为三大类：
PV：页面事件或者叫做页面曝光事件，就是当用户打开美团 APP，每次进入一个页面的时候，就会立即上报一条页面的 PV 日志，每个页面都有自己的唯一标识 page_id
MC：模块点击事件。点击比较好理解，就是用户每次点击都立即上报一条 MC 日志，每个模块都有唯一标识
MV：模块曝光事件。曝光指用户浏览某个模块，就是用户看到某模块就会上报一条日志，在 APP 页面上，某个模块只要显示（只有一个像素出现在屏幕上）就会上报一条日志，同样每条 MV 日志都会记录模块的唯一标识
如上图中左下角是个实例：
在 APP 页面的顶部，我们用绿色框圈中的部分是一个 banner，上报这个 banner 日志的时候会携带 page_id ，和首页 pv 日志的 page_id 值相同，上报曝光、点击日志的时候都会有一个自己的唯一标识。中间是频道区，同上面的 banner 一样上报时都会携带 page_id，每次点击都会上报模块唯一标识 click_id，这 15 个频道会分别上报15条曝光日志，它们的 page_id、view_id 相同，通过位置字段（从 0 位到 14 位）来区分。再下面这个的 banner 位置日志上报规则同顶部 banner 相同。
在这样的事件分类下，我们把一个用户行为按照时间排序得到图中右下角所示的序列：用户首先进入一个页面上报PV日志，会看到很多模块上报MV日志，然后点击某个模块上报MC日志，接着发生跳转跳到新的页面，然后接着浏览、点击、跳转、浏览 ......
从这样一个序列中可以看出在整个上报日志中，数据量最大就是 MV 事件。
3. 埋点规范与协作流程
接下来介绍埋点规范与协作流程以及一些问题点。埋点这个事情是一个多团队协作的事情，需要大家一起协同，所以流程、规范很重要，不然会发生不必要的分歧。
协作流程：我们的流程是这样的，先由需求方提出需求交给业务 PM，业务 PM 在埋点平台做埋点配置，埋点平台根据配置生成代码给到客户端 RD，客户端RD 使用埋点 SDK 做埋点实施，实施之后由客户端 QA 来测试校验然后上线，接着数据组 RD 使用日志数据表加工数据将数据结果交付给数据组 PM，最后将结果交付给需求方。这里简单说下埋点配置环节，在美团外卖是由业务 PM 来统一负责，同时数据团队做规范的指导、定期参加一些埋点评审。
埋点规范：主要是约束一些字段的上报方法，包括字段名称、上报时机等。
问题排查：在问题排查方面，我们有一套比较完整埋点问题追踪流程，也是方便后续做埋点问题的复盘。
埋点 SLA：我们专门制定了一套埋点 SLA ( Service Level Agreement - 服务级别协议 ) 机制，目前这块主要由客户端 RD 和 QA 来保证 SLA，业务 PM 根据埋点重要性提供需要保证的 SLA 列表，数据组提供监控工具。
数据生产链路主要有以下几个阶段：需求、配置、埋点、验证、上报、日志表。
流程是：在需求确定之后会做埋点的配置，客户端进行测试上线。之后客户端会根据用户行为将日志上报（这里分为实时上报和延迟上报两种）到 nginx 服务器，通过 flume 将日志收集传输到 kafka 里，然后做实时处理，包括数据校验、过滤、字段拆分等比较简单的数据处理，之后将数据落地到离线的 log 表，在离线阶段的会进行比较重的数据处理操作，比如去重、关联、标记等，最后产出公司级别数据表，提供公司各个业务部门使用。
4. 埋点注意事项
前面介绍了埋点的基本信息与规范流程，这里给大家介绍一些埋点的注意事项。个人觉得做埋点还是非常需要经验的，甚至是需要更多的试错，这里给大家列了一些注意事项以供参考：
同质参数的名称和类型保持一致：主要就是体现在通用参数、业务参数、行为标识的统一，尽量做到事前治理，给整个的数据加工、数仓建设减轻工作量，当然在数仓加工过程中也一定要做一些容错；
通用复用：尽量少的创建新的事件，而是想办法复用原来的事件，方便后续的埋点管理；比如某弹窗在很多页面都出现过，弹窗模块曝光标识需要是唯一的，当它出现在不同的页面的时候，我们可以通过页面标识 page_id 来区分，而不是每出现一个新的页面就重新定义一个模块标识；
最小粒度：埋点定义到模块内的最小元素，可以避免重复上报；
合并上报：相同模块的 MV 事件可以合并上报；某一页面中一定出现的元素可以不用上报 ( 这里是指 MV 曝光事件 )，或者和 PV 时间合并上报，在 PV 中加一个字段标识即可；
历史兼容：不能改变已有事件标识的含义，不能改变属性标识的含义，不能改变参数值的含义；一般只做新增，不做修改，可以废弃；
追踪回溯：埋点设计文档可以回退到历史版本，便于排查问题。
介绍完了埋点信息，接下来重点讲解流量数仓建设和归因建设，首先介绍流量数仓架构。
1. 流量数仓模型架构
在整个流量数仓建设过程中还是面对很多挑战的，比如：
数据量大，每天几百亿条的日志，数仓模型要使用成本低、查询性能较好；
采集的客户端种类多、日志种类多，数仓建模过程中维度建设复杂、数据整合复杂；
业务系统变更频繁，特别是资源位、广告位变更频繁，数仓模型要及时响应、运维成本低；
多变的归因统计需求 ( 目标行为和来源行为都不固定 )，需要归因模型使用成本低且易用性高。
整个流量数仓架构如图中所示，与之前惠明老师介绍的《美团外卖离线数仓建设实践》基本相同，具体细节可参考原文，这里稍微讲下：
ODL：Operational Data Layer，操作型数据层，这一层主要对采集到的数据进行无损着陆、基础字段清洗加工。ODL是原始日志明细宽表，完成了日志数据清洗过滤、归因建设、公共维度建设等。全链路归因建设在这一层实现。公共维度建设比如地理位置维度生成、常用维度代理键生成等，下沉到ODL来进行，降低了运维和下游使用成本，需要依赖于DIM层的环境维度表。
IDL：Integrated Data Layer，集成数据层，这一层在ODL之上，主要完成领域数据建模，描述业务对象属性、业务对象间的关系、业务行为属性、业务行为与业务对象的关系等。IDL层是明细宽表层，根据数据域和业务过程进行主题划分，在主题内描述业务对象和业务行为，特别是对主题内常用的扩展维度字段进行提取，并且进一步使用维度退化手段，提高明细宽表的易用性、降低使用成本。例如搜索主题筛选了用户搜索行为相关的日志，并将描述搜索业务的扩展字段进行提取。
CDL：Component Data Layer，元件数据层，这一层在IDL之上，主要完成分析实体识别，在主题划分基础上，形成分析实体/实体关系特征模型，对模型的指标进行加工，分为明细数据视图和聚合数据表两类。
MDL：Mart Data Layer，集市数据层，这一层在CDL之上，建立在主题划分基础上，通过维度层级汇总形成汇总表，通过维度主键关联形成宽表，给数据应用提供便利应用的半成品数据集，例如，常见的商家流量宽表（商家的点击、曝光、进店统计）。
ADL：App Data Layer，应用数据层，不属于OneData内统一建设，这一层在MDL之上，直接面对数据应用，优先使用MDL的数据，当MDL不满足时，可以向下使用CDL、IDL的数据。ADL作为数据应用的个性化数据一般不对外提供数据服务。
DIM：公共维度层，包括了流量数仓建设过程中使用的流量维表，分成主题维度表和环境维度表。其中主题维度表将埋点标识（用户行为标识）映射成主题维度，是IDL、CDL进行主题划分的核心维度表。环境维度表包括了流量静态属性中常见的维度，例如app名称、启动渠道、设备类型等，主要应用于ODL层的公共维度建设。
2. 流量数仓建设原则
在数仓建设中有很多原则，这里拿出其中三个在流量数仓中比较重要的原则跟大家分享下：
① 高内聚和低耦合
将业务相近或相关、粒度相同、高概率同时访问的数据放在一起。具体在流量数仓建设过程中，合理的主题划分其实就是遵循高内聚低耦合的原则。不合理的主题划分会导致数据使用成本、运维成本增大。主题划分是和业务强相关的事情，需要大家定期 review 自己的主题划分是否合理，一定要紧跟业务需求。
② 公共处理逻辑下沉且单一
越是底层公用的处理逻辑，越要放在数据底层封装与实现，不要让公共逻辑多处存在且暴露给上层的表。流量底层数据的公共处理逻辑主要是环境维度建设和归因建设。
③ 成本与性能平衡
适当的进行数据冗余来换取查询和刷新性能，但不要过度冗余与数据复制。这是最通俗易懂的原则，但在流量数仓建设过程中，需要综合考虑各种使用场景，实践起来很难。美团外卖每天的数据量几百亿条，这样一份数据，如果在多处出现复制，对存储资源就是很大的浪费。成本与性能平衡确实需要多思考，在做数仓规划时就需要把这个事情考虑到。具体实践如下：
仅在IDL层保留了明细的日志数据，且通过维度退化手段提高明细宽表表的易用性、降低使用成本。
IDL层的主题划分过程，如果B主题是A主题的子集，两个主题的区别在于业务描述（业务扩展维度字段）不同，那么A主题使用表来存储逻辑和数据，B主题在A主题表之上使用视图的方式存储数据加工逻辑。举例来说，在美团外卖app首页存在着很多资源位，资源位中有有一部分是营销活动的位置，那么营销活动主题就是B主题，美团外卖app首页资源位主题就是A主题。
在CDL层对明细数据也使用了视图，不再占用物理存储。
3. 维度建设
为什么常说流量数据在做数仓建设时比业务数据困难，个人觉得是因为流量数据的数据源本身是一些半结构化的数据，没有分析维度的概念，所以在数仓的建设时我们要做很多的维度建设工作。因此维度建设是整个流量数仓工作中最核心工作，同时也是最大的难点。
我们维度建设分为两种，环境维度和主题维度。
环境维度：
环境维度是指用户行为所处的环境描述，例如用户的定位城市、用户的设备类型、用户使用的app名称等，这些维度是在主题划分基础上，分析实体维度模型中最主要的维度，即用户在选定业务过程后最主要的分析视角。环境维度建设主要遵守公共处理逻辑下沉且单一这个原则，在ODL完成建设。环境维度建设过程中，如果分析的维度在日志中已经存在明确字段，且该字段具有业务含义并是自然主键，那么就会直接使用这个自然键和相对应的维度属性表。如果分析的维度需要日志中的多个字段联合，这时我们会对这多个字段生成一个代理键，并构建以这个代理键为主键的维度属性表。
举例来说，终端维度需要由日志中的操作系统类型、app名称、启动渠道这三个字段联合生成。如下表所示，我们使用这三个字段生成了一个代理键终端id。特别说明的是，终端id的映射维表并不是简单的可以通过操作系统、app名称、启动渠道这三个字段关联得到。比如，终端id = 3的这一行，操作系统字段可以为任意值（对上报日志不做要求）。这就要求我们在生成代理键的时候需要采取一种更加灵活的方式，以应对上游数据的不确定性冲击。所以我们使用了UDF来实现：
UDF ( 操作系统，app名称，启动渠道 ) = 终端id
UDF中可以适配各种灵活多变的映射逻辑，这样大大提高了我们的灵活性，降低了运维成本。
代理键生成之后，我们构建了终端id为主键的维度属性表。
主题维度：
原始日志在采集上来之后，是不具备业务过程分类的，仅仅能通过埋点标识来做区分。所以我们需要对日志进行主题划分，也就是业务过程划分。举例来说，我们想知道一个用户在外卖搜索页的全部行为，我们就需要先找到外卖搜索页的全部埋点标识，然后从原始日志中过滤出来。主题划分就是，将原始日志进行按照埋点标识划分到不同的主题表中。
我们将外卖整体的业务过程按照实体加行为进行抽象。外卖业务中，常见的实体包括用户、商家、菜品、订单。实体和实体之间通过行为来连接。比如，用户和商家之间的行为可以有搜索、使用智能助手、使用购物车、点击商家资源位等。
我们将这个埋点标识与主题表中的业务标识构建成主题维度表，用于管理埋点标识与业务标识的关系。在主题维表中，业务标识使用代理键，并在IDL中通过主题维表关联出代理键。主题划分过程中，我们还需要将主题内常用的扩展维度字段进行提取，对于不同的埋点提取这些字段的方式不太一样，我们也将埋点标识与主题扩展维度提取方式的对应关系维护在主题维度表中。
以资源位主题为例讲解一下建设的过程：
业务过程描述：在做主题建设时我们首先要确定业务过程，这里的业务过程就是从外卖的资源位点击开始，用户在点击之后会进入商家页，然后进入提单页提交订单，最后下单。
业务过程提取：描述清楚业务过程之后，要对业务过程进行提取，即从 ODL 日志中找出所有浏览和点击的日志，具体做法是：
首先维护一张资源位主题维度表，表中记录下埋点与资源位的对应关系
然后通过 ODL 日志表与资源位主题维度表关联即可获得资源位埋点的浏览、点击明细日志。
同时我们在描述资源位这个业务活动的时候需要看资源位位置，这个位置就是描述用户点击的商家在商家列表的第几位，资源位位置在各个埋点里上报的值可能不一样，所以需要在资源位主题维度表里记录埋点标识，记录好之后在加工 IDL 表时就可以根据埋点标识将资源位位置加工出来。
同理进入商家页、进入提交订单页还有提交订单的业务过程提取也是一样的，先找出他们的日志，再根据维表信息关联加工出 IDL 表，只不过这里的关联字段使用的链路信息字段
维度管理：
在维度建设这边，最后再聊下维度管理的事情，从刚才的内容大家应该也可以感受到，在流量数仓中维度建设是最核心的内容，它决定流量数仓的分析视角以及流量数仓的运维成本，在做流量数仓建设时建议认真做下维度管理。
我们是专门做了一个工具来做维度管理。所有维度信息在管理平台统一录入、校验、更新，最后同步到数仓的 DIM 层，给数仓的生产使用。这样降低了数仓的运维成本。
4. 归因建设
归因需求介绍：
前面内容我们讲了数仓整体架构以及维度建设方面内容细节，接下来我们介绍流量数据最核心的、也是大家会经常遇到的归因建设。在流量数据分析场景中，有一类需求是基于单一埋点或埋点集合的且不需要进行日志关联的分析，比如某种用户行为的人数、次数等；另一类需求是需要将日志进行关联并且对日志的先后顺序有要求的分析，比如常见的统计经过外卖首页商家列表点击后的成单行为人数、次数。第二类需求其实就是我们说的流量数据归因。
流量数据归因建设在外卖业务场景下是非常难的，难点有二：数据量大，在几百亿条的日志中，将需要的日志进行关联是非常耗时、耗资源的；需求不固定，通常我们无法预知需求方想将哪些日志做归因分析。
因此，流量数据归因建设要重点解决这两个难点问题，特别是难点二，由于需求的不固定，我们要实现全链路的归因建设，而不是只针对某些行为的日志做归因建设。
首先，我们要将需求简化并且标准化，我们将所有的归因统计抽象成如下问题描述：
统计经过A行为的B行为的次 ( 人 ) 数
应对这样的问题，给出的伪SQL：
select count(1) from 日志 where 行为 = B and 链路信息 包含 A经过这样抽象后，我们发现问题变得清晰一些，这个伪SQL就是所有归因分析场景的标准化查询。问题聚焦在'链路信息'的建设。我们要为每一个用户行为建立一个链路信息字段。
什么是链路信息呢？在外卖业务场景下，链路信息是：某一行为的时间前序行为集合，集合中不包含相同页面之间的行为。
链路信息建设：
在目标表中，为每一行数据新增一列链路信息，使用数组格式来存储当前行的行为的链路信息。数组中每一个元素即代表一个时间前序行为（排除了MV事件），其中包含的字段会选取一些业务独特的、与当前行为不同的字段（不包括通用环境字段），这是由于一个行为的时间前序行为中，通用环境字段一般是相同的（比如设备号、操作系统等），且通用环境字段已经作为了分组排序的条件。这样设计表结构的好处是：目标表的行数没有变多；对所有的用户点击行为和用户进入某一页面行为加工了链路信息字段。
可能会有同学质疑这个字段会不会特别长，特别是当用户行为链路特别长的时候，后面的行为日志这个字段值会很长。这种场景下我们就需要考虑到底哪些行为应该放在这个字段里，这里我们使用因果关系来判断哪个行为是这行日志的原因行为。
我们将因果关系定义为为与相同页面之间的事情无关。如上图中事件序列记录某用户从 P1 点击进入 P2 再点击进入 P3，然后又回到 P2 接着回到了 P1 又点击了其它模块。在这段用户行为中 P3 的链路信息如图中所示彩色部分只包含第一次到达 P3 时经过的路径；M5 模块的链路信息如图中彩色模块所示，我们认为图中所示的两个 P2 之间的链路与 M5 链路信息无关；M7 的链路信息同理。
这样我们屏蔽掉用户操作过程中的回退操作，最终记录的链路信息字段值不会很大，当然这种因果关系一定要契合业务情况。
定义好链路信息和目标表结构之后，我们进行数据加工，链路信息字段使用udf（自定义函数）来加工得到，伪SQL代码如下：
insert into target table select log表中的字段，udf(归因处理输入字段) as 原因行为 from 分组排序后的log表归因处理输入字段选取了部分通用环境字段和业务字段，通用环境字段用来判断当前行数据中的环境参数是否发生变化（例如是否换了一个设备），业务字段主要用于udf的输出结果。具体数据处理流程如下：
1. 对日志进行分组排序，使用distribute by按照通用环境字段进行分组，使用sort by按照时间戳顺序排序，这样保证了相同分组的数据分配到同一个reducer当中进行处理，并且是按照时间戳排序之后进行有序处理；
2. 在日志分组排序之后，进行链路信息字段加工，使用hive udf来实现。在udf中，通过栈来存储链路信息，一次udf执行过程简述如下图所示：udf输入参数的通用环境字段用来判断是否更换了设备或app，如果通用参数发生变化，说明上一个分组内的数据全部处理完，清空栈内的数据，把当前行为入栈。如果通用参数没有发生变化，说明仍然在处理相同组内的数据。需要判断当前行为的加入是否发生页面回退，如果发生页面回退，则需按将相同页面之间的行为出栈，最终将当前行为入栈。
3. 结果数据输出过程中，会首先进行行为标记，比如将每个页面的最后一次点击行为进行特殊标记，然后再将栈中所有的元素放入数组中，作为最终的链路信息字段。
链路信息字段加工之后，我们要使用这个字段来解决流量归因统计需求。我们回过头来看一下之前提到的流量数据归因建设两个难点。其实，把问题标准化成统计经过A行为的B行为的次（人）数，并且加工出链路信息字段，就已经解决了上述的两个难点问题：链路信息字段是经过分组排序加工出来的，等同于提前做好了日志关联；对所有的用户点击行为和用户进入某一页面行为都加工了链路信息字段，实现了全链路归因。链路信息字段加工过程是与业务需求解耦的，即不根据业务需求定制化开发，这就使得我们的方案具有很强的灵活性和拓展性。在IDL层可以根据主题的需要取出任何主题所需要的归因数据。
其中，链路信息包含某行为需要通过udf来实现，因此我们开发了一系列的udf、udtf来使用链路信息字段。
前面介绍了在归因建设中我们使用的链路信息追加的方案，可能在业界其他团队使用的是其它的方案，比如挂单，这里给出不同方案的简单对比：
链路信息追加：典型空间换时间的方案，特点是存储冗余，同时需要写UDF实现，有一定使用成本，但是它比较灵活，可以支持任意的原因行为、目标行为分析
指定目标事件归因：这种方案是针对固定场景的，适合在需求比较固定的业务场景。比如在当前阶段，我们只对订单这个事件做归因分析，那就可以在每条日志后面加一个字段记录订单id。相对链路信息追加这种方案的特点是存储不冗余、使用成本低，适用于需求固定的场景
仔细对比我们会发现这两种方案是对称的，链路信息追加存储的是当前行为之前发生的行为，挂单存储的是当前行为之后发生的行为。
勾稽关系：
接下来介绍一个流量数据校验方案，勾稽关系校验。勾稽关系在流量数据加工过程中可以很方便的做监控、校验。比如一个简单场景就是落地页流量要等于来源流量，搜索点击的人数一定是跟搜索页面浏览人数相差不大的。这里将勾稽关系单独列出，也是希望大家在做流量数仓过程中可以灵活使用它。
5. 埋点治理
介绍完数据加工内容之后，我们讲解下数据治理方案，整个的数据治理或者数据资产管理包含很多工作，细节可以参考《美团外卖离线数仓建设实践》，这里简单介绍下埋点治理方案。埋点数据的特点是数据量级很大，因此在做埋点治理时一定要做 ROI 评估，目前的办法就是做血缘追溯，追溯埋点在ETL任务中的使用情况。
我们将埋点使用情况分成了三类：
在数仓内建设的表，IDL层的表会属于唯一一个主题，且该表内使用的埋点就是主题维表中的所有埋点；CDL层会依赖于IDL层的一个或多个主题表，可以通过CDL中主题维度代理键使用情况标记出该表使用的所有埋点；MDL层如果依赖于IDL、CDL、MDL的主题表，同样可以通过主题维度代理键使用情况来标记；
ADL层的表比较灵活，如果直接依赖于IDL层的明细数据表和主题维表，可以通过主题维表的使用情况来标记使用的埋点；
ADL层的数据直接依赖于IDL明细数据，并且直接使用了埋点唯一标识，那就可以直接标记出所用的埋点了。
将全部使用流量数据的ETL任务标记完之后，我们就可以给每个埋点进行评分，分数较低的埋点会进行有计划的删减和治理，对于分数较高的埋点会进行更好的监控及跟踪。
最后简单说下外卖流量数据的应用，目前主要有三类：
OLAP 分析：事件分析、页面分析、资源位分析、AB 实验分析
用户行为分析：漏斗分析、路径分析、留存分析、用户细查、用户分群分析；目前主要使用的技术是 Doris
标签数据层：流量数据很大部分场景都是在标签应用，比如：算法策略、营销都会用到标签
在 OLAP 引擎方面，大家都很了解，不做过多介绍，美团外卖对Doris、Kylin、Druid 都有使用，对几种 OLAP 引擎对比以及在美团外卖的使用场景如下图所示：
经过几年的建设实践，美团外卖流量数据仓库已经提供了完善、准确的离线数据服务，未来我们将更加关注实时流量数仓的建设，特别是实时数据全链路归因建设依然面临着一些挑战。
在数据治理方面，我们将持续完善数据监控、完善埋点血缘检测，并将预测算法、根因分析等应用于数据监控和问题分析，进一步的降低运维成本
在数据产品方面，我们将继续打造一站式分析平台，让用户更加自助、灵活、即时的进行行为数据分析
今天的分享就到这里，谢谢大家。