大家晚上好，我是百度外賣·研發(fā)中心·大數(shù)據(jù)研發(fā)部的高級研發(fā)工程師，劉海宇。今天有幸為大家分享下我們大數(shù)據(jù)部門的一個報表系統(tǒng)。

大家應(yīng)該都看到了圖中的彩色字體，“自如報表”、十分醒目。這個“自如”在我們今晚的分享中是啥呢？不是租房、不是搬家，這個“自如”呢其實是我們馬上要介紹的這個報表系統(tǒng)的項目代號。

為什么叫“自如”呢？來自首席架構(gòu)梁福坤賦名，抽象自《金剛經(jīng)》第三十一品 知見不生分，“于一切法，應(yīng)如是知，如是見，如是信解，不生法相?！?/strong>，初衷想讓我們的報表系統(tǒng)可以做到：展示靈活、數(shù)據(jù)源靈活，不要拘相。這種平臺化交付設(shè)計在百度外賣大數(shù)據(jù)平臺中體現(xiàn)的淋漓盡致，通過我們本節(jié)課的介紹，大家會有較深刻體會。

下面來看下本次課程的一個簡要的介紹。從上一頁的大標(biāo)題也看出來了，本次課程會緊密圍繞“報表”兩個字來展開，數(shù)據(jù)報表、報表平臺，離不開“報表”兩個字。

課程內(nèi)容

如本頁ppt所述，課程內(nèi)容方面呢，本次課程會為大家介紹一個有高度定制化特點的、并且能夠按規(guī)則例行的這樣一套報表體系。這里有兩個關(guān)鍵字昂，定制化和例行化。什么是定制化？就是很靈活，內(nèi)容可以完全由自己指定，包括數(shù)據(jù)表格的內(nèi)容、展現(xiàn)形式、布局以及樣式等等從大到小的點、只要你想指定。

那么什么是例行化？比如每小時例行、每日例行、每周例行、每月例行，就像大家平時發(fā)的的時報、日報、周報、月報，甚至季度報、半年報。叨叨了這么多，配置方面呢，大家放心，也是很高效靈活的，并且我們也提供了一個非常強大的可視化界面。

課程關(guān)鍵字

課程關(guān)鍵字方面，報表解決方案。這里要重點強調(diào)的是說，我們的這個報表系統(tǒng)啊，適用于用sql出報表的使用場景。之所以是sql，是因為sql的靈活度高，只要基礎(chǔ)數(shù)據(jù)在那里，用戶想要什么數(shù)據(jù)完全可以自己搞出來。其它的出數(shù)據(jù)的方式，我們這個課程暫不涉及。如果您平時不用sql出報表，也不妨聽一下，說不定也會有所收獲呢。

課程傾向

課程傾向這一塊呢，會有功能展示與設(shè)計方案這兩部分組成。因為是一個我們這邊正在線上使用的一個報表工具，直接講設(shè)計思路和解決方案太抽象，所以會有一些ppt頁面給大家展示這個工具的界面、以及簡單的使用流程。雖然是界面和功能的展示，也希望能夠在與大家分享的過程中，哪怕有零星幾個亮點功夠引起大家的共鳴、甚至能夠在未來的某日落地應(yīng)用到大家的報表體驗中。當(dāng)然，大家有改進建議或者問題吐槽我們也隨時歡迎。然后基于這些功能展示，我們會講一些重點難點的設(shè)計思路和解決方案。

面向人群

面向人群方面，就是與報表、與數(shù)據(jù)相關(guān)的我們。不是研發(fā)人員，也完全能夠融入其中。

看到本次課程的主要內(nèi)容。第一章、第二章主要是體驗與展示，第三章第四章是系統(tǒng)設(shè)計與解決方案方面的，我們會首先介紹下整體的架構(gòu)和設(shè)計，然后介紹下這個報表系統(tǒng)發(fā)展上遇到的痛點，有兩個具體的案例會跟大家分享。第五章，介紹下我們的所見即所得的高大上的可視化，如何三步走秒配報表。最后，總結(jié)和答疑。

第一章 初體驗

好，下面我們來看下第一章，對這個報表系統(tǒng)的初體驗。

1.需求場景

1.1 人工報表時代

首先來看一下需求場景，通俗的講，就是我們?yōu)槭裁串?dāng)初要做這個報表系統(tǒng)、我們當(dāng)初遇到了什么困境讓我們“不得已”開發(fā)了這套系統(tǒng)呢。當(dāng)然，不得已加引號，開發(fā)人員開發(fā)的還是很開心的。

相信大家中的一部分人，是天天與sql、與數(shù)據(jù)、與報表、與郵件打交道的報表配置人員。也許你們已經(jīng)有了更加高大上的報表系統(tǒng)，但是一部分同學(xué)呢，肯定還是需要每日人工查詢sql、每日人工導(dǎo)出數(shù)據(jù)、每日人工發(fā)出報表郵件。

如ppt中所述，為了每天獲取最新的數(shù)據(jù)，所以必須要人工完成一系列查詢、導(dǎo)出、郵件流程，以及一些美化。美化方面就比較細節(jié)了，比如說有插入折線圖、文字大小字體，甚至行列轉(zhuǎn)置、合并單元格，以及數(shù)據(jù)千分位、正數(shù)用什么顏色負數(shù)用什么顏色這種細節(jié)問題。

這個過程，無疑耗費了人力，每個人維護多張報表的話，一張報表可能一天要花1小時的時間來維護，少則幾分鐘。而且，如果數(shù)據(jù)需求方需要每天5點6點就給到數(shù)據(jù)呢？這樣如果每日都人工去做，很難受，內(nèi)心是拒絕的。當(dāng)然，這個報表系統(tǒng)上線之前我們也是這么做的。

1.2 “自動”代替“人工”

所以，我們?yōu)楹尾幌朕k法把“人工”改為“自動”呢？可以看到ppt三個紅色的圓圈，自動查詢、自動郵件、自動美化和加工。這就是我們這個報表系統(tǒng)做的工作。

當(dāng)然，sql自己寫，前面也說到了，我們這個報表系統(tǒng)適用于配置人員使用sql出數(shù)據(jù)的場景，出什么數(shù)據(jù)我們不管，sql配置人員自己來寫。其實通過后面的講解，會發(fā)現(xiàn)配置人員關(guān)注的點有且只有sql本身，其它的都交給我們。那么這個過程對于曾經(jīng)的報表配置人員來說，大幅度的解放了人力，全自動、一次配置、一勞永逸。具體的配置過程，我們后面會看。當(dāng)然，當(dāng)業(yè)務(wù)變動而牽扯到sql細節(jié)修改的這個更新過程，這個還是需要配置人員親自動手的。

還有，最下面那個帶蛤蟆鏡的小人頭表情包左邊的兩句話，大家請瞄一眼。高度自定義、按規(guī)則例行。

2.自如報表閃亮登場

2.1 定制化與例行化

下面，我們的報表系統(tǒng)，即“自如報表”閃亮登場。是能夠?qū)崿F(xiàn)那兩個功能的報表系統(tǒng)，重復(fù)了好幾遍了。聽眾們是否有共鳴呢？是否你也需要這樣的內(nèi)容高度定制化、按規(guī)則例行的這樣一套報表解決方案呢，帶著這樣的需求我們繼續(xù)講解。

2.2 如何實現(xiàn)定制化

看到ppt里面的交互圖，整個報表系統(tǒng)的工作流程是這樣的。紅色的兩條箭頭，是配置人員需要關(guān)注的。專人配置報表，專人配置例行規(guī)則。

