文章一如既往比較長(cháng)，可以先收藏后面慢慢看。也可以直接拉到文末掃碼領(lǐng)取福利哦！

1 什么是 Modern Data Stack

1.1 背景

近兩年來(lái)，Modern Data Stack 越來(lái)越成為了一個(gè)熱門(mén)的技術(shù)話(huà)題。越來(lái)越多的企業(yè)組織在完成了信息化，在線(xiàn)化轉型后，都把數據智能化作為下一個(gè)戰略目標，出現了“數據是新的石油”的說(shuō)法。

于是一方面，大數據的浪潮席卷而來(lái)，每家公司都在致力于收集更多的數據，推動(dòng)了 Hadoop，數據湖等技術(shù)的興起。另一方面，AI 成了從海量數據中獲取業(yè)務(wù)價(jià)值的“煉金術(shù)”，幾乎每家公司都在不遺余力的投入各種 AI 項目的嘗試與探索。

但經(jīng)過(guò)幾年的實(shí)踐，現實(shí)給我們上了很好的一課，大家越來(lái)越發(fā)現光有更多的數據并不一定代表更好的業(yè)務(wù)產(chǎn)出，現有的算法也很難在混亂的數據中挖到業(yè)務(wù)洞見(jiàn)。于是 Modern Data Stack 應運而生，其主要目的就是圍繞數據與業(yè)務(wù)決策打造一個(gè)更好的基礎設施，來(lái)提升數據的產(chǎn)出價(jià)值。這背后的驅動(dòng)因素主要來(lái)自?xún)煞矫妫?/span>

• 商業(yè)方面：從軟件吞噬世界，到數據作為差異化競爭力的核心，賦能組織做更好的決策。
• 技術(shù)方面：大數據，云原生，AI 浪潮的興起，對技術(shù)棧的形態(tài)和組成部分造成了巨大的影響。

這兩個(gè)因素推動(dòng)了我們的 Data Stack 從早年的傳統數倉，再到 2010 年前后開(kāi)始出現的數據湖，再到現在的云原生數據平臺的演化過(guò)程。

1.2 演化邏輯

傳統數據棧的典型架構就是“數據源 -> ETL 工具 -> 數據倉庫 -> BI 軟件”這幾個(gè)步驟。這里面最大的瓶頸來(lái)自于數據倉庫，從一開(kāi)始并沒(méi)有區分 OLTP 和 OLAP，到后來(lái)逐漸有了 MPP 架構，都是為了去提升數據分析消費場(chǎng)景下的數倉服務(wù)性能與可擴展性?？傮w來(lái)說(shuō)當時(shí)數倉都是價(jià)格昂貴的商業(yè)系統，使用門(mén)檻較高。為了更好地實(shí)現數據分析消費，我們不得不在數倉的輸入和輸出兩端做各種優(yōu)化，例如通過(guò)復雜的 ETL，將數據預先做篩選清洗，并聚合到較高的維度，避免出現超大的數據量。在 BI 軟件層面，也做了很多查詢(xún)優(yōu)化，緩存，二次計算，Cube 等方面的技術(shù)創(chuàng )新，使得系統整體能服務(wù)更多的用戶(hù)的復雜查詢(xún)和并發(fā)操作。

在 2010 年左右大數據技術(shù)開(kāi)始興起，但當時(shí)的 SQL-on-Hadoop 技術(shù)主要還是應用在 ETL 這種批處理操作中，并沒(méi)有對實(shí)時(shí)交互分析產(chǎn)生多大的影響。當時(shí)還出現了知名的 Lambda 架構等，其中也仍然需要數據倉庫層對外提供分析服務(wù)。

2016 年開(kāi)始逐漸火熱的云原生浪潮帶來(lái)了不少新的思路，其中一個(gè)很重要的想法就是做“拆分”，出現了存儲和計算兩個(gè)模塊分離的云數倉，使得其擴展能力得到了極大的提升，并且成本方面也能控制的比較好。傳統 ETL 對于數據應用造成的一個(gè)最大困難就在于我需要提前設計好分析消費時(shí)需要的表結構，一旦后續出現變更，需要消耗巨大的時(shí)間和成本來(lái)重新執行 ETL，甚至可能原先的數據都不存在了。有了幾乎可以“無(wú)限擴展”的云數倉，我們可以把 ETL 也拆分了，其中 EL 兩步主要做數據的“復制”，把所有可用信息都導入到云數倉中，后續再根據需求靈活的執行 T 就可以。

這個(gè)“拆分”還在不斷自我增強，計算和存儲拆開(kāi)了，EL 和 T 拆開(kāi)了，那么調度自然也需要單獨一個(gè)模塊來(lái)跨組件統籌，元數據分散在各個(gè)系統也不行，于是數據管控，可觀(guān)測性也都拆了出來(lái)。這跟微服務(wù)興起后，服務(wù)發(fā)現，消息系統，可觀(guān)測性等都有了自然的需求是類(lèi)似的，我們也可以把 DevOps 中的很多概念對應到 DataOps 上。于是現在，現代數據棧的全景圖就變成了下面這個(gè)模樣：

也難怪要叫現代數據“?！绷?。

1.3 特性

相比于數倉和數據湖平臺，Modern Data Stack 以云數據庫為中心，引發(fā)了一系列的產(chǎn)品技術(shù)的變化，進(jìn)而影響到了企業(yè)組織，業(yè)務(wù)流程的改進(jìn)優(yōu)化，形成了新一代平臺的特點(diǎn)與優(yōu)勢，包括：

• 充分擁抱云原生，極大地降低運維方面開(kāi)銷(xiāo)，更低的啟動(dòng)成本，且可以彈性擴展，按量付費。當然這一點(diǎn)也會(huì )帶來(lái)新的挑戰，例如如何管理和優(yōu)化云服務(wù)的開(kāi)銷(xiāo)。
• 從 IT 為中心轉向以業(yè)務(wù)為中心，更加強調基礎設施要為快速的業(yè)務(wù)變化提供敏捷，靈活，自助化的解決方案。這也是傳統平臺的一大痛點(diǎn)，典型的例子如 ETL 到 ELT 的轉變，analytics engineer 的出現等。
• 隨著(zhù)數據量，用戶(hù)數的增長(cháng)，應用場(chǎng)景的數量也會(huì )迎來(lái)爆發(fā)。因此數據管控會(huì )成為重要的“一等公民”。如果只是一味追求自助化，那么更多的數據意味著(zhù)更多的混亂，更少的信任。
• 傳統數倉的應用以數據分析為主，相對單一。為了實(shí)現數據價(jià)值，必須要賦能決策，深入到各個(gè)業(yè)務(wù)流程中去，支持分析與決策的完整工作流。這方面也出現了反向 ETL 等技術(shù)產(chǎn)品。
• 模塊化，易于集成的產(chǎn)品組合，而不再是之前的 all-in-one 解決方案。例如存算分離的趨勢，各種接口的標準化，避免 vendor lock-in。

后面我們會(huì )針對這些特性做進(jìn)一步的展開(kāi)分析。

1.4 典型架構

在之前的 聊聊云原生數據平臺^[1] 一文中，我們已經(jīng)詳細介紹過(guò) Modern Data Stack 的典型架構，其中主要包括以下幾個(gè)部分：

• 數據獲取
• 數據存儲
• 數據處理
• 數據分析消費
• 數據管控
• 流程編排

今天我們的主題會(huì )圍繞著(zhù)數據分析與消費這個(gè)方向來(lái)展開(kāi)。

2 Modern Data Stack 中的數據分析

數據分析與消費是整個(gè) Data Stack 中面向用戶(hù)量最廣的一個(gè)環(huán)節，也是讓數據最終產(chǎn)生業(yè)務(wù)價(jià)值的“門(mén)戶(hù)”，影響了整體技術(shù)棧的演進(jìn)。延續前面提到的 Modern Data Stack 特性，我們來(lái)看下針對分析領(lǐng)域出現的趨勢。

2.1 流程對比

對于用戶(hù)來(lái)說(shuō)，最顯著(zhù)的變化來(lái)自于數據分析的流程從 IT 為中心轉向了以業(yè)務(wù)為中心。例如傳統數據分析產(chǎn)品的典型流程如下：

1. 決策人員提出了一個(gè)業(yè)務(wù)問(wèn)題。
2. 分析師需要提 request 給數據/IT 部門(mén)，獲取相關(guān)數據。
3. 經(jīng)過(guò)幾周漫長(cháng)的等待，數據終于準備好了，可能以 Excel 或數據庫表或 cube 的形式提供給分析師。
4. 分析師使用 BI 工具進(jìn)行數據準備，建模等工作，涉及大數據量時(shí)可能會(huì )碰到工具的性能問(wèn)題。而且如果發(fā)現數據有問(wèn)題，還需要反復與 IT 部門(mén)進(jìn)行溝通，重新獲取。
5. 完成處理后，制作報表，看板進(jìn)行業(yè)務(wù)問(wèn)題的分析。
6. 得出結論后，導出數據和可視化內容，放到報告文檔（word，ppt）里，構建相關(guān)的敘述內容。
7. 展示給決策者，過(guò)程中決策者提了幾個(gè)新問(wèn)題，但現有的數據沒(méi)法進(jìn)行回答。
8. 回到第一步，再針對新的問(wèn)題走一遍流程。

