一、魔鏡平臺(tái)背景介紹

首先和大家分享魔鏡平臺(tái)的背景。

1、遇到的問題&破局思路

2015年左右，整個(gè)互聯(lián)網(wǎng)行業(yè)處于高速發(fā)展的階段，業(yè)務(wù)多樣化，變化快，同時(shí)期在愛奇藝也有著非常多的創(chuàng)新業(yè)務(wù)在發(fā)展。由于業(yè)務(wù)的快速發(fā)展，固定的報(bào)表開發(fā)難以滿足業(yè)務(wù)方的數(shù)據(jù)需求，BI的表現(xiàn)主要是數(shù)據(jù)需求多，需求變化快，為了保證工作的有序推進(jìn)，BI需要對業(yè)務(wù)的數(shù)據(jù)需求進(jìn)行評審，然后根據(jù)優(yōu)先級進(jìn)行排期開發(fā)。對業(yè)務(wù)來說，數(shù)據(jù)工程師逐漸成為業(yè)務(wù)獲取數(shù)據(jù)的瓶頸，難以滿足業(yè)務(wù)的需求。

【資料圖】

為解決這些問題，我們解決問題的思路是賦能業(yè)務(wù)自助獲取數(shù)據(jù)的能力，因此開發(fā)了數(shù)據(jù)分析平臺(tái)魔鏡，提升業(yè)務(wù)獲取數(shù)據(jù)的效率。

二、魔鏡平臺(tái)各階段發(fā)展歷程1、魔鏡平臺(tái)各階段發(fā)展歷程

魔鏡平臺(tái)從2015年到現(xiàn)在共分為三個(gè)階段，第一個(gè)階段是2015年魔鏡1.0上線，主要支持pingback投遞管理和可視化分析。第二個(gè)階段是2019年上線了魔鏡2.0，主要支持?jǐn)?shù)據(jù)倉庫表接入和數(shù)據(jù)分析模板化。第三個(gè)階段是2022年上線了魔鏡3.0，主要支持分析智能化與分析模板優(yōu)化。

2、魔鏡1.0

2015年魔鏡1.0架構(gòu)，在產(chǎn)品功能上支持了投遞注冊，在計(jì)算層面支持基礎(chǔ)計(jì)算、計(jì)算列表及計(jì)算執(zhí)行結(jié)果的查看。在服務(wù)層主要支持投遞注冊、表管理以及對應(yīng)的ETL。服務(wù)層主要支持基礎(chǔ)計(jì)算的SQL生成、計(jì)算執(zhí)行及結(jié)果查看。引擎端主要支持Hive引擎。

（1）下面簡單介紹魔鏡1.0的前端交互頁面。

魔鏡1.0的基礎(chǔ)計(jì)算，前端配置主要分為三個(gè)部分，第一部分是選擇業(yè)務(wù)和表名，第二部分是計(jì)算信息的配置，主要是包括維度、指標(biāo)以及計(jì)算條件。第三部分是配置計(jì)算的基本信息。通過簡單的三步配置，就可以讓用戶擁有自主分析數(shù)據(jù)的能力。

（2）接下來介紹魔鏡的執(zhí)行計(jì)算和查看計(jì)算結(jié)果。

在計(jì)算執(zhí)行層面，我們支持三種方式，第一種是計(jì)算一天，第二種是支持連續(xù)執(zhí)行多天，第三種是支持自定義多天。

第一種很好理解只統(tǒng)計(jì)指定日期一天的數(shù)據(jù)。第二種連續(xù)計(jì)算多天，通常用戶在創(chuàng)建完計(jì)算之后需要回溯歷史數(shù)據(jù)，連續(xù)執(zhí)行多天支持選擇一個(gè)開始時(shí)間和一個(gè)結(jié)束時(shí)間，平臺(tái)能幫助用戶去執(zhí)行這段時(shí)間內(nèi)每天的計(jì)算。第三種自定義執(zhí)行多天可以指定一段時(shí)間內(nèi)非連續(xù)的某幾天日期。例如可以選擇1號、3號、5號，當(dāng)用戶只需要回溯一段時(shí)間內(nèi)的某些日期的數(shù)據(jù)時(shí)，可以節(jié)省用戶回溯歷史數(shù)據(jù)的時(shí)間。下面的圖是計(jì)算執(zhí)行完成之后，結(jié)果數(shù)據(jù)查看頁面。

