導讀
introduction
本文主要介紹了商業智能(BI)以及Turing Data Analysis(TDA)的概念和應用。BI通過收集、整理、分析和呈現資料，幫助企業做出更好的決策和戰略規劃。然而，傳統的BI建設思路存在問題，如業務變更資料需求時需要重新開發，以及分析底層資料的效率低等。是以，TDA作為一站式自助分析平台應運而生，它基于明細資料，按照分析主題建設公共資料集，使用者可以自由拖拽分析并一鍵儲存結果，同時也可以分享給其他人檢視。然而，TDA的建設也面臨着分析次元名額要全，資料口徑要準，以及查詢性能等挑戰。針對這些挑戰，我們提出全、準、效、快的目标，并通過流程機制和功能建設以及MPP資料引擎來實作這些目标。
全文5795字，預計閱讀時間15分鐘。
GEEK TALK
01
背景與目标
BI即商業智能（Business Intelligence），通過收集、整理、分析和呈現資料，輔助企業領先于競争對手，做出更好的業務決策和戰略規劃。收集和整理的過程就是數倉的建設，而分析和呈現資料就是可視化分析平台建設。
業内比較常見的BI建設思路：業務想看某名額資料變化，向中台提需，資料RD從ODS>DWD>DWS>ADS逐層模組化，然後定制化的開發ADS結果表落地到Palo/Mysql，最後配置成多個圖表儲存到報表中供業務檢視。這種建設思路雖然滿足了業務的看數需求，但面臨兩個問題：1、當業務變更資料需求時，需要重新定制化開發ADS結果表，會重複占用研發人力；2、隻解決了業務看數的需求，如果想進一步下鑽分析波動的原因，就比較困難，因為底層表是僅包含目前圖表資料的聚合表，想分析隻能下載下傳明細資料，再通過Excel或者其他方式分析，效率比較低。
TDA（Turing Data Analysis ），目标就是為了解決上述BI中分析鍊路長的問題，而建設的一站式自助分析平台。
TDA的建設思路：基于DWD明細寬表，按照分析主題建設公共資料集（單天資料千萬+），使用者基于公共資料集自由拖拽分析，可以一鍵将分析結果儲存到個人儀表盤或者釋出成公共儀表盤，分享給其他人檢視；其他人可以在公共儀表盤檢視波動趨勢、下鑽分析到可視化分析頁面繼續探索波動原因，一站式完成“看趨勢、拆次元、查明細”的分析三闆斧。
下圖是TDA建設思路的整體流程：
這種建設思路下同樣會面臨一些挑戰：
1、分析次元名額要全，否則就需要建設多個資料集，造成資料集多而散，和之前的報表建設一樣的問題；
2、資料口徑要準、資料權威；
3、單日資料千萬+，查詢性能是巨大挑戰。
針對以上挑戰，我們也制定了相應的目标，來滿足業務高效分析訴求：
1、全（分析次元名額要全，覆寫業務80%+的需求）；
2、準（口徑統一、資料準确）；
3、效（資料産出時效T+10h）；
4、快（10億級資料查詢10s内）。
TDA平台會從流程機制和功能建設上來保證資料集建設的全、準、效，結合MPP資料引擎來保證查詢性能，通過BI的可視化拖拽、場景分析、自助模組化等能力提升使用者的分析效率。
GEEK TALK
02
技術方案
基于以上分析，TDA的産品定位是一個可以實作使用者一站式自助查詢的BI平台，使用者可以自由拖拽資料集，進行可視化資料分析，并進行核心儀表盤的搭建。從以下角度幫助使用者實作查詢分析的一站式體驗：
業務看闆疊代提效（自助化）：資料報表疊代模式發生變化，從PM提需RD排期模式逐漸轉換為PM/營運自助化操作(做看闆/分析資料）。
資料洞察分析提效（極速）：單次資料查詢從分鐘級降低到秒級，名額波動分析效率提升20倍，單次名額波動歸因分析端到端從2小時->5分鐘内。
業務一站式自助分析（一站式）：實作資料趨勢觀測、次元下鑽分析、明細導出等功能，實作了資料監控、資料分析一體化體驗。
本産品的功能矩陣如下：
1、資料源接入：業務使用TDS将上遊圖靈表資料通過計算引擎計算後，将資料寫入到clickhouse/mysql/palo等引擎，通過直連的方式接入；或者業務提供自己的palo/mysql資料源接入。
a.資料源管理：資料源增删改查、clickhouse/mysql/palo等引擎驅動适配
2、資料模組化：對接完資料源，資料可以通過寫SQL、直接原始表的方式加載到産品中。但這些表通常還需要做一些簡單的二次處理，變成可以被分析的資料集。
a.資料集的管理：增删改查、資料預覽、schema檢視、一鍵可視化分析等功能
b.資料集字段管理：增删改查、字段排序、自定義字段等
c.資料集類目管理：字段所屬類目的增删改查、自定義排序等
d.資料集目錄管理：資料集目錄的增删改查、自定義排序等
3、資料分析：使用者基于資料集，自由拖拽名額、次元、篩選，選擇合适的圖表類型及場景分析方式，進行分析計算。
a.資料配置：切換資料集、添加自定義字段
b.圖表配置：表格、折線圖、柱狀圖、餅圖等多種圖表類型配置、圖例顔色設定、資料格式設定等
c.場景分析：日均值、同環比、占比、合計等多種場景分析能力支援
d.歸因分析：自助歸因分析能力
e.互動分析：下鑽分析等
4、資料應用：使用者可将分析結果儲存至儀表盤、或嵌出到第三方平台、或儲存至大屏、或直接用于智能分析等。
a.儀表盤管理：儀表盤增删改查、自定義排序、釋出下線、資料導出、訂閱預警等
b.嵌出式分析：ifame嵌出、sdk嵌出等多種嵌出模式
c.大屏：實時大屏
d.智能分析：LUI對話式分析
2.1 整體設計
TDA整體架構如下圖所示：
整體流程：使用者發起查詢，經服務端統一查詢上下文，構造查詢對象，底層引擎方言适配，傳回統一資料格式，再由前端渲染架構根據圖表類型适配渲染。
服務端：
1、統一查詢上下文：為了後期擴充其他圖表功能時，友善通用功能的複用，設計統一的查詢上下文。
2、查詢構造器：根據前端傳過來的請求參數，構造出查詢對象（可以是多個，如對表格分頁，需要構造兩個查詢對象，一個是分頁查詢對象，一個是計數查詢對象）。
3、查詢連接配接器：
a.目前隻有SQL連接配接器，用以滿足拼SQL查詢的引擎（mysql、palo、clickhouse等），不同引擎、文法或一些函數可能會不同，通過不同引擎規則配置去适配；
b. 未來可以擴充其他連接配接器滿足非sql查詢。
4、緩存寫入：保證查詢性能，兩種寫入方式，使用者首次通路時寫入，或通過celery定時任務預熱緩存。
5、資料集子產品：提供資料支援，和底層資料源建立連結，保證資料品質。
6、系統保障子產品：訂閱、預警、公告實作資料預警能力，分享、釋出、授權提升資料的流轉效率，管理中心和權限為資料提供底層管理和權限支援。
前端：
1、元件庫：提供配置解析、不同圖表渲染元件、過濾器元件以及自定義元件能力。
2、互動：封裝了頁面互動能力，包括拖拽式編輯器、下鑽關聯、輔助快捷功能、畫布能力以及其他事件互動。
3、應用：實作不同的可視化應用，面向不同的使用者和使用場景，如儀表盤、大屏等。
2.2 詳細設計
2.2.1 核心查詢
一站式自助BI，通過公共資料集模組化思路，實作“趨勢、次元、明細”三闆斧的分析思路，會面臨諸多挑戰，包括：
- 多源資料、多圖表呈現、多種場景分析計算：BI系統底層資料源引擎不止一種，為了靈活的擴充資料源，且呈現樣式上也需要豐富的圖表支撐，同時為了滿足不同場景下的分析計算，需要支援如同環比、日均值等常用的分析能力。
- 千萬級資料秒級查詢：公共資料集的建設思路，便于分析的同時也引入了新的挑戰。單日千萬資料量，對于查詢性能的巨大挑戰。
針對以上問題，制定了對應的解決方案：
- 統一查詢：統一查詢上下文，構造查詢對象，底層引擎方言适配，傳回統一資料格式，前端渲染架構根據圖表類型适配渲染。
- 查詢優化：Ⅰ>緩存+自動上卷，覆寫70%公共儀表盤請求；Ⅱ>優化建構SQL查詢，充分利用引擎側聚合能力；III>多域名并發請求，多協程響應處理。
統一查詢：
平台使用者統一查詢流程如下：
1、使用者在頁面上自由拖拽分析：切換資料集，切換不同圖表類型，拖拽名額、次元、篩選，查詢即可；或想使用一些進階的場景分析能力，一鍵切換配置。
2、前端請求會處理成統一的查詢上下文：包含資料源、查詢對象、傳回形式，其中查詢對象封裝了基礎的名額、次元、篩選資訊，以及進階的同環比、日均值等分析配置。
3、統一的鑒權服務：基于儀表盤和資料集雙重鑒權的核心，同時支援行列權限更細粒度的權限控制。
4、構造查詢對象：先根據名額、次元、篩選三元組完成基礎SQL構造（聚合、分組、過濾），然後根據排序規則，組裝排序邏輯，有些進階分析選項（如同環比、日均值等）添加額外的組裝邏輯，然後處理分頁，整個過程中需要結合方言适配，查詢資料時根據不同的引擎連結器查詢不同的資料庫（如mysql、palo、clickhouse等）。
5、查詢&處理資料：通過連結器查詢資料後，對資料進行處理（日期格式處理、折線圖的透視等）。
6、緩存：處理後的資料寫入緩存；或查詢時如果直接命中緩存則直接讀取緩存資料并傳回。
7、前端渲染架構統一渲染：傳回統一的資料格式，前端完成圖表、樣式等适配渲染。
查詢優化：Ⅰ>緩存+自動上卷，覆寫70%公共儀表盤請求。
1、兩種緩存方式：
- 首次查詢：使用者首次通路（緩存穿透），查詢資料庫，然後寫入緩存。
- 離線任務預熱：掃描公共儀表盤圖表記錄，模拟圖表請求（每次更新500+）強刷緩存。
2、自動上卷：
根據曆史查詢的三元組（名額、次元、篩選），建立上卷表，查詢命中上卷表，查詢的資料量級大幅減少，性能加快。
查詢優化：Ⅱ>優化建構SQL查詢，充分利用MPP架構引擎（如clickhouse/palo等）的聚合能力。
公共資料集分析場景下，查詢出資料後，再在記憶體中聚合計算，幾乎不太可能（如(a + b) / c需要基于明細資料a、b、c聚合計算），需要借助引擎側MPP架構的查詢能力，将聚合計算提煉到引擎側執行，如同環比按月聚合，資料量涉及百億，引擎側聚合計算後的資料量減少幾十倍，性能也随之提升幾倍。
查詢優化：III>多域名并發請求，多協程響應處理。
1、浏覽器并發6限制：通過多域名方式，将圖表請求與其他請求分流，保證平台互動流暢，圖表請求并發度提升，進而提升總體性能。
- 對作業系統端口資源考慮：PC總端口數為65536，那麼一個TCP（http也是tcp）連結就占用一個端口。作業系統通常會對總端口一半開放對外請求，以防端口數量不被迅速消耗殆盡。
- 過多并發導緻頻繁切換産生性能問題：一個線程對應處理一個http請求，那麼如果并發數量巨大的話會導緻線程頻繁切換。而線程的上下文切換有時候并不是輕量級的資源。這導緻得不償失，是以請求控制器裡面會産生一個連結池，以複用之前的連結。是以我們可以看作同域名下連結池最大為4～8個，如果連結池全部被使用會阻塞後面請求任務，等待有空閑連結時執行後續任務。
- 避免同一客服端并發大量請求超過服務端的并發門檻值：在服務端通常都對同一個用戶端來源設定并發閥值避免惡意攻擊，如果浏覽器不對同一域名做并發限制可能會導緻超過服務端的并發閥值被BAN掉。
- 用戶端良知機制：為了防止兩個應用搶占資源時候導緻強勢一方無限制的擷取資源，導緻弱勢一方永遠阻塞狀态。
2、服務端多程序+多協程并發：
- 使用多程序開發時，可能會遇到“驚群問題”，即多個程序等待同一個事件。當事件發生時，所有的程序都會被核心喚醒，但喚醒後隻有一個程序獲得了該事件并進行處理，其他程序發現擷取時間失敗後又繼續進入了等待狀态，監聽同一個事件的程序數越多，争用CPU的情況越嚴重，造成了嚴重的上下文謝歡成本。
- 故針對這種情況，uwsgi服務設計并實作了共享鎖機制，保證同一時刻隻有一個程序在監聽事件，解決了驚群問題。
- 但即使如此，程序數也不能無限制擴增，一般建議等于2倍的cpu核心數。
- 那既然程序數有限制，如何提高吞吐呢？一般情況下IO是阻塞的，你在讀資料庫或者讀檔案時，目前的程序、線程會一直等待，直到 IO 操作傳回結果才能繼續執行後續的代碼。如果我們通過多線程的方式增大吞吐，遇到IO阻塞，線程會卡住，其他并發請求就沒線程處理了，通過協程實作異步的 IO，即對于每一個線程來說，在自己 IO 時不再等待 IO 結果，而是先去處理新來的請求，等 IO 完成了再跳回到需要等待 IO 的這段代碼。通過這種方式，我們充分利用了程式中的每一個線程，讓它們永遠有事可做。這種方式提高了整體的吞吐量，降低了整體耗時，對單個耗時沒有影響。
2.2.2 系統保障
訂閱預警：
使用者可針對報表進行報告配置，可根據訂閱管理界面，對生成的訂閱報告進行管理，并可檢視系統的執行日志即報告的推送情況。
報告配置主要包括四部分，推送内容、推送形式、觸發條件和推送人：
推送内容：單個圖表、整張報表
推送形式：三種形式推送
- 圖表截圖
- 圖表的csv資料郵件附件
- 報表截圖
觸發條件：
- 定時推送，根據cron表達式定時推送。
- 在資料完成同步時推送，在該報表所有圖表關聯的資料集完成資料同步時，觸發推送條件，完成郵件通知。
推送人：郵箱賬号，多個時以“,”分割。
權限：
資料權限分級管控：基于資料集&儀表盤雙層鑒權核心，支援行列權限按規則粒度申請授權，靈活控制使用者權限。
高效協同：打通MPS（統一權限管理系統）統一權限服務，實作權限的審批、到期回收、離職當機等能力，打通如流辦公，加速權限審批的高速流轉。
GEEK TALK
03
總結和規劃
3.1 總結
經過不斷疊代，TDA已基本具備一站式自助分析能力，實作了以下幾個名額：
- 規模增長：pv由0增長到2w+，uv由0增長到1000+，每日新增圖表由0增長到300+。
- 性能提升：儀表盤首屏90分位耗時從10s+下降到5s。
- 業務提效：促成核心業務80%+自助化率，波動分析效率提升20倍，單次名額波動歸因分析端到端從2小時->5分鐘内。
3.2 規劃
随着AI原生技術在各個領域的滲透，未來TDA也會結合AI技術，提升平台的智能分析體驗，主要有如下幾點：
- 資料自助接入：會放開資料接入，擴充資料源類型等。
- AI+BI：歸因分析、嵌出式分析、分析報告等BI能力，結合大模型AI，完善智能分析産品。
- 管理駕駛艙（探索）：OKR目标儀表盤。
作者:Someday
來源:微信公衆号:百度Geek說
出處:https://mp.weixin.qq.com/s/gQEKKnhXPJTTLi-swONQdQ