從這個(gè)過(guò)程中，可以看出很多問(wèn)題：

• 由于技術(shù)的局限，數據架構的性能和易用性無(wú)法達到要求，各類(lèi)數據操作中涉及到復雜的定制化代碼撰寫(xiě)，MapReduce 任務(wù)開(kāi)發(fā)，復雜度高且運行效率較低。這一點(diǎn)引發(fā)了后續問(wèn)題。
• 在組織與流程上，傳統的數據棧更多是以 IT 為中心，面向技術(shù)人員為主。對于業(yè)務(wù)最了解的需求提出方，無(wú)法深度參與數據的獲取，處理流程，會(huì )導致很多來(lái)回溝通與返工的額外開(kāi)銷(xiāo)。
• 從分析產(chǎn)品角度來(lái)說(shuō)，因為底層技術(shù)的不成熟，需要做很多額外的工作，例如查詢(xún)優(yōu)化，二次計算，本地緩存，OLAP cube 建模等等，反而忽視了產(chǎn)品核心的分析能力和用戶(hù)體驗。
• 在應用落地方面，分析與決策相對割裂，一般都是導出分析結果后再通過(guò)其它方式進(jìn)行呈現，討論，最終進(jìn)行決策，這個(gè)流程中又引入了決策人員與分析師的認知 gap，也會(huì )有很多額外開(kāi)銷(xiāo)與返工。

這幾個(gè)因素疊加，讓傳統的數據消費變得非常低效，容易出錯，相關(guān)項目的 ROI 較低甚至很容易回退到拋開(kāi)數據憑經(jīng)驗決策的舊方法上去。

理想中的現代數據分析流程如下：

1. 決策人員有了一個(gè)業(yè)務(wù)問(wèn)題，首先在數據分析工具中搜索相應的關(guān)鍵詞。
2. 選擇與之相關(guān)的，經(jīng)過(guò)數據 owner 認證的數據集。
3. 對數據進(jìn)行自助式的交互分析。也可以通過(guò)一些增強分析能力，由系統自動(dòng)診斷生成數據中的洞察。
4. 創(chuàng )建可視化儀表板，形成圖文并茂的數據故事。還可以選擇將分析結果一鍵推送到移動(dòng)端，或其它業(yè)務(wù)系統中。
5. 與決策者會(huì )面討論，過(guò)程中有新的問(wèn)題也可以快速通過(guò)分析工具進(jìn)行回答。
6. 迅速形成決策，在業(yè)務(wù)系統中生成相關(guān)動(dòng)作，也可以為特定場(chǎng)景配置特定的監控和自動(dòng)化決策流程，減少后續的人工介入。
7. 所有流程都可以在一個(gè)整體的產(chǎn)品中完成，減少任務(wù)切換。業(yè)務(wù)人員解決完一個(gè)問(wèn)題后，可以立刻開(kāi)始探索下一個(gè)問(wèn)題。

怎么樣，是不是感覺(jué)好了很多！

2.2 挑戰和趨勢

為了實(shí)現這個(gè)理想的分析流程，也就給 Modern Data Stack 中的數據分析部分提出了很多挑戰。很多現代 BI 軟件的發(fā)展趨勢都順應了這些挑戰：

• 為了與整個(gè) Modern Data Stack 協(xié)同，實(shí)現較低的運維成本和強大的彈性擴展能力，現代 BI 產(chǎn)品也必須適配云原生的基礎架構要求。而傳統的私有化部署將很難融入 cloud infra 中，遇到存儲，計算方面的需求時(shí)必須單獨進(jìn)行規劃和維護，效率，性能和穩定性都存疑。
• 以業(yè)務(wù)為中心，對于產(chǎn)品力也提出了更高的要求。現代 BI 產(chǎn)品需要滿(mǎn)足多種數據消費者角色的需求，包括業(yè)務(wù)人員，數據分析師，數據工程師，數據科學(xué)家等。不同角色對于產(chǎn)品能力上會(huì )有不同的要求，且整個(gè)流程的串聯(lián)與協(xié)作也需要非常細致深入的考量，并以先進(jìn)的架構設計進(jìn)行配套服務(wù)。
• 業(yè)務(wù)的自助分析獲得初步成功后，很快隨之而來(lái)的就是面對大量的分析場(chǎng)景和業(yè)務(wù)應用，我們如何進(jìn)行有效的管理，編排，監控，運維和持續優(yōu)化。這對于傳統的高門(mén)檻的分析軟件來(lái)說(shuō)是全新的挑戰。很多一開(kāi)始推崇完全自助分析的產(chǎn)品也都在大規模應用后，遇到了這方面的問(wèn)題。
• 隨著(zhù)數據分析成熟度的提升，數據消費的覆蓋范圍也會(huì )開(kāi)始拓展，從單一的分析，到之后的決策，業(yè)務(wù)流程打通，形成決策閉環(huán)。這對于分析軟件來(lái)說(shuō)一方面提升了對決策相關(guān)能力的需求，如預測，仿真，優(yōu)化等；另一方面也對于其 composable 能力有了更多的要求，能夠與各類(lèi)業(yè)務(wù)系統融合打通。

接下來(lái)我們會(huì )主要從這四個(gè)方面來(lái)詳細闡述現代 BI 產(chǎn)品的演進(jìn)趨勢。

3 云原生架構

傳統的企業(yè)級軟件棧都是以硬件采購，私有化部署模式為主的。這種方式在啟動(dòng)成本，產(chǎn)品項目的快速交付與迭代，持續的運維開(kāi)銷(xiāo)，可擴展性等方面都具有比較大的問(wèn)題。

以數據分析中的 ETL 數據準備為例，一般在業(yè)務(wù)系統更新數據后，每天會(huì )在固定的時(shí)間段觸發(fā)大量的 ETL 計算操作，將業(yè)務(wù)數據載入到分析系統中。這個(gè)時(shí)候就對計算資源提出了非常高的要求，需要采購大量的服務(wù)器資源才能夠滿(mǎn)足。一旦完成了 ETL 操作，整個(gè)系統的負荷又會(huì )很快下降到一個(gè)較低的水平，大量的服務(wù)器資源又處于一個(gè)閑置的狀態(tài)，造成浪費。而現代云服務(wù)就能比較好的解決這類(lèi)彈性計算資源的需求問(wèn)題，降低成本。

隨著(zhù)云原生技術(shù)的興起和成熟，越來(lái)越多的企業(yè)都開(kāi)始擁抱“上云”，帶來(lái)了諸多好處：

• 各種存儲，計算資源都可以做到按量付費，靈活擴縮容。
• 各種專(zhuān)業(yè)技術(shù)能力如身份認證，數據安全，負載均衡，動(dòng)態(tài)擴展，計算優(yōu)化等都可以通過(guò)調用成熟的云服務(wù)來(lái)實(shí)現普惠。
• 在服務(wù)接口標準化的情況下，靈活的替換云服務(wù)產(chǎn)品，獲得極致的用戶(hù)體驗也會(huì )變得越來(lái)越便捷可行。

隨著(zhù)這個(gè)大的發(fā)展趨勢，數據分析軟件也必須符合云原生的架構標準，才能充分享受到這些“技術(shù)紅利”。具體如：

• 數據分析軟件本身應該按照云原生的標準來(lái)進(jìn)行設計，研發(fā)與部署運行。如微服務(wù)，容器化，DevOps 和持續交付等。
• 組件化架構，除了核心模塊外，各種擴展功能支持“即插即用”，通過(guò) serverless 的方式按需啟動(dòng)。后續也能在此基礎上形成豐富的數據應用市場(chǎng)。
• 支持對接各類(lèi)主流的云服務(wù)，從底層的公有云基礎設施，到核心的云數倉，再到各類(lèi) SaaS 云服務(wù)，而不是各種功能都只能使用自身實(shí)現。
• “云無(wú)關(guān)”特性，不與某個(gè)具體的云服務(wù)深度綁定，適應各類(lèi)企業(yè)的不同需求，同時(shí)也能利用不同云中最適應業(yè)務(wù)需求的服務(wù)。例如使用 Azure 來(lái)做企業(yè)級身份管理，而利用谷歌云做機器學(xué)習相關(guān)能力的拓展。

