如何構建面向使用者的資料分析架構

• 什麼是面向使用者的分析？
• 面向使用者的分析的商業價值是什麼
• 為什麼很難實現面向使用者的實時分析？
• 構建分析基礎架構以提供面向使用者的分析有哪些選擇？

Airbeds——Airbnb 的克隆
讓我舉一個現實的例子來為我們的討論做鋪墊。
假設我們正在構建“ Airbeds ”，這是流行的度假租賃平臺 Airbnb 的克隆版。Airbeds 是一個典型的雙邊市場，房東在 Airbeds（列表）上列出他們的財產，允許客人在到達之前搜尋和預訂。

Airbeds領域模型

為了衡量他們的房源在 Airbeds 上的表現，我們需要為房東提供一個分析儀表板，顯示特定時間範圍內的以下指標。

• total_nightly_revenue：在該持續時間內進行的預訂產生的總收入。
• total_nightly_revenue_by_listing：按單個列表列出的總預訂收入。例如，哪個上市帶來了最高和最低的收入？
• average_nightly_rate：每晚總收入除以預訂房源的天數。
• average_length_of_stay：這是客人每次預訂的平均入住晚數。

Airbeds 平臺中的所有房東都可以檢視此儀表板。那麼我們如何構建它呢？
在進入技術之前，讓我們看看“面向使用者的分析”的重要性。

面向使用者的分析的商業價值
“每個人都是資料人，但只有少數人可以訪問洞察資料”——這即將改變！ — Kishore Gopalakrishna，StarTree Inc
讓我們進一步澄清術語“面向使用者的分析”，以瞭解其在業務環境中的重要性。

從歷史上看，資料驅動型組織中存在兩個陣營：運營陣營和分析陣營。

運營營地由與客戶和終端使用者互動的機器和操作員組成。這些互動產生的資料作為副產品，透過 ETL 工具將其提取並移動到分析系統中。
分析陣營由分析師、決策者和高階管理人員組成，他們利用分析工具從處理過的運營資料中獲得洞察力。

到目前為止，分析陣營是唯一可以訪問分析的實體。但不長久。
Google、Facebook 和 LinkedIn 等網際網路規模的公司已經鋪平了將分析作為資料產品向其客戶和使用者公開的道路。
例如：

• Google 將其搜尋和網頁排名公開為 Google Analytics。
• Facebook 向廣告商公開了其使用者參與度指標。
• LinkedIn 向其使用者公開了“誰檢視了我的個人資料”。

客戶和終端使用者，他們是一樣的嗎？
客戶透過消費產品並最終為其交付的價值付費，從而直接從產品中受益。使用者消費該價值，但可能會或可能不會為此付費。
有時，客戶可以是使用者——瀏覽 amazon.com 的消費者會購買星級最高的產品，同時扮演這兩個角色。但是，請考慮比薩餅店的經理使用 ERP 系統進行庫存補貨的情況。在這種情況下，經理是 ERP 系統的終端使用者，而不是直接客戶。
從商業角度來看，雙方都應該可以訪問分析。

使用者分析——它創造了什麼價值？
為簡單起見，從現在開始，我將使用術語使用者來指代客戶和終端使用者。
現在讓我們回到我們的 Airbeds 用例。
分析儀表板對於房東衡量房源效能並採取糾正措施以改善整體業務至關重要。
例如：

• 指標total_nightly_revenue有助於識別表現良好的列表和需要注意的列表。
• 指標average_nightly_rate有助於將當前匯率與市場中位數進行比較。如果市場繁榮，主辦方可以提高利率。
• 指標average_length_of_stay有助於確定客人不喜歡特定房源的原因。

為什麼提供面向使用者的分析很難？
當分析僅限於分析陣營時，分析師接受的培訓是處理緩慢的查詢和包含陳舊資料的儀表板。組織中只有少數決策者。這些痛點並不重要，因為它是內部的。
但是，在向運營營地提供分析時，它不應該遵循同樣的做法。
例如，Airbeds 平臺可以擁有數百萬臺主機，其中絕大多數將同時訪問分析。此外，結果應在亞秒級延遲內顯示，以獲得更好的使用者體驗。底層分析基礎架構必須具有可擴充套件性、高效能和可靠性，才能承受高查詢吞吐量 (QPS) 並以超低延遲交付結果。
在本文中，我想列出幾種構建分析基礎架構以向使用者提供分析的方法。這可能直接適用於您的組織，也可能不適用。但至少您可以將它們用作指導原則，以避免重新發明輪子。

選項 1：從 OLTP 資料庫提供分析服務
讓我們從最直接的選項開始，我們直接從運營資料庫提供分析服務。

該架構由以下部分組成：

• 前端：分析儀表板透過網路和移動渠道提供給使用者。
• API層：代理前端和微服務之間的請求。此外，它還處理 API 身份驗證 (OAuth)、協議轉換和速率限制。
• 微服務：查詢資料庫並使用分析資料響應 API 層。
• 運算元據庫：此 OLTP 資料庫將預訂記錄儲存在預訂表中。

預訂表的架構

以下查詢生成total_nightly_revenue指標。

SELECT sum(total) as total_revenue FROM reservations where date_in > '2021-01-01' and date_in < '2021-01-31' and host_id=1;