（3）下面簡單總結(jié)魔鏡1.0的主要內(nèi)容。

魔鏡1.0的主要優(yōu)點(diǎn)是使用簡單，業(yè)務(wù)能自助獲取數(shù)據(jù)了。上線后有26%的BI報(bào)表用戶開始使用魔鏡進(jìn)行數(shù)據(jù)分析，一定程度上解決了數(shù)據(jù)工程師人力問題，提高了數(shù)據(jù)需求處理效率。在1.0版本中還存在一些不足，主要表現(xiàn)為只支持單表計(jì)算，不支持復(fù)雜的數(shù)據(jù)分析場景，使用場景受限。在引擎端，由于采用的是單點(diǎn)執(zhí)行，當(dāng)計(jì)算并行度達(dá)到一定數(shù)量時(shí)，會(huì)存在5%的概率計(jì)算任務(wù)執(zhí)行失敗。

3、魔鏡2.0

上面是魔鏡2.0架構(gòu)，魔鏡2.0在產(chǎn)品功能上，通過對各業(yè)務(wù)的歷史數(shù)據(jù)需求的綜合梳理分析，發(fā)現(xiàn)數(shù)據(jù)需求主要集中在單表、關(guān)聯(lián)分析和留存分析等分析場景。所以我們在產(chǎn)品功能上抽象出基礎(chǔ)計(jì)算、關(guān)聯(lián)計(jì)算、留存計(jì)算等計(jì)算模板。在服務(wù)層數(shù)據(jù)管理中支持了數(shù)倉表注冊，下線了1.0版本中的投遞注冊。主要原因是1.0版本沒有對投遞做很好的管理，導(dǎo)致會(huì)存在一些數(shù)據(jù)質(zhì)量問題。在定制計(jì)算部分支持了模板SQL生成。然后也支持各計(jì)算模板的計(jì)算執(zhí)行和結(jié)果查看。在引擎端主要是集成了愛奇藝自研的分布式Gear工作流系統(tǒng)，Gear工作流系統(tǒng)支持將任務(wù)分布到 HIVE集群的各個(gè)節(jié)點(diǎn)去執(zhí)行，解決了1.0版本單點(diǎn)執(zhí)行計(jì)算有概率的任務(wù)失敗問題。

魔鏡2.0關(guān)聯(lián)計(jì)算，關(guān)聯(lián)計(jì)算的使用場景主要是支持多表分析，它解決了1.0版本僅支持單表分析的問題。整個(gè)業(yè)務(wù)配置步驟分為三部分，第一部分是配置子查詢計(jì)算信息。因?yàn)殛P(guān)聯(lián)計(jì)算至少是兩個(gè)子計(jì)算關(guān)聯(lián)，所以系統(tǒng)默認(rèn)創(chuàng)建兩個(gè)子計(jì)算配置項(xiàng)，如果用戶的需求比較復(fù)雜，需要更多的關(guān)聯(lián)計(jì)算分析時(shí)，可以點(diǎn)擊添加計(jì)算按鈕添加計(jì)算。在關(guān)聯(lián)分析這一部分，系統(tǒng)支持常用的，例如join，left join ，right join等。第二步配置是配置維度信息、計(jì)算信息。第三步是配置基本信息。通過簡單的三步配置，用戶就可以實(shí)現(xiàn)復(fù)雜的關(guān)聯(lián)計(jì)算分析場景。

魔鏡留存分析適用的場景主要是用于衡量用戶的粘性，反映產(chǎn)品的受歡迎程度，通常APP上線之后，留存是一個(gè)很重要的分析指標(biāo)，留存率越高表示用戶越喜歡你的產(chǎn)品。整個(gè)配置分為4部分，第一步是先定義初始行為，第二步是定義留存行為，第三步是選擇留存指標(biāo)，系統(tǒng)提供一些常用的留存指標(biāo)，例如次日留存，3日、7日，目前最大支持30日留存，這些基本涵蓋到常用的留存指標(biāo)分析。第四部分是配置基本信息，通過簡單的四步配置，用戶就能實(shí)現(xiàn)業(yè)務(wù)的留存分析計(jì)算了。

