大數據架構和模式(三)理解大數據解決方案的架構層

作者: Divakar等  來源: DeveloperWorks     原文鏈接 
摘要:大數據解決方案的邏輯層可以幫助定義和分類各個必要的組件,大數據解決方案需要使用這些組件來滿足給定業務案例的功能性和非功能性需求。這些邏輯層列出了大數據解決方案的關鍵組件,包括從各種數據源獲取數據的位置,以及向需要洞察的流程、設備和人員提供業務洞察所需的分析。

  概述

  這個 “大數據架構和模式” 系列的 第 2 部分 介紹了一種評估大數據解決方案可行性的基於維度的方法。如果您已經使用上一篇文章中的問題和提示分析了自己的情況,並且已經決定開始構建新的(或更新現有的)大數據解決方案,那麼下一步就是識別定義項目的大數據解決方案所需的組件。

  大數據解決方案的邏輯層

  邏輯層提供了一種組織您的組件的方式。這些層提供了一種方法來組織執行特定功能的組件。這些層只是邏輯層;這並不意味着支持每層的功能在獨立的機器或獨立的進程上運行。大數據解決方案通常由以下邏輯層組成:

  1. 大數據來源
  2. 數據改動 (massaging) 和存儲層
  3. 分析層
  4. 使用層
  • 大數據來源:考慮來自所有渠道的,所有可用於分析的數據。要求組織中的數據科學家闡明執行您需要的分析類型所需的數據。數據的格式和起源各不相同:
    • 格式— 結構化、半結構化或非結構化。
    • 速度和數據量— 數據到達的速度和傳送它的速率因數據源不同而不同。
    • 收集點— 收集數據的位置,直接或通過數據提供程序,實時或以批量模式收集數據。數據可能來自某個主要來源,比如天氣條件,也有可能來自一個輔助來源,比如媒體贊助的天氣頻道。
    • 數據源的位置— 數據源可能位於企業內或外部。識別您具有有限訪問權的數據,因爲對數據的訪問會影響可用於分析的數據範圍。
  • 數據改動和存儲層:此層負責從數據源獲取數據,並在必要時,將它轉換爲適合數據分析方式的格式。例如,可能需要轉換一幅圖,才能將它存儲在 Hadoop Distributed File System (HDFS) 存儲或關係數據庫管理系統 (RDBMS) 倉庫中,以供進一步處理。合規性制度和治理策略要求爲不同的數據類型提供合適的存儲。
  • 分析層:分析層讀取數據改動和存儲層整理 (digest) 的數據。在某些情況下,分析層直接從數據源訪問數據。設計分析層需要認真地進行事先籌劃和規劃。必須制定如何管理以下任務的決策:
    • 生成想要的分析
    • 從數據中獲取洞察
    • 找到所需的實體
    • 定位可提供這些實體的數據的數據源
    • 理解執行分析需要哪些算法和工具。
  • 使用層:此層使用了分析層所提供的輸出。使用者可以是可視化應用程序、人類、業務流程或服務。可視化分析層的結果可能具有挑戰。有時,看看類似市場中的競爭對手是如何做的會有所幫助。

  每一層包含多種組件類型,下面將會介紹這些類型。

圖 1. 邏輯和垂直層的組件

