傳統企業大資料架構的問題

上圖是大家都很熟悉的基於 Hadoop 體系的開源大資料架構圖。在這個架構中，大致可以分成三層。最下一層是資料採集，通常會採用 kafka 或者 Flume 將 web 日誌通過訊息佇列傳送到儲存層或者計算層。對於資料儲存，目前 Apache 社群提供了多種儲存引擎的選擇，除了傳統的 HDFS 檔案和 H ，還提供了 Kudu、ORC、Parquet 等列式儲存，大家可以根據自身的需求特點進行選擇。在這之上的資料計算層，選擇就更豐富了。如果你想做實時推薦，可以採用 Storm、Spark Streaming 這樣的流計算引擎對 Kafka 或者 Flume 傳遞上來的資料進行實時處理。如果你想進行客戶畫像，可以使用 Mahout 或者 Spark LMlib 裡的機器學習演算法進行分類。如果你想檢視當天的銷售排名，可以使用 H 、Impala 或者 Presto。如果想對某些商品的銷售進行比較複雜的漏斗分析，則使用 HIVE 或者 Spark 可能會更合適。

當然，大家根據各自的需求，可以疊加上 Redistribution 快取，ElasticSearch 全文字搜尋，或者像 MongoDB、Cassandra 這些產品。所以，大家會發現，其實在大資料計算方面，並沒有什麼特別成熟的架構，大家所做的大多都是針對一些問題點不斷進行創新、改進和修正，再把幾個產品想辦法整合起來。這是因為做為一個新興的領域，大資料計算方面的技術積累還很不夠，還有很多難點沒有攻克，還處在一個不斷成長的階段。而在大資料技術開拓創新上，網際網路企業是引領潮流的。目前的大量收到追捧的大資料技術產品，大多都是由網際網路企業。做為大資料技術的基石的 Hadoop 的基本思想基於 Google 的 Map/Reduce 和 Google File System，Presto 來自於 Facebook，貢獻了 Impala 和 Flume 的 Cloudera 雖然不算一家網際網路公司，但是帶有很強的網際網路基因。國內的 BAT 等網際網路企業也對大資料開源社群做出了很大貢獻。

但這也帶來了一個問題，那就是這些大資料產品即架構都是針對網際網路企業的因為需求與場景設計的。雖然這些需求和場景具有一定的普適性，但是在企業的整體 IT 架構上，傳統企業與網際網路企業有著很大的不同。

首先，傳統企業和網際網路企業在專業技術人員配備上有很大的不同。網際網路企業聚集了大量的高水平計算機軟體設計開發維護人員，這是絕大多數傳統企業所不具備的。這裡的差別一個是在量。傳統企業中，一個擁有幾百個技術人員的資訊中心已經是一個相當大的團隊了；而網際網路企業的技術人員往往都有數千人的規模，像 BAT 這樣的企業，開發維護技術人員都達到了上萬人。另一個差別則在質上。網際網路企業中通常會有一支專門的平臺支撐專家團隊，有能力自行及時修復開源產品中的 BUG，保障系統服務的穩定執行。而由於薪資等方面的原因，傳統企業往往很難招到掌握開源產品核心技術的頂級開發者。這給開源產品的使用帶來的隱患。一旦開源產品出現的 BUG 等問題，無人可以及時應對，將會給企業的生產服務造成很大的損失。

其次，傳統企業的 IT 架構也和網際網路企業有很大不同。網際網路企業的歷史相對較短，而且具有以開源軟體為基礎自行研發應用的基因，各企業自己對各種技術細節業務邏輯都非常瞭解，大資料系統甚至是和業務系統緊密聯絡的，不會有太多的整合性的問題。而傳統企業往往歷史較長，在 IT 建設走過多種技術路線，往往有大量的架構不統一的遺留系統。很多企業過去曾經建設過企業資料倉庫，現在又開始建設大資料平臺，這之間又沒有特別嚴格的劃分，不僅造成很多功能的重疊，更是造成了很多的資料冗餘，很多資料會在不同的系統中保留多份拷貝，甚至不少企業需要頻繁地把同一份資料在不同的系統中來回傳輸。這就帶來了很嚴重的整合性問題。

第三，相對於網際網路企業，大多數傳統企業的資料量其實並沒有那麼大。相比較 Google 每秒超 10 萬次的搜尋，支付寶雙十一每秒超過 25 萬筆交易，絕大多數的傳統企業的資料量真沒那麼大，可能還不至於成為不可攻克的難題。對於這樣的資料量，可能傳統的技術就可以解決，而不一定非要用到 Hadoop 這樣重的架構。而為了挖掘出這些資料中的價值，多源異構的複雜環境可能是一個更加麻煩的問題。

他山之石可以攻玉