select avg(datediff(date_out, date_in)) as length_of_stay FROM reservations where date_in > '2021-01-01' and date_in < '2021-01-31' and host_id=1;

SELECT listing_id, sum(total) as revenue_per_listing FROM reservations where date_in > '2021-01-01' and date_in < '2021-01-31' and host_id=1 group by listing_id order by revenue_per_listing desc;

挑戰
當保留表隨時間增長時，這些查詢將變得越來越慢，從而導致資料庫出現瓶頸。這導致前端效能低下。智慧索引將帶我們到一定程度。但很快，它也將達到一個極限。
OLTP 資料庫旨在一次處理較少的記錄，而不是透過大規模聚合、過濾、分組和排序來處理 OLAP 查詢。

選項 2：從 NoSQL 資料庫提供分析
前一個的主要限制是 OLTP 資料庫的讀取效能較差。選項 2 透過使用讀取最佳化的資料庫來提供分析微服務來解決這個問題。
新架構將有兩個新元素，NoSQL 資料庫和 ETL 管道。

受資料新鮮度限制
ETL 管道定期從保留表（在 MySQL 中）提取記錄，應用轉換，並將最終結果載入到 NoSQL 資料庫中，如 MongoDB、Cassandra 或 AWS Dynamodb。
我們可以使用 Apache Spark、Beam、Hive 甚至 Hadoop 作業等技術來構建 ETL 管道。其目標是利用非規範化和預聚合技術將源資料轉換為讀取最佳化格式。例如，我們可以在管道執行期間為每個主機預先計算指標，以防止 NoSQL 資料庫按需聚合它們。

挑戰
選項 2 帶來了兩個挑戰；第一個與資料新鮮度有關。ETL 管道以批處理模式執行，導致前端顯示陳舊資料。隨著資料的增長，管道執行時間也會增加，迫使我們在管道執行之間保持較長的間隔。
其次，我們將管理兩個分散式系統，即 NoSQL 資料庫和 ETL 管道。這增加了運營負擔。

選項 3：從實時 OLAP 資料庫提供分析
選項 2 幾乎是完美的，除了資料新鮮度問題。第三個選項透過使用帶有流式 CDC 管道的實時 OLAP 資料庫來解決這個問題。
獲得及時和一致的分析是該架構的目標
這些是新增到架構中的新元件。

• 變更資料捕獲（CDC）機制（Debezium）
• 事件流平臺（Kafka）
• 流式 ETL 流水線（Flink、Kafka Streams 等，可選）
• 實時 OLAP 資料庫 (Apache Pinot)

使用 Debezium 實時捕獲 OLTP 變化
與週期性的批處理 ETL 過程不同，像Debezium這樣的 CDC 工具可以捕獲對資料庫所做的更改。Debezium 部署在 Kafka Connect 上。
在我們的例子中，我們可以使用 Debezium 的 MySQL 聯結器來流式傳輸來自預訂表的更改。資料庫更改被編碼為事件並寫入 Kafka 中配置的主題。

將實時變化事件同步到 Apache Pinot
Apache Pinot 是一個實時分散式 OLAP 資料儲存，用於提供可擴充套件的低延遲實時分析。它可以從 Kafka 等流式資料來源和批處理資料來源中攝取資料，並提供一層索引技術，可用於最大限度地提高查詢效能。此外，流攝取是實時發生的，使資料可在幾秒鐘內進行查詢，使我們能夠以更高的幅度保持資料新鮮度。
Pinot 可以配置為從 Kafka 主題中攝取事件，其中 Debezium 流式傳輸來自預訂表的更改事件。攝取的事件會立即建立索引，允許前端在保持資料新鮮度的同時進行查詢。Pinot 還支援upserts，有助於讀取變化流中的最新值。
例如，假設客人現在進行預訂。這將在幾秒鐘內反映在分析儀表板中，讓主持人看到及時的見解。

使用流處理器進行動態轉換
有時，來自 Kafka 的更改事件需要經過處理步驟才能登陸 Pinot。這包括轉換、連線和時間聚合。
我們可以透過在兩者之間新增像 Apache Flink 這樣的流處理器來實現這一點。然後 Flink 從更改事件主題中消費，應用轉換，並寫入 Pinot 從中攝取事件的最終主題。

​

流式 ETL
但是，這對於大多數部署來說是可選的。一旦資料被攝取，Pinot 還可以使用 UDF 執行查詢連線和轉換。

挑戰
這種架構中唯一的挑戰是部署的複雜性，需要管理和監控的元件很多。但是當組織規模擴大時，及時和一致的分析的好處超過了操作的複雜性。

概括
資料即產品的概念將在這十年中發揮關鍵作用。組織中的每個人，包括員工和客戶，都將使用資料進行決策。因此，民主化分析是當今組織的必備條件。
在實施面向使用者的分析時，沒有硬性規定。我建議從最便宜和最直接的選擇開始，看看它失敗的地方。如果您從小流量開始，即使是 OLTP 資料庫也是一個很好的起點。您可以考慮根據您組織的預算、技能組合和對新分析的需求轉向選項 2 和 3。

參考：

大規模實時分析的挑戰

Data Mesh 原理和邏輯架構