以“日報”為例，這兩個“專人配置”是人工的，但是是一次性的。只需要配置一次，明天開始甚至當(dāng)天就可以開始例行發(fā)送了，后面大家就不用操心了。當(dāng)然，一些變動和修改除外。配置日報，即第一條紅色箭頭呢，需要做的就是把sql告訴我們的報表系統(tǒng)。第二條紅色箭頭，就是告訴我們的系統(tǒng)每天什么時候發(fā)，比如早晨8點、上午10點，或者等某個前置任務(wù)成功之后日報發(fā)出，這個前置任務(wù)可能是數(shù)據(jù)準(zhǔn)備或一個數(shù)據(jù)校驗的任務(wù)。收斂一下，第一條紅色箭頭，把報表配置告訴報表系統(tǒng)。第二條紅色箭頭，把例行規(guī)則告訴調(diào)度系統(tǒng)。

談及“調(diào)度系統(tǒng)”，這個系統(tǒng)是與我們的報表系統(tǒng)相獨立的一個系統(tǒng)。按照事先指定的小時、日、周、月等時間頻次以及依賴關(guān)系進行任務(wù)觸發(fā)，并監(jiān)控任務(wù)執(zhí)行狀況的系統(tǒng)。比如什么任務(wù)需要幾點執(zhí)行、什么任務(wù)需要在哪一個或哪幾個任務(wù)執(zhí)行完了再執(zhí)行。關(guān)于這個系統(tǒng)，我們后面也安排了相應(yīng)的課程為大家講解，名字叫“通天”調(diào)度，一個很高大上的名字。本節(jié)課程不多描述。

2.3 如何實現(xiàn)例行化

日報是如圖紅色箭頭的兩個流程，周報、月報一樣。重點文字，大家可以看到右下角。配置之后呢，等到了相應(yīng)的時間點，或者相應(yīng)的條件符合了，調(diào)度系統(tǒng)就會自動回調(diào)報表系統(tǒng)，觸發(fā)日報發(fā)送動作。稍許等待，日報就發(fā)出了，發(fā)到了用戶的郵箱。這兩個過程，回調(diào)和發(fā)出是完全自動的，即上圖兩個藍色箭頭，用戶不用操心。當(dāng)然，發(fā)出的時間也與用戶sql本身的復(fù)雜程度和數(shù)量有關(guān)，后面我們也會講到一些優(yōu)化的方式。

好了，這就是一個自如日報的配置和發(fā)送流程。

3.自如報表能做什么

3.1一張標(biāo)準(zhǔn)報表

下面開始展現(xiàn)一下我們的報表系統(tǒng)能做什么。如ppt中，這是一封標(biāo)準(zhǔn)的報表郵件。出于數(shù)據(jù)安全的考慮，部分數(shù)據(jù)需要打碼。

一般的報表呢，由一個表或多個表、每個表格都是一行一行的數(shù)據(jù)。這個功能，我們完全能夠?qū)崿F(xiàn)，也是最最基礎(chǔ)的功能。同時，可以方便的添加標(biāo)題、二級標(biāo)題、三級標(biāo)題等，就是ppt中這個例子圖片中的紅色字體。

以及樣式，字體、顏色、字號、粗體，表格的樣式、文字的樣式都可以很方便的配置。當(dāng)然，也可以選擇默認的樣式，更加減少自己的配置成本。

還有百分比的紅正綠負這樣的動態(tài)數(shù)據(jù)樣式策略，以及正文中第一行寫到的配置人員是誰、有問題找誰。

這是一封最基礎(chǔ)的最普通最標(biāo)準(zhǔn)的數(shù)據(jù)報表郵件。其實只要你有sql，這封報表就能出，其它的什么都不用管。

3.2 帶附件的報表

這一個功能說的是附件。郵件正文是一部分，有的數(shù)據(jù)不適合放郵件正文，我們也支持放到附件。附件支持xls和csv格式，后者會有更小的體積。

以及ppt中這個例子的最下面一行，有一句“指標(biāo)定義”的解釋，只要你想加上，隨便加。常見的比如指標(biāo)口徑的解釋，更加方便大家理解和使用你的報表。

仔細看的話，可以看到這個例子中報表的結(jié)構(gòu)，一張表格不像一條sql能跑出來的。可能需要更多的變換和組織。不用擔(dān)心，絕大多數(shù)情況下，只要你知道原本用excel怎么出，該系統(tǒng)幾乎都能支持到。

3.3 帶圖形的報表

表格展示展示完了。報表中難道只有表格嗎？還會有圖形，比如常用的折線圖、柱狀圖、扇形圖。都可以使用這套系統(tǒng)進行繪制和例行發(fā)出。

而且，對于一張已經(jīng)現(xiàn)成的表格。繪制為圖形也是很簡單的，我們支持對已有表格數(shù)據(jù)的引用。以及表格、圖形、附件可以融合在一張報表中發(fā)出。

圖形本身呢，寬度、高度、是否顯示圖例、柱子顏色等屬性，用戶可以使用默認配置，也可以進行個性化的設(shè)置。

只要你有sql，圖形就能出來。

3.4 與第三方數(shù)據(jù)平臺打通

除了基礎(chǔ)的表格和圖形功能之外呢，這個報表系統(tǒng)本身還會與其它的數(shù)據(jù)平臺進行打通。這里舉個例子，我們這里有個數(shù)據(jù)平臺叫做“亮劍”，是提供數(shù)據(jù)的例行拉取或主動推送，并支持多維度多方式展示數(shù)據(jù)的一個數(shù)據(jù)平臺。

當(dāng)日報郵件發(fā)出，用戶收到的只是一封郵件。關(guān)于歷史數(shù)據(jù)只能去歷史郵件中找，而且不能夠點擊和交互。當(dāng)用戶有這種分析歷史數(shù)據(jù)，還能夠以交互的方式分析歷史數(shù)據(jù)的需求的時候，就適合用到這一個功能。

日報發(fā)出的時刻，會把數(shù)據(jù)同步推送到亮劍。日報中也會攜帶一個鏈接，用戶單擊鏈接就可以看到平臺上的這一張報表，如圖所示，含有歷史數(shù)據(jù)以及豐富的圖形化展示。

3.5 細節(jié)功能——行列轉(zhuǎn)置

下面看5個典型的、能夠提升用戶體驗、豐富大家日報內(nèi)容和形式的細節(jié)功能。

先來看第一個，這里首先介紹的是行列轉(zhuǎn)置功能。如ppt中的例子，一個sql輸出A表格很簡單，只需要按照時間字段group by，然后select語句中輸出相應(yīng)指標(biāo)即可。但是一個sql輸出B不容易，B的特點是是一行一個指標(biāo)，一列一個日期，大家可以思考下如何一個sql產(chǎn)出呢？也許可以，但是并不容易。

這種場景下，你只需想辦法查出A，然后在這個報表系統(tǒng)中進行一個配置、或者可以理解為勾選一個“行列轉(zhuǎn)置”的勾選框，B就會出來了，并隨郵件發(fā)出。很方便實用的功能。

3.6 細節(jié)功能——動態(tài)合并單元格

第二個細節(jié)功能，合并單元格。不需要大家手動的指定哪幾個單元格合并。因為很多情況下，需要根據(jù)查詢出來的具體數(shù)據(jù)進行合并，這個數(shù)據(jù)的樣子在我們配置的時候往往是未知的，而且隨著業(yè)務(wù)發(fā)展是會發(fā)生變化的。雖然人工報表時代可以實現(xiàn)，但是在這種托管式的一次配置一勞永逸的報表方式下如何才能應(yīng)付自如呢？

所以，這里就提供了動態(tài)合并單元格的功能。并且，為了可控，還會提供下標(biāo)和區(qū)間控制選項，讓合并行為發(fā)生在你想要的可控范圍內(nèi)。