前面介紹的是固定的分析模板。由于固定的分析模板，一定程度上只能支持通用的分析場景，不能滿足全部的數(shù)據(jù)分析需求。系統(tǒng)針對高端用戶即懂SQL的用戶，提供了直接編寫SQL的方式，用戶可以很方便的在任務(wù)開發(fā)區(qū)編寫SQL，編寫完成之后進(jìn)行計(jì)算執(zhí)行。任務(wù)執(zhí)行完成后，在任務(wù)開發(fā)區(qū)的下方表格中可以查看計(jì)算執(zhí)行結(jié)果。

魔鏡2.0的優(yōu)點(diǎn)是通過標(biāo)準(zhǔn)的數(shù)據(jù)分析模板與自定義SQL形式，基本實(shí)現(xiàn)了分析場景的全覆蓋。魔鏡2.0上線之后，日均用戶數(shù)增長25%。通過接入數(shù)倉表，提高了數(shù)據(jù)質(zhì)量，數(shù)據(jù)分層提升了用戶獲取數(shù)據(jù)的效率。在引擎端提升了引擎的穩(wěn)定性，保障任務(wù)的成功率，大大提高了用戶體驗(yàn)。同樣在魔鏡2.0版本還存在一些不足。主要集中在執(zhí)行效率層面，由于魔鏡2.0版本底層使用的還是HIVE計(jì)算引擎，在日益增長的數(shù)據(jù)現(xiàn)狀下，難以滿足業(yè)務(wù)獲取數(shù)據(jù)的時(shí)效性需求。在可視化層面僅支持表格查看數(shù)據(jù)，用戶如果需要進(jìn)行圖表可視化分析，需要將數(shù)據(jù)導(dǎo)出之后使用第三方分析工具進(jìn)行圖表的可視化，使用流程會(huì)非常長。

三、當(dāng)前架構(gòu)、功能及解決的問題1、魔鏡3.0架構(gòu)

上圖是魔鏡3.0的整體架構(gòu)，在存儲(chǔ)層支持HIVE，ICEBERG，本地存儲(chǔ)。數(shù)據(jù)層支持統(tǒng)一數(shù)倉與數(shù)據(jù)集市數(shù)據(jù)。統(tǒng)一數(shù)倉包含DWD層，MID層，還包括DIM層以及AL層數(shù)據(jù)。數(shù)據(jù)集市也包含DWD層、MID層，DIM層與AL層數(shù)據(jù)。除了以上數(shù)倉的范疇之外，還支持本地文件上傳，因?yàn)橛脩艨赡苄枰獙⒈镜財(cái)?shù)據(jù)上傳到魔鏡平臺(tái)進(jìn)行數(shù)據(jù)分析。

引擎端自研了pilot通用計(jì)算引擎。服務(wù)層主要是對2.0版本的自定義SQL分析與基礎(chǔ)分析模板進(jìn)行了優(yōu)化升級。通用服務(wù)層面抽象出訂閱服務(wù)，對計(jì)算結(jié)果進(jìn)行郵件訂閱。應(yīng)用層的主要使用場景是包括用戶增長、會(huì)員營銷、內(nèi)容運(yùn)營、產(chǎn)品分析等。

2、魔鏡3.0數(shù)據(jù)層

我們看一下魔鏡3.0的數(shù)據(jù)層的處理流程。

