1.1　從原始數據到洞察

傳統上，數據倉庫聚合了來自事務性數據庫的數據，并生成回顧性的批處理報告。數據倉庫解決方案通常由單一的供應商打包銷售，集成了元數據編目、查詢調度、接入連接器等功能。查詢引擎和數據存儲耦合在一起，互操作性選擇有限。在今天的大數據時代，數據平臺是由不同的數據存儲、框架和處理引擎組合而成的，支持多種數據屬性和洞察類型。在內部部署、云部署或混合部署中，有許多技術可供選擇，存儲和計算的解耦使得數據存儲、處理引擎和管理框架的混合和匹配成為可能。大數據時代的口號是根據數據類型、用例需求、數據用戶的復雜程度以及與已部署技術的互操作性，使用“合適的工具來完成合適的工作”。表1-1對比了傳統數據倉庫時代和大數據時代的關鍵區別。

編輯注1：有的文獻寫作Value（價值性）。

提取洞察分為四個關鍵階段：發現、準備、構建和實施（如圖1-2所示）。我們以構建一個實時業務洞察儀表盤為例來詳細說明，該儀表盤可以跟蹤收入、營銷活動績效、顯示客戶注冊和流失情況等。儀表盤還包括一個機器學習預測模型，用于預測不同地區的收入。

1.1.1　發現

所有洞察項目都是從發現可用的數據集和工件，并收集提取洞察所需的任何額外數據開始的。通常，數據發現的復雜性源于企業內部知識擴展的困難性。數據團隊往往從小規模開始，團隊知識容易獲得且可靠。但隨著數據量的增長和團隊規模的擴大，會在各業務線之間形成孤島，導致沒有可信的單一數據源。今天的數據用戶，需要在質量、復雜性、相關性和可信度各不相同的數據資源海洋中前行。以實時業務儀表盤和收入預測模型為例，數據用戶的出發點是了解常用數據集的元數據，即客戶資料、登錄日志、計費數據集、定價和促銷活動等。

發現數據集的元數據細節

第一步是理解元數據的屬性，比如數據來自何處、數據屬性是如何生成的等。元數據在決定數據的質量和可靠性方面也發揮著關鍵作用。例如，如果模型是使用未正確填充的表，或者其數據管道中存在錯誤的表構建的，那么該模型是不正確和不可靠的。數據用戶首先獲取其他用戶提供的團隊知識，這些知識可能是過時的和不可靠的。收集和關聯元數據需要訪問數據存儲、接入框架、調度器、元數據目錄、合規框架等。在數據集被收集和轉換的過程中，沒有標準化的格式來跟蹤數據集的元數據。理解元數據的屬性所需的時間需要通過度量“解釋耗時”來追蹤。

搜索可用的數據集和工件

具備理解數據集元數據細節的能力后，下一步就是找到所有相關的數據集和工件，包括視圖、文件、流、事件、指標、儀表盤、ETL和即席查詢等。在一個典型的企業中，數據集往往非常多。作為一個極端的例子，谷歌有260億個數據集（https://oreil.ly/Feume）。根據規模的不同，數據用戶可能需要花費數天或數周的時間來確定相關細節。如今，搜索主要依賴于數據用戶的團隊知識和應用程序開發人員。可用的數據集和工件在不斷地演進，需要不斷地更新元數據。完成這一步所需的時間需要通過度量“搜索耗時”來追蹤。

為機器學習模型重用或創建特征

繼續這個示例，開發收入預測模型需要使用市場、產品線等歷史收入數據進行訓練。作為機器學習模型輸入的屬性（如收入）稱為特征。如果歷史數據可用，那么屬性就可以作為特征使用。在構建機器學習模型的過程中，數據科學家對特征組合進行迭代，以生成最準確的模型。數據科學家需要花費60%的工作時間來創建訓練數據集，為機器學習模型生成特征。重用現有特征可以從根本上減少機器模型的開發時間。完成這一步所需的時間需要通過度量“特征處理耗時”來追蹤。

聚合缺失的數據

為了創建業務儀表盤，需要將已識別的數據集（如客戶活動和賬單記錄）關聯起來，以生成留存風險的洞察。為了訪問橫跨不同應用程序孤島的數據集，通常需要將這些數據集匯總并遷移到一個集中式的中央存儲庫中，類似數據湖。遷移數據涉及協調異構系統間的數據移動、驗證數據正確性，以及適應數據源上發生的任何模式或配置更改。一旦將洞察部署到生產環境中，數據遷移就是一個持續的任務，需要作為管道的一部分進行管理。完成這一步所需的時間需要通過度量“數據可用性耗時”來追蹤。

管理點擊流事件

