數據計算中間件技術綜述

傳統企業大數據架構的問題

  上圖是你們都很熟悉的基於 Hadoop 體系的開源大數據架構圖。在這個架構中，大體能夠分紅三層。最下一層是數據採集，一般會採用 kafka 或者 Flume 將 web 日誌經過消息隊列傳送到存儲層或者計算層。對於數據存儲，目前 Apache 社區提供了多種存儲引擎的選擇，除了傳統的 HDFS 文件和 HBase，還提供了 Kudu、ORC、Parquet 等列式存儲，你們能夠根據自身的需求特色進行選擇。在這之上的數據計算層，選擇就更豐富了。若是你想作實時推薦，能夠採用 Storm、Spark Streaming 這樣的流計算引擎對 Kafka 或者 Flume 傳遞上來的數據進行實時處理。若是你想進行客戶畫像，可使用 Mahout 或者 Spark LMlib 裏的機器學習算法進行分類。若是你想查看當天的銷售排名，可使用 HBase、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）

數據計算中間件須要要很好的可擴展性，支持分佈式計算，具有了這種能力，數據計算中間件纔可能在實際的應用環境從容面對不一樣數據量的場景，而且在數據量業務量不斷增加的時候，仍然保證自身提供的各類數據服務持續可用。

-    集成性（Embeddable）

作爲一款中間件，可集成性也是必須的。這裏的集成包含兩個方面，一個是對第三方軟件的集成，一個是被集成到第三方的軟件中。數據應用的場景很是多樣，只有具有很強的集成性，才能在更多的環境中獲得應用。

以上就是咱們評估數據計算中間件的幾個關鍵考量，能夠簡稱爲 CHEASE。若是在 CHEASE 對應的六個方面都獲得很好的知足，那這就是一款優秀的數據計算中間件。

潤乾集算器

數據計算中間件是一個全新的概念，目前數據計算方面的產品中，與之最接近的是集算器。集算器是北京潤乾信息系統科技有限公司徹底自主研發的一款輕量級大數據融合計算平臺，一種針對結構化和半結構化數據的計算設計開發的新型計算引擎。集算器的設計目標，是試圖解決描述計算的效率和實施計算的效率。集算器具備如下一些特色。

1.    爲了達到設計目標，潤乾公司首先爲集算器設計了一種面向過程計算的腳本編程語言 SPL（Structured Precessing Language），能夠方便地描述數據的計算過程。集算器採用了新的數據和計算模型，提供了豐富的基礎計算方法，特別適合業務規則複雜的多步驟運算，讓計算自己變得易於描述，從而提升代碼的開發效率。
2.    集算器在內部的計算實現上，作了大量的優化工做，這些算法的優化使得在對數據集進行排序、彙總、關聯等計算時，速度獲得很大提高，大大提升了計算實施的效率。
3.    集算器內置大量數據訪問接口，能夠輕鬆鏈接各類數據源並從中獲取數據。支持的數據源包括但不限於：
    -    商用 RDBMS：Oracle、MS SQL Server、DB二、Informix
    -    開源 RDBMS：MySQL、PostgreSQL
    -    開源 NOSQL：MongoDB、Redis、Cassandra、ElasticSearch
    -        Hadoop 家族：HDFS、HIVE、HBase
    -    應用軟件：SAP ECC、BW
    -    文件：Excel、Json、XML、TXT
    -    其餘：http Restful、Web Services、支持 OLAP4j 的多維數據庫、阿里雲
4.    SPL 爲解釋型語言，不須要進行編譯。這使得集算器的任務腳本在集算器內部的部署十分方便，能夠很方便地實現動態熱部署。
5.    集算器提供了並行多線程計算和集羣分佈式計算的能力，並且集羣的節點能夠動態添加，具備十分優秀的可擴展能力。
6.    集算器的核心功能由若干個 Java JAR 包實現，短小精悍，具備超強的可集成性、靈活性、擴展性、開放性、可定製性，很是易於和 Java 應用進行深度整合。加之對外提供了 JDBC、Restful、Web Services 等標準接口，使之與第三方的應用很是容易進行整合集成。

以上這六個特色，偏偏對應了 CHEASE 的六個方面。雖然潤乾集算器設計之初尚沒有提出數據計算中間件的概念，可是整個產品的設計宗旨始終圍繞着 CHEASE，因此在兼容性、熱部署能力、計算性能、敏捷性、可擴展性和集成性幾個方面，至關得均衡，各方面的表現都至關優秀。若是你以爲在你的數據計算架構中須要一款數據計算中間件，那集算器恐怕是目前惟一的選擇。

尚待解決的一些困難

固然，數據計算中間件的概念剛剛被提出，集算器也是一款新產品，概念須要不斷驗證完善，產品也確定會有不少不足之處。目前可見的困難由如下兩點。

-    獲取數據的性能 

數據應用不一樣於其它的應用，它老是牽扯到大量數據的讀取，所以數據讀取的性能很是關鍵。數據讀取的性能不只取決於數據計算中間件自己，還取決於數據源和接口類型。若是經過 JDBC 這樣的標準接口，數據訪問使沒有任何問題的，可是讀取速度上是卻很難知足數據應用的性能要求的。對於這個問題，潤乾爲集算器提供了多種格式的內部文件存儲作爲數據緩存機制來加速計算，這是是一種很實用的折中方法。同時潤乾也在嘗試開發具備針對性的高性能接口，用於提升了從外部獲取數據的速度。固然數據計算中間件涉及的接口極多，要解決好這個問題，是一個很大的挑戰。

-    對機器學習的支持 

現在，人人都在談論機器學習，雖然傳統數據分析仍然是主流，並且在大多數領域，機器學習並不成熟，實際應用的效果大多也差強人意。可是不能否認的是機器學習是將來的方向，將會是數據應用中不可或缺的重要組成部分。所以，機器學習的功能應該是數據計算中間件必須具有的。集算器目前還不具有機器學習的能力，這使它的使用受到了必定的限制。固然，集算器自己在發展，將來可期。