400-8166108
行業(yè)動態(tài)
在這里，聆聽大咖的聲音
數據指標兩方面內容：數據指標的工具產品與梳理過程的方法論。
個人對于數據指標工具有這樣的區(qū)分，主要也是和個人的工作經歷有關。之前做過數據開發(fā)，在開發(fā)數據模型的時候，曾經待過的一家企業(yè)也有過一個數據指標系統(tǒng)，當時的數據指標系統(tǒng)，能夠實現數據指標的錄入，可以理解為Excel維護的信息，在線化的進行維護。本來計劃下一步，在建模型的時候，都使用數據指標系統(tǒng)里面管理的指標，在創(chuàng)建模型的時候以可視化的形式，下拉選擇在數據指標系統(tǒng)里面管理好的指標，不允許手動輸入模型字段，通過這種方式來保證所有建模的數據指標統(tǒng)一。但是這件事情并沒有后續(xù)，隨著時間也不了了之了。所以，現在每次聽到數據指標系統(tǒng)，第一反應就是，這個數據指標系統(tǒng)，和我之前用的那個系統(tǒng)有什么區(qū)別那？也是想在創(chuàng)建數據模型的時候，不允許手動輸入字段，通過下拉選擇，從而保證模型里字段的唯一性嗎？但是，有的數據指標系統(tǒng)，似乎又有數據查詢的能力。如果通過這個指標系統(tǒng)能夠查詢數據的話，是不是就和上面說的是完全不同的兩個系統(tǒng)了？所以，個人就對數據指標系統(tǒng)進行了一個分類。（這個分類很個人，目前沒看到其他人這么分。）。這個分類就是，當說數據指標系統(tǒng)的時候，需要回答的第一個問題是：這個數據指標系統(tǒng)是一個指標口徑管理系統(tǒng)，還是一個指標數據查詢系統(tǒng)。指標口徑管理系統(tǒng)，是面向數據加工者的，即主要是數據加工者使用。是在開發(fā)之前確定好指標名稱，口徑，取數方式等等，目的是讓開發(fā)的數倉模型更加規(guī)范化?？梢岳斫鉃橐粋€在線的Excel，如果沒有這個系統(tǒng)的話，指標信息的收集、保存都是通過Excel來完成。
指標數據查詢系統(tǒng)，是面向數據消費者的，即主要是數據消費者使用。是讓數據消費者能夠更好的找到指標，并使用指標查詢分析指標數據，甚至，想要直接通過指標數據查詢之后，和BI可視化系統(tǒng)做關聯，生成報表。目的是加速數據消費者的數據消費，統(tǒng)一指標口徑，是一種數據消費的形式。這兩個其實是完全不同的兩個系統(tǒng)，或者說完全不同的內容。
在上面也簡單說了，指標口徑管理系統(tǒng)，是一個在線的指標信息維護系統(tǒng)，保存的是梳理好的各個指標字段，算是一個指標庫，它只保存最終的指標信息。而在指標梳理過程中，個人感覺仍舊是使用Excel更加方便、靈活一些。
這種在線版的指標口徑管理系統(tǒng)有一個比較大的問題，就是除了一個在線Excel，起到一個指標口徑保存的作用之外，怎么進一步的去使用這些指標是個大問題。
目前想到的一種使用方式就是在建模型的時候，都使用指標口徑管理系統(tǒng)里面管理的指標，在創(chuàng)建模型的時以可視化的形式，下拉選擇已經管理好的指標，不允許手動輸入字段創(chuàng)建模型。通過這種方式來保證所有建模的數據指標名稱統(tǒng)一。但是，這種形式幾乎不可行，如果要使用這種可視化建表的形式，則需要禁掉通過SQL創(chuàng)建表的權限。讓所有的表，在創(chuàng)建、修改時，都使用可視化的形式。這種形式如果遇到幾百個字段，都下拉選擇，那么在交互形式上，在創(chuàng)建效率上，都是不可行的。而且，即使使用下拉在創(chuàng)建時選擇了已經固定的指標。但是，指標名稱統(tǒng)一，并不意味著指標口徑就統(tǒng)一了。在兩個選取了同一指標的模型中，維度設置的不同，那么雖然名字一樣，口徑仍然是不同一的?？趶浇y(tǒng)一，意味這名稱、粒度、維度等等的多種統(tǒng)一，下拉建表的形式并不能達到這個效果。這些在指標口徑管理系統(tǒng)管理下的一個一個的數據指標中也沒有辦法體現。所以，即使采用上面說的建模形式，最終起到的效果也有限。且不說上面的形式會大大的限制開發(fā)的效率和靈活性。這就是指標口徑管理系統(tǒng)的困境，似乎只能做一個指標信息保管庫。沒有特別明確的場景，來進一步使用。可能，能夠在建模時，進行字段命名時，提供一些命名的思路。如果，提供命名思路的話，指標口徑管理系統(tǒng)，還需要有一個對應縮寫清單。什么樣的中文，對應什么樣的英文，對應什么樣的縮寫。在建模的時候能夠參考這個清單，來確保建模的通用可讀性。所以，結論就是，個人認為指標口徑管理系統(tǒng)的使用場景有限。
“指標數據查詢系統(tǒng)”，一般又都叫做指標平臺。后續(xù)如果沒有特殊的區(qū)分，那么指標平臺就是指“指標數據查詢系統(tǒng)”。
當說起指標平臺的來源的時候，其實還和BI系統(tǒng)有一定的關系?？梢酝ㄟ^BI系統(tǒng)的演化路徑，來關聯出指標平臺。（不可否如BI可視化，是數據應用中的一個大頭。）
我們先看看BI系統(tǒng)的一個演化路徑，通過BI系統(tǒng)的演化路徑，來看看為什么需要一個指標平臺。
BI系統(tǒng)一共有幾代，這個也沒有一個唯一的標準，個人認為到現在是三代：第一代：傳統(tǒng)式BI、自助式BI、Headless BI。
個人認為，ChatBI或者智能BI，僅僅是一種交互形式的增強，本質上沒有什么變化。
第一代：傳統(tǒng)式BI
此時，數據指標都保存在數據倉庫中。（此時數據倉庫可以理解為在Oracle或者MySQL上面構建的一個數倉）。而傳統(tǒng)式BI只負責展示。代表產品：SAP BusinessOjects，IBM Cognos，OBIEE，MicroStrategy。依賴 IT 人員開發(fā)固定報表，靈活性差。
這種傳統(tǒng)BI，基本上和傳統(tǒng)的數倉相結合，是在大數據生態(tài)繁榮起來之前的一個BI解決方案。整個數據倉庫的加工，BI報表的制造都是有IT部門來承擔。業(yè)務人員只是使用最終加工好的報表。有新的需求也是再提給IT人員，由IT人員再進行加工調整。
第二代：自助式BI
業(yè)務人員可自助分析，但指標口徑分散在 BI 工具中。現在，自助式BI產品是一個較為主流的BI解決方案，不管是各個云廠 商還是國內的BI公司，基本都是自助式BI。傳統(tǒng)式BI主要問題是什么？是靈活性不足，所有的BI報表展示需求都 需要統(tǒng)一 提交給IT部門，由IT部門來制作。所以，自助式BI也主要是想解決傳統(tǒng)式BI的靈活性的問題。因為是自 助式BI，所以BI報 表的制造就不再歸由IT部門來承擔了。而是讓各個 業(yè)務線的業(yè)務人員能夠自助的創(chuàng)建BI。隨著自助創(chuàng)建BI能力一同下放 的還有數倉里面的一表權限，也被下放給業(yè)務人員了。此時，自助式BI里面展示的數據指標，主要是將下放給業(yè)務人員表， 加載在自助式BI系統(tǒng)中，生成數據集，在數據集的基礎上進行展示。 數據集也會進行一定程度的加工，生成新指標。代表 產品：Tableau、帆軟等。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
這里可能會有一個疑問，第三代是否可以直接在數據倉庫上構建BI，讓數據倉庫承擔統(tǒng)一數據指標的定位。理論上可行，實際上不行。一方面，就是存儲介質不同，大數據時代的數據倉庫存儲介質一般查詢較慢，而BI類產品又需要能夠較快的返回結果。
另一方面，就是有統(tǒng)一指標需求的公司，現實情況下的數據倉庫已經龐大的無從下手了，能夠從頭再來，有一個干凈的指標層是一個更好的選擇。但是，反過來說，個人認為這種情況也一定程度上，意味著數據治理或者數據管理本身已經失敗了，已經沒有辦法在數倉層面來做到數據指標的統(tǒng)一了。
指標平臺的由來，就是為了解決業(yè)務自助分析時的指標不一致問題的。是在數據倉庫和上層應用之間，增加的新的一層。即可完整的實現指標的規(guī)范化開發(fā)管理，也能解決指標口徑不一致的問題。同時，通過調整存儲介質，解決指標查詢性能問題。
第一個沖突就是，如何讓指標平臺和自助式BI平臺之間進行兼容。
因為自助式BI的成熟，現在大部分企業(yè)均采購一套BI產品，這就注定了沒辦法通過企業(yè)內部自研來解決這個兼容問題，所以，只能等采購的BI系統(tǒng)在能力升級，拋棄將表導入生成數據集這種形式，而是直接引用第三方數據集的形式了。
如果重頭自研一套BI系統(tǒng)，那么成本時間又是非常大的了。
第二個沖突就是和開發(fā)過程的沖突。
這個在之前的章節(jié)中也介紹過，一般的數據開發(fā)過程為“數據導入--數據加工--數據應用”?？梢钥吹?，這個過程中，數據消費者是直接使用最終的加工產物的，僅僅消費數據，而不會產生新的數據。
而指標平臺一般還會承諾，導入基礎指標，能夠進行復合指標的加工生產，這就承擔了一部分數據加工的能力了。
所以就有一個邊界的問題了。哪些數據在數據倉庫中進行加工？哪些 數據在指標平臺中進行加工？會不會出現同一個指標，即在數據倉庫 加工了，又在指標平臺加工一遍的問題？上面兩個沖突，就是指標平臺在落地時和現狀的實際問題，是需要解決的。
既然上面說到指標的沖突，那么，如果要讓指標平臺能夠在企業(yè)內順利落地就需要解決上面提到的兩個沖突。
第一個沖突：和現有自助式BI的沖突
解決這個沖突，可以是等待自助式BI能夠更加靈活的和指標平臺這一層進行關聯，而不使用導入內部自建數據集這種形式。只要自助式BI升級了這個能力，問題就解決了。
也可以自研一套自助式BI，不用等現有的BI廠商的升級。當然，這個成本就高許多了。
你覺得哪種方案合適？
或者，可以直接跳過BI系統(tǒng)，直接采購指標平臺，因為很多指標平臺，除了定義和開發(fā)指標外，也具有指標應用能力，支持簡單的指標可視化，以及指標拆解。這樣既可解決指標規(guī)范化管理問題，也幫助企業(yè)節(jié)約了BI的軟件采購成本。不過也依賴于指標平臺的數據應用能力是否足夠，解決大部分可視化的問題，個人對這也是存疑的。而且，沒有BI平臺的話，需要有打破歷史慣性的魄力。
第二個沖突：和數據倉庫開發(fā)的邊界問題
個人認為，這個問題就需要有一個統(tǒng)一的體系化的數據指標目錄了，能夠在目錄中快速找到需要的指標，并能夠顯示對應數據指標所在的位置。通過所有的指標，來對應出來存儲的邊界問題。
從而，讓指標平臺能夠存儲所有的關鍵指標，作為一個數據指標標準化的單一可信源。
上面兩個沖突的解決，都需要比較大的投入，所以本質上當前階段的指標平臺的落地，個人還是比較悲觀的。但是，對于chatBI如果能夠有一個更加規(guī)范的指標平臺，來作為大模型的輸入，對于提升chatBI的準確性又是有極大幫助的。所以，似乎這又是一個歷史的方向。很多時候，要做什么這件事情的決定是復雜的，可能做的時候還沒有想起楚，先做起來，邊做邊找路也可以。畢竟，先發(fā)占位也是一種思路。
在開篇的時候，就提到當提到數據指標工具的時候，會有這樣兩種劃分。
實際上現在大部分企業(yè)都想要一個指標平臺（指標數據查詢系統(tǒng)），但是第一步不是想的怎么打通和BI系統(tǒng)的對接鏈路，不是想怎么和現有的數據加工做定位區(qū)分，而是第一步想著先把有多少指標給收集起來，在系統(tǒng)里面能夠查詢到。這就一下子變成了指標口徑管理系統(tǒng)了。這些收集起來的指標沒有和其他系統(tǒng)有聯動，甚至單純的做了登記的功能，完全沒有下一步的應用了。這就是企業(yè)在做數據指標系統(tǒng)的時候，可能面臨的一個問題，本質上還是沒有分清楚兩者的定位。
不管哪種工具，是“指標口徑管理系統(tǒng)”，還是“指標數據查詢系統(tǒng)-指標平臺”，其中添加的數據指標，都是已經梳理好的指標，在添加指標的過程中，都需要一個流程化的審批流，才能夠保證數據指標的穩(wěn)定性。這兩個系統(tǒng)中，管理登記的數據指標，會在下一章中介紹的數據指標體系的梳理過程，在指標口徑管理系統(tǒng)中，指標的創(chuàng)建、指標的評審、指標的廢棄等等流程，都是線上發(fā)起。且線上能夠留痕，一直進行查詢，一直進行升級。有的時候，這一部分和數據模型的發(fā)布審核過程類似，因為模型的新增，也是需要對應的數據管家進行審核的。
上面介紹了兩個數據指標工具，也表達了對這兩個工具的態(tài)度，不管是“指標口徑管理系統(tǒng)”還是“指標數據查詢系統(tǒng)-指標平臺”，在現階段的落地情況，個人都是比較悲觀的。要不就是缺少下一步的應用場景，要不就是和現有的現狀沖突較大。但是，尷尬的一點就是，數據指標這樣重要的一個模塊，居然沒有一個特別好的工具來保證統(tǒng)一的管理。梳理過程使用簡單的excel或者腦圖來梳理，沒有特別好的工具。梳理結束之后，最終的指標結果沒有一個特別好的保存位置。這不得不說還真是多少有點尷尬了。
本章主要介紹了數據指標的相關工具，指出了數據指標工具，有兩種形式，一種是面向開發(fā)的指標口徑管理系統(tǒng)，一種是面向數據應用的指標數據管理系統(tǒng)，或者稱為指標平臺。