右下角那個可憐的很小的圖片，是前面講到的行列轉(zhuǎn)置與本頁講到的動態(tài)合并單元格混合使用的案例。大家有興趣，可以放大看一下。以及考慮下，如果沒有這兩個小功能，如何用一條sql產(chǎn)出這一個表格呢。

3.7 細節(jié)功能——自定義動態(tài)樣式

第三個細節(jié)功能，自定義動態(tài)樣式。這是個很炫的細節(jié)功能，支持五彩斑斕的動態(tài)樣式設(shè)置。比如你有一個表格描述了所有銷售人員的銷售業(yè)績，你要把銷售額最高的那一個銷售人員的那一行展現(xiàn)為紅色背景、白色字體、加粗、字體大一號，銷售額最低的是綠色背景、白色字體、加粗，雖然這對銷售額低的同學(xué)來講很是沒面子。

用以往的人工報表肯定可以實現(xiàn)，人工判斷下，然后選中、標(biāo)個顏色即可。但是這種托管式的、一勞永逸的配置模式下，如何實現(xiàn)呢？而且數(shù)據(jù)本身在查詢和發(fā)出前都是不可預(yù)測的。所以，在這種場景下這個細節(jié)功能就有了用武之地。

支持最大值、最小值、區(qū)間的樣式策略。最大值最小值好理解，區(qū)間值的策略，比如對一列進行設(shè)置，數(shù)值1000-2000是紅色粗體，2000-3000是紫色粗體等等。樣式方面，你能想到的樣式策略比如字體、字號、加粗等都是支持的。而且可以控制樣式的作用范圍是單元格范圍還是行的范圍。

與行列轉(zhuǎn)置結(jié)合使用，比如圖中圖E的例子。如果不提供這一系列的功能，E以及其它例子的樣子是很難實現(xiàn)的。其他的例子，大家可以點開本頁ppt看下文字描述。就不一一說明了。

3.8 細節(jié)功能——數(shù)據(jù)格式化

第四個細節(jié)功能，數(shù)據(jù)格式化，這是個很普遍的功能。比如訂單量要用千分位來表示，流水要用千分位并且保留兩位小數(shù)來表示，新用戶占比要用百分比來表示。這些都是可以靈活指定的。具體的語法，可以看到ppt里面的這個表格，指定是很靈活的。而且，我們后面要講到的可視化部分也做了對常用格式的一鍵選擇的支持。

3.9 細節(jié)功能——收件人列表托管

第五個要展示的細節(jié)功能，也是最后一個細節(jié)功能，收件人列表的托管。

傳統(tǒng)的郵件發(fā)送呢，都是由配置人員手工指定、人工維護主送和抄送人員的。那么在某種場景下，我們更希望通過系統(tǒng)來維護、自動分法。這就用到了我們這個收件人列表托管功能。

比如說，ppt中的圖片中的例子，我們要按城市權(quán)限分發(fā)報表郵件給代理商，代理商是與城市掛鉤的，A代理商是某城市的、那么他就只能收到該城市的數(shù)據(jù)。

這個掛鉤的映射關(guān)系呢是由系統(tǒng)來維護的。那么允許用戶指定開啟這樣一種分發(fā)方式，并按照規(guī)范指定權(quán)限參考字段，這個例子里面就是城市名字段嘛。然后平臺會根據(jù)分發(fā)規(guī)則進行自動的發(fā)送，把相應(yīng)城市的數(shù)據(jù)分發(fā)給相應(yīng)的城市。因為城市有很多，所以會產(chǎn)生很多獨立的郵件報表，但是對于配置人員來講他只需要維護一份配置。

3.10 配套設(shè)施——日報級監(jiān)控

功能展示的最后，來看兩個配套的監(jiān)控。

這里首先出場的監(jiān)控功能是報表級的監(jiān)控，能夠查看當(dāng)前報表的發(fā)送狀態(tài)和耗時。以及報表本身的一些信息，比如分類、用戶簽到記錄、發(fā)送歷史和關(guān)聯(lián)的調(diào)度信息。

這里不詳細的一一描述了，感興趣的同學(xué)可以看到ppt里面的文字，有寫到使用場景和解決方案，關(guān)于簽到信息那塊我們后面會作為案例重點講到。

3.11 配套設(shè)施——sql級監(jiān)控

有了報表級別的監(jiān)控，其實還不夠。比如一個報表開始了很久了但是發(fā)送狀態(tài)一直是發(fā)送中，感覺有問題，當(dāng)然可以找研發(fā)同學(xué)幫忙看日志。但是為了讓用戶能夠自助定位問題，包括也為了方便研發(fā)人員定位問題，這時候我就需要一個sql級別的監(jiān)控，從而定位到用戶當(dāng)前查詢的是哪一條sql、以及sql的耗時。從而呢，就可以統(tǒng)計出哪些sql耗時較久影響了整體發(fā)送，方便定向優(yōu)化。

包括查詢報錯、發(fā)送失敗，這時候呢，也是需要這么一個sql級的監(jiān)控，來定位到具體是哪一條sql有問題，如ppt中的兩個圖片。下圖是一個查詢失敗的sql的報錯信息。

3.12 小節(jié)

介紹了很多功能。主要功能是表格和圖形。以及各種好用好玩的細節(jié)功能，幫助報表配置人員方便的輕松實現(xiàn)各種想要的靈活的報表內(nèi)容和形式。

杜絕日復(fù)一日的人工，要一次配置、一勞永逸。

第二章 簡單示例

下面來看到第二章。第二章會比第一章短很多。設(shè)計與方案相關(guān)的后面章節(jié)會講到，為了避免講解起來太抽象，這里主要結(jié)合一個非常簡單的示例來為大家介紹一下配置流程。

1.人工時代的流程

比如現(xiàn)在一個同學(xué)，叫小明。小明同學(xué)呢，寫出了一個sql，如ppt中所述。是一個查詢某日期的若干城市的白天溫度和白天天氣的sql，~例子非常簡單。以往的方式呢，是手動查詢、導(dǎo)出、郵件、發(fā)出。小明同學(xué)失去了每天早晨多吃一根油條的的時間。

2.自如的自動化流程

2.1 下載預(yù)置模板

于是，老巫婆飄過來了，在右上角，那個sql也在。講解了配置我們自如報表的基本步驟。老巫婆講解起來的表情，比天橋下貼手機膜的都認真。

第一步，到平臺去下載一個基礎(chǔ)的預(yù)置模板（默認模板）。

這里大家肯定會有疑問。什么是模板？官方定義，模板就是承載報表全部內(nèi)容的一個載體，比如數(shù)據(jù)內(nèi)容、就像用戶書寫的sql，比如樣式內(nèi)容、就像字體和表格的高矮胖瘦，比如細節(jié)屬性、就像是否轉(zhuǎn)為附件啊、是否使用行列轉(zhuǎn)置啊類似的功能。在這里呢，我們的模板采用html來進行存儲。

當(dāng)然可以使用其它的文件來存儲或者更好的方式，比如xml，那還得自己定義一套標(biāo)簽體系和樣式規(guī)則。這里之所以用html，是因為它的語法是標(biāo)準(zhǔn)化的，而且很方便的可以定義頁面的內(nèi)容和樣式。估計大家也都用過html，內(nèi)容可以通過div、table、h1這類的標(biāo)簽來指定，樣式呢即css。瀏覽器可以直接打開html，所見即所得。

雖然這里講到了很多html、css這樣的代碼。一般情況下，用戶是無需關(guān)注的，搞到預(yù)置模板（默認模板），sql粘貼進去就可以了。包括我們后面還開發(fā)了可視化，來進一步減輕這一個過程的配置成本。