當然云服務(wù)時(shí)代也給企業(yè)帶來(lái)了新的挑戰，尤其是在新應用的部署越來(lái)越方便的今天，如何更好的去管理和優(yōu)化云計算的費用開(kāi)銷(xiāo)，成了一個(gè)新的課題。以往碰到一些效率低下的 SQL 查詢(xún)，或者沒(méi)有被用戶(hù)使用的 workflow，頂多占用一些已有的硬件資源而已。但在云服務(wù)時(shí)代，一條有問(wèn)題的 Snowflake 查詢(xún)，就可能要花掉公司幾百塊錢(qián)。如果這個(gè)查詢(xún)被反復執行，而其產(chǎn)出結果卻沒(méi)人來(lái)消費，那就真的是“燒錢(qián)”了。而且云服務(wù)本身的可選項也越來(lái)越豐富，同一件事情可能有好幾種不同的云服務(wù)和計費方式可以選擇，進(jìn)一步提升了問(wèn)題難度。

另一方面，如何滿(mǎn)足企業(yè)級應用中多租戶(hù)，資源隔離以及計算優(yōu)先級等問(wèn)題，即使在云計算時(shí)代也仍然是一個(gè)需要面對的重要課題。

我們觀(guān)遠數據在這塊處在國內比較領(lǐng)先的狀態(tài)，從 16 年第一行代碼開(kāi)始就跑在了 K8s 環(huán)境上，很多基礎能力都同時(shí)考慮了私有化部署和公有云服務(wù)對接的兼容性。這幾年更是與很多超頭部企業(yè)一起共建，積累了很多大型公有云，私有云基礎設施深度集成協(xié)作的經(jīng)驗，能夠在上萬(wàn) CPU 的集群上執行復雜的計算調度，服務(wù)整個(gè)企業(yè)多個(gè)事業(yè)部 3 萬(wàn)名以上的活躍數據分析師、決策者用戶(hù)。

在管理云計算開(kāi)銷(xiāo)方面，我們也做了不少創(chuàng )新的實(shí)踐，推出了“云巡檢”功能，與后面提到的數據管控與觀(guān)測能力一起，在保證高質(zhì)量的數據分析應用交付的同時(shí)，還能不斷控制降低不必要的計算開(kāi)銷(xiāo)，可謂是云時(shí)代的必備核心功能了。

4 自助分析：從服務(wù)到產(chǎn)品

前面有提到，以往的分析軟件以服務(wù) IT 部門(mén)為主，業(yè)務(wù)方發(fā)起需求，由 IT 部門(mén)來(lái)進(jìn)行滿(mǎn)足。所以分析系統以一種被動(dòng)提供服務(wù)，響應需求的形式存在，周期長(cháng)，效率低?，F代分析軟件的一個(gè)重要趨勢就是將被動(dòng)服務(wù)轉變?yōu)橹鲃?dòng)打造“數據產(chǎn)品”，做更系統和長(cháng)遠的規劃，協(xié)同業(yè)務(wù)部門(mén)一起來(lái)推動(dòng)數據賦能決策。

4.1 數據產(chǎn)品

實(shí)現自助分析的一個(gè)核心觀(guān)念轉變是打造數據產(chǎn)品，而非被動(dòng)響應服務(wù)。那么什么是數據產(chǎn)品呢？

簡(jiǎn)單來(lái)說(shuō)，就是通過(guò)提供數據，來(lái)滿(mǎn)足各類(lèi)企業(yè)決策和流程應用的產(chǎn)品。我們在日常生活中其實(shí)也在很多情況下不經(jīng)意間在使用數據產(chǎn)品，例如出門(mén)逛街時(shí)找吃飯的地方，我們就會(huì )打開(kāi)大眾點(diǎn)評應用，上面列出了各種飯店的類(lèi)型，多個(gè)維度的評分，評價(jià)人數，具體的評論信息等數據，我們通過(guò)分析這一系列的數據，最終做出選擇（想象一下如果這個(gè)過(guò)程需要通過(guò) dashboard 來(lái)完成）。這個(gè)過(guò)程與企業(yè)內部的業(yè)務(wù)決策者流程很相似，所以說(shuō)數據產(chǎn)品并不只是復雜的 dashboard 的形態(tài)，而需要根據不同的用戶(hù)角色來(lái)進(jìn)行特定的交互設計。例如對于很多業(yè)務(wù)人員來(lái)說(shuō)，移動(dòng)端的數據智能應用就更加方便易用，而不是碰到任何的業(yè)務(wù)問(wèn)題都需要打開(kāi)電腦來(lái)做復雜的看板分析。

數據產(chǎn)品的構建需要引入產(chǎn)品設計思維：

• 我們需要去深入了解用戶(hù)需求，設計 user story，撰寫(xiě)設計文檔等。
• 系統性規劃產(chǎn)品的長(cháng)期 roadmap，關(guān)注產(chǎn)品的功能，性能，可擴展性，ROI 等屬性，并持續與用戶(hù)同步。
• 需要了解各類(lèi)領(lǐng)域知識，例如前面提到的不同垂直領(lǐng)域的決策者，可能對產(chǎn)品形態(tài)的要求就會(huì )很不一樣。
• 需要有相應的 SLA（如典型的數據質(zhì)量指標），提供幫助文檔，各類(lèi)技術(shù)支持等配套。
• 需要做持續的用戶(hù)推廣，并設定相應的客戶(hù)成功指標，例如通過(guò)數據產(chǎn)品來(lái)提升決策速度和質(zhì)量。
• 可以借鑒產(chǎn)品迭代開(kāi)發(fā)的模式，這一點(diǎn)后面我們會(huì )再展開(kāi)。

需要注意的是數據產(chǎn)品的核心還是在分析型應用，輔助決策和業(yè)務(wù)流程，而不是自研各種 data infra。相反，為了實(shí)現數據產(chǎn)品化，投資于自助式的數據類(lèi)軟件會(huì )是非常有幫助的。他們相當于提供了一個(gè)底層的“數據操作系統”，提供標準的數據收集，存儲，消費能力，幫助企業(yè)的數據團隊能更好的在這之上去構建數據應用產(chǎn)品。

4.2 數據消費者倒三角

產(chǎn)品思維中很重要的一點(diǎn)是明確目標客戶(hù)，我們來(lái)看下數據產(chǎn)品需要服務(wù)的目標用戶(hù)有哪些。一般來(lái)說(shuō)，企業(yè)的數據分析決策相關(guān)人員會(huì )分成下圖中的幾類(lèi)角色：

1. 業(yè)務(wù)決策者：通過(guò)數據來(lái)做業(yè)務(wù)情況監控與決策的用戶(hù)，一般會(huì )專(zhuān)注于某個(gè)垂直場(chǎng)景，如供應鏈，市場(chǎng)，銷(xiāo)售，財務(wù)，人力資源等。他們一般會(huì )使用的數據產(chǎn)品的功能包括指標查看，監控與告警推送，移動(dòng)端或業(yè)務(wù)軟件中的嵌入式分析等。這類(lèi)用戶(hù)也會(huì )非常受益于新一代的增強分析能力，例如自然語(yǔ)言的數據問(wèn)答，數據洞察的自動(dòng)推薦等。
2. 業(yè)務(wù)分析師：在業(yè)務(wù)問(wèn)題驅動(dòng)之下進(jìn)行深入分析的用戶(hù)，尤其在一些復雜場(chǎng)景，跨部門(mén)的交叉分析領(lǐng)域，為決策者提供數據洞見(jiàn)。他們一般會(huì )進(jìn)行高級交互式分析，what-if 場(chǎng)景分析，協(xié)助進(jìn)行業(yè)務(wù)數據準備，構建數據故事等。
3. 分析工程師：從這一層開(kāi)始往下，主要就是數據產(chǎn)品的開(kāi)發(fā)者群體了。分析工程師是結合業(yè)務(wù)理解與 IT 能力的開(kāi)發(fā)者，為分析師和決策者構建相應的數據，可視化，分析應用基礎。他們主要負責數據建模，ELT 開(kāi)發(fā)，分析應用設計開(kāi)發(fā)，數據質(zhì)量，數據管控，以及相關(guān)的流程編排等方面工作，也可以利用一些 autoML 的能力進(jìn)行一些算法建模開(kāi)發(fā)。
4. 數據科學(xué)家：深入業(yè)務(wù)流程的特定 AI 解決方案開(kāi)發(fā)者，將企業(yè)整體的分析成熟度進(jìn)一步提升，實(shí)現決策建議甚至自動(dòng)化決策流程。他們主要進(jìn)行各類(lèi)探索性數據科學(xué)實(shí)驗，AI 解決方案設計和流程開(kāi)發(fā)，主要依靠 notebook，IDE 等代碼開(kāi)發(fā)環(huán)境的支持。

當然這幾個(gè)典型分類(lèi)在不同規模的公司也會(huì )有不同的體現，相對小型的公司可能會(huì )主要分為數據開(kāi)發(fā)者和消費者兩類(lèi)，而大型公司可能在這個(gè)基礎上進(jìn)一步細分出數據工程師，BI 工程師，數據運維，數據產(chǎn)品經(jīng)理，數據大使等角色來(lái)。

