一、魔镜平台背景介绍
首先和大家分享魔镜平台的背景。
1、遇到的问题&破局思路
2015年左右，整个互联网行业处于高速发展的阶段，业务多样化，变化快，同时期在爱奇艺也有着非常多的创新业务在发展。由于业务的快速发展，固定的报表开发难以满足业务方的数据需求，BI的表现主要是数据需求多，需求变化快，为了保证工作的有序推进，BI需要对业务的数据需求进行评审，然后根据优先级进行排期开发。对业务来说，数据工程师逐渐成为业务获取数据的瓶颈，难以满足业务的需求。
为解决这些问题，我们解决问题的思路是赋能业务自助获取数据的能力，因此开发了数据分析平台魔镜，提升业务获取数据的效率。
二、魔镜平台各阶段发展历程
1、魔镜平台各阶段发展历程
魔镜平台从2015年到现在共分为三个阶段，第一个阶段是2015年魔镜1.0上线，主要支持pingback投递管理和可视化分析。第二个阶段是2019年上线了魔镜2.0，主要支持数据仓库表接入和数据分析模板化。第三个阶段是2022年上线了魔镜3.0，主要支持分析智能化与分析模板优化。
2、魔镜1.0
2015年魔镜1.0架构，在产品功能上支持了投递注册，在计算层面支持基础计算、计算列表及计算执行结果的查看。在服务层主要支持投递注册、表管理以及对应的ETL。服务层主要支持基础计算的SQL生成、计算执行及结果查看。引擎端主要支持Hive引擎。
（1）下面简单介绍魔镜1.0的前端交互页面。
魔镜1.0的基础计算，前端配置主要分为三个部分，第一部分是选择业务和表名，第二部分是计算信息的配置，主要是包括维度、指标以及计算条件。第三部分是配置计算的基本信息。通过简单的三步配置，就可以让用户拥有自主分析数据的能力。
（2）接下来介绍魔镜的执行计算和查看计算结果。
在计算执行层面，我们支持三种方式，第一种是计算一天，第二种是支持连续执行多天，第三种是支持自定义多天。
第一种很好理解只统计指定日期一天的数据。第二种连续计算多天，通常用户在创建完计算之后需要回溯历史数据，连续执行多天支持选择一个开始时间和一个结束时间，平台能帮助用户去执行这段时间内每天的计算。第三种自定义执行多天可以指定一段时间内非连续的某几天日期。例如可以选择1号、3号、5号，当用户只需要回溯一段时间内的某些日期的数据时，可以节省用户回溯历史数据的时间。下面的图是计算执行完成之后，结果数据查看页面。
（3）下面简单总结魔镜1.0的主要内容。
魔镜1.0的主要优点是使用简单，业务能自助获取数据了。上线后有26%的BI报表用户开始使用魔镜进行数据分析，一定程度上解决了数据工程师人力问题，提高了数据需求处理效率。在1.0版本中还存在一些不足，主要表现为只支持单表计算，不支持复杂的数据分析场景，使用场景受限。在引擎端，由于采用的是单点执行，当计算并行度达到一定数量时，会存在5%的概率计算任务执行失败。
3、魔镜2.0
上面是魔镜2.0架构，魔镜2.0在产品功能上，通过对各业务的历史数据需求的综合梳理分析，发现数据需求主要集中在单表、关联分析和留存分析等分析场景。所以我们在产品功能上抽象出基础计算、关联计算、留存计算等计算模板。在服务层数据管理中支持了数仓表注册，下线了1.0版本中的投递注册。主要原因是1.0版本没有对投递做很好的管理，导致会存在一些数据质量问题。在定制计算部分支持了模板SQL生成。然后也支持各计算模板的计算执行和结果查看。在引擎端主要是集成了爱奇艺自研的分布式Gear工作流系统，Gear工作流系统支持将任务分布到 HIVE集群的各个节点去执行，解决了1.0版本单点执行计算有概率的任务失败问题。
魔镜2.0关联计算，关联计算的使用场景主要是支持多表分析，它解决了1.0版本仅支持单表分析的问题。整个业务配置步骤分为三部分，第一部分是配置子查询计算信息。因为关联计算至少是两个子计算关联，所以系统默认创建两个子计算配置项，如果用户的需求比较复杂，需要更多的关联计算分析时，可以点击添加计算按钮添加计算。在关联分析这一部分，系统支持常用的，例如join，left join ，right join等。第二步配置是配置维度信息、计算信息。第三步是配置基本信息。通过简单的三步配置，用户就可以实现复杂的关联计算分析场景。
魔镜留存分析适用的场景主要是用于衡量用户的粘性，反映产品的受欢迎程度，通常APP上线之后，留存是一个很重要的分析指标，留存率越高表示用户越喜欢你的产品。整个配置分为4部分，第一步是先定义初始行为，第二步是定义留存行为，第三步是选择留存指标，系统提供一些常用的留存指标，例如次日留存，3日、7日，目前最大支持30日留存，这些基本涵盖到常用的留存指标分析。第四部分是配置基本信息，通过简单的四步配置，用户就能实现业务的留存分析计算了。
前面介绍的是固定的分析模板。由于固定的分析模板，一定程度上只能支持通用的分析场景，不能满足全部的数据分析需求。系统针对高端用户即懂SQL的用户，提供了直接编写SQL的方式，用户可以很方便的在任务开发区编写SQL，编写完成之后进行计算执行。任务执行完成后，在任务开发区的下方表格中可以查看计算执行结果。
魔镜2.0的优点是通过标准的数据分析模板与自定义SQL形式，基本实现了分析场景的全覆盖。魔镜2.0上线之后，日均用户数增长25%。通过接入数仓表，提高了数据质量，数据分层提升了用户获取数据的效率。在引擎端提升了引擎的稳定性，保障任务的成功率，大大提高了用户体验。同样在魔镜2.0版本还存在一些不足。主要集中在执行效率层面，由于魔镜2.0版本底层使用的还是HIVE计算引擎，在日益增长的数据现状下，难以满足业务获取数据的时效性需求。在可视化层面仅支持表格查看数据，用户如果需要进行图表可视化分析，需要将数据导出之后使用第三方分析工具进行图表的可视化，使用流程会非常长。
三、当前架构、功能及解决的问题
1、魔镜3.0架构
上图是魔镜3.0的整体架构，在存储层支持HIVE，ICEBERG，本地存储。数据层支持统一数仓与数据集市数据。统一数仓包含DWD层，MID层，还包括DIM层以及AL层数据。数据集市也包含DWD层、MID层，DIM层与AL层数据。除了以上数仓的范畴之外，还支持本地文件上传，因为用户可能需要将本地数据上传到魔镜平台进行数据分析。
引擎端自研了pilot通用计算引擎。服务层主要是对2.0版本的自定义SQL分析与基础分析模板进行了优化升级。通用服务层面抽象出订阅服务，对计算结果进行邮件订阅。应用层的主要使用场景是包括用户增长、会员营销、内容运营、产品分析等。
2、魔镜3.0数据层
我们看一下魔镜3.0的数据层的处理流程。
在数据源部分，魔镜3.0主要包括APP的行为日志、业务后台数据及其他数据源。数据源通过实时数据入湖，进入到统一数仓的原始数据层ODS层，然后经过实时处理传输到DWD层，然后再向上汇总进入到MID层。统一数仓的数据可以再向上产出到业务集市，最终就支持了上层的定制计算模板分析与自定义SQL分析。这样的数据存储优势在于，第一数据是实时入湖的，时效性高；第二是因为数仓采用了统一的指标和统一的维度，数据含义清晰降低了用户的理解成本；第三是数据质量高，因为数据经过了数仓的统一数据治理，大大提高了数据质量。数据分层之后，用户可以优先选择使用MID层数据，因为MID层是经过了聚合的数据，可以大大提高数据查询的效率。
3、魔镜3.0pilot引擎
pilot引擎主要支持4个功能，第一是语法解析，第二是支持查询拦截，第三是计算智能路由，最后是多引擎支持。
架构层面，在底层主要是基础平台，支持HADOOP、TRINO、IMPALA。其中TRINO和IMPALA都是独立部署的。在引擎端主要支持 SPARK SQL、HIVE、TRINO和IMPALA。引擎端之上是服务端，最上层是客户端。整个引擎的处理流程是客户端首先将用户执行的SQL进行语法解析，语法解析校验用户输入的SQL是否存在语法问题。语法解析通过之后会进行数据源解析，数据源解析主要是检查用户使用的数据源类型。例如HIVE，ICEBERG等。当数据源解析通过之后，会进行大数据查询拦截。大数据查询拦截的作用是检测用户的查询是否有指定分区条件，主要是为了防止用户漏掉分区条件之后会导致全表查询，进而会影响集群的性能。
语法解析服务通过之后，会进入到路由服务。路由服务主要的作用是智能的识别用户SQL的执行集群，结合元数据服务智能识别出用户拥有表访问权限的账号与YARN资源队列。
经过路由服务之后，客户端会将查询提交到服务端，服务端会根据解析服务中解析出的数据源类型，去使用对应的查询引擎。例如当用户使用的数据源类型是HIVE表时，服务端会优先使用SPAKR SQL执行。当用户使用的数据源类型是ICEBERG表时，服务端会使用TRINO引擎。以上对用户是完全无感知的，最后服务端会将查询任务提交到基础计算平台执行，执行完成之后会将查询的结果反馈给客户端。
在服务端还支持日志中心，方便用户在计算执行过程中可以查看任务的执行日志。当发生异常时，用户可以判断任务失败原因。比如语法问题或其他的原因。另外服务端也支持监控中心监控当前服务端的压力情况，当负载过大时可以支持动态扩容。
pilot引擎上线之后用户无需关心任务应该在哪里执行，使用什么样的资源。提高了任务的执行效率与用户的体验。
在2.0版本时使用的HIVE引擎，当时任务的平均时长在20分钟左右，Pilot引擎上线之后，任务的平均直接时长在6分钟左右，提高了70%，大大提高了用户分析数据的效率。
4、魔镜3.0自定义Sql
自定义SQL在功能层面主要是支持分析的场景化和图表的可视化。
分析的场景化主要带来两个方面的优势。
第一，从产品层面来看，2.0版本计算执行完之后，是以列表的形式来展现，非常不利于用户查找历史计算。做了场景化之后，先是创建一个菜单，再去添加计算。这样的优势是用户在查找历史计算时，通过找到对应的菜单，就能找到历史的计算。
第二，从数据分析思维层面来看，主要是有数据分析思维的提升。比如有了分析场景之后，用户需要先明确需求是什么，明确了需求相当于分析场景有了，然后再进一步去做需求拆解，我先做什么再做什么。
比如爱奇艺一部很火的剧《尘封13载》，假设说我是这部剧的运营，我需要分析这部剧的数据，我的需求是对《尘封13载》做一个数据分析，第一步，我先统计这部剧的整体数据，可以观察出数据的趋势。通过趋势数据观察到一些信息之后，比如某天流量上涨，需要分析上涨的流量来源，就可以再细化统计该天这部剧导流资源位的数据，去衡量资源位的导流情况。通过这样一种方式便训练了用户结构化数据分析的思维。
关于图表的可视化，在2.0版本中自定义SQL只支持表格查看数据，表格不便于用户很好的理解数据，用户需要将数据导出后进行图表可视化。在3.0版本结果查看部分直接集成了图表可视化的功能，目前主要支持4种可视化图表分析，例如趋势图，饼图、柱状图等。下图是可视化图表样例。
5、魔镜3.0基础计算
魔镜3.0优化了基础计算，优点是统一了指标和维度，用户无感知的实现了多表分析，提升了用户体验，并且用户不用关心计算的数据源。
下面是具体的配置流程，用户第一步选择业务，选择业务之后，第二步是添加计算指标。对比1.0版本，用户需要具体配置指标计算规则，比如需要关心我应该是用去重计数，还是应该用求和。新版本优化后，系统直接集成了数仓指标，用户直接添加就可以，不需要关心指标的具体计算规则，节省了用户理解的成本。
系统是怎么实现用户无感知多表分析的，首先系统将指标依据数仓的概念按照事件类型区分，当用户选择多个事件类型的指标时，比如上述图片有一个系统启动的指标和页面展现的指标，这两个指标是跨多个事件的，在底层来说可能就会对应到多张表，多张表的逻辑对用户是无感知的，这样就大大的扩展了用户场景分析的使用场景。
除了支持数仓的指标之外，还支持用户自定义指标。自定义指标的含义是指用户可以基于选择的数仓指标，通过四则运算方式创建自定义指标。
第三步指标配置完成之后用户可以选择维度。在维度这一部分，系统还支持一个比较高级的功能，用户选择维度之后，可能需要对维度做一些处理。比如选择了一个日期维度，用户希望通过这个日期去生成一个周维度或者一个月维度，那么就可以在选择使用日期函数，很方便的支持维度的扩展，这是一个很方便的功能。
第四部分是查询条件，查询条件对于用户来说是一个可选的配置，如果用户希望统计业务的全量数据，是不需要配置的。
6、魔镜3.0基础计算指标体系
魔镜3.0基础分析的指标体系，通过具体的指标体系，支持基础分析的优化，指标体系的一个优点是统一了指标的含义，相同类型的指标名称是固定的，节省了用户理解的成本。第二个优点是统一了指标的口径。
下面具体介绍指标体系，指标体系在最底层是指标元数据，包括原子指标和复合指标，这个指标元数据是由数仓的管理员去创建的。
数仓管理员创建好指标元数据之后，上层统计指标是由业务的数据产品来创建，即业务数据产品收到业务的数据需求之后会来创建统计指标，统计指标也是包含了两大类，一种是统计指标，第二种是复合统计指标。统计指标是基于原子指标，结合时间统计周期，然后再加上修饰词，规范的产生出统计指标。复合统计指标也是复合统计指标，结合时间周期，然后再加上修饰词规范的产出了复合统计指标。
有了统计指标之后会再进入到统一数仓，统一数仓先利用指标元数据进行数据建模，数据建模之后会再产出物理建模，会具体产出表。
当统一数仓把模型创建好之后，上层的业务集市会基于统一数仓模型进行业务集市的数据建模和物理建模，最终这些数据将在基础分析中进行使用。
前面提到用户无需关心使用的表，具体的实现方式是用户在配置页面，选择指标和维度之后，服务端可以基于用户选择的维度、指标信息结合维度信息智能的匹配出数据模型。这里有一个策略，理论上我们最上层的数据模型是最优的，比如匹配到一个聚合层的模型，这聚合层的模型是一个聚合的表，因为数据量会减少，最终的体现是查询效率会很高。通过匹配到最优的数据模型之后，就能匹配出物理表，整个实现了基础分析的优化。
7、魔镜3.0分析看板
魔镜3.0版本支持分析看板，解决了1.0和2.0版本分析模板结果的查看效果。1.0和2.0版本呈现的都是一个表格，不太便于用户去分析数据。通过分析看板的多计算数据结果可视化能力，提升了数据分析综合能力。
上面截图可看到，一个图对应一个计算，用户可以根据需求添加多个组件。
四、魔镜平台收益
第四部分是魔镜平台上线后的收益，魔镜平台的收益可以从以上4个角度衡量。
第一个，从业务角度，模型平台上线之后，到现在基本上实现了全业务的覆盖，即整个公司业务线都在使用魔镜平台进行数据分析。
第二个，从用户层面来看，基本上公司的产品、运营、分析师、开发等等都在使用魔镜平台。
第三个，从时效性角度来看，业务获取数据的时间，从以前的天级降到现在的分钟级，大大节省了业务获取数据进行分析的效率。
第四个，从资源层面来看，一是降本增效，二是数据安全。在降本增效层面，早期的时候，业务通过跳板机直接登录到服务器进行数据查询，我们和公司的大数据团队配合去推动服务器的下线，大概下线几百台服务器，大大节省公司成本。从数据安全角度来看，早期的时候用户是通过服务器去查询更新数据，这样会带来一个风险，即用户在服务器上更新线上表数据时是不可控的，数据产出之后，用户还能通过服务器S进行数据更新，这是非常不安全，也会带来数据的一致性问题。现在我们将服务器下线之后，全部通过魔镜平台去实现时，魔镜平台通过分析SQL能够监控到用户是查询还是更新操作。如果是更新操作，系统会进行拦截。
五、未来展望
最后一部分是未来的展望，未来展望第一个是扩展查询引擎，第二个是让数据分析更智能化，现在的分析模板主要还是配置化操作，我们希望可以更智能化的节省用户的配置操作。