有的時候，在考慮一個問題的解決辦法時，從類似問題的解決辦法中獲得一些借鑑是一個不錯的開始。

其實，在交易類應用領域，也曾出現過類似的情況。企業中執行這各種各樣的應用系統，這些應用由不同的開發者開發，技術路線、體系架構、遵循的標準都相差甚遠，造成了一個個資訊孤島，一些需要共享的資訊，不能在系統之間交換，造成很多資訊的滯後和資料不一致現象。

那麼後來這些問題解決了嗎？又是怎麼解決的？————有人發明了中介軟體。

什麼是中介軟體，並沒有人對它做出一個科學的定義。總體來說，是一個為了解決分佈異構問題而提出的一個概念它位於平臺 (硬體和作業系統) 和應用之間，為雙方或者多方提供的通用服務，這些服務具有標準的程式介面和協議。針對不同的作業系統和硬體平臺，它們可以有符合介面和協議規範的多種實現。 解決多源異構並不是中介軟體出現的唯一原因，但是是它解決的異構重要問題，一般來說，中介軟體具有以下特點：

1. 滿足大量應用的需要
2. 運行於多種硬體和 OS 平臺
3. 支援分佈計算，提供跨網路、硬體和 OS 平臺的透明性的應用或服務的互動
4. 支援標準的協議
5. 支援標準的介面

也就是說，中介軟體的主要作用，就是建立跨平臺的標準化互動介面。按照應用場景的不同，中介軟體開源分為網路通訊中介軟體、RPC 中介軟體、訊息中介軟體、交易中介軟體、Web 中介軟體、安全中介軟體等。這些不同的中介軟體在實際功能與實現方式上各不相同，在各自的領域中發揮著不同的作用，但是都滿足以上列出的特點，都具有上述描述的基本功能。

那麼，為什麼不考慮在資料應用領域也採用中介軟體技術呢？

資料計算中介軟體

為什麼提出資料計算中介軟體這個概念？因為在開發資料應用的過程，大家通常都會被以下的問題所困擾。

- 需要跨系統跨平臺操作，從不同的資料來源的資料放在一起計算
- 需求變化頻繁，不斷出現新需求，老需求不斷修改
- 業務邏輯與資料耦合過緊
- 複雜計算實現困難，執行效能差

而通過設定異構資料計算中介軟體，就可以很好地解決多源異構環境下的融合計算問題。當然，僅僅解決異構資料的互動訪問還是遠遠不夠的，要解決上面的困難，資料計算中介軟體還需要能夠提供高效的開發效率，優秀的計算效能和方便的程式碼管理能力。綜合起來，我們可以從下面幾個方面資料計算中介軟體進行評估。

- 相容性 （Cross-platform）

這裡的相容性主要是指的跨平臺的資料訪問能力。前面我們說到過傳統企業 IT 系統的異大特點就是存在大量異構系統，這些異構系統之間的互操作性很差，資料計算中介軟體的首要任務就是打通這個壁壘，起到連通的作用，將不同異構平臺中的資料整合到一起。

- 熱部署 （Hot-deploy）

資料應用的特點之一就是需求變化很快，我們對資料分析的要求是無止境的，總是在探求新的目標，總是希望能夠從資料中挖掘出更多的資訊。因此，資料應用的需求變化是異構持續的常態。這就對應用的部署提出了新的要求，如果每次部署新功能模組時都需要停止服務，勢必對服務的質量造成很大的影響。如果應用模組可以熱插拔，不需要停止整個服務，模組之間也相互隔離，那麼這個應用的執行就會更加平順，服務質量也可以得到保障。

- 高效能 （Efficient）

資料計算處理的效能對於資料計算中介軟體也非常重要，即使傳統企業的資料量沒有網際網路企業那麼大，資料應用需要處理的資料也是具有相當規模的，高的計算效能是評價資料計算中介軟體的異構重要指標。雖然不存在異構硬性的效能指標，但是在可能的情況下，我們總是希望處理速度越快越好。

- 敏捷性 （Agile）

敏捷性在這裡，強調的是開發的方面。正因為資料應用的需求會持續不斷變化，因此開發也會是一個持續的任務，不會像傳統業務應用一樣在相當一段時間內保持不變。開發的敏捷性可以保證資料應用可以在儘可能短的時間內完成新功能的交付使用，在某些特定的場景中，這可能為企業避免巨大的損失。

- 擴充套件性 （Scalability）

資料計算中介軟體需要要很好的可擴充套件性，支援分散式計算，具備了這種能力，資料計算中介軟體才可能在實際的應用環境從容面對不同資料量的場景，並且在資料量業務量不斷增長的時候，仍然保證自身提供的各種資料服務持續可用。

- 整合性 （ dable）