另外這里只考慮了數據方面的相關(guān)角色，沒(méi)有把軟件開(kāi)發(fā)，基礎架構，云服務(wù)運維等方面的角色放進(jìn)來(lái)。如果考慮商業(yè)化問(wèn)題，那么我們還需要關(guān)注企業(yè)管理者角色的思考與決策方式，可能會(huì )對具體的采購行為有較大的影響力。

這幾類(lèi)角色的用戶(hù)數量會(huì )呈現一個(gè)倒三角的分布，例如典型的例子可能是決策者 10000 人，分析師 1000 人，看板開(kāi)發(fā) 300 人，AI 建模 30 人這樣的比例。

為了服務(wù)多種多樣的用戶(hù)群體，就對現代數據分析軟件提出了更高的要求。傳統的 BI 軟件基本上都只能提供可視化，看板的組合，但我們知道對于市場(chǎng)部門(mén)來(lái)說(shuō)，體驗最好的肯定是 Google Analytics 這類(lèi)的分析形式；對于門(mén)店店長(cháng)來(lái)說(shuō)，通過(guò)移動(dòng)端數據應用來(lái)獲取信息與實(shí)時(shí)分析或許效率更高；而對于數據科學(xué)家，則必須提供靈活的 notebook 支持。因此現代的自助分析軟件就需要提升在數據消費方面的能力，例如支持定制化的可視化，低代碼的數據應用開(kāi)發(fā)，各種連接器來(lái)實(shí)現“反向 ETL”，或提供高級探索實(shí)驗所需要的 notebook，SQL IDE 支持等。

除了業(yè)務(wù)用戶(hù)，數據產(chǎn)品的“開(kāi)發(fā)者”用戶(hù)群體也同樣重要，我們在下面一節來(lái)展開(kāi)描述。

4.3 Analytics as Software

在產(chǎn)品思維之外，數據產(chǎn)品從技術(shù)角度也給了我們很多不一樣的思考角度。作為軟件工程師，我們應該對敏捷開(kāi)發(fā)，持續集成，DevOps 這些工程實(shí)踐都非常熟悉了。而報表、儀表盤(pán)這類(lèi)數據產(chǎn)品的開(kāi)發(fā)，目前大都還處在一種非?！霸肌钡臓顟B(tài)：

• 瀑布式的開(kāi)發(fā)模式，在交付給最終用戶(hù)時(shí)才發(fā)現需求并沒(méi)有得到很好的滿(mǎn)足，重新做需求變更與返工帶來(lái)大量的資源浪費。
• 缺乏工程化的管理，在項目復雜度上升之后經(jīng)常因為業(yè)務(wù)邏輯，數據質(zhì)量問(wèn)題消耗大量的排查修復時(shí)間。
• 以單一的數據可視化分析為主，用戶(hù)只能在產(chǎn)品中完成部分需求，沒(méi)有嵌入到業(yè)務(wù)流程中形成決策閉環(huán)。

因此新一代的分析軟件都開(kāi)始借鑒很多軟件工程的思想，提出了“Analytics as Software”的新主張。

4.3.1 軟件工程的啟發(fā)

典型的例子如 dbt，Looker 等產(chǎn)品中，都支持通過(guò)代碼（DSL）來(lái)構建數據處理邏輯和數據模型。使用代碼來(lái)定義看起來(lái)像是提高了使用門(mén)檻，跟自助式分析的初衷相違背，但我認為實(shí)際上并不矛盾。面向數據產(chǎn)品的“開(kāi)發(fā)者”用戶(hù)，以及對分析應用的底層構建來(lái)說(shuō)，需要有足夠的復雜邏輯表達能力和簡(jiǎn)潔性，代碼是一種非常理想的表達形式。

以代碼為核心邏輯的載體，我們就可以利用上很多軟件工程的最佳實(shí)踐，例如版本控制，Code Review，代碼包復用，自動(dòng)化測試，持續集成發(fā)布，易于自動(dòng)化集成等。在企業(yè)級應用中對數據的需求和重視程度的不斷提升，數據產(chǎn)品項目中涉及到的各種數據源，獲取方式，指標定義，數據處理邏輯等各類(lèi)信息的復雜度已經(jīng)完全不亞于常規的軟件系統了。不借助這些優(yōu)秀的工程實(shí)踐，僅僅靠項目規范把控會(huì )很容易積累起數據產(chǎn)品的技術(shù)債，效率低下且難以持續。例如 dbt 就是一個(gè)非常優(yōu)秀的以代碼為核心的數據轉換框架，這兩年非?；鸨?，風(fēng)頭超過(guò)了很多主打無(wú)代碼的拖拽式 ETL 工具：

除了以代碼為核心，我們還可以將產(chǎn)品的核心能力通過(guò) public API 進(jìn)行開(kāi)放，方便各類(lèi)分析需求與業(yè)務(wù)流程的深度集成串聯(lián)，并進(jìn)行持續的監控和運維，不斷優(yōu)化數據產(chǎn)品的性能，效率和用戶(hù)體驗。前面舉了大眾點(diǎn)評的例子，可以想象一下如市場(chǎng)投放，風(fēng)控，客戶(hù)營(yíng)銷(xiāo)，供應鏈優(yōu)化等方面，都會(huì )有類(lèi)似的業(yè)務(wù)流程結合數據分析的需求。通過(guò)開(kāi)放 API 的 composable 能力，我們就可以讓分析產(chǎn)品的形態(tài)更加多樣化，更好的滿(mǎn)足用戶(hù)從分析到?jīng)Q策動(dòng)作的全流程。這對于構建 data-driven 的企業(yè)文化來(lái)說(shuō)也是至關(guān)重要的一點(diǎn)。

以代碼為核心，分離了“定義”與“運行”，API 開(kāi)放了底層能力，兩者相結合，我們就可以構建一個(gè)更加開(kāi)放的數據應用生態(tài)平臺，讓更多的分析工程師，社區愛(ài)好者來(lái)貢獻各類(lèi)數據插件與應用，基于統一的數據平臺，打破企業(yè)的數據孤島，覆蓋更多的業(yè)務(wù)領(lǐng)域。想象一下如果 Facebook，Uber 這些軟件如果誕生在現在，可能就會(huì )成為數據平臺上的一個(gè)應用，甚至兩者之間的信息也能做到互通。這種數據應用市場(chǎng)的未來(lái)想象空間是非常巨大的，極有可能顛覆很多現有的企業(yè)級業(yè)務(wù)軟件系統，我們也已經(jīng)觀(guān)察到不少相關(guān)的案例出現。

4.3.2 低代碼

如果只是以代碼為核心，那么自助式分析的門(mén)檻就會(huì )變得更高。即使面對開(kāi)發(fā)者用戶(hù)，我們也需要注意將業(yè)務(wù)邏輯跟執行細節能夠很好的區分開(kāi)來(lái)，例如應該把底層技術(shù)細節進(jìn)行隱藏，無(wú)論用的是 OLAP 數據庫還是時(shí)序數據庫，無(wú)論是批處理還是流式處理，用戶(hù)都只需要關(guān)心業(yè)務(wù)的核心邏輯即可，所以數據產(chǎn)品中比較流行的代碼基本都是 DSL 形式，降低學(xué)習門(mén)檻。

而面向業(yè)務(wù)用戶(hù)，需要進(jìn)一步隱藏細節，低代碼仍然是一個(gè)重要的產(chǎn)品形態(tài)。在 DSL 的基礎上，構建業(yè)務(wù)用戶(hù)容易理解和使用的低代碼產(chǎn)品，也是非常自然的一步。接下來(lái)主要討論下兩者之間的關(guān)系。

我們日常使用的代碼，大都是經(jīng)過(guò)精心設計的通用語(yǔ)言或領(lǐng)域特定語(yǔ)言（如 SQL），可以類(lèi)比成我們日常使用的漢語(yǔ)，具有非常高的靈活性和擴展性，可以表達任何內容。但缺點(diǎn)是有一定的門(mén)檻，就好比大家都認識字，但是寫(xiě)作文的溝通表達能力就可能天差地別。

而低代碼的產(chǎn)品則是在代碼的基礎上做了一層封裝，從技術(shù)角度來(lái)說(shuō)就是只能調用一些相對固定的 API，通過(guò)不同參數，API 的組合來(lái)表達業(yè)務(wù)邏輯。類(lèi)比到日常生活中，可能比較像手勢，或者 emoji 這類(lèi)符號，對自然語(yǔ)言也是做了一定的封裝，好處在于門(mén)檻極低，大家都很容易使用和理解如 ?? 這樣的 emoji。但擴展性和靈活性就會(huì )比較低了，我們很難把一堆 emoji 組成一篇復雜的文章。