在業務儀表盤中，假設我們要分析應用程序中最耗時的工作流。這需要根據點擊、瀏覽和相關上下文來分析客戶的活動，比如之前的應用程序頁面、訪問者的設備類型等。為了跟蹤活動，數據用戶可以利用產品中現有的記錄活動的工具，或者添加額外的工具來記錄特定小組件（如按鈕）的點擊。點擊流數據在用于生成洞察之前，需要經過聚合、過濾和豐富。例如，需要從原始事件中過濾由機器人產生的流量。處理大量的流事件非常具有挑戰性，特別是在近實時的應用場景中，例如定向個性化。完成收集、分析和聚合行為數據這一步所需的時間需要通過度量“點擊指標耗時”來追蹤。

1.1.2　準備

準備階段致力于為構建實際業務邏輯以提取洞察做好數據準備。準備工作是一項反復的、耗時的任務，包括數據聚合、清理、標準化、轉換和反規范化。這個階段涉及多種工具和框架。另外，準備階段還需要進行數據治理，以滿足監管合規性需求。

在中央存儲庫中管理聚合數據

繼續這個例子，業務儀表盤和預測模型所需的數據現在聚合在一個中央存儲庫（通常稱為數據湖）中。業務儀表盤需要結合歷史批處理數據和流式行為數據事件。根據數據模型和存儲在磁盤上的格式，需要有效地對數據進行持久化。與傳統的數據管理類似，數據用戶需要確保訪問控制、備份、版本控制、并發數據更新的ACID屬性等。完成這一步所需的時間需要通過度量“數據湖管理耗時”來追蹤。

結構化、清理、豐富和驗證數據

現在數據已經聚集在湖中，我們需要確保數據的格式是正確的。例如，假設在計費數據集中，試用客戶的賬單記錄有一個空值。作為結構化的一部分，空值將被顯式地轉換為零。同樣，在使用選定客戶時可能存在異常值，需要排除它們以防止影響整體參與度分析。這些活動被稱為數據整理。應用整理轉換需要用Python、Perl和R等編程語言編寫特殊的腳本，或者進行煩瑣的手工編輯。鑒于數據的數量、速度和多樣性不斷增長，數據用戶使用低級編碼技能以高效、可靠和重復的方式大規模地應用轉換。并且，這些轉換不是一次性的，而是需要以可靠的方式持續應用。完成這一步所需的時間需要通過度量“整理耗時”來追蹤。

確保數據權限合規

假設客戶不同意使用他們的行為數據來產生洞察，則數據用戶需要了解哪些客戶的數據可以用于哪些用例。合規性是在給客戶提供更好的洞察體驗和確保數據的使用符合客戶的意圖之間的平衡。目前沒有簡單的方法可以解決這個問題。數據用戶希望有一種簡單的方法可以定位給定用例的所有可用數據，且不必擔心違反合規性。沒有單一標識符可用于跨孤島數據集來跟蹤客戶數據。完成這一步所需的時間需要通過度量“合規耗時”來追蹤。

1.1.3　構建

構建階段的重點是編寫提取洞察所需的實際邏輯。以下是這個階段的關鍵步驟。

確定訪問和分析數據的最佳方法

構建階段的起點是確定編寫和執行洞察邏輯的策略。數據湖中的數據可以持久化為對象，也可以存儲在專門的服務層中，即鍵-值存儲、圖數據庫、文檔存儲等。數據用戶需要決定是否利用數據存儲的原生API和關鍵字，并確定處理邏輯的查詢引擎。例如，在Presto集群上運行短時的交互式查詢，而在Hive或Spark上運行長時的批處理查詢。理想情況下，轉換邏輯應該是不可知的，并且在將數據遷移到不同的聚類存儲時，或部署了不同的查詢引擎時，轉換邏輯不應該改變。完成這一步所需的時間需要通過度量“虛擬化耗時”來追蹤。

編寫轉換邏輯

業務儀表盤或模型洞察的實際邏輯通常是以提取-轉換-加載（ETL）、提取-加載-轉換（ELT）或流式分析模式編寫的。業務邏輯需要被翻譯成高性能、可擴展性良好且易于管理更改的代碼。需要監控邏輯的可用性、質量和變更管理。完成這一步所需的時間需要通過度量“轉換耗時”來追蹤。

訓練模型

在收入預測示例中需要訓練一個機器學習模型。我們使用歷史收入數據來訓練模型。隨著數據集和深度學習模型的規模不斷增長，訓練可能需要幾天甚至幾周的時間。訓練在由CPU和GPU等專用硬件組成的服務器群上運行。并且，訓練是迭代的，有數百種模型參數和超參數值的排列組合，用于尋找最佳模型。模型訓練不是一次性的，需要針對數據屬性的變化重新訓練。完成這一步所需的時間需要通過度量“訓練耗時”來追蹤。

持續集成機器學習模型變化

假設在業務儀表盤示例中，計算活躍用戶的定義發生了變化。機器學習模型管道隨著源模式、特征邏輯、依賴數據集、數據處理配置和模型算法的變化而不斷演進。與傳統的軟件工程類似，機器學習模型也在不斷更新，各團隊每天都會進行多次更改。為了集成這些變化，需要跟蹤與機器學習管道相關的數據、代碼和配置。通過在測試環境中部署并使用生產數據來驗證更改。完成這一步所需的時間需要通過度量“集成耗時”來追蹤。