在數(shù)據(jù)源部分，魔鏡3.0主要包括APP的行為日志、業(yè)務(wù)后臺(tái)數(shù)據(jù)及其他數(shù)據(jù)源。數(shù)據(jù)源通過實(shí)時(shí)數(shù)據(jù)入湖，進(jìn)入到統(tǒng)一數(shù)倉的原始數(shù)據(jù)層ODS層，然后經(jīng)過實(shí)時(shí)處理傳輸?shù)紻WD層，然后再向上匯總進(jìn)入到MID層。統(tǒng)一數(shù)倉的數(shù)據(jù)可以再向上產(chǎn)出到業(yè)務(wù)集市，最終就支持了上層的定制計(jì)算模板分析與自定義SQL分析。這樣的數(shù)據(jù)存儲(chǔ)優(yōu)勢在于，第一數(shù)據(jù)是實(shí)時(shí)入湖的，時(shí)效性高；第二是因?yàn)閿?shù)倉采用了統(tǒng)一的指標(biāo)和統(tǒng)一的維度，數(shù)據(jù)含義清晰降低了用戶的理解成本；第三是數(shù)據(jù)質(zhì)量高，因?yàn)閿?shù)據(jù)經(jīng)過了數(shù)倉的統(tǒng)一數(shù)據(jù)治理，大大提高了數(shù)據(jù)質(zhì)量。數(shù)據(jù)分層之后，用戶可以優(yōu)先選擇使用MID層數(shù)據(jù)，因?yàn)镸ID層是經(jīng)過了聚合的數(shù)據(jù)，可以大大提高數(shù)據(jù)查詢的效率。

3、魔鏡3.0pilot引擎

pilot引擎主要支持4個(gè)功能，第一是語法解析，第二是支持查詢攔截，第三是計(jì)算智能路由，最后是多引擎支持。

架構(gòu)層面，在底層主要是基礎(chǔ)平臺(tái)，支持HADOOP、TRINO、IMPALA。其中TRINO和IMPALA都是獨(dú)立部署的。在引擎端主要支持 SPARK SQL、HIVE、TRINO和IMPALA。引擎端之上是服務(wù)端，最上層是客戶端。整個(gè)引擎的處理流程是客戶端首先將用戶執(zhí)行的SQL進(jìn)行語法解析，語法解析校驗(yàn)用戶輸入的SQL是否存在語法問題。語法解析通過之后會(huì)進(jìn)行數(shù)據(jù)源解析，數(shù)據(jù)源解析主要是檢查用戶使用的數(shù)據(jù)源類型。例如HIVE，ICEBERG等。當(dāng)數(shù)據(jù)源解析通過之后，會(huì)進(jìn)行大數(shù)據(jù)查詢攔截。大數(shù)據(jù)查詢攔截的作用是檢測用戶的查詢是否有指定分區(qū)條件，主要是為了防止用戶漏掉分區(qū)條件之后會(huì)導(dǎo)致全表查詢，進(jìn)而會(huì)影響集群的性能。

語法解析服務(wù)通過之后，會(huì)進(jìn)入到路由服務(wù)。路由服務(wù)主要的作用是智能的識別用戶SQL的執(zhí)行集群，結(jié)合元數(shù)據(jù)服務(wù)智能識別出用戶擁有表訪問權(quán)限的賬號與YARN資源隊(duì)列。

經(jīng)過路由服務(wù)之后，客戶端會(huì)將查詢提交到服務(wù)端，服務(wù)端會(huì)根據(jù)解析服務(wù)中解析出的數(shù)據(jù)源類型，去使用對應(yīng)的查詢引擎。例如當(dāng)用戶使用的數(shù)據(jù)源類型是HIVE表時(shí)，服務(wù)端會(huì)優(yōu)先使用SPAKR SQL執(zhí)行。當(dāng)用戶使用的數(shù)據(jù)源類型是ICEBERG表時(shí)，服務(wù)端會(huì)使用TRINO引擎。以上對用戶是完全無感知的，最后服務(wù)端會(huì)將查詢?nèi)蝿?wù)提交到基礎(chǔ)計(jì)算平臺(tái)執(zhí)行，執(zhí)行完成之后會(huì)將查詢的結(jié)果反饋給客戶端。

在服務(wù)端還支持日志中心，方便用戶在計(jì)算執(zhí)行過程中可以查看任務(wù)的執(zhí)行日志。當(dāng)發(fā)生異常時(shí)，用戶可以判斷任務(wù)失敗原因。比如語法問題或其他的原因。另外服務(wù)端也支持監(jiān)控中心監(jiān)控當(dāng)前服務(wù)端的壓力情況，當(dāng)負(fù)載過大時(shí)可以支持動(dòng)態(tài)擴(kuò)容。

pilot引擎上線之后用戶無需關(guān)心任務(wù)應(yīng)該在哪里執(zhí)行，使用什么樣的資源。提高了任務(wù)的執(zhí)行效率與用戶的體驗(yàn)。