2.2 粘貼sql

預(yù)置模板（默認模板）下載到了，那么下一步就按照我們前面所說的，把sql粘貼到相應(yīng)位置就可以了。當(dāng)然，表頭的列中文名以及展示順序也需要同步的指定下，否則出來的表格很難看。

這里大家的疑惑，一定是為什么要使用這樣的標(biāo)簽結(jié)構(gòu)？那個標(biāo)簽是什么東西呢？之所以用這樣的標(biāo)簽配置結(jié)構(gòu)。是因為我們系統(tǒng)中事先制定了一套約定和規(guī)范，服務(wù)端就會按照這樣的結(jié)構(gòu)去解析，所以呢也會引導(dǎo)用戶這么去寫?？傊?，這里跟大家分享的是報表的解決方案，不是使用和實現(xiàn)的細節(jié)。當(dāng)然，如果大家有更友好的約定和規(guī)范，以及實現(xiàn)方案，也歡迎與我交流。這里呢，只是舉例說明。

2.3 上傳到平臺

最后，上傳到我們的平臺。在頁面中寫好郵件標(biāo)題、主送抄送，點發(fā)送，郵件就發(fā)出來了。最終結(jié)果如ppt中右圖所示。

2.4 例行化的配置

其實到上一步，整個配置過程就完成了。

回顧一下，第一下載，第二粘貼sql，第三上傳發(fā)送。就完成了。要關(guān)注的重點似乎只有sql，如果一個報表中有多個sql，那就照貓畫虎的把基礎(chǔ)模板中相應(yīng)的區(qū)域復(fù)制幾遍即可。

最后這里呢，說的是例行化的配置，比如日報、來指定每天幾點發(fā)，周報、來指定每周幾的幾點發(fā)，月報、來指定每月的第幾天的幾點發(fā)。

到這里呢，第二章所要介紹的配置流程就講解完了。

第三章 系統(tǒng)設(shè)計篇

那么有了形象的功能展示和配置流程作為基礎(chǔ)，下面我們來看系統(tǒng)設(shè)計篇。會從平臺架構(gòu)與交互流程這兩塊入手來看，以及最后為大家簡要介紹一下主要模塊的技術(shù)方案。

1.平臺架構(gòu)圖

1.1 基礎(chǔ)版架構(gòu)圖

首先來看基礎(chǔ)版本的架構(gòu)圖。之所以叫基礎(chǔ)版本，是因為這個架構(gòu)圖所提供的服務(wù)，已經(jīng)滿足了最基本的報表發(fā)送流程的訴求。關(guān)于后續(xù)功能如可視化、第三方集成這張圖中沒有。也是為了方便大家理解。

這個架構(gòu)圖中，結(jié)構(gòu)比較簡單。最上層用戶UI，就是用戶下載上傳模板、填寫主送抄送。然后與自如的基礎(chǔ)服務(wù)進行交互，比如作業(yè)注冊、模板解析等，這個后面會一一提到。然后底層依賴了緩存，比如用戶多次查詢同一條sql，那么如果用戶需要，第二次及其以后的就會從緩存中讀取。以及依賴了API接口還有底層的集群服務(wù)。最后，是右邊的通天調(diào)度，負責(zé)例行化，貫穿了整個流程的始終。

自如報表系統(tǒng)最關(guān)心的是上兩層，即平臺UI和基礎(chǔ)服務(wù)。其實本身這個報表系統(tǒng)也是建立在一些底層服務(wù)之上的數(shù)據(jù)應(yīng)用平臺。

1.2 擴展版架構(gòu)圖

看完基礎(chǔ)版本的架構(gòu)圖，我們再快速看一眼擴展版本的架構(gòu)圖。這里就加入了可視化、第三方的支持。以及我們后續(xù)不斷的對模板解析和優(yōu)化插件的升級。

可視化后面會有一章為大家講解。第三方系統(tǒng)因為涉及了其它較多的系統(tǒng)，牽扯內(nèi)容較多，本節(jié)課不會介紹。

2.交互流程圖

下面我們重點看一下自如的服務(wù)器端，即我們所關(guān)心的自如的基礎(chǔ)服務(wù)那一層所做的事情。右上角的縮略圖是前面提到過的一個簡易的流程圖，現(xiàn)在我們把中間的那塊“報表系統(tǒng)”展開，其它的基本沒有變化。大家重點看到ppt中流程圖的中間部分的兩個矩形框。上面的矩形框是作業(yè)注冊的流程，下面的矩形框是作業(yè)發(fā)送的流程。

2.1 作業(yè)注冊

根據(jù)我們前面的流程的舉例講解，用戶配置好報表模板后，即可以到平臺進行作業(yè)的注冊以及例行規(guī)則的指定了。這就是上面的矩形框。

2.2 作業(yè)發(fā)送

當(dāng)時間符合或者依賴就緒的時候，比如到了早晨8點，某日報要開始發(fā)送了。通天系統(tǒng)回調(diào)報表系統(tǒng)，觸發(fā)發(fā)送流程。這就是下面的矩形框。

發(fā)送流程呢，首先獲取到了作業(yè)的元數(shù)據(jù)，如配置人員、郵件主題、主送抄送，最重要的是獲取到所對應(yīng)的模板文件。讀取到這一系列信息后，開始對那個模板文件進行解析，比如取出某一個表格的sql、以及解析到是否需要轉(zhuǎn)化為附件、是否需要行列轉(zhuǎn)置等一系列內(nèi)容和屬性。知道了sql以后，就可以進行查詢了，于是把sql提交到了自如端底層的查詢隊列進行并發(fā)查詢。稍等片刻，數(shù)據(jù)返回，進行數(shù)據(jù)的組織、后續(xù)的優(yōu)化，最終發(fā)出郵件。整個過程還是很簡單的。

3.主要就模塊技術(shù)方案

上面的一系列流程很簡單。其中涉及到的主要模塊的技術(shù)方案也不困難。平臺的服務(wù)端使用java語言實現(xiàn)的。

3.1 模板解析

模板解析部分，使用的是jsoup這一個開源工具。大家有興趣可以了解下，可以非常方便的解析html文件，可以在服務(wù)器端代碼中，使用類似css選擇器的方式取出和操作數(shù)據(jù)。

3.2 并發(fā)隊列

并發(fā)隊列這一塊，用到的是jdk的java.util.concurrent包里的工具類，非常常用，用法就不多介紹了。需要重點說明的是，并發(fā)隊列在報表系統(tǒng)中有兩層。首先，底層有一個sql級別的隊列進行流量控制，限制一下同一時刻允許提交sql的最大數(shù)量，避免sql大量涌入集群。再者，上層還有一個日報級別的隊列，限制一個日報最多有幾個sql同時進行查詢，從而避免有過多sql的日報占滿底層隊列，讓其它短平快的日報需要等待好久才能發(fā)出。二者分別實現(xiàn)了集群資源的合理利用以及自如端并發(fā)資源的合理利用。

3.3 其它模塊

再往下數(shù)據(jù)組織、優(yōu)化插件以及郵件服務(wù)。尤其是優(yōu)化插件，前面在功能展示部分也有展示。大家可以看一下ppt中的問題，不做詳細說明了。

第四章 技術(shù)痛點和解決方案

到這里，自如的主要部分已經(jīng)講完了。但是，還是感覺比較平淡。那就再嘮個5毛錢的吧。下面，就為大家介紹下自如發(fā)展過程中遇到的技術(shù)痛點以及相應(yīng)的解決方案。結(jié)合兩個具體的案例來看。

1.發(fā)展史上的里程碑