洞察的A/B測試

考慮一個為終端客戶預測房價的機器學習模型。假設針對此洞察開發了兩個同樣準確的模型，哪一個更好？在大多數企業內部，普遍做法是部署多個模型，并將它們呈現給不同的客戶集。基于客戶使用的行為數據，從而選擇一個更好的模型。A/B測試（也稱為桶測試、拆分測試或控制實驗）正在成為做出數據驅動決策的標準方法。將A/B測試整合為數據平臺的一部分，以確保在機器學習模型、業務報告和實驗中應用一致的指標定義，這一點至關重要。正確配置A/B測試實驗非常重要，并且必須確保不存在不平衡，避免導致不同群體之間的興趣度量在統計上出現顯著差異。同時，在不同實驗變體之間，客戶不應該被交叉影響。完成這一步所需的時間需要通過度量“A/B測試耗時”來追蹤。

1.1.4　實施

在提取洞察的實施階段，洞察模型已經部署到生產環境中。此階段一直持續到洞察模型在生產中被廣泛使用為止。

驗證和優化查詢

繼續以業務儀表盤和收入預測模型為例，數據用戶編寫了數據轉換邏輯，可以是SQL查詢，也可以是用Python、Java、Scala等實現的大數據編程模型（例如，Apache Spark或Beam）。好的查詢和不好的查詢之間的差異非常明顯。根據實際經驗，一個需要運行幾個小時的查詢可以通過調優在幾分鐘內完成。數據用戶需要了解Hadoop、Spark和Presto等查詢引擎中的眾多旋鈕及其功能。這需要深入了解查詢引擎的內部工作原理，對于大多數數據用戶而言挑戰極大。沒有什么通用方案——查詢的最佳旋鈕值根據數據模型、查詢類型、集群大小、并發查詢負載等的不同而有所不同。因此，查詢優化是一項需要持續進行的活動。完成這一步所需的時間需要通過度量“優化耗時”來追蹤。

編排管道

該過程需要調度與業務儀表盤和預測管道相關的查詢。運行管道的最佳時間是什么時候？如何確保正確處理依賴關系？編排是確保管道服務水平協議（SLA）和有效利用底層資源的一種平衡行為。管道調用的服務橫跨接入、準備、轉換、訓練和部署。數據用戶需要監控和調試管道，以確保這些服務的正確性、健壯性和及時性（這很不容易）。管道的編排是多租戶的，支持多個團隊和業務用例。完成這一步所需的時間需要通過度量“編排耗時”來追蹤。

部署機器學習模型

預測模型部署在生產環境中，以便不同的程序調用它以獲得預測值。部署模型不是一次性的任務——機器學習模型會根據重新訓練定期更新。數據用戶使用非標準化、自主開發的腳本來部署需要定制的模型，以支持廣泛的機器學習模型類型、機器學習庫與工具、模型格式和部署終端（如物聯網設備、移動設備、瀏覽器和Web API）。目前還沒有標準的框架來監控模型的性能并根據負載自動擴展。完成這一步所需的時間需要通過度量“部署耗時”來追蹤。

監控洞察的質量

業務儀表盤每天都在使用，假如它在某一天顯示了一個不正確的值，原因可能如下：不同步的源模式更改、數據元素屬性發生變化、數據接入問題、源系統和目標系統的數據不同步、處理失敗、生成指標的業務定義不正確等。數據用戶需要對數據屬性進行異常分析，并對檢測到的質量問題進行根因調試。數據用戶依賴一次性檢查，在大量數據流經多個系統的情況下，這種檢查是不可擴展的。我們的目標不僅是檢測數據質量問題，還要避免將低質量的數據記錄與其他數據集分區混在一起。完成這一步所需的時間需要通過度量“洞察質量耗時”來追蹤。

持續成本監控

我們現在已經在生產中部署了洞察模型，并進行了持續監控以確保質量。實施階段的最后一部分是成本管理。在云端，成本管理尤其關鍵，即付即用的付費模型會隨著使用量的增加而線性增長（與傳統的先買后用、固定成本模式不同）。隨著數據大眾化，數據用戶可以在日常工作中自助提取洞察，但這有可能出現大量資源浪費，導致成本無限高的情況。比如，在高配GPU上運行一個糟糕的查詢可能在幾個小時內花費數千美元，這通常會讓數據用戶感到驚訝。數據用戶需要回答以下問題：

a. 每個應用程序花了多少錢？

b. 哪個團隊的支出會超出預算？

c. 是否可以在不影響性能和可用性的情況下減少開銷？

d. 分配的資源是否得到了適當的利用？

完成這一步所需的時間需要通過度量“優化成本耗時”來追蹤。

總的來說，在提取洞察的每個階段，數據用戶都把大量時間花在數據工程任務上，比如遷移數據、了解數據沿襲、搜索數據工件等。數據用戶的理想“天堂”是一個數據自助服務平臺，它可以簡化和自動化日常工作中遇到的任務。