在2.0版本時(shí)使用的HIVE引擎，當(dāng)時(shí)任務(wù)的平均時(shí)長在20分鐘左右，Pilot引擎上線之后，任務(wù)的平均直接時(shí)長在6分鐘左右，提高了70%，大大提高了用戶分析數(shù)據(jù)的效率。

4、魔鏡3.0自定義Sql

自定義SQL在功能層面主要是支持分析的場景化和圖表的可視化。

分析的場景化主要帶來兩個(gè)方面的優(yōu)勢。

第一，從產(chǎn)品層面來看，2.0版本計(jì)算執(zhí)行完之后，是以列表的形式來展現(xiàn)，非常不利于用戶查找歷史計(jì)算。做了場景化之后，先是創(chuàng)建一個(gè)菜單，再去添加計(jì)算。這樣的優(yōu)勢是用戶在查找歷史計(jì)算時(shí)，通過找到對應(yīng)的菜單，就能找到歷史的計(jì)算。

第二，從數(shù)據(jù)分析思維層面來看，主要是有數(shù)據(jù)分析思維的提升。比如有了分析場景之后，用戶需要先明確需求是什么，明確了需求相當(dāng)于分析場景有了，然后再進(jìn)一步去做需求拆解，我先做什么再做什么。

比如愛奇藝一部很火的劇《塵封13載》，假設(shè)說我是這部劇的運(yùn)營，我需要分析這部劇的數(shù)據(jù)，我的需求是對《塵封13載》做一個(gè)數(shù)據(jù)分析，第一步，我先統(tǒng)計(jì)這部劇的整體數(shù)據(jù)，可以觀察出數(shù)據(jù)的趨勢。通過趨勢數(shù)據(jù)觀察到一些信息之后，比如某天流量上漲，需要分析上漲的流量來源，就可以再細(xì)化統(tǒng)計(jì)該天這部劇導(dǎo)流資源位的數(shù)據(jù)，去衡量資源位的導(dǎo)流情況。通過這樣一種方式便訓(xùn)練了用戶結(jié)構(gòu)化數(shù)據(jù)分析的思維。

關(guān)于圖表的可視化，在2.0版本中自定義SQL只支持表格查看數(shù)據(jù)，表格不便于用戶很好的理解數(shù)據(jù)，用戶需要將數(shù)據(jù)導(dǎo)出后進(jìn)行圖表可視化。在3.0版本結(jié)果查看部分直接集成了圖表可視化的功能，目前主要支持4種可視化圖表分析，例如趨勢圖，餅圖、柱狀圖等。下圖是可視化圖表樣例。

5、魔鏡3.0基礎(chǔ)計(jì)算

魔鏡3.0優(yōu)化了基礎(chǔ)計(jì)算，優(yōu)點(diǎn)是統(tǒng)一了指標(biāo)和維度，用戶無感知的實(shí)現(xiàn)了多表分析，提升了用戶體驗(yàn)，并且用戶不用關(guān)心計(jì)算的數(shù)據(jù)源。

下面是具體的配置流程，用戶第一步選擇業(yè)務(wù)，選擇業(yè)務(wù)之后，第二步是添加計(jì)算指標(biāo)。對比1.0版本，用戶需要具體配置指標(biāo)計(jì)算規(guī)則，比如需要關(guān)心我應(yīng)該是用去重計(jì)數(shù)，還是應(yīng)該用求和。新版本優(yōu)化后，系統(tǒng)直接集成了數(shù)倉指標(biāo)，用戶直接添加就可以，不需要關(guān)心指標(biāo)的具體計(jì)算規(guī)則，節(jié)省了用戶理解的成本。

系統(tǒng)是怎么實(shí)現(xiàn)用戶無感知多表分析的，首先系統(tǒng)將指標(biāo)依據(jù)數(shù)倉的概念按照事件類型區(qū)分，當(dāng)用戶選擇多個(gè)事件類型的指標(biāo)時(shí)，比如上述圖片有一個(gè)系統(tǒng)啟動(dòng)的指標(biāo)和頁面展現(xiàn)的指標(biāo)，這兩個(gè)指標(biāo)是跨多個(gè)事件的，在底層來說可能就會(huì)對應(yīng)到多張表，多張表的邏輯對用戶是無感知的，這樣就大大的擴(kuò)展了用戶場景分析的使用場景。

