Google Cloud X Kyligence｜如何從業務視角管理資料湖？

近日，Google Cloud、Kyligence 和 WebEye 共同舉辦了「智慧資料助力企業數字化轉型」的線上研討會，Kyligence 技術合夥人兼副總裁李棟在會上分享了主題為「Kyligence Cloud 簡化資料湖多維分析」的演講。

以下為李棟演講實錄

大家好，我是李棟，Kyligence 是 Google Cloud ISV Partner，今年我們最新的雲原生多維資料庫產品 Kyligence Cloud 也支援了 Google Cloud，今天我將會給大家介紹企業如何通過智慧多維資料庫，從業務視角管理資料湖。

1. 資料湖分析典型痛點

越來越多企業都開始在雲上搭建資料湖，支撐企業內部的資料分析和資料決策，但在資料湖和真正的資料應用之間往往存在很多痛點。如今，多數企業面臨的不再是資料量過少，而是資料量太多，這導致業務使用者在查詢和使用資料時，難以精準定位到想要的資料。

從資料入到資料湖，再到被業務使用者使用，不僅時效性較差，而且整個過程依賴資料工程師去進行 ETL，資料開發流程比較繁重。所有 ETL 都需要消耗大量計算資源和儲存資源，會大大提升資料平臺的成本；而隨著資料的增大，TCO 也會逐漸增長。這些可能是每一位在使用資料湖相關技術的使用者都會遇到的問題。

這裡舉 Kyligence 服務的一線網際網路電商企業作為例子，這家企業在 2019 年開始搭建自己的數字分析平臺，正式進入數字化轉型的階段。其所有資料要通過資料庫，落到資料湖，下游是各種資料產品、報表以及 BI、AI 的應用等，使用者從資料湖中分析資料，使用一段時間就會發現資料湖逐漸進入“渾水期”。

企業所有資料載入到資料湖上，起初可能只有 5700 多張貼源層 ODS 表。但是隨著業務使用越來越多，每一個數據分析需求或每一個數據產品背後都需要從源表進行一系列的加工和處理，就變成超過 100 萬張的寬表或聚合表。雖然現階段資料分析和資料應用的業務可以正常開展，但是企業在資料湖的資料管理方面會逐漸地進入混亂的階段。

舉個例子，這裡的 order 表就是訂單表，它被業務引用的次數很多，我們可以看到它的整個後繼節點。在資料血緣上來看，一個 order 表的後繼節點至少有超過 1 萬多張表。同樣的一份原始資料，可能被加工成了一萬多張寬表，應用在不同的業務和資料分析場景中，後續就會帶來很多問題。

假如這裡 ETL 的計算邏輯、指標加工的邏輯、資料時效性等這些生命週期的管理不一致，很容易造成同樣一份資料出來的指標結果是不一樣的。那麼對於這家企業而言，他們就會面臨“寬表爆炸”的情況。其實現在很多企業都面臨類似的挑戰，這大大影響了資料分析的 ROI ，短期來看資料分析的目標也許達到了，但是背後的投入和成本其實是過高的。

1.1 資料口徑不一致

一個 order 表就衍生出上萬張寬表，寬表間是缺少信任的。使用者在使用時，很難說哪張表的資料是最可信的。對於這家電商而言，不同區域或者部門計算出來的 revenue 指標累加在一起，很可能和直接從貼源資料里加工算出來的 total revenue 是不一樣的，這種情況可能在很多企業並不少見。

1.2 渾濁的資料湖

對於整個資料湖而言，資料儲存方面上會變得愈加渾濁。每個業務部門或者 BU 都會有一些屬於自己的資料集。對於一個訂單資料而言，財務部、運營部門、市場部門都會基於這個資料去來打造自己的資料集。其實，這背後的很多資料指標往往是共享或者是邏輯一致的，但是這些資料本身卻很難被複用。而這些問題的積累就會導致寬表爆炸愈加激烈，這些 ETL 和寬表的快速增長會帶來大量儲存和計算資源的冗餘。

1.3 IT 成本過高

如果企業的使用者數增長了 100 倍，那 IT 的成本難道也需要增長 100 倍嗎？其實這樣增長是難以控制的，不同業務的複雜程度是不一樣的。如果因為某些業務很複雜，就把整個 IT 成本提高，而其他業務並不需要，就會產生成本浪費。

2. Kyligence 智慧多維資料庫產品

Gartner 2022 年報告指出，當前資料湖上的很多企業，在引入資料倉庫等技術去支撐資料分析時，也希望通過資料倉庫的理論改善資料管理方面的痛點。通過 Kyligence 智慧多維資料庫，企業可以把資料集市或者是 OLAP 理論引入到資料湖，解決資料管理類的問題。

2.1 產品架構

下圖是 Kyligence 產品的架構，從整個技術架構上來看，只要資料已經接入到 Google Cloud ，比如說雲端儲存、Google SQL 、Google BigQuery 等，企業就可以從該平臺接入資料並建立資料模型來搭建資料集市。