值得注意的是，并不是說(shuō)漢語(yǔ)掌握的很好的人就完全不需要 emoji 了，能夠流暢做代碼開(kāi)發(fā)的專(zhuān)業(yè)人員，也完全可以利用低代碼工具來(lái)輔助提升其開(kāi)發(fā)效率，主要是看應用場(chǎng)景是否是高度需要定制化的。例如我們在做數據模型開(kāi)發(fā)時(shí)，如果每次微小的修改都需要人工 pull 代碼，checkout 分支，做修改，commit，提 PR，跑測試，review 完成后合并發(fā)布，顯然是很不友好的。所以可以看到像語(yǔ)雀文檔這樣的產(chǎn)品里，就隱含集成了一些版本控制的能力，以無(wú)代碼的方式提升了文檔的開(kāi)發(fā)和運維效率。

從前面的用戶(hù)分層來(lái)看，業(yè)務(wù)決策者和業(yè)務(wù)分析師在面對很多相對固定的場(chǎng)景時(shí)，完全可以使用低代碼的方式來(lái)實(shí)現其相關(guān)需求，甚至不需要了解很多底層運作的細節，其易用性和用戶(hù)體驗會(huì )明顯更優(yōu)。即使是分析工程師和數據科學(xué)家，也可以利用低代碼的工具來(lái)輔助提升效率。但在一些定制化程度很高的場(chǎng)景，例如業(yè)務(wù)場(chǎng)景中的 AI 模型開(kāi)發(fā)，很可能需要做很多的特殊處理，這時(shí)候如果強行套用低代碼工具，可能反而給自己的工作增加了束縛。這也是為何之前很多拖拽式建模開(kāi)發(fā)工具沒(méi)有得到大規模應用的原因之一。

最后，代碼和低代碼工具應該做到緊密結合，這樣才能讓不同角色的用戶(hù)能夠緊密協(xié)作，且在產(chǎn)品體驗上能夠體現一致性與流暢度。因為代碼的表達能力更強，所以個(gè)人認為核心邏輯的存儲應該以代碼為準，這樣也能同時(shí)享有前面提到的軟件工程實(shí)踐所帶來(lái)的各種優(yōu)越性和便利。通過(guò)低代碼的方式開(kāi)發(fā)的 ETL，流程編排，可視化，機器學(xué)習等邏輯，應該都能直接轉化為代碼來(lái)進(jìn)行存儲，這樣就能同時(shí)享受到兩種方式所帶來(lái)的優(yōu)勢。這方面的一個(gè)優(yōu)秀的例子是 Looker，業(yè)務(wù)用戶(hù)可以用低代碼的方式來(lái)創(chuàng )建可視化：

而這些可視化的背后都自動(dòng)生成了相應的代碼，用戶(hù)完全可以用管理代碼項目的方式來(lái)管理整個(gè)項目，如創(chuàng )建分支，測試，提交 PR，合并發(fā)布等。

4.4 增強分析

沿著(zhù)數據產(chǎn)品的思考邏輯，最后我們再來(lái)看下如何提升分析產(chǎn)品的易用性和用戶(hù)體驗。這對于擴大產(chǎn)品的用戶(hù)滲透率來(lái)說(shuō)是非常關(guān)鍵的一點(diǎn)。近年來(lái)一個(gè)非常重要的趨勢就是通過(guò) AI 的能力，來(lái)輔助用戶(hù)使用數據分析產(chǎn)品，降低門(mén)檻并提升效率。

其中一些典型的場(chǎng)景包括：

• 數據準備增強，包括 schema 的自動(dòng)發(fā)現，基于數據字典、血緣、profiling 元數據等信息，向用戶(hù)提供處理建議，提升數據問(wèn)題排查效率。例如我們可以在 ETL 工具中實(shí)現自動(dòng)的數據 join 操作，或者對引入的數據集做自動(dòng)化的數據質(zhì)量檢查診斷，提供處置建議。
• 數據分析增強，包括數據解釋?zhuān)诮y計模型的洞察，自動(dòng)特征工程，自動(dòng)算法模型構建等能力，提供場(chǎng)景化的數據見(jiàn)解和決策建議。例如通過(guò)算法來(lái)自動(dòng)查找數據中的隱含 pattern 或異常點(diǎn)，生成相關(guān)報告推送給用戶(hù)，省去繁瑣的交互式分析流程。
• 產(chǎn)品交互增強，通過(guò)自然語(yǔ)言查詢(xún)，自然語(yǔ)言結果生成，嵌入式 BI 等能力，提供更簡(jiǎn)單易用的交互方式。同時(shí)支持用戶(hù)反饋，提供個(gè)性化的結果推薦。這個(gè)就很好理解了，就像我們使用淘寶那樣，通過(guò)搜索和推薦的方式來(lái)找到我們感興趣或者可能有用的數據洞察。

以業(yè)務(wù)決策用戶(hù)為例，要做到數據分析與最終的決策結合，比較自然的步驟是先了解發(fā)生了什么，再了解為什么會(huì )發(fā)生這個(gè)變化，最終再給出如何提升的建議。傳統的做法一般是通過(guò)監控發(fā)現問(wèn)題，然后再由業(yè)務(wù)分析師進(jìn)行深入的交互式分析，通過(guò)查看海量的看板，執行不同的篩選條件，下鉆上卷，最終形成一些結論與決策者討論。

增強分析的一個(gè)核心目標就是為了提升這個(gè)流程的效率。當發(fā)現公司的銷(xiāo)售額出現了預期外的波動(dòng)時(shí)，可以自動(dòng)進(jìn)行關(guān)鍵因子的分析，找出引起變化的業(yè)務(wù)根源，例如是因為某個(gè)客群的銷(xiāo)售額下降了，再進(jìn)一步實(shí)現客群轉化率，續約率，增購的自動(dòng)建模分析，從幾個(gè)方向上給出操作建議。這三個(gè)步驟可以直接形成一個(gè)圖文并茂的“數據故事”推送給客戶(hù)，快速形成感知，理解和決策。

4.5 現代自助分析產(chǎn)品

這一節的內容比較多，我們圍繞數據產(chǎn)品這個(gè)中心點(diǎn)，闡述了多個(gè)現代自助分析產(chǎn)品所需要具備的核心能力，包括：

• 對于多種用戶(hù)角色需求的滿(mǎn)足，良好的協(xié)作能力，極致的用戶(hù)體驗。
• 代碼和低代碼兩種開(kāi)發(fā)模式的支持，無(wú)縫切換，提升數據產(chǎn)品的開(kāi)發(fā)，運維效率。
• 開(kāi)放 API 的支持，composable 能力，支持分析與業(yè)務(wù)流程集成。
• 開(kāi)放架構，應用市場(chǎng)生態(tài)的支持，滿(mǎn)足各種垂直化場(chǎng)景需求。
• AI 能力加持，實(shí)現增強分析能力，邁向智能化、更易用的數據分析產(chǎn)品。

國外已經(jīng)有很多產(chǎn)品在這些方面走在了前面，例如這幾年非?；鸬?Looker，Mode，GoodData 等 BI 產(chǎn)品，以及在增強分析領(lǐng)域的先驅 ThoughtSpot，Pyramid 等，有很多值得我們借鑒之處。

我們觀(guān)遠數據在這幾個(gè)方面也有了不少的探索實(shí)踐：

• 我們的 SmartETL 和 Universe 產(chǎn)品，就實(shí)現了代碼和低代碼開(kāi)發(fā)模式的支持，嵌入了如版本控制，自動(dòng)化測試，代碼插件打包，集成發(fā)布的能力，對于各階段的企業(yè)，各類(lèi)角色用戶(hù)的需求都能有比較好的滿(mǎn)足。
• 觀(guān)遠也提供了完善的 public API 支持，還內置了非常多的行業(yè)數據連接器，在很多決策智能項目中實(shí)現了分析，預測與業(yè)務(wù)流程的無(wú)縫整合，實(shí)現決策閉環(huán)。
• 觀(guān)遠的數據應用市場(chǎng)從 2019 年開(kāi)始設計開(kāi)發(fā)，也逐漸形成了一系列的行業(yè)垂直數據應用，未來(lái)還會(huì )不斷迭代優(yōu)化，致力于打造國內最好的分析師開(kāi)發(fā)生態(tài)。
• 今年我們也將正式推出經(jīng)過(guò)了多次內部迭代的增強分析產(chǎn)品，目前在金融風(fēng)控，電商銷(xiāo)售分析，客戶(hù)復購分析等場(chǎng)景上實(shí)現了 10 倍以上的效率提升及明顯的業(yè)務(wù)決策效果回報，未來(lái)有望形成更多的場(chǎng)景化智能應用。

5 受管控的自助分析