除了支持?jǐn)?shù)倉的指標(biāo)之外，還支持用戶自定義指標(biāo)。自定義指標(biāo)的含義是指用戶可以基于選擇的數(shù)倉指標(biāo)，通過四則運(yùn)算方式創(chuàng)建自定義指標(biāo)。

第三步指標(biāo)配置完成之后用戶可以選擇維度。在維度這一部分，系統(tǒng)還支持一個(gè)比較高級的功能，用戶選擇維度之后，可能需要對維度做一些處理。比如選擇了一個(gè)日期維度，用戶希望通過這個(gè)日期去生成一個(gè)周維度或者一個(gè)月維度，那么就可以在選擇使用日期函數(shù)，很方便的支持維度的擴(kuò)展，這是一個(gè)很方便的功能。

第四部分是查詢條件，查詢條件對于用戶來說是一個(gè)可選的配置，如果用戶希望統(tǒng)計(jì)業(yè)務(wù)的全量數(shù)據(jù)，是不需要配置的。

6、魔鏡3.0基礎(chǔ)計(jì)算指標(biāo)體系

魔鏡3.0基礎(chǔ)分析的指標(biāo)體系，通過具體的指標(biāo)體系，支持基礎(chǔ)分析的優(yōu)化，指標(biāo)體系的一個(gè)優(yōu)點(diǎn)是統(tǒng)一了指標(biāo)的含義，相同類型的指標(biāo)名稱是固定的，節(jié)省了用戶理解的成本。第二個(gè)優(yōu)點(diǎn)是統(tǒng)一了指標(biāo)的口徑。

下面具體介紹指標(biāo)體系，指標(biāo)體系在最底層是指標(biāo)元數(shù)據(jù)，包括原子指標(biāo)和復(fù)合指標(biāo)，這個(gè)指標(biāo)元數(shù)據(jù)是由數(shù)倉的管理員去創(chuàng)建的。

數(shù)倉管理員創(chuàng)建好指標(biāo)元數(shù)據(jù)之后，上層統(tǒng)計(jì)指標(biāo)是由業(yè)務(wù)的數(shù)據(jù)產(chǎn)品來創(chuàng)建，即業(yè)務(wù)數(shù)據(jù)產(chǎn)品收到業(yè)務(wù)的數(shù)據(jù)需求之后會(huì)來創(chuàng)建統(tǒng)計(jì)指標(biāo)，統(tǒng)計(jì)指標(biāo)也是包含了兩大類，一種是統(tǒng)計(jì)指標(biāo)，第二種是復(fù)合統(tǒng)計(jì)指標(biāo)。統(tǒng)計(jì)指標(biāo)是基于原子指標(biāo)，結(jié)合時(shí)間統(tǒng)計(jì)周期，然后再加上修飾詞，規(guī)范的產(chǎn)生出統(tǒng)計(jì)指標(biāo)。復(fù)合統(tǒng)計(jì)指標(biāo)也是復(fù)合統(tǒng)計(jì)指標(biāo)，結(jié)合時(shí)間周期，然后再加上修飾詞規(guī)范的產(chǎn)出了復(fù)合統(tǒng)計(jì)指標(biāo)。

有了統(tǒng)計(jì)指標(biāo)之后會(huì)再進(jìn)入到統(tǒng)一數(shù)倉，統(tǒng)一數(shù)倉先利用指標(biāo)元數(shù)據(jù)進(jìn)行數(shù)據(jù)建模，數(shù)據(jù)建模之后會(huì)再產(chǎn)出物理建模，會(huì)具體產(chǎn)出表。

當(dāng)統(tǒng)一數(shù)倉把模型創(chuàng)建好之后，上層的業(yè)務(wù)集市會(huì)基于統(tǒng)一數(shù)倉模型進(jìn)行業(yè)務(wù)集市的數(shù)據(jù)建模和物理建模，最終這些數(shù)據(jù)將在基礎(chǔ)分析中進(jìn)行使用。