做為一款中介軟體，可整合性也是必須的。這裡的整合包含兩個方面，一個是對第三方軟體的整合，一個是被整合到第三方的軟體中。資料應用的場景非常多樣，只有具備很強的整合性，才能在更多的環境中得到應用。

以上就是我們評估資料計算中介軟體的幾個關鍵考量，可以簡稱為 CHEASE。如果在 CHEASE 對應的六個方面都得到很好的滿足，那這就是一款優秀的資料計算中介軟體。

潤乾集算器

資料計算中介軟體是一個全新的概念，目前資料計算方面的產品中，與之最接近的是集算器。集算器是北京潤乾資訊系統科技有限公司完全自主研發的一款輕量級大資料融合計算平臺，一種針對結構化和半結構化資料的計算設計開發的新型計算引擎。集算器的設計目標，是試圖解決描述計算的效率和實施計算的效率。集算器具有以下一些特點。

1. 為了達到設計目標，潤乾公司首先為集算器設計了一種面向過程計算的指令碼程式語言 SPL（Structured Precessing Language），可以方便地描述資料的計算過程。集算器採用了新的資料和計算模型，提供了豐富的基礎計算方法，特別適合業務規則複雜的多步驟運算，讓計算本身變得易於描述，從而提高程式碼的開發效率。

2. 集算器在內部的計算實現上，做了大量的優化工作，這些演算法的優化使得在對資料集進行排序、彙總、關聯等計算時，速度得到很大提升，大大提高了計算實施的效率。

3. 集算器內建大量資料訪問介面，可以輕鬆連線各種資料來源並從中獲取資料。支援的資料來源包括但不限於：

- 商用 RDBMS：Oracle、MS SQL Server、DB2、Informix
- 開源 RDBMS：MySQL、PostgreSQL
- 開源 NOSQL：MongoDB、Redis、Cassandra、ElasticSearch
- Hadoop 家族：HDFS、HIVE、H
- 應用軟體：SAP ECC、BW
- 檔案：Excel、Json、 、TXT
- 其他：http Restful、Web Services、支援 OLAP4j 的多維資料庫、阿里雲

4. SPL 為解釋型語言，不需要進行編譯。這使得集算器的任務指令碼在集算器內部的部署十分方便，可以很方便地實現動態熱部署。

5. 集算器提供了並行多執行緒計算和叢集分散式計算的能力，而且叢集的節點可以動態新增，具有十分優秀的可擴充套件能力。

6. 集算器的核心功能由若干個 Java JAR 包實現，短小精悍，具有超強的可整合性、靈活性、擴充套件性、開放性、可定製性，非常易於和 Java 應用進行深度整合。加之對外提供了 JDBC、Restful、Web Services 等標準介面，使之與第三方的應用非常容易進行整合整合。

以上這六個特點，恰恰對應了 CHEASE 的六個方面。雖然潤乾集算器設計之初尚沒有提出資料計算中介軟體的概念，但是整個產品的設計宗旨始終圍繞著 CHEASE，所以在相容性、熱部署能力、計算效能、敏捷性、可擴充套件性和整合性幾個方面，相當得均衡，各方面的表現都相當優秀。如果你覺得在你的資料計算架構中需要一款資料計算中介軟體，那集算器恐怕是目前唯一的選擇。

尚待解決的一些困難

當然，資料計算中介軟體的概念剛剛被提出，集算器也是一款新產品，概念需要不斷驗證完善，產品也肯定會有很多不足之處。目前可見的困難由以下兩點。

- 獲取資料的效能

資料應用不同於其它的應用，它總是牽扯到大量資料的讀取，因此資料讀取的效能非常關鍵。資料讀取的效能不僅取決於資料計算中介軟體本身，還取決於資料來源和介面型別。如果通過 JDBC 這樣的標準介面，資料訪問使沒有任何問題的，但是讀取速度上是卻很難滿足資料應用的效能要求的。對於這個問題，潤乾為集算器提供了多種格式的內部檔案儲存做為資料快取機制來加速計算，這是是一種很實用的折中方法。同時潤乾也在嘗試開發具有針對性的高效能介面，用於提高了從外部獲取資料的速度。當然資料計算中介軟體涉及的介面極多，要解決好這個問題，是一個很大的挑戰。

- 對機器學習的支援

如今，人人都在談論機器學習，雖然傳統資料分析仍然是主流，而且在大多數領域，機器學習並不成熟，實際應用的效果大多也差強人意。但是不可否認的是機器學習是未來的方向，將會是資料應用中不可或缺的重要組成部分。因此，機器學習的功能應該是資料計算中介軟體必須具備的。集算器目前還不具備機器學習的能力，這使它的使用受到了一定的限制。當然，集算器本身在發展，未來可期。

總結

以上所述是小編給大家介紹的資料計算中介軟體技術綜述 ，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對我們網站的支援！