隨著(zhù)自助式數據產(chǎn)品形態(tài)的成熟，接下來(lái)一個(gè)比較明顯的挑戰是應用場(chǎng)景數量的爆炸，大量的用戶(hù)和大量的數據內容兩者自由組合，就會(huì )出現很多管控上的挑戰。一方面自助分析的確給我們帶來(lái)了靈活，敏捷，可以快速滿(mǎn)足業(yè)務(wù)需求，但如果缺乏系統性的管控又會(huì )很快陷入低效和混亂的泥潭之中。

在很多企業(yè)級分析項目中我們都會(huì )看到，相關(guān)的參與者需要耗費 50-80% 的時(shí)間來(lái)處理各種數據問(wèn)題，檢查數據源，核對計算口徑，處理各類(lèi)數據質(zhì)量問(wèn)題。

項目上線(xiàn)運行后，也需要持續保證數據的可靠性，一旦出現沒(méi)有及時(shí)更新，數據質(zhì)量出錯或者服務(wù)不可用等問(wèn)題，都會(huì )影響到公司的日常運作。這也是我們之前提到的數據產(chǎn)品需要有相應的 SLA 的要求，而且數據的不可用（不僅僅是服務(wù)不中斷，而數據質(zhì)量也要得到保證）相比軟件系統來(lái)說(shuō)會(huì )更加的難以發(fā)現和處理。這里一個(gè)典型的指標是“data downtime”，等于出問(wèn)題的次數 * （發(fā)現數據問(wèn)題的耗時(shí) + 解決數據問(wèn)題的耗時(shí)）。

如果 data downtime 的指標居高不下，那么很容易進(jìn)入數據混亂，缺乏信任，用戶(hù)各自構建更多的缺乏保障的數據的惡性循環(huán)，最終大家會(huì )逐漸拋棄現有系統，回到之前通過(guò) Excel 取數和分析的時(shí)代。這一節我們就來(lái)討論下如何應對這個(gè)挑戰，實(shí)現受管控的自助分析。

5.1 應用場(chǎng)景的擴展性

當前的很多自助分析產(chǎn)品，大都處于“野蠻生長(cháng)”的狀態(tài)。用戶(hù)可以自由的接入數據，做處理，構建指標，創(chuàng )建可視化分析等，但對于什么是可信的數據源，如何確保指標的一致性和復用，如何持續確?？窗鍞祿恼_性，如何找到跟業(yè)務(wù)最相關(guān)的分析內容等問(wèn)題缺乏考慮。很多企業(yè)在這方面的實(shí)踐還處于建設“數據門(mén)戶(hù)”的階段，可以想象一下如果沒(méi)有搜索引擎，回到 internet 早年的“門(mén)戶(hù)時(shí)代”，我們獲取和利用信息的效率肯定是大打折扣的。

在數據處理和計算方面，我們已經(jīng)有了 SQL 標準，但在元數據領(lǐng)域缺乏統一標準，這也是數據管控需要解決的核心問(wèn)題。很多時(shí)候我們可以獲取數據，也可以獲取到 schema 信息，但這份數據是什么時(shí)候更新的，有多少用戶(hù)在使用這份數據，是否通過(guò)了相關(guān)的數據質(zhì)量檢查，企業(yè)統一的指標認證等問(wèn)題，我們都不得而知。數據的上游和下游只管讀取和寫(xiě)入數據，但卻彼此不知道具體的生產(chǎn)和使用情況，想想就是一個(gè)很不可靠的狀態(tài)。

為了解決這個(gè)問(wèn)題，越來(lái)越多的 Modern Data Stack 中，都把數據管控，元數據管理作為一等公民來(lái)看待，出現了非常多的新興產(chǎn)品專(zhuān)門(mén)針對這個(gè)問(wèn)題，如 Data Observability 領(lǐng)域的 Monte Carlo，BigEye，Data Catalog 領(lǐng)域的 Atlan，DataHub 等。接下來(lái)我們對這個(gè)領(lǐng)域做一些簡(jiǎn)單的探索。

5.2 元數據類(lèi)型

由于本身還沒(méi)形成行業(yè)一致的標準，所以在元數據這塊的功能分類(lèi)也是非常模糊，有非常多的名詞，如 catalog，governance，observability，discovery 或者干脆就叫 metadata 等。為了簡(jiǎn)單起見(jiàn)，這里我們就分為兩類(lèi)：

• Data catalog：以數據靜態(tài)屬性的管理為主，如數據定義，權限控制等。
• Data observability：以數據的動(dòng)態(tài)內容管理為主，用于數據質(zhì)量的監控與可用性的保證。

下面來(lái)看下具體的元數據類(lèi)型，具體的分類(lèi)方法有很多，我們這里參考的是 DevOps 中對軟件系統 observability 的分解，分別是 metric，trace 和 log。我們的產(chǎn)品中應該支持用戶(hù)或者系統自動(dòng)的生成，記錄和更新這些版本化的信息，并提供統一的對外服務(wù)標準接口，且這些能力需要與整個(gè) Data Stack 中的各類(lèi)組件進(jìn)行很好的結合，具備數據產(chǎn)品的可編程、可組合能力。

5.2.1 Metric

包含了各種數據的屬性信息，很多也屬于“數據質(zhì)量”的范疇，如：

• Schema
• 數據量
• 數據新鮮度
• 數據分布，統計信息
• 數據的完整性
• 數據的準確性
• 數據的合理性
• 是否有重復數據
• 是否有敏感信息

5.2.2 Lineage

顧名思義，血緣關(guān)系主要指的是數據之間的依賴(lài)信息，包括數據表，字段，算法模型以及分析應用等。

5.2.3 Log

數據與生產(chǎn)消費者間的交互關(guān)系，包括：

• 內部數據交互，如數據生成，更新，數據轉換的時(shí)間點(diǎn)，所耗費的時(shí)間等。
• 外部數據交互，用戶(hù)訪(fǎng)問(wèn)，分析查詢(xún)，AI 建模等訪(fǎng)問(wèn)信息。

5.2.4 業(yè)務(wù)元數據

涉及業(yè)務(wù)的各類(lèi)信息，如擁有者，所屬組織，訪(fǎng)問(wèn)權限，業(yè)務(wù)定義與說(shuō)明等。

5.3 元數據應用

關(guān)于元數據系統的設計可以參考我們之前云原生數據平臺一文中的內容。有了這些元數據的系統性記錄和相應的查詢(xún)服務(wù)，我們可以用于各種應用。而且在元數據積累的量達到一定規模后，我們還有機會(huì )利用元數據做各類(lèi)更加智能化的產(chǎn)品功能，如自動(dòng)數據異常探測，修復建議，更智能的數據發(fā)現等。

5.3.1 數據管控

對數據的訪(fǎng)問(wèn)權限，數據安全，合規，一致性與可信度等方面提供支持。

有了合理的管控，我們能夠形成更加清晰、一致的數據架構，減少不必要的復雜依賴(lài)。當上游數據發(fā)生變更時(shí)，也能及時(shí)通知下游，避免出現數據誤用或其它的質(zhì)量問(wèn)題。當然最重要的是，通過(guò)數據管控來(lái)實(shí)現安全與合規方面的要求。尤其在合規方面，大數據架構設計之初并沒(méi)有很好地考慮用戶(hù)可能有刪除個(gè)人數據的訴求，這方面對于數據湖倉及后續數據轉換方面的工作都提出了很大的挑戰。

5.3.2 數據發(fā)現

在數據產(chǎn)品開(kāi)發(fā)過(guò)程中，能讓用戶(hù)更加完整，深入的了解數據相關(guān)信息，來(lái)判斷應該使用什么數據集。典型的信息包括：

• 哪些數據集已經(jīng)很久沒(méi)有被使用了，而哪些數據集有很多消費者。
• 數據最近更新的時(shí)間點(diǎn)是什么，是否符合業(yè)務(wù)預期。
• 數據集中各個(gè)字段的業(yè)務(wù)含義是什么。
• 數據的上下游依賴(lài)如何，從哪來(lái)到哪去。
• 數據質(zhì)量以及過(guò)去的可用情況如何。
• 數據是否滿(mǎn)足相關(guān)的業(yè)務(wù)假設與消費需求。
• 與之類(lèi)似的數據集有哪些。
• 數據版本隨時(shí)間推移發(fā)生的變化有哪些。

在數據發(fā)現服務(wù)過(guò)程中，如何設計高效且智能的搜索系統，綜合相關(guān)性，熱門(mén)程度對結果進(jìn)行排序展示等都是非常重要的話(huà)題。

5.3.3 數據可觀(guān)測性