首先簡單看一下發(fā)展歷程。系統(tǒng)第一版于2015年10月上線，上線之后隨著用戶的使用和反饋，遇到了一些問題和瓶頸。圖中紫色的字體說明了當(dāng)時遇到的問題。

其中，第三個臺階的自如可視化部分下一章節(jié)講解。第二個臺階和后三個臺階，分別遇到的問題是SQL復(fù)雜度高集群壓力大，和不必要的SQL數(shù)量多。為了說明當(dāng)時的場景以及解決方案，我們會對其中兩個案例進行重點說明。分別是SQL拆解聚合和日報簽到。

2.典型案例——SQL拆解聚合

2.1 需求場景

2.1.1 從現(xiàn)象入手

首先看SQL拆解聚合這一個案例。名字聽起來怪怪的，隨著講解，大家會理解這里的拆和聚的含義。這一頁ppt描述了當(dāng)時的場景，用戶sql、以及其它來源的sql、以及一些其它因素，導(dǎo)致集群狀況不佳，導(dǎo)致用戶查詢得不到數(shù)據(jù)。用戶很苦惱，我們也是在極力的去改善。

用戶得不到數(shù)據(jù)咋辦呢？會通過我們的各種平臺去嘗試，自如是其中一部分，這里還有其它的數(shù)據(jù)平臺可供用戶獲得數(shù)據(jù)。自如端來看呢，就是用戶不停的重試，包括調(diào)度系統(tǒng)也會對失敗作業(yè)自動重試。于是查詢請求越多，集群狀況越是不容樂觀，造成了這一個惡性循環(huán)。

2.1.2 惡性循環(huán)

既然有了惡性循環(huán)，我們就打算把它打破，或者有效的緩解。針對圖中黃色節(jié)點，用戶在自如提交的sql，我們打算從單條sql本身以及sql數(shù)量上做文章。

第一，單條sql方面，有的sql本身呢，占用著并發(fā)隊列的席位，提交到集群后，查詢的慢，很久才返回或者返回報錯信息，或者命中集群的監(jiān)控腳本的策略，比如查詢時間過長導(dǎo)致被殺掉。這種查詢時間長的、消耗集群資源大的，一般是由于sql本身的過于復(fù)雜，或者相對其它短平快的sql來講較復(fù)雜。我們下面就要對癥下藥，來降低這樣的sql的復(fù)雜度。

第二，sql數(shù)量上，其實由于自如端有并發(fā)控制，在自如這個口子上不會無上限的提交sql到集群，這里要做的呢，是盡量減少不必要sql的提交，在這個解決方案上來講，其實是為了減少不必要的高復(fù)雜度的sql的提交數(shù)量。

其它的，紅色節(jié)點和藍色節(jié)點的優(yōu)化方案，這里不再詳細說明。

2.2 原因探究

2.2.1 單條sql復(fù)雜度高

既然要對癥下藥，那么首先分析一下癥狀產(chǎn)生的原因。經(jīng)過對自如端用戶sql的觀察，發(fā)現(xiàn)高復(fù)雜度的sql，有這樣的特點。比如一個sql查詢多個指標(biāo)、多個指標(biāo)來源于多個事實表、以及子查詢的嵌套和關(guān)聯(lián)，還有就是本身的業(yè)務(wù)需求時間跨度長、結(jié)果集條數(shù)多。那么針對這樣的情況，除了第四種業(yè)務(wù)強需求之外，對于前三種，用戶為什么要寫這樣的sql呢？是因為傳統(tǒng)的配置方式，一個表格的一行或者多行只能由一個sql來決定，這一個sql必須完整的輸出最終要展現(xiàn)的所有列。

一部分情況下，也是用戶被迫的。那么對于這種原因產(chǎn)生的高復(fù)雜度的sql，我們的策略就是“拆”，之后再“聚”。解決方案的思路，就是把一個高復(fù)雜度的sql拆分為多個低復(fù)雜度的sql，至少復(fù)雜度是相對比較低。具體實現(xiàn)起來，就是把來源于同一個sql的多個指標(biāo)拆分為來源于多個sql的多個指標(biāo)，然后再把最終結(jié)果想辦法聚合在一起。

后面馬上會結(jié)合一個具體的例子來講解。

2.2.2 高復(fù)雜度sql數(shù)量多

上面說的是單條sql復(fù)雜度高，對應(yīng)ppt的左邊的圖。右邊的圖，講到的是高復(fù)雜度sql的數(shù)量多。經(jīng)觀察，發(fā)現(xiàn)有些不必要的高復(fù)雜度sql，除了業(yè)務(wù)強需求的原因外，是由于對現(xiàn)有sql的結(jié)果進行二次查詢、或者要取得現(xiàn)有sql結(jié)果集中某一部分作為子集等因素造成的。

大家可以考慮下這種場景，現(xiàn)在某查詢需要用到現(xiàn)有sql查詢出來的結(jié)果，由于迫于這樣的結(jié)果用戶并沒有辦法渠道，因為查詢出來直接就展示到表格了嘛，所以只能在sql中一層層嵌套、把原本一個挺大的sql嵌套為一個子查詢、然后再在這個基礎(chǔ)上做二次查詢、三次查詢等。所以，我們會針對這一種場景進行解決，為了能夠讓用戶引用到自己寫過的sql的查詢結(jié)果。

基于這兩點，圖中的先拆后聚，以及先存后用。我們就有了解決方案。

2.3 解決方案

2.3.1 傳統(tǒng)模式寫出的sql

結(jié)合一個具體的例子首先來看一下“先拆后聚”。如ppt中報表的示例所述，是我們這邊每天都在發(fā)送的一封報表的一部分。如果用以往的傳統(tǒng)模式，就是我們前面所提到的“一個表格的一行或者多行只能由一個sql來決定，這一個sql必須完整的輸出最終要展現(xiàn)的所有列”。

使用這樣的模式呢，用戶寫出來的sql可能就是如圖中那樣的，三個子查詢相互關(guān)聯(lián)然后外面包一個外層查詢輸出結(jié)果，這還是一個比較簡單的例子，不過也能說明問題。

那么這樣的sql呢，相對而言，在集群狀況不佳的情況下，有可能導(dǎo)致被殺掉、查詢慢或者報錯。以及占用著各服務(wù)的內(nèi)存，不僅不出結(jié)果，甚至還會引發(fā)一些性能問題。

2.3.2 先拆后聚——怎么拆

于是呢，我們前面所研究而產(chǎn)生的“先拆后聚”的解決方案就派上用場了。

怎么拆？可以看到ppt右側(cè)，拆為了三個短小的sql。就是原來的大sql中的三個子查詢。他們都有相同的維度列index_day。這里需要提一句，可能有的同學(xué)會覺得這個例子比較典型，直接把子查詢拿出來就完成了拆解，其實只要是迫于使用一個sql輸出最終表格所有列的、并且發(fā)現(xiàn)這個sql可以拆分為多個小sql來對每個指標(biāo)列分別查詢的、或者一個小sql查詢其中某幾個指標(biāo)、并且這幾個拆分后的sql都有相同維度列的，都能夠進行拆分，進而使用這個解決方案。這里為了方便描述，舉了這個比較典型的例子。從而，三個短平快的小sql，速戰(zhàn)速決。至少比原本的大sql查詢的要快。

2.3.3 先拆后聚——內(nèi)存聚合

怎么聚？大家可以看到ppt右側(cè)的那個大大的紅色的Map，相信大家一看就懂。Map的key存儲維度值，多個維度列那么就是多個維度值的組合值，Map的value是一個k-v映射，存儲什么指標(biāo)對應(yīng)什么數(shù)值。

