本文作者Armel Nene是大數據公司ETAPIX Global創(chuàng)始人,在軟件開發(fā)和數據架構領域有多年經驗,熟悉Java、SOA、BI、企業(yè)搜索和數據倉庫,同時也是開源貢獻者,曾在諾基亞、Tata等多家公司工作。
軟件供應商的營銷部門在大數據方面做得很好,并使之成為了主流。這意味著什么?如果使用大數據,那么我們可以實現任何承諾;實現充分的商業(yè)洞察力并打敗競爭對手。然而,目前并沒有像之前被廣泛宣傳的那樣,存在大數據的成功實現?,F在的問題是:為什么沒有呢?顯然,這些銀彈企業(yè)已經看到了數十億美元的投資,可是至今投資并沒有回報。是誰的錯?畢竟,企業(yè)不必宣傳自己的內部流程或項目。在這一點上,我覺得這是由IT部門導致的。多數大數據項目的問題是由于技術人員(而不是業(yè)務人員)缺乏對于架構調整的理解和對未來商業(yè)的憧憬而造成的。
大數據項目的初步階段與其他任何IT項目沒有什么不同。項目都是由業(yè)務需求/要求所驅動的。這里不像黑客帝國那樣,我們無法回答那些還沒有被提出來的問題。在開始任何工作或討論應該使用何種技術之前,所有的利益相關者都應該了解以下幾方面:
·企業(yè)的背景
·企業(yè)的主要驅動力和組成部分
·對于架構工作的要求
·該架構的原則
·所使用的框架
·管理框架之間的關系
·企業(yè)架構的成熟度
在大多數情況下,大數據項目包括:了解當前商業(yè)技術環(huán)境;在當前和未來的應用與服務方面:
·戰(zhàn)略和經營計劃
·經營方針、目標和主要驅動
·正在實施的重要商業(yè)架構
·管理和法律框架
·IT戰(zhàn)略
·預先存在的架構框架、組織模式和架構倉庫
大數據連續(xù)/大數據項目不應該也永遠不能被孤立。一個簡單的事實就是大數據需要依靠其他系統存活,這意味著整個團隊應該開辟溝通的渠道。在大數據部署時,我想出了五個簡單的圖層/堆棧方法來獲得一個成功的架構。為了更傾向于技術架構,這似乎顯而易見:
·數據來源
·大數據的ETL
·數據服務API
·應用
·用戶界面服務
·數據源
為了在競爭中獲得優(yōu)勢,當前和未來的應用程序將會產生越來越多的數據以及數據處理過程。數據來自于各種各樣的途徑,但我們可以將它們分為兩大類:
結構化數據:通常以下一個預定義的格式存儲,例如使用已知的、成熟的數據庫技術。但并不是所有的結構化數據都存儲在數據庫中,因為很多企業(yè)選擇使用平面文件,如Microsoft Excel或者制表符分隔文件來存儲數據。
非結構化數據:企業(yè)產生大量的非結構化數據,如電子郵件、即時消息、視頻會議、網絡、平面文件,這些文檔、圖片和列表的數量是巨大的。我們稱之為“非結構化”數據。因為他們沒有明確的格式,這也為用戶查詢其內容帶來了方便。
在“大數據”普及之前,我已經將我的職業(yè)生涯的大部分時間花費在了企業(yè)搜索技術上。了解其數據的來源和以什么形式存在才能夠對部署大數據ETL項目產生價值。在編寫程序代碼之前,架構師需要嘗試規(guī)范數據的通用格式。
大數據ETL
這是令技術人員(特別是開發(fā)團隊)感到興奮的那部分。隨著每天有那么多關于大數據的博客和文章發(fā)表,使得非技術人員容易產生困惑。當然,能夠使用快捷的工具處理PB級的數據,會讓人們感到無比興奮,Hadoop和它的生態(tài)系統正是這樣的工具之一。在我們得意忘形之前,我們首先需要制定一些基本原則:
實時處理
批量處理
數據服務API
無論是否使用Hadoop工具,Extract Transform Load(ETL)項目的目的都在于將數據整合到一個基于查詢的主數據管理視圖中。Hadoop和其生態(tài)系統用來處理ETL大數據并不屬于查詢部分。所使用的工具將很大程度取決于項目處理的需要(無論是實時處理或批量處理);即Hadoop是用于處理大容量數據的批量處理框架。一旦數據已被處理時,主數據管理系統(MDM)可以存儲于數據存儲庫中,如基于NoSQL或RDBMS,這只是取決于查詢的需要。
隨著ETL工具受到越來越多的關注,一個非常重要的領域通常會被忽視,直到它幾乎成為次要考慮。 MDM需要被存儲在一個儲存庫,以便需要時存取信息。在真正的面向服務體系結構的精神中,數據存儲庫應該能夠向外部第三方應用程序提供一些接口,用來數據檢索和操作。在過去,MDM大多都建立在RDBMS中并使用結構化查詢語言來進行檢索和操縱。這并沒有必要去改變,但架構師應該意識到NoSQL等其它形式的數據庫類型。在選擇數據庫解決方案時,應該考慮到以下因素:
·是否有標準的查詢語言
·我們如何連接到數據庫; 數據庫驅動程序或者是可用的Web服務
·當數據增長時,數據庫是否可以擴容
·需要什么樣到安全機制來保護某些或全部數據
·項目中其它具體問題也應包括在該清單中
商務應用程序
到目前為止,我們已經將數據提取、轉換并裝載到主數據管理系統中。正常的數據現在是通過web服務公開(或數據庫驅動程序)由第三方應用程序使用。將承擔大數據的項目放在首要位置的原因就在于商務應用程序。有人會說,我們應該雇傭一個數據科學家。許多博客表明,數據科學家的角色是理解數據、探索數據、原型 (未知問題的新答案)并評估他們的發(fā)現。這很有趣,因為它讓我想起了電影《黑客帝國》,甚至在Neo要求他們決定哪一個相關之前,架構師就已經知道了答案。但這并不是企業(yè)的運行情況。如果數據科學家可能會建議按照意識新方法(《盜夢空間》)去做,但大部分情況下,問題將由數據科學家或那些了解數據的人來回答,這將是非常有價值的。商務應用程序將是這些問題的答案。
用戶界面服務
用戶界面是項目的成敗,UI設計的不好會影響到其背后的數據。直觀的設計將提高采用率,而且用戶可能會開始質疑數據的質量。用戶將訪問不同的數據、手機、電視和網絡。例如,用戶通常會將重點放在數據的某一方面,因此他們將需要的數據以定制的方式呈現。用戶想要通過當前的儀表板獲取一些數據,來匹配他們的視覺和感受。同樣,安全也將是一個問題。。企業(yè)門戶已經存在了很長一段時間, 它們通常用于數據集成項目。然而,這些標準(如遠程Portlet Web)使用戶界面通過Web服務調用對外提供服務。
結束語:本文展示了在項目著手之前,對大數據項目進行架構設計的重要性。該項目需要與商業(yè)遠景相結合,并對當前和未來的技術前景有很好的理解。數據需要為商業(yè)帶來價值,因此企業(yè)也需要從一開始就參與。理解數據將如何被使用是其成功的關鍵,另外,采用面向服務的架構方法也可以滿足數據的多種商業(yè)需求。