最后，在數據被使用起來(lái)之后，我們需要持續關(guān)注數據的可觀(guān)測性。相比于軟件系統，數據內容非常容易出現“靜默失敗”的情況，雖然報表還能展示，模型也能正常輸出預測，但其實(shí)里面所使用的數據可能已經(jīng)有了很多問(wèn)題。如果你也是一名數據從業(yè)者，肯定碰到過(guò)類(lèi)似的情況：突然有一天用戶(hù)說(shuō)數據好像看起來(lái)不對，然后經(jīng)過(guò)了幾個(gè)小時(shí)甚至幾天的排查，終于找到了問(wèn)題所在，然后還發(fā)現有個(gè)處理邏輯已經(jīng)持續錯了幾周甚至幾個(gè)月了。

可觀(guān)測性主要就是為了解決此類(lèi)“data downtime”的問(wèn)題，主要包括幾個(gè)步驟：

• 檢測數據問(wèn)題，當數據出現問(wèn)題時(shí)，能第一時(shí)間在最上游感知到問(wèn)題，影響范圍就越小，越容易修復，而不是等著(zhù)幾千份報告發(fā)出去之后由用戶(hù)來(lái)報告數據是錯的。
• 解決數據問(wèn)題，當某個(gè)環(huán)節發(fā)現了數據問(wèn)題時(shí)，能夠在復雜的數據鏈路中快速定位到問(wèn)題原因，并進(jìn)行修復。這也是我們常說(shuō)的“對數”問(wèn)題，如果缺少產(chǎn)品的輔助，經(jīng)常要耗費大量的時(shí)間精力。
• 預防后續的數據問(wèn)題，在解決問(wèn)題之后，還需要能很方便的加上相關(guān)的自動(dòng)檢查，告警或自動(dòng)修復機制，避免問(wèn)題再次出現時(shí)需要反復投入時(shí)間來(lái)進(jìn)行類(lèi)似的排查工作。

以算法自動(dòng)決策類(lèi)項目為例，構建相關(guān)的數據完整性，質(zhì)量檢查，數據分布漂移檢查，對于項目的持續運維來(lái)說(shuō)是至關(guān)重要的。如果發(fā)現了上游數據出現了巨大的數據分布變化，我們就應該及時(shí)停止下游預測輸出流程的執行，并告警通知用戶(hù)，避免產(chǎn)出錯誤的決策建議，影響業(yè)務(wù)正常運作。另外也需要持續進(jìn)行決策效果的追蹤和半自動(dòng)化的誤差分析，不斷完善整個(gè)數據流程中重要部分的可觀(guān)測性。

5.3.4 綜合應用

傳統架構中，元數據經(jīng)常分散在各個(gè)組件中，例如數據庫，ETL 工具，BI 等。有了統一管理的元數據中心，就可以提供給 Data Stack 中的各種組件進(jìn)行綜合性應用：

• 對于流程編排組件，可以通過(guò)獲取數據使用情況，來(lái)設定編排運行的優(yōu)先級，讓重要的數據優(yōu)先得到計算生成，提高整體效率。
• 數據產(chǎn)品的自動(dòng)化測試，持續集成與發(fā)布也可以與各類(lèi)元數據信息結合，幫助我們更好的判斷變更帶來(lái)的影響和潛在風(fēng)險。
• 在前面增強分析部分有提到，我們可以根據用戶(hù)的使用習慣，推薦其它相關(guān)的數據集或者分析報表內容，這部分的用戶(hù)行為信息獲取，就需要通過(guò)元數據方面的獲取與分析來(lái)完成。
• 支持不同角色用戶(hù)的協(xié)作，例如在數據處理系統中做的各類(lèi)數據集，指標等信息，也能被數據分析與決策的產(chǎn)品組件獲取到；或者通過(guò)與工作 IM 系統的集成發(fā)送各類(lèi)通知，實(shí)現信息互通。

5.4 自助分析與決策中的元數據

把元數據的話(huà)題延展到自助分析與決策方面，除了數據集，對于分析資產(chǎn)的元數據管理也非常重要，市面上也有類(lèi)似的產(chǎn)品支持：

• Metric store 產(chǎn)品，如 dbt，Transform，LookML 等都希望能構建一個(gè)標準的“語(yǔ)義層”，讓消費者都能獲取到統一定義的可信數據，而不是將邏輯散落在各個(gè)報表，可視化內部。
• Model store，feature store，evaluation store 等算法相關(guān)的元數據管理產(chǎn)品，之前在聊 MLOps 的文章^[2] 里有所提及。不得不說(shuō)大家起名的想象力真的是非常豐富 :)
• Analytics catalog 產(chǎn)品，提供分析資產(chǎn)的元數據管理與各類(lèi)應用，代表廠(chǎng)商如 Metric Insights。
  

觀(guān)遠在服務(wù)了多家月活分析師數量上千的企業(yè)后，也遇到了很多分析資產(chǎn)管控，數據可靠性，安全等方面的挑戰，并開(kāi)發(fā)了若干產(chǎn)品進(jìn)行應對：

• 針對數據質(zhì)量，可觀(guān)測性，我們在產(chǎn)品中內置了數據血緣，數據質(zhì)量檢查等功能模塊，可以支持數據 schema，新鮮度，數據量，分布情況，異常值的自動(dòng)探測，以及自定義的業(yè)務(wù)檢查規則的撰寫(xiě)，并支持相關(guān)報告的自動(dòng)生成與推送。在進(jìn)行數據架構重構或數據問(wèn)題排查時(shí)，也可以充分利用血緣功能提高效率。
• 為了在企業(yè)中推廣數據驅動(dòng)文化，同時(shí)也盡可能優(yōu)化云計算資源的開(kāi)銷(xiāo)，我們開(kāi)發(fā)了云巡檢產(chǎn)品，對數據用戶(hù)活躍度，分析資產(chǎn)的使用率，計算開(kāi)銷(xiāo)等元數據進(jìn)行了細致的監控記錄，并在實(shí)際客戶(hù)場(chǎng)景中發(fā)揮了很好的作用。
• 針對數據安全要求較高的行業(yè)，我們還推出了敏感信息探測，自動(dòng)脫敏等相關(guān)能力。結合強大的企業(yè)級權限體系，同時(shí)支持 RBAC 與 ABAC，提升企業(yè)的整體數據安全水平，滿(mǎn)足各類(lèi)合規要求。
• 我們也開(kāi)始著(zhù)力打造指標平臺產(chǎn)品，與算法行業(yè)特征庫一起，提升大型項目中指標管理的標準化程度和運作效率，探索未來(lái)企業(yè)級受管控的自助分析的最佳實(shí)踐。

6 邁向決策智能

觀(guān)遠對于自身使命的定義是“讓業(yè)務(wù)用起來(lái)，讓決策更智能”。前半句對應的是前面提到的數據產(chǎn)品以業(yè)務(wù)為核心，提供自助化服務(wù)，不斷提升用戶(hù)體驗。而后半句對應的就是通過(guò)產(chǎn)品來(lái)不斷提升不同角色的分析能力，邁向決策智能。

6.1 什么是決策智能

在完成了基礎架構，產(chǎn)品體驗，自助式分析的有效管控幾方面的基礎夯實(shí)之后，企業(yè)的數據分析成熟度自然就會(huì )開(kāi)始逐漸上升，從現狀分析，到原因診斷，再到未來(lái)預測，最終到達輔助決策智能的處方建議。尤其是后面兩點(diǎn)，需要深度結合 AI 能力來(lái)進(jìn)行賦能，實(shí)現數據驅動(dòng)的高質(zhì)量決策。

從另一個(gè)角度看，邁向決策智能也不僅僅是分析能力的提升，還有一個(gè)重要的考量是要解決“最后一公里”問(wèn)題，實(shí)現由數據驅動(dòng)的業(yè)務(wù)流程。這個(gè)方向上也有很多相關(guān)的產(chǎn)品能力設計，如實(shí)時(shí)數據分析，開(kāi)放 API，嵌入式分析（js，iframe），以及近兩年很火的“反向 ETL”。

這幾類(lèi)決策智能的典型場(chǎng)景包括：

• 當決策的頻率較低，且決策的影響較大，或決策動(dòng)作空間比較靈活時(shí)，可以通過(guò)增強分析的方式，將數據診斷結果或決策建議提供給用戶(hù)，再由人工來(lái)決定最終決策動(dòng)作。例如周度經(jīng)營(yíng)分析會(huì )場(chǎng)景，可以通過(guò)增強分析給出業(yè)務(wù)問(wèn)題診斷和提升建議，幫助業(yè)務(wù)做出更高質(zhì)量的決策。
• 當決策的行為在下游系統發(fā)生，有比較固定的業(yè)務(wù)規則時(shí)，可以實(shí)現數據驅動(dòng)的流程自動(dòng)化，完成業(yè)務(wù)閉環(huán)。例如通過(guò)反向 ETL，將客戶(hù)相關(guān)的統計信息傳輸到 CRM 系統中，觸發(fā)相應的客戶(hù)關(guān)系維持動(dòng)作。
• 決策的頻率高，數量大，且每個(gè)具體決策造成的影響較小時(shí)，可以利用數據與決策模型流程閉環(huán)來(lái)實(shí)現自動(dòng)化決策，比較典型的場(chǎng)景如導航軟件中的路徑規劃與行程時(shí)間預估，電商購物場(chǎng)景中的推薦系統等。