但是用內(nèi)存聚合的方式呢，會有弊端。比如消耗服務(wù)內(nèi)存、多維度不好管理、冗余代碼維護、不利于二次查詢。最明顯的第三點，自己在代碼中寫這樣一個Map，肯定需要更多的代碼。這時候如果用戶再求個日環(huán)比、周同比，可能還需要一些代碼進行兼容和維護。很不方便。

本頁的最后，大家看一下上面的三個小sql的樣子，有相同的維度列index_day，各自有自己不同的指標(biāo)列。我們要進行另一個聚合方案的講解了。

2.4 解決方案——“聚”的升級版

2.4.1 中間表聚合方案

由于內(nèi)存里面聚合不太方便，于是我們采用數(shù)據(jù)庫中間表的形式進行聚合。如圖所示，這個例子生成了這樣一張中間表。其中呢，對維度列建立了唯一索引，就相當(dāng)于前面講到的Map的key。當(dāng)然，當(dāng)維度列有多個的時候，比如日期、城市為維度列，那么就建立聯(lián)合唯一索引。

2.4.2 中間表聚合步驟流程

心里帶著前面的三個小sql，跟著圖中的流程步驟一起看一下。

第一個sql查詢完畢后，如圖所示，會把index_day和第一個指標(biāo)的指標(biāo)值插入到中間表中。

第二個sql查詢完畢后，會以on duplicate key update的形式把第二個指標(biāo)也插入到中間表中。這一種插入方式，簡單解釋一下，會首先判斷唯一索引的字段值為當(dāng)前值的記錄是否存在，本例中，這里就會判斷index_day為20170817的值的記錄是否存在，如果不存在就會執(zhí)行插入，如同第一個sql插入數(shù)據(jù)時候的樣子，如果記錄已存在，就會以更新的方式更新到那條記錄的相應(yīng)字段上。

同理，第三個sql也會攜帶第三個指標(biāo)值回來，以同樣的方式把指標(biāo)值插入到對應(yīng)記錄的對應(yīng)字段中。

于是，到目前為止，在我們的數(shù)據(jù)庫里面就會生成一張?zhí)畛浜脭?shù)據(jù)的物理中間表。當(dāng)然，也允許其中的一個小sql帶多個指標(biāo)值回來，都是支持的，具體使用的時候可以在考慮和權(quán)衡。這里為了方便舉例說明。

對于我們上面說到的這種中間表，用戶就可以用sql進行任何他們想要的select操作了。一般的，用戶會指定一個查詢，把最終結(jié)果查詢出來。如ppt右上角的sql所示，輸出了最終結(jié)果。

2.4.3 使用中間表聚合的優(yōu)勢

到這里，使用中間表進行聚合的解決方案就講完了。它的好處首先與前面講的內(nèi)存映射的幾個弊端相對應(yīng)，不再消耗服務(wù)內(nèi)存、多維度好管理、無需冗余代碼。比較值得強調(diào)的是第四點，因為現(xiàn)有數(shù)據(jù)會存在一張中間表里，用戶可以用sql進行他們?nèi)魏蜗胍牟僮鳎?/strong>比如做除法、做環(huán)比、使用count或sum等進行再次的聚合、進行orderby以及l(fā)imit等操作。這些，使用冗余代碼進行兼容會很頭疼，即使兼容了用戶還要學(xué)習(xí)如何去使用，倒不如直接讓他們使用他們最擅長的sql更加方便。

最后，需要說明的是。用中間表的優(yōu)勢不止這些。有一個很好的特點是，中間表與中間表之間可以相互關(guān)聯(lián)，從而方便做二次、三次查詢。更加豐富了用戶對數(shù)據(jù)產(chǎn)出流程的把控、豐富了數(shù)據(jù)組織的形式，從而得以制作出更加豐富靈活的報表。只要你的sql能寫得出，數(shù)據(jù)產(chǎn)出流程隨你怎么控制。當(dāng)然，當(dāng)用戶需要做更加復(fù)雜的報表的時候，對用戶的需求就不再是簡單的一條sql出數(shù)據(jù)了。所以，使用者可以在靈活與簡單之間權(quán)衡一下。其實，有了這樣靈活的組織形式，使用者也是樂于參與其中的。

2.5 解決方案——多維度舉例

2.5.1 案例特點分析

如果覺得剛才的例子過于生拉硬拽，我們可以再簡單看一下這個多維度表格的例子。那么這個表格的特點是有兩個維度列，就是圖中的平臺和日期，維度列之外呢還有5個基本指標(biāo)，圖中已經(jīng)圈出。未圈出的指標(biāo)可以由已有指標(biāo)計算所得。

除此之外呢，可以看到左側(cè)，平臺這個維度有三個維度項，除了iphone和android外還有一行匯總。這一個匯總值，在以往的方式中必須由完整的sql去集群查詢從而獲得結(jié)果，現(xiàn)有的方式，其實根本不需要提交它的查詢，它的結(jié)果可以由iphone和android的結(jié)果匯總而來。

那么如果使用原有的模式，單一sql查詢集群輸出所有列，可能會導(dǎo)致各種問題，至少風(fēng)險是有的。

2.5.2 對本例實施“先拆后聚”

那么采用先拆后聚，如何拆？拆分為5個獨立的sql，就是五個指標(biāo)所對應(yīng)的各自的查詢，每個指標(biāo)的sql都需要攜帶平臺和日期。怎么聚？在中間表中，以平臺、日期作為聯(lián)合唯一索引，相應(yīng)的sql回來數(shù)據(jù)后以on duplicate key update的形式進行插入。

到了這里，中間表的數(shù)據(jù)就到位了，用戶就可以基于中間表進行二次查詢了。中間表的數(shù)據(jù)往往是通過用戶的sql查詢明細數(shù)據(jù)匯總過一遍而得的匯總數(shù)據(jù)，量級一般不會很大，速度是很快的。即使由于量級大、查詢慢，耗時幾秒，在整個報表發(fā)送的過這種也是可以忽略的。

2.5.3 隨心所欲的二次查詢

中間表有了數(shù)據(jù)，用戶的二次查詢就開始了，比如比值相關(guān)的，可以直接select 某一指標(biāo)列除以另一指標(biāo)列，或者判斷某列分母是否為0，都是很方便的。同時，我們的目標(biāo)表格中那一行匯總值，也可以由iphone和android的值匯總而來。

當(dāng)然，不是所有的值都可以匯總，比如uv指標(biāo)，需要去重，不能夠直接sum聚合。所以，還需要根據(jù)具體的場景進行選擇和權(quán)衡。當(dāng)然，我們所說的這個例子中是可以直接做sum的。

最后，看一眼最右邊的圖，這是用戶配置這個報表中實際寫的一個查詢中間表的sql。這個sql雖然長，但是細看呢都是指標(biāo)字段的select，以及除法求比值，sum求匯總，union求并集。相信，這一個功能為集群減輕查詢壓力的同時，也為用戶減輕了絞盡腦汁產(chǎn)出數(shù)據(jù)拼寫復(fù)雜sql的負擔(dān)。

2.6 用戶的配置

這個解決方案介紹完了。這里再來看一眼，用戶如何配置以激活這樣的數(shù)據(jù)產(chǎn)出流程呢。大家可以看到上面的第一步、第二步、第三步做參考，幫助理解和加深下剛才講到的解決方案的步驟。這里就不詳細說明了。畢竟這樣的標(biāo)簽結(jié)構(gòu)，是我們現(xiàn)有平臺的規(guī)范，相信大家如果要進行實現(xiàn)，一定也會有更好的配置規(guī)范。

2.7 收益與反饋

2.7.1 收益

收益方面。對于集群來講，相對減輕集群壓力、有效合理利用集群資源。自如端來講，如果用戶在需要的場景下使用了這樣的配置，會保證提交的sql相對短平快、速戰(zhàn)速決。對于用戶本身而言，報表發(fā)送更加準(zhǔn)時穩(wěn)定、體驗更好。