Kyligence 智慧多維資料庫中最核心的概念就是多維資料模型，從資料來源中接入資料，創建出多維資料模型，然後通過標準的 SQL 或 MDX 介面，將多維資料模型在BI 工具或 Excel 等資料分析的工具中進行消費。

Kyligence 以 Apache Kylin 為核心，融合了 ClickHouse 等技術，來支撐資料分析中高效能和高併發的場景。同時，Kyligence 的 AI 增強引擎，可以根據查詢模式的變化，自動優化資料模型，一方面節約成本，另一方面優化效能。Kyligence Cloud 支援無縫相容 Google Cloud，只要資料在 Google Cloud 上就可以直接使用，從而加速資料洞察和分析的過程。

因為多維資料模型的存在，每個模型內部會統一儲存所有資料的指標，統一資料指標口徑的管理，自動化和簡化資料開發的過程。同時，Kyligence 的 OLAP 引擎可以針對大資料量進行優化，企業能以更低的 TCO 來支撐更大的資料量。

2.2 核心概念

在關係型資料庫中，資料往往是兩維的，表要麼是行，要麼是列。但是實際的業務往往是多維的，比如業務分析，大家會從不同維度和屬性檢視指標及資料洞察。如果想要從業務視角來管理和分析資料湖，多維資料庫會是更好的方式。因為在多維資料庫裡核心概念是多維資料模型，而不是表。

傳統關係型資料庫中的原始表可能只有 DBA 或者懂技術的同事才能理解，但多維資料模型用的是業務語言，暴露的直接是維度和指標，業務人員能夠更好地理解資料和使用資料。

同時，多維資料庫把所有的業務語義和指標進行統一的管理，而不是分散地儲存在各個寬表裡面。從介面上，其實只要定義好一個模型，通過 SQL 或者 MDX 把指標給暴露出去，就可以直接在 BI 工具當中使用。

接下來，通過一個例子來看多維資料庫如何解決上述問題。

對於電商企業而言，不同的部門有不同的分析需求。比如，美國和國內的銷售團隊，會去做資料加工，生成一張寬表，再進行聚合。以此類推，由於不同的團隊資料分析需求不同，都會進行類似操作。慢慢平臺裡就會出現八張表，至少有四張大寬表，四張聚合表。但通過多維資料模型，就可以把這些表的資料模型定義在多維資料庫中，把所有的資料進行整合。

從儲存和計算資源上看，這裡其實是從八張表變成三張表的過程，需要生成四次大寬表的超大規模資料集下計算的 ETL 任務，現在只需要一次。所以整個的儲存和計算資源的消耗都會大大的降低，這也是如何通過多維資料模型解決寬表爆炸。

在多維資料庫上，企業可以去定義業務分析使用的指標，並形成指標體系，如基礎指標、衍生指標等。如果不同的指標背後對應的資料模型是同一個，那麼指標的加工和計算過程是可以複用的。如果同一份資料按不同口徑、服務不同業務，則通過衍生指標靈活響應業務需求，既能滿足業務多變的需求，又能避免資料冗餘導致的寬表爆炸。

在多維資料庫中，企業可以統一管理所有業務指標的口徑來實現 Single Source of Truth；其次，多維資料模型可以把所有寬表收納在一起，減少冗餘的儲存；除此之外，預計算索引還可以優化查詢效能，進一步降低單條 SQL 查詢的使用成本。

對於客戶而言，通過 Kyligence 多維資料庫把最初 5700 多張 ODS 表，逐漸變成 2000 多個基礎指標和一萬多個衍生指標，以管理指標的方式來去管理這些資料，更好地提升資料服務的 ROI，降低冗餘儲存。業務人員可以更容易地使用所有指標，實現自助式資料分析；同時，整個架構又是雲原生的彈性架構，在 Google Cloud 上可以實現動態的伸縮。

3. Kyligence 指標中臺產品實踐

Kyligence 基於指標中臺實踐經驗和雲原生 OLAP 基礎能力，上線了智慧指標驅動的管理和決策平臺 Kyligence Zen，李棟從以下四個方面介紹了指標中臺的能力：

• 指標目錄：統一管理所有業務指標口徑從資料湖的表開始定義指標，包括基礎指標和衍生指標，並將所有指標管理在一個平臺中，實現業務指標的統一管理。

 

• 指標自動化：以指標管理資料，消除寬表操作根據指標定義的邏輯對底層資料進行加工、預計算，並根據指標所在的資料模型進行合併，消除寬表爆炸。若是指標很少被訪問或是不再被訪問，可以自動清理指標資料的預計算結果。此外，系統也會智慧向用戶推薦常用或關聯度高的指標，提升找指標的效率。

 

• 目標管理：用目標管理指標，形成指標體系管理指標的目的是幫助企業實現業務目標管理，因此通過管理目標的方式管理指標，形成指標體系，可幫助企業更好地達成目標。

 

• API 整合：構建資料應用，一致消費指標資料當指標和目標完成定義，系統需要一個出口。通過標準的指標 API ，讓使用者輕鬆構建資料應用，為應用提供一致的資料來源，消除指標割裂和資料孤島。

如果您對 Kyligence Zen 感興趣，歡迎點選 Kyligence Zen 指標平臺申請試用。