從上面的場(chǎng)景舉例可以看到，很多決策的最終形成都是在“業(yè)務(wù)系統”中的，那么是否意味著(zhù)在業(yè)務(wù)系統中去構建數據分析能力也就足夠了呢？這也是我們經(jīng)?？吹胶芏嗫蛻?hù)會(huì )直接使用例如 ERP，CRM 系統或者“生意參謀”這類(lèi)產(chǎn)品中的數據分析模塊，而沒(méi)有另外構建所謂的“數據產(chǎn)品”。這種做法在企業(yè)發(fā)展的某些階段或許是適用的，但從長(cháng)期來(lái)說(shuō)，單一系統內能夠獲取到的信息是相對有限的，在進(jìn)行電商營(yíng)銷(xiāo)類(lèi)決策時(shí)，我們也需要引入生產(chǎn)，物流，倉儲，供應商管理，財務(wù)，人力資源等等方面的信息輔助，否則就容易在數據孤島狀態(tài)下做出一些“局部最優(yōu)”的決策。利用數據平臺加上決策應用產(chǎn)品的設計思路，能夠減少很多重復建設的工作，并且保證決策信息輸入的完整和一致性。

6.2 決策智能產(chǎn)品能力

為了實(shí)現決策智能，現代數據產(chǎn)品也需要配備相應的關(guān)鍵功能點(diǎn)：

• Notebook 開(kāi)發(fā)集成，對于機器學(xué)習預測能力的落地，往往需要深入業(yè)務(wù)流程做模型邏輯的特定實(shí)驗與開(kāi)發(fā)。因此 notebook 開(kāi)發(fā)能力的集成是非常重要的，支撐數據科學(xué)家完成相關(guān)的工作。例如 Mode 中就有很好的 SQL editor 和 notebook 支持。
• AutoML 能力，對于特征預處理，特征選擇，模型選擇，參數調優(yōu)方面的任務(wù)，大都已經(jīng)可以用 AutoML 的能力來(lái)滿(mǎn)足，而不需要再花費數據科學(xué)家的額外時(shí)間，也可以賦能分析工程師來(lái)做一些自助建模。具體可以參考之前 關(guān)于 AutoML 的介紹文章^[3]。
• 模型解釋能力，單純的模型預測輸出很難與人工的判斷進(jìn)行結合，尤其是增強分析的輔助決策場(chǎng)景中，我們需要提供一定的模型解釋能力，讓業(yè)務(wù)理解模型給出預測建議背后的原因，便于進(jìn)一步的分析與判斷。
• 運籌優(yōu)化引擎，利用運籌或強化學(xué)習技術(shù)來(lái)滿(mǎn)足業(yè)務(wù)決策中的仿真和優(yōu)化訴求。典型場(chǎng)景如工廠(chǎng)排產(chǎn)，倉網(wǎng)規劃，運輸計劃生成等。這方面 IBM 的 CPLEX 是一款比較知名的工具，也很好的集成在了他們的產(chǎn)品體系中。
• 因果建模與推理，目前的算法模型絕大多數都是以統計學(xué)為核心的，無(wú)法真正實(shí)現認知決策中所需要的知識表達，邏輯推理方面的能力。當然這方面的發(fā)展還處在比較早期，業(yè)界相關(guān)的探索與應用還比較有限。
• 用戶(hù)交互與反饋，在人機協(xié)同場(chǎng)景中，數據產(chǎn)品需要收集各類(lèi)人工判斷反饋，并作為輸入數據的一種，實(shí)現算法的不斷迭代優(yōu)化。
• MLOps(AI Engineering) 能力，在決策智能逐漸普及的情況下，數據產(chǎn)品中需要越來(lái)越多處理跟特征服務(wù)，模型服務(wù)，模型指標監控，自動(dòng)重訓練，以及模型元數據管理等方面的問(wèn)題。這也是一塊非常新興和活躍的產(chǎn)品市場(chǎng)，有很多相關(guān)的創(chuàng )業(yè)公司都瞄準了這個(gè)方向。
• 實(shí)時(shí)數據分析，業(yè)務(wù)決策的環(huán)境是快速多變的，因此我們需要支持實(shí)時(shí)的數據流和分析預測能力，才能更好的服務(wù)對時(shí)效性要求很高的場(chǎng)景。比如我們在看一些電競比賽時(shí)，教練在做 Ban/Pick 時(shí)就需要非常實(shí)時(shí)的陣容信息更新，并以此推算不同英雄的選擇勝率等。
• 開(kāi)放 API，這一點(diǎn)也在前面有提到，為了實(shí)現決策落地，數據的最終消費形式需要非常靈活，可以通過(guò) API 的方式讓各類(lèi)垂直應用來(lái)獲取相關(guān)信息。在這個(gè)領(lǐng)域也出現了很多新興的低代碼 App 構建廠(chǎng)商，如 retool，Appsmith 等。
• 反向 ETL，讓分析工程師開(kāi)發(fā)和維護數據到業(yè)務(wù)系統的對接還是件比較麻煩的事情，需要考慮同步進(jìn)度，失敗重試，checkpoint，rate limit，以及 API 變更等問(wèn)題。因此出現了一批類(lèi)似于反向 ingestion 的產(chǎn)品，提供更加流暢，低門(mén)檻，低運維成本的用戶(hù)體驗，比較知名的如 Census，Hightouch 等。

在決策智能方向，觀(guān)遠從成立之初就一直倡導 BI + AI 結合的產(chǎn)品形態(tài)，提供了豐富的產(chǎn)品功能支持，也在很多 500 強頭部企業(yè)實(shí)現了項目落地。例如：

• 觀(guān)遠在 Universe 平臺中提供了非常強大的 notebook 集成，SQL 開(kāi)發(fā)能力，可以無(wú)縫與 BI 用戶(hù)協(xié)作，共享相關(guān)的模型產(chǎn)出與業(yè)務(wù)指標追蹤分析。
• 觀(guān)遠的 AutoML 模塊與模型解釋能力可以同時(shí)為模型開(kāi)發(fā)，增強分析等場(chǎng)景進(jìn)行服務(wù)，讓業(yè)務(wù)分析師也能快速構建預測模型，并理解模型預測背后的參考因素，應用在金融風(fēng)控，用戶(hù)營(yíng)銷(xiāo)，需求計劃，門(mén)店選址等熱門(mén)場(chǎng)景中。
• 為了完成決策的最后一公里閉環(huán)，觀(guān)遠的主要產(chǎn)品線(xiàn)都提供了豐富的開(kāi)放 API 能力，通過(guò) Atlas 應用市場(chǎng)可以實(shí)現多個(gè)流程的串聯(lián)打通，配合垂直場(chǎng)景的應用，解決了很多現有業(yè)務(wù)系統、流程中的效率痛點(diǎn)，比如面向供應鏈場(chǎng)景的計劃助手系列產(chǎn)品。

7 總結

前面我們從產(chǎn)品技術(shù)趨勢和企業(yè)分析成熟度兩條線(xiàn)穿插介紹了關(guān)于 Modern Data Stack 中的自助分析與決策產(chǎn)品的一些思考，如果把演進(jìn)時(shí)間線(xiàn)加上，大概是如下的形態(tài)：

不同的企業(yè)在不同的階段可以根據這個(gè)思路來(lái)設計自己的產(chǎn)品技術(shù)棧和相應的數據產(chǎn)品用戶(hù)群體和應用范圍?！禩he Self-Service Data Roadmap》一書(shū)中還給出了很具有實(shí)操性的計分卡和相關(guān)提升手段，來(lái)幫助評估企業(yè)當前的數據自助服務(wù)能力水平，并設計相應的 roadmap。

從實(shí)現數據賦能決策的最終目標出發(fā)來(lái)看，好的產(chǎn)品技術(shù)肯定是其中的重要一環(huán)。如果你對于如何做代表未來(lái)的企業(yè)級 BI 產(chǎn)品選型有興趣，歡迎領(lǐng)取下載由我們觀(guān)遠出品的 企業(yè)級 BI 平臺白皮書(shū)^[4]。據說(shuō)企業(yè)級移動(dòng) BI 白皮書(shū)也已經(jīng)在路上了，值得期待一下。

有了好的產(chǎn)品，如何做系統架構的遷移，如何設計企業(yè)的數據應用流程，如何做數據產(chǎn)品的用戶(hù)推廣，打造配套的組織和文化，也都是需要考慮的重要問(wèn)題。以后有機會(huì )也可以請觀(guān)遠的解決方案與客戶(hù)成功團隊就這些話(huà)題做一些經(jīng)驗分享。

參考資料