2.7.2 反饋

最下面是一個用戶曾經(jīng)的反饋。左側(cè)的反饋，是說到了4個報表24個sql的查詢，通過這個解決方案的提供，優(yōu)化為了4個報表4個sql查詢。4個報表串行發(fā)送，時間從原來的10min降低到了2min。大大提升了用戶的體驗。右側(cè)的反饋，是說到了中間表的高效，對于本身的二次計算和三次計算，以及多個中間表之間的相互關(guān)聯(lián)都是很靈活方便和高效的。

3.僵尸日報例行關(guān)閉

3.1 需求場景

3.1.1 每日例行的報表發(fā)送流程

下面來看到第二個案例?？吹筋}目就覺得很奇怪，僵尸日報？僵尸日報就是說的在我們平臺中，還在例行的、但是對于業(yè)務(wù)而言，其實是并不再需要的。

這個解決方案，是使用用戶簽到的反饋機制來實現(xiàn)的。用來應(yīng)對不斷增多的報表、不斷增多的sql查詢。ppt中的圖片所示流程，這個流程大家也都很了解了。通天觸發(fā)自如，自如查詢數(shù)據(jù)以及發(fā)出報表，這個過程呢是每日例行的。

3.1.2 發(fā)現(xiàn)了“只增不減”的詬病

報表配置人員很辛苦，不斷擁抱變化、應(yīng)對業(yè)務(wù)需求、配置新的報表。于是自如報表的報表數(shù)越來越多，這是根源。從而，與之配套而生的通天調(diào)度的任務(wù)也越來越多。于是通天每日觸發(fā)的報表數(shù)也越來越多，從而導(dǎo)致查詢集群的sql也是只增不減。

查詢的sql只增不減，就會增加集群的查詢壓力，本來3個就能查詢完成、現(xiàn)在卻需要5個小時才能完成全部查詢，不能很好的有效利用，而且也增加了觸發(fā)性能、穩(wěn)定性問題的風(fēng)險，也會反過來影響自如本身的查詢過程，甚至影響報表發(fā)出的穩(wěn)定性和耗時。當(dāng)然，除了集群本身，這一部分不再需要的作業(yè)對通天和自如本身的占用，也是浪費。

那么針對圖中的三個頭疼的“只增不減”怎么辦呢？

一個字，“減”。如何做到呢？在自如原有的方案中啊，會讓配置人員配置日報的同時手工設(shè)定一個截止時間點，就是說到了這個時間點，日報就不發(fā)了。但是經(jīng)過實踐和觀察，這個時間點往往設(shè)置的不準(zhǔn)，會導(dǎo)致仍需要的日報呢已經(jīng)停止了，不需要的日報還在發(fā)。而且大部分用戶的需求和美好愿景呢，是希望好不容易配置的這一封日報一直發(fā)下去，直到世界末日。

于是就有必要采取另一種方案來實現(xiàn)“減”。

3.1.3 日報簽到機制實現(xiàn)“減”

所以就有了方案二。決定清理所謂的“僵尸日報”，這一部分日報清理了，從而自如作業(yè)少了、通天任務(wù)少了，那么相應(yīng)的通天回調(diào)觸發(fā)的報表就少了，查詢集群的sql就減少了。當(dāng)然，用戶郵件數(shù)也會變少。那么何為僵尸日報？前面有解釋了，即不需要的但是還仍在發(fā)送的。怎么判斷是否需要呢？這個就需要用戶來幫忙反饋了。從而，我們就有了日報簽到機制。如圖中綠色的箭頭所示。

最終，清理這一部分“僵尸作業(yè)”，能夠幫助我們把有限的集群資源用在真正需要產(chǎn)出的數(shù)據(jù)和日報上。

3.2 功能預(yù)覽

簡單看一下用戶的簽到流程。在每一封發(fā)出的自如報表郵件的最下端，就會有一個簽到區(qū)域。用戶點擊后出現(xiàn)綠色的簽到成功。這個簽到記錄可以在平臺看到，以及平臺會提供一個簽到排行榜的頁面鼓勵用戶簽到。

就這么簡單，用戶只需要點一下即可。當(dāng)然，我們收集到這樣的簽到信息，也是報表熱度信息，基于這些熱度信息，我們也可以做一些優(yōu)先級隊列等類似的功能。

3.3 例行關(guān)閉

3.3.1 簽到為“是否仍需要”做了反饋

上面講到了用戶的簽到，簽到呢對日報的“是否仍需要”做了很好的反饋。那么下面如何根據(jù)收集到的簽到信息來判斷哪一些作業(yè)是“僵尸日報”從而關(guān)閉它們呢。ppt中的這一個圖，描述了自如發(fā)出郵件、用戶收到郵件、以及用戶簽到的流程。

3.3.2 例行判斷和關(guān)閉的邏輯

為了實現(xiàn)“減”，我們會每日例行這一個判斷“僵尸作業(yè)”并關(guān)閉它們的邏輯。看到流程圖中的A部分的文字，每天0點通天會調(diào)用自如，這次可不是發(fā)送日報，而是觸發(fā)自如的關(guān)閉“僵尸作業(yè)”的邏輯。

這里需要提到的是，通天調(diào)度系統(tǒng)不僅為自如報表系統(tǒng)提供報表發(fā)送的觸發(fā)操作。而是可以為任何可以根據(jù)時間觸發(fā)和依賴觸發(fā)的任務(wù)提供調(diào)度服務(wù)機制。

途中的A部分的文字，觸發(fā)了關(guān)閉“僵尸作業(yè)”的邏輯后。圖中的B部分文字描述的邏輯，就是自如去判定僵尸作業(yè)的過程，判定的條件呢我們這邊制定了有5個，其中“30天沒有任何簽到記錄的作業(yè)”是其中最重要的一條。如果中標(biāo)，代表這30天都沒有人在看，但是還在照發(fā)不誤。于是符合這5條條件的作業(yè)，就會被識別為“僵尸作業(yè)”。

于是就會由自如回調(diào)通天，關(guān)閉這些“僵尸作業(yè)”所對應(yīng)的通天任務(wù)。

3.3.3 實現(xiàn)最終目的

那么“僵尸作業(yè)”的通天任務(wù)被關(guān)閉了，每天活躍的通天任務(wù)就少了，從而例行的日報數(shù)減少，最終查詢集群的sql減少。確保每條sql查詢都是業(yè)務(wù)所真正需要的數(shù)據(jù)，實現(xiàn)了我們想要把有限的集群資源用在真正需要產(chǎn)出的數(shù)據(jù)和日報上這一目的。

有同學(xué)會有疑問？為什么要關(guān)閉通天作業(yè)，而不是刪掉自如作業(yè)或者通天呢？因為還是會存在極少量的日報忘記簽到，當(dāng)他們再次想起需要例行的時候，只需要把對應(yīng)的通天調(diào)度任務(wù)再次打開即可。如果這個過程執(zhí)行了刪除，那么再恢復(fù)的過程可能就不是像點一下鼠標(biāo)直接開啟對應(yīng)任務(wù)這么簡單了。

第五章 所見即所得的可視化配置

除了前面介紹的兩個典型的技術(shù)痛點和解決方案外，還有一個非常重要的環(huán)節(jié)。就是所見即所得的可視化配置，前面也有多次提到。本章節(jié)，相對前面來講，內(nèi)容以展示為主，解決方案也比較簡單。

1.引言