前面提到用戶無需關(guān)心使用的表，具體的實(shí)現(xiàn)方式是用戶在配置頁面，選擇指標(biāo)和維度之后，服務(wù)端可以基于用戶選擇的維度、指標(biāo)信息結(jié)合維度信息智能的匹配出數(shù)據(jù)模型。這里有一個(gè)策略，理論上我們最上層的數(shù)據(jù)模型是最優(yōu)的，比如匹配到一個(gè)聚合層的模型，這聚合層的模型是一個(gè)聚合的表，因?yàn)閿?shù)據(jù)量會(huì)減少，最終的體現(xiàn)是查詢效率會(huì)很高。通過匹配到最優(yōu)的數(shù)據(jù)模型之后，就能匹配出物理表，整個(gè)實(shí)現(xiàn)了基礎(chǔ)分析的優(yōu)化。

7、魔鏡3.0分析看板

魔鏡3.0版本支持分析看板，解決了1.0和2.0版本分析模板結(jié)果的查看效果。1.0和2.0版本呈現(xiàn)的都是一個(gè)表格，不太便于用戶去分析數(shù)據(jù)。通過分析看板的多計(jì)算數(shù)據(jù)結(jié)果可視化能力，提升了數(shù)據(jù)分析綜合能力。

上面截圖可看到，一個(gè)圖對應(yīng)一個(gè)計(jì)算，用戶可以根據(jù)需求添加多個(gè)組件。

四、魔鏡平臺(tái)收益

第四部分是魔鏡平臺(tái)上線后的收益，魔鏡平臺(tái)的收益可以從以上4個(gè)角度衡量。

第一個(gè)，從業(yè)務(wù)角度，模型平臺(tái)上線之后，到現(xiàn)在基本上實(shí)現(xiàn)了全業(yè)務(wù)的覆蓋，即整個(gè)公司業(yè)務(wù)線都在使用魔鏡平臺(tái)進(jìn)行數(shù)據(jù)分析。

第二個(gè)，從用戶層面來看，基本上公司的產(chǎn)品、運(yùn)營、分析師、開發(fā)等等都在使用魔鏡平臺(tái)。

第三個(gè)，從時(shí)效性角度來看，業(yè)務(wù)獲取數(shù)據(jù)的時(shí)間，從以前的天級降到現(xiàn)在的分鐘級，大大節(jié)省了業(yè)務(wù)獲取數(shù)據(jù)進(jìn)行分析的效率。

第四個(gè)，從資源層面來看，一是降本增效，二是數(shù)據(jù)安全。在降本增效層面，早期的時(shí)候，業(yè)務(wù)通過跳板機(jī)直接登錄到服務(wù)器進(jìn)行數(shù)據(jù)查詢，我們和公司的大數(shù)據(jù)團(tuán)隊(duì)配合去推動(dòng)服務(wù)器的下線，大概下線幾百臺(tái)服務(wù)器，大大節(jié)省公司成本。從數(shù)據(jù)安全角度來看，早期的時(shí)候用戶是通過服務(wù)器去查詢更新數(shù)據(jù)，這樣會(huì)帶來一個(gè)風(fēng)險(xiǎn)，即用戶在服務(wù)器上更新線上表數(shù)據(jù)時(shí)是不可控的，數(shù)據(jù)產(chǎn)出之后，用戶還能通過服務(wù)器S進(jìn)行數(shù)據(jù)更新，這是非常不安全，也會(huì)帶來數(shù)據(jù)的一致性問題?，F(xiàn)在我們將服務(wù)器下線之后，全部通過魔鏡平臺(tái)去實(shí)現(xiàn)時(shí)，魔鏡平臺(tái)通過分析SQL能夠監(jiān)控到用戶是查詢還是更新操作。如果是更新操作，系統(tǒng)會(huì)進(jìn)行攔截。

五、未來展望

最后一部分是未來的展望，未來展望第一個(gè)是擴(kuò)展查詢引擎，第二個(gè)是讓數(shù)據(jù)分析更智能化，現(xiàn)在的分析模板主要還是配置化操作，我們希望可以更智能化的節(jié)省用戶的配置操作。

關(guān)鍵詞：