該圖顯示了邏輯和垂直層的組件

  大數據來源

  此層包含所有必要的數據源,提供瞭解決業務問題所需的洞察。數據是結構化、半結構化和非結構化的數據,而且來自許多來源:

  • 企業遺留系統— 這些系統是企業應用程序,執行業務需要的分析並獲取需要的洞察:
    • 客戶關係管理系統
    • 結算操作
    • 大型機應用程序
    • 企業資源規劃
    • Web 應用程序開發

    Web 應用程序和其他數據來源擴充了企業擁有的數據。這些應用程序可使用自定義的協議和機制來公開數據。

  • 數據管理系統 (DMS)— 數據管理系統存儲邏輯數據、流程、策略和各種其他類型的文檔:
    • Microsoft® Excel® 電子表格
    • Microsoft Word 文檔

    這些文檔可以轉換爲可用於分析的結構化數據。文檔數據可公開爲領域實體,或者數據改動和存儲層可將它轉換爲領域實體。

  • 數據存儲— 數據存儲包含企業數據倉庫、操作數據庫和事務數據庫。此數據通常是結構化數據,可直接使用或輕鬆地轉換來滿足需求。這些數據不一定存儲在分佈式文件系統中,具體依賴於所處的上下文。
  • 智慧設備— 智慧設備能夠捕獲、處理和傳輸使用最廣泛的協議和格式的信息。這方面的示例包括智能電話、儀表和醫療設備。這些設備可用於執行各種類型的分析。絕大多數智慧設備都會執行實時分析,但從智慧設備傳來的信息也可批量分析。
  • 聚合的數據提供程序— 這些提供程序擁有或獲取數據,並以複雜的格式和所需的頻率通過特定的過濾器公開它。每天都會產生海量的數據,它們具有不同的格式,以不同的速度生成,而且通過各種數據提供程序、傳感器和現有企業提供。
  • 其他數據源— 有許多數據來自自動化的來源:
    • 地理信息:
      • 地圖
      • 地區詳細信息
      • 位置詳細信息
      • 礦井詳細信息
    • 人類生成的內容:
      • 社交媒體
      • 電子郵件
      • 博客
      • 在線信息
    • 傳感器數據:
      • 環境:天氣、降雨量、溼度、光線
      • 電氣:電流、能源潛力等
      • 導航裝置
      • 電離輻射、亞原子粒子等
      • 靠近、存在等
      • 位置、角度、位移、距離、速度、加速度
      • 聲音、聲震動等
      • 汽車、運輸等
      • 熱量、熱度、溫度
      • 光學、光、成像、見光度
      • 化學
      • 壓力
      • 流動、流體、速度
      • 力、密度級別等
      • 來自傳感器供應商的其他數據

  數據改動和存儲層

  因爲傳入的數據可能具有不同的特徵,所以數據改動和存儲層中的組件必須能夠以各種頻率、格式、大小和在各種通信渠道上讀取數據:

  • 數據獲取— 從各種數據源獲取數據,並將其發送到數據整理組件或存儲在指定的位置中。此組件必須足夠智能,能夠選擇是否和在何處存儲傳入的數據。它必須能夠確定數據在存儲前是否應改動,或者數據是否可直接發送到業務分析層。
  • 數據整理— 負責將數據修改爲需要的格式,以實現分析用途。此組件可擁有簡單的轉換邏輯或複雜的統計算法來轉換源數據。分析引擎將會確定所需的特定的數據格式。主要的挑戰是容納非結構化數據格式,比如圖像、音頻、視頻和其他二進制格式。
  • 分佈式數據存儲— 負責存儲來自數據源的數據。通常,這一層中提供了多個數據存儲選項,比如分佈式文件存儲 (DFS)、雲、結構化數據源、NoSQL 等。

  分析層

  這是從數據中提取業務洞察的層:

  • 分析層實體識別— 負責識別和填充上下文實體。這是一個複雜的任務,需要高效的高性能流程。數據整理組件應爲這個實體識別組件提供補充,將數據修改爲需要的格式。分析引擎將需要上下文實體來執行分析。
  • 分析引擎— 使用其他組件(具體來講,包括實體鑑別、模型管理和分析算法)來處理和執行分析。分析引擎可具有支持並行處理的各種不同的工作流、算法和工具。
  • 模型管理— 負責維護各種統計模型,驗證和檢驗這些模型,通過持續培訓模型來提高準確性。然後,模型管理組件會推廣這些模型,它們可供實體識別或分析引擎組件使用。

  使用層

  這一層使用了從分析應用程序獲取的業務洞察。分析的結果由組織內的各個用戶和組織外部的實體(比如客戶、供應商、合作伙伴和提供商)使用。此洞察可用於針對客戶提供產品營銷信息。例如,藉助從分析中獲取的洞察,公司可以使用客戶偏好數據和位置感知,在客戶經過通道或店鋪時向他們提供個性化的營銷信息。

  該洞察可用於檢測欺詐,實時攔截交易,並將它們與使用已存儲在企業中的數據構建的視圖進行關聯。在欺詐性交易發生時,可以告知客戶可能存在欺詐,以便及時採取更正操作。

  此外,可以根據在數據改動層完成的分析來觸發業務流程。可以啓動自動化的步驟 — 例如,如果客戶接受了一條可自動觸發的營銷信息,則需要創建一個新訂單,如果客戶報告了欺詐,那麼可以觸發對信用卡使用的阻止。

  分析的輸出也可由推薦引擎使用,該引擎可將客戶與他們喜歡的產品相匹配。推薦引擎分析可用的信息,並提供個性化且實時的推薦。

  使用層還爲內部用戶提供了理解、找到和導航企業內外的鏈鎖信息的能力。對於內部使用者,爲業務用戶構建報告和儀表板的能力使得利益相關者能夠制定精明的決策並設計恰當的戰略。爲了提高操作有效性,可以從數據中生成實時業務警告,而且可以監視操作性的關鍵績效指標:

  • 交易攔截器— 此組件可實時攔截高容量交易,將它們轉換爲一種容易被分析層理解的實時格式,以便在傳入數據上執行實時分析。事務攔截器應能夠集成並處理來自各種來源的數據,比如傳感器、智能儀表、麥克風、攝像頭、GPS 設備、ATM 和圖像掃描儀。可以使用各種類型的適配器和 API 來連接到數據源。也可以使用各種加速器來簡化開發,比如實時優化和流分析,視頻分析,銀行、保險、零售、電信和公共運輸領域的加速器,社交媒體分析,以及情緒分析。
  • 業務流程管理流程— 來自分析層的洞察可供業務流程執行語言 (BPEL) 流程、API 或其他業務流程使用,通過自動化上游和下游 IT 應用程序、人員和流程的功能,進一步獲取業務價值。
  • 實時監視— 可以使用從分析中得出的數據來生成實時警告。可以將警告發送給感興趣的使用者和設備,比如智能電話和平板電腦。可以使用從分析組件生成的數據洞察,定義並監視關鍵績效指標,以便確定操作有效性。實時數據可從各種來源以儀表板的形式向業務用戶公開,以便監視系統的健康或度量營銷活動的有效性。
  • 報告引擎— 生成與傳統商業智能報告類似的報告的能力至關重要。用戶可基於從分析層中得到的洞察,創建臨時報告、計劃的報告或自助查詢和分析。
  • 推薦引擎— 基於來自分析層的分析結果,推薦引擎可向購物者提供實時的、相關的和個性化的推薦,提高電子商務交易中的轉換率和每個訂單的平均價值。該引擎實時處理可用信息並動態地響應每個用戶,響應基於用戶的實時活動、存儲在 CRM 系統中的註冊客戶信息,以及非註冊客戶的社交概況。
  • 可視化和發現— 數據可跨企業內外的各種聯邦的數據源進行導航。數據可能具有不同的內容和格式,所有數據(結構化、半結構化和非結構化)可組合來進行可視化並提供給用戶。此能力使得組織能夠將其傳統的企業內容(包含在企業內容管理系統和數據倉庫中)與新的社交內容(例如 tweet 和博客文章)組合到單個用戶界面中。

  垂直層

  影響邏輯層(大數據來源、數據改動和存儲、分析和使用層)的所有組件的各方面都包含在垂直層中:

  • 信息集成
  • 大數據治理
  • 系統管理
  • 服務質量

  信息集成

  大數據應用程序從各種數據起源、提供程序和數據源獲取數據,並存儲在 HDFS、NoSQL 和 MongoDB 等數據存儲系統中。這個垂直層可供各種組件使用(例如數據獲取、數據整理、模型管理和交易攔截器),負責連接到各種數據源。集成將具有不同特徵(例如協議和連接性)的數據源的信息,需要高質量的連接器和適配器。可以使用加速器連接到大多數已知和廣泛使用的來源。這些加速器包括社交媒體適配器和天氣數據適配器。各種組件還可以使用這一層在大數據存儲中存儲信息,從大數據存儲中檢索信息,以便處理這些信息。大多數大數據存儲都提供了服務和 API 來存儲和檢索該信息。

  大數據治理

  數據治理涉及到定義指南來幫助企業制定有關數據的正確決策。大數據治理有助於處理企業內或從外部來源傳入的數據的複雜性、量和種類。在將數據傳入企業進行處理、存儲、分析和清除或歸檔時,需要強有力的指南和流程來監視、構建、存儲和保護數據。

  除了正常的數據治理考慮因素之外,大數據治理還包含其他因素:

  • 管理各種格式的大量數據。
  • 持續培訓和管理必要的統計模型,以便對非結構化數據和分析進行預處理。請記住,設置處理非結構化數據時的重要一步。
  • 爲外部數據設置有關其保留和使用的策略和合規性制度。
  • 定義數據歸檔和清除策略。
  • 創建如何跨各種系統複製數據的策略。
  • 設置數據加密策略。

  服務質量層

  此層複雜定義數據質量、圍繞隱私和安全性的策略、數據頻率、每次抓取的數據大小和數據過濾器:

  • 數據質量
    • 完整地識別所有必要的數據元素
    • 以可接受的新鮮度提供數據的時間軸
    • 依照數據準確性規則來驗證數據的準確性
    • 採用一種通用語言(數據元組滿足使用簡單業務語言所表達的需求)
    • 依據數據一致性規則驗證來自多個系統的數據一致性
    • 在滿足數據規範和信息架構指南基礎上的技術符合性
  • 圍繞隱私和安全的策略
    需要策略來保護敏感數據。從外部機構和提供程序獲取的數據可能包含敏感數據(比如 Facebook 用戶的聯繫信息或產品定價信息)。數據可以來源於不同的地區和國家,但必須進行相應的處理。必須制定有關數據屏蔽和這類數據的存儲的決策。考慮以下數據訪問策略:
    • 數據可用性
    • 數據關鍵性
    • 數據真實性
    • 數據共享和發佈
    • 數據存儲和保留,包括能否存儲外部數據等問題。如果能夠存儲數據,數據可存儲多長時間?可存儲何種類型的數據?
    • 數據提供程序約束(政策、技術和地區)
    • 社交媒體使用條款(參見 參考資料
  • 數據頻率
    提供新鮮數據的頻率是多少?它是按需、連續還是離線的?
  • 抓取的數據大小
    此屬性有助於定義可抓取的數據以及每次抓取後可使用的數據大小。
  • 過濾器
    標準過濾器會刪除不想要的數據和數據中的干擾數據,僅留下分析所需的數據。

  系統管理

  系統管理對大數據至關重要,因爲它涉及到跨企業集羣和邊界的許多系統。對整個大數據生態系統的健康的監視包括:

  • 管理系統日誌、虛擬機、應用程序和其他設備
  • 關聯各種日誌,幫助調查和監視具體情形
  • 監視實時警告和通知
  • 使用顯示各種參數的實時儀表板
  • 引用有關係統的報告和詳細分析
  • 設定和遵守服務水平協議
  • 管理存儲和容量
  • 歸檔和管理歸檔檢索
  • 執行系統恢復、集羣管理和網絡管理
  • 策略管理

  結束語

  對開發人員而言,層提供了一種對大數據解決方案必須執行的功能進行分類的途徑,爲組織建議必需執行這些功能所需的代碼。但是,對於想要從大數據獲取洞察的業務用戶,考慮大數據需求和範圍通常會有所幫助。原子模式解決了訪問、處理、存儲和使用大數據的機制,爲業務用戶提供了一種解決需求和範圍的途徑。下一篇文章將介紹用於此用途的原子模式。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章