這篇文章主要介紹了數據計算中間件技術綜述 ，傳統企業大數據架構的問題，通過一張圖就能看懂，感興趣的朋友跟隨小編一起通過本文學習吧
傳統企業大數據架構的問題
上圖是大家都很熟悉的基於 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 這樣的標準接口，數據訪問使沒有任何問題的，但是讀取速度上是卻很難滿足數據應用的性能要求的。對於這個問題，潤乾為集算器提供了多種格式的內部文件存儲做為數據緩存機制來加速計算，這是是一種很實用的折中方法。同時潤乾也在嘗試開發具有針對性的高性能接口，用於提高了從外部獲取數據的速度。當然數據計算中間件涉及的接口極多，要解決好這個問題，是一個很大的挑戰。
- 對機器學習的支持
如今，人人都在談論機器學習，雖然傳統數據分析仍然是主流，而且在大多數領域，機器學習並不成熟，實際應用的效果大多也差強人意。但是不可否認的是機器學習是未來的方向，將會是數據應用中不可或缺的重要組成部分。因此，機器學習的功能應該是數據計算中間件必須具備的。集算器目前還不具備機器學習的能力，這使它的使用受到了一定的限制。當然，集算器本身在發展，未來可期。
總結
以上所述是小編給大家介紹的數據計算中間件技術綜述 ，希望對大家有所幫助，喜歡的小夥伴可以關注小編並幫小編轉發哦，小編後期會持續更新的。
閱讀更多 架構師公社 的文章