老巫婆又出來了，認真的為大講解。盡管在現(xiàn)有的配置方式中，配置人員只需要準(zhǔn)備好sql，然后粘貼到模板的對應(yīng)位置上。但是，對于用戶而言，特別是沒有代碼背景的用戶而言，需要接觸html代碼，配置是有成本的，而且報錯了也不能很好的一眼看出。

于是另一只巫婆提議，那么用拖拉拽、點擊雙擊、0代碼的方式讓大家配置報表是否可以接受呢？

2.需求場景

于是基于用戶的學(xué)習(xí)、配置、調(diào)試和維護成本的考慮，以及RD的客服和培訓(xùn)成本，也為了給刀耕火種的自如報表系統(tǒng)帶來一個質(zhì)的飛躍，我們開發(fā)了所見即所得的可視化報表系統(tǒng)。

目的就是讓專業(yè)的人做專業(yè)的事。報表配置人員只需要集中精力寫好業(yè)務(wù)sql，其它的交給我們。

3.功能界面

3.3.1 基礎(chǔ)頁面

既然談到了可視化。這里又是一波可視化的前端界面的展示。大家可以大致看一看都有什么內(nèi)容，希望與大家能夠得到共鳴，或者有寶貴的建議也可以反饋給我們。

這一張ppt是整個自如可視化的頁面，每個部分的功能都有詳細的介紹，一看就懂，不多敘述。

3.3.2 布局面板

這是可視化的兩塊重點的配置區(qū)域。從E區(qū)選擇所需的組件，鼠標(biāo)左鍵按住不放，拖拽到D區(qū)域松手。在D區(qū)域可以對已有的組件進行任意的拖拽、排布和縮放，為更加定制化、個性化的報表奠定基礎(chǔ)。

3.3.3 三步走生成一個報表

了解了界面的基本組成后，下面看到配置一張報表的三步。與之前第二章介紹的三步走來說可謂簡單了很多。第一步，拖拽組件；第二步，雙擊打開粘貼入sql；第三步，預(yù)覽模板輸出最終數(shù)據(jù)。

3.3.4 一張發(fā)出的報表

比如舉個例子，用戶拖拽的如本頁ppt右上角的一個布局，以及編輯了每個組件里面的sql后，最終渲染發(fā)出來的報表郵件是這樣的。最上面兩個表格，中間一個折線圖，最下面三個扇形圖。

而整個配置過程，不需要任何的代碼，html、css都不需要。需要的只是你準(zhǔn)備好sql，雙擊組件，粘貼進去，保存即可。

3.3.5 個性化的細節(jié)控制一

那么什么代碼都不需要了，用戶如何進行一些細節(jié)控制呢？如何對數(shù)值進行格式化控制、如何設(shè)置表格的字體和字號呢？如本頁ppt所示，這都是支持的。

只需要用戶動動鼠標(biāo)進行勾選。完全替代了以往的代更火種的html和css的代碼的形式。當(dāng)然，用戶也完全可以不需要這樣的配置，粘貼sql出報表即可，這些屬于美化的細節(jié)功能。

3.3.6 個性化的細節(jié)控制二

同樣的，本頁面也展示了其它的細節(jié)控制。比如上圖，是附件設(shè)置和表格顏色背景色的設(shè)置。下圖是折線圖、柱狀圖以及扇形圖的圖形選項的設(shè)置，如是否顯示圖例、x軸標(biāo)簽是否傾斜。

3.3.7“先拆后聚”仍可只關(guān)注sql

還記得我們前面提到過的SQL拆解聚合，用戶以前需要寫較長的html代碼配置。盡管有預(yù)置模板（默認模板），盡管用戶只需要關(guān)注sql本身，但是面對冗長的html還是增加了學(xué)習(xí)和配置成本。所以，這里我們?yōu)檫@個配置提供了如本頁ppt所示的配置方式，用戶只需要粘貼三個sql即可，拆解過程和識別輸出列等過程都是系統(tǒng)自動實現(xiàn)的。

比如右下角的圖，當(dāng)用戶粘貼進三個拆解后的小sql之后，系統(tǒng)會自動識別出來哪些是維度列、哪些是指標(biāo)列。如大圖所示，當(dāng)用戶粘貼入查詢中間表的最終sql后，右邊會自動識別用戶即將要輸出的列，就是圖中哪些五彩斑斕的矩形色塊。

到這里，可視化的界面功能就展示完了。下面簡單看一下設(shè)計與實現(xiàn)。

3.4 簡單架構(gòu)圖

首先看到一個簡單的架構(gòu)圖。按照ABC的順序。

A圖中，整個圖形交互層由前端UI和圖形化的服務(wù)端支持兩部分，前端UI當(dāng)然是提供給用戶，用戶可以在瀏覽器中進行操作，就像前面所講到的拖拉拽、擺放和縮放。然后整個圖形交互層整體依賴于底層通用服務(wù)，以及數(shù)據(jù)查詢。

對于這里提到的底層通用服務(wù)和大數(shù)據(jù)查詢引擎怎么理解呢？看到B圖，大數(shù)據(jù)查詢引擎，就是說給它sql、它吐出數(shù)據(jù)；底層通用服務(wù)支持就是自如的底層服務(wù)，就是以往的刀耕火種的配置模式，給它配置，它吐出報表郵件。

所以，這個可視化做的就是在以往的基礎(chǔ)服務(wù)之上做了一層用戶交互。這里的“圖形交互層”再接下來兩頁重點討論下，也很簡單。

3.5 圖形層交互流程圖

結(jié)合上一頁說到的圖形交互層，如本頁ppt右上角。對應(yīng)到用戶操作流程和服務(wù)器流程上來看，就是ppt中那個帶箭頭的流程圖，藍色背景的區(qū)域就是用戶的操作，進行組件和布局的拖拽配置。黃色背景的區(qū)域是服務(wù)端的動作，進行解析和持久化。其它透明部分，同以前的方式一樣，配置作業(yè)、通天調(diào)度。比較好理解。

3.6 服務(wù)端持久化流程圖

前端配置剛才通過功能展示看到了，也了解了與服務(wù)端的交互。這里簡單看一下服務(wù)端持久化用戶組件和持久化用戶布局的過程。

對于用戶組件和用戶布局的保存請求，服務(wù)端首先進行參數(shù)的接收，然后進行一些校驗和處理，最后存儲到數(shù)據(jù)庫的兩張實體表中。

進行這樣結(jié)構(gòu)化存儲的好處，是方便用戶對組件和布局進行修改。但是當(dāng)報表發(fā)送的時候，為了兼容底層，還是會把配置轉(zhuǎn)化為一個html文件，傳入底層進行處理和發(fā)送。

3.7 收益

本章最后，看一下可視化這一舉措所帶來的收益。通過前面的講解，相信大家也深有體會。降低了用戶的配置成本、降低了RD研發(fā)人員的教學(xué)成本，以及交互性、易用性的提升，真正的實現(xiàn)了平臺化。從刀耕火種的模板時代完成了到可視化的質(zhì)的飛躍。

第六章 總結(jié)與答疑

1.回到出發(fā)點

所有分享的內(nèi)容到這里就結(jié)束了。讓我們回到最初的出發(fā)點，看到那三個無奈的表情包。你是否有人工寫sql查詢、人工導(dǎo)出數(shù)據(jù)、人工郵件以及人工美化的工作需求呢？需要每天占用一部分維護時間，或者需要早起呢？如果有這樣的場景，不妨考慮下這個系統(tǒng)。希望通過今天的分享，能夠解決大家的一部分困惑，哪怕是一個小點的共鳴。

2.問題與答疑

最后，是問題與答疑時間。大家關(guān)于講到的功能點和解決方案有什么不理解的地方或者更好的建議，歡迎暢談。

本次分享到此結(jié)束，感謝大家的支持。謝謝大家！