GemFire與Greenplum的最佳集成實踐之實施經驗談
最近的10年之中，很多應用系統、業務系統不斷在迭代，不斷有新版本在發布，可以看到有很多更創新式的應用來服務於我們的生活，我們的生活方式也因此改變很多。但是如果往後台數據看一下，會發現，雖然應用在前進，但是數據服務實際上還是在原地踏步。 發展到今天，現代系統中會經常面臨這三個問題：
1. 應用的發展和延展性，會被數據服務的並發性邊界所束縛，這種應用的延展可能會包含幾個方面：
隨著系統支持的用戶量的增加，應用的實例數會顯著增加。
隨著行業的發展，會開發出或者交付出更多的應用，也就是說，應用的數量也在延展。
隨著現在各種設備的發展，整個系統不但要接收從應用過來的請求，也要接收從各種設備上發出的信息對於數據介質的請求。
這三個方面都會導致對後台的數據服務能承載的並發量有一個更高的要求。但實際情況是，資料庫是有並發邊界的，這是一個障礙，限制了應用系統的發展。
2. 在業務中會發現，很難做到分析數據是可以更貼近於交易數據或者貼近於線上數據，可以提供一個準確的報告。在金融行業大家都會經常討論的T+1報表的問題。假如我在凌晨12點才能開始計算前一天24小時之內的數據。那麼開始計算之後，大概多長時間能拿到前一天24小時的結果呢？這取決於每個客戶支持的最終用戶的數量或分析的複雜度。有時候這種耗時可能要以小時計，有時候可能需要等到八九點開門之前領導才可能拿到前一天所有的數據分析報告。這對於整個系統來說，是一個很大的限制——我們的分析報告不能貼近於實時的交易數據，降低了分析報表的作用。
3.隨著近幾年雲計算的發展，微服務改造的發展，對於應用提出了更多的要求，需要進行持續交付、永遠在線、可以任意時候進行動態延展的要求。但是反過來看，數據並沒有準確好，數據現在不是Cloud ready，可能現在還部署在一個個的數據中心內部。當然，目前也會有很多的廠商在做Cloud Data這樣的工作。但是我們目前在各個系統中看到的採用情況，這個比例並不樂觀。
Pivotal 解決方案
看到了這三個問題之後，Pivotal的方案是什麼呢？
Pivotal在數據方案中有數據套件這樣的方案，Pivotal大數據套件包括了三個產品——MPP分析庫，Greenplum；內存數據網格GemFire；基於Spring Cloud平台來進行數據抽取、數據轉化的軟體，叫做Spring Cloud Data Flow。
這三個軟體分別做什麼用呢？
Greenplum主要進行複雜的場景的分析，基於業務規則的分析，基於機器學習的相關的計算，這都可以用Greenplum來做。
GemFire主要是用來進行實時交易和實時判斷的，或者說承載著大並發量的低延遲響應時間的業務上要求，是用GemFire來解決的。
Spring Cloud Data Flow做的是如何把數據從一個介質挪到另一個介質。例如從前端的應用產生的數據，通過Spring Cloud Data Flow 可以流轉給GemFire、可以流轉給Greenplum，也可以流轉給系統中需要的其他的數據介質。
前面說的會遇到的三種問題，一個是數據並發邊界的問題，這種時候可以使用GemFire來解決這樣的問題。對於GemFire來說，萬級別的TPS才是剛起步，GemFire可以隨著計算的資源的增加、隨著節點數量的增加，可以線性的提高承載的並發數量。
第二個問題是如何解決在分析數據和交易數據之間時間上的gap。在Pivotal有一個搭建於 GemFire 和 Greenplum 之間的組件—— GGC（GemFire Greenplum Connector）。通過這樣的組件，可以把分析極限貼近於交易，甚至可以把分析在GemFire中就可以進行完成。所以這裡是可以有很多選擇的。
第三個問題，數據是否是Cloud ready的。在之前GemFire、Greenplum都已經有公有雲的版本，基於AWS也好，基於Azure也好，Pivotal在數據上已經準備好Cloud ready了。
GemFire可以接收前端的請求。中間 Greenplum做各種分析，包括基於文本的分析，基於地理的分析，對其他操作語言提供介面來進行相關的複雜的機器學習的分析。在後端，我們會對接很多業界產品，無論是 AWS 的 S3、Google 的 GCP、微軟的 Azure還是 Hortonworks等等，都是可以在這種數據架構中為我們整體來服務的。
對於GemFire，它在數據溫度中是在hot一端，Greenplum是在warm一端。後端是在cold這端。主要是基於兩方面來綜合考慮的：一方面從數據存儲的數量，另一方面從需要的響應時間和承載的並發請求數方面，綜合來考慮進行分層的。
那麼GGC在哪裡呢？GGC就在GemFire和Greenplum之間進行互聯，可以進行數據的高速整合，也可以進行分析結果的互相傳遞。
GemFire和Greenplum進行聯合的四種典型的場景
場景1
如果前端有很大量的並發請求，例如到萬、到十幾萬的小顆粒度的寫請求的時候，Greenplum的產品因為主要是靠近於分析域，所以對於這樣請求的承載度並不如GemFire好，可以把GemFire放在前端來承載這些並發請求，然後GemFire作為一個write buffer，把這些寫請求cache下來，然後批量寫給Greenplum，來分擔整個系統的寫的壓力。這是第一個場景。
場景2
在Greenplum中可能有大量的分析的結果，這些結果如果是對外開放的，可能會有所有的最終客戶都可以訪問到的這種結果，這種情況下可以把結果放到GemFire里，由GemFire接收前端所有的查詢請求。這時候，GemFire就變成了一個read cache，就是一個讀緩存，它可以承載所有前端讀的請求。
場景3
如果需要一個事中的處理，在事件發生的過程中對它進行處理，可以做到什麼地步呢？在 GemFire 接收前端的寫請求的同時，同時展開事件的分析，分析結果完成之後把 GemFire 的分析結果作為反饋，反饋給前端也好，作為結果保存給 Greenplum 也好，都是可以做的。可以把事件從事後分析的級別調整到事中分析的級別，這對於風控系統，對於很多交易系統來說，還有反欺詐來說，都是非常關鍵的一步。
場景4
假如在一些系統需要根據不同用戶提交的數據對它進行分類和級別的判斷。而且這種判斷是要隨著整體數據量的變化進行不斷地學習和調整的，這種時候該怎麼做呢？首先基於 Greenplum 對歷史數據進行分析、進行建模，獲得相關的模型。然後把這個模型返身實施到 GemFire 中，由 GemFire 根據這個模型的內容，對於前端的輸入請求進行不斷地分析、判斷。這樣就在 GemFire 和 Greenplum 之間形成了一個正向反饋，有更新的數據提交給 GemFire，GemFire 可以迅速判斷。GemFire 把這個數據落到Greenplum 中，由 Greenplum 對它進行歷史模型的學習，學習完了之後，把結果重新更新給 GemFire，整個循環達成了，這個系統的數據是可以不斷向前邁進的。
我們在美國的公共事業行業有一個非常大的客戶，它既是 Greenplum 的客戶，也是 GemFire 的客戶。但是該客戶面臨了一個困境，它有很多數據分析產品可以做成模型，可是做出來的模型可以有JAVA語言的版本，但是做不出SQL的版本。這是它的第一問題。
第二個問題，客戶有很多既有的歷史系統是對接SQL的，需要訪問Greenplum來獲得相關的分析結果。
客戶每天需要把大量的數據從 Greenplum 傳給 GemFire，也需要把 GemFire 里分析好的數據再傳給 Greenplum。就是數據要在兩個存儲介質之間進行互傳。在那個時候是沒有GemFire Greenplum Connector的。那麼他們是怎麼來做這件事呢？
手動寫代碼，通過 JDBC 從 Greenplum 中拿到數據，然後寫給 GemFire，GemFire也把自己的數據通過 JDBC 寫給 Greenplum，這樣做，開發量很大，並且隨著系統數量的增加，這種聯繫、這種階乘關係增長速度是非常快的。
他們當時向我們的產品經理、產品管理團隊提出了這個需求，表示他們需要一個中間的連接組件。然後我們的產品管理團隊評估了這個組件，是有典型性和代表性的，也是可以在整個業界通用的。所以我們的研發團隊組織了一個大概五六人的小的團隊，快速的把這個組件開發出來，這個組件在2016年隨著 GemFire 9.0 的GA正式發布出來，到現在這個組件也在不斷向前演進。
參考案例
案例一：反欺詐系統
在反欺詐系統中GemFire能做什麼呢？
GemFire 在機器學習的場景，根據 Greenplum 運行出來的模型來判斷當前這筆輸入是否是正常的，是否是系統允許的，對它進行判斷。如果發現這筆操作有可能是欺詐或者是有問題的，那麼 GemFire 會把這個操作直接提示出來，返回給調查員，由調查員對這個內容進行分析。這個場景也是事中分析，在交易發生的過程中，GemFire 就已經介入，對請求根據 Greenplum 提供的模型進行判斷。
在這裡使用 GGC在做什麼呢？一個是把 GemFire 那邊接收到的交易數據通過 GGC 批量地寫到 Greenplum 中。另一個是通過 GGC 把 Greenplum 中更新好的模型返回給GemFire，用做以後交易的判斷。所以在這個架構中，GemFire 和 GGC 在這裡實現的功能是非常核心的，可以作為以後項目的一個參考。
案例二——某省移動實時區域人流計算分析
分享一個去年國內某用戶實施的項目。它實際上是使用 GemFire 做人流的分析，人流的分析並不是無目的性的，目前主要是針對一些旅遊的景區來做。旅遊業在快速發展，面對快速增長的旅遊市場如何快速高效的管理，統計，分析各旅遊景區的特色服務，來訪遊客，同期比對等數據為各景區提供高價值的信息服務是目前急需解決的問題。
如果某一個景區接待的旅遊人數是超限的，這時候景區應該啟動相關的措施對人員進行限流、分流，而不是等到大家都排隊，排到索道上，或者排到登山的階梯上，然後再關閉園門，這樣就太晚了。所以這時候也對計算的及時性有一個比較高的要求。
而且， 大家都知道在旅遊的黃金時間或者長假期間，各個景區人流是聚集的，聚集的人流會對移動運營商有很高要求，如何保證信號質量，如何調整基站，如何優化，如何增加。如果沒有這樣的數據，拿什麼作為基礎？如何知道哪個景區要加多少基站是正常的，如何知道哪個景區需要臨時調配多少通信車輛才可以承擔這個景區的通信請求。所以這些非常具體的業務，都是依賴於非常基礎的計算數據才可以進行判斷的，這也是這個場景中為什麼要進行計算的原因。
這是改造之前的一個場景，可以看到業界中都在流行的一些產品，包括Kafka、Storm、Redis，最後是Greenplum作為最後的分析庫。
在這個架構中，看起來是非常漂亮的，但是存在著哪些問題呢？第一，Redis只能存儲，不能用計算，需要使用其他伺服器作為計算伺服器。在Redis進行數據的快速存取，這都是沒有問題的，但是不能用做計算。這個架構圖上橫向的箭頭，指的就是需要依賴於其他伺服器從Redis上取數據，把數據拉回去，計算好了之後，再把計算結果放回來，這樣的過程。在這中間涉及到要把大批量數據通過網路傳輸，這是非常耗時的。在外部伺服器進行計算，也會非常耗時，因為它並不是在本地內存計算，然後再把計算結果放回去。如果計算結果比較小還好，如果計算結果是比較大、比較複雜的，那麼再把這個計算結果放回去，還要再耗一遍時間。就像把一頭大象從冰箱里拉出來，切好、做深加工好了之後，再重新放回到冰箱里一樣。
第二，這個整體架構中並不是HA的。Redis Cluster中有一個精確的說明：Redis的Cluster是不保證強一致性的，這意味著在 master 和 slave 之間是會有數據上的差距的。所以這個客戶為了保證在整個集群中能達到同樣的數據，它在這裡使用了單點Redis。這種時候這裡就會產生另一個問題，導致整個架構不是HA的。
是不是使用了一個 Cluster 的 Redis，這個架構就是HA的了？這也不是完全HA的。因為數據節點是有差的，這種時候不叫做HA。
第三個問題，再往下看，這個架構中存放數據是非常快的。無論Kafka、Storm，還是Redis，都會很快，Greenplum存放結果也會很快，但是計算耗時非常嚴重。二三十萬的數據可能要耗時達到分鐘級，這是一個非常恐怖的數字。
調整之後是什麼樣呢？
Kafka、GemFire 通過 GGC 連接 Greenplum，這個技術架構的特點是：
首先，整個體系架構是完整HA的架構，沒有單點故障。
第二，GemFire既作為數據的存放平台，支持並發計算，也作為數據的計算平台，同時這個計算平台是計算性能非常好的，而且它的計算性能是可以隨著節點數量的增加或者CPU數量的調整線性增加，達到進一步提升，滿足未來的要求。
第三，使用 GGC 在 GemFire 和 Greenplum 之間是一個非常簡單的連接，通過XML這樣的文件，把 GemFire 中的對象屬性和在 Greenplum 中的 table 中的 field 進行mapping之後，就可以進行相關操作，所以它非常簡單。
另外，因為GGC是基於GemFire的數據節點，cache server，和Greenplum裡面的segments之間的並行互聯傳輸數據的，所以傳輸數據的速率是非常高效的。
文章一開始介了GGC的場景中說的四個場景，這個場景屬於第三個場景，即在GemFire里計算完結果，把結果寫到 GGC 中。再暢想一下未來，如果未來想做一些更複雜的事情的話，甚至可以把 GemFire 在這裡面根據手機的信息做一些實時的分析或者實時的告警，這也是可以做到的。
這是優化調整的結果。當測試的數據量和第一期上線的數據量是50萬，最終目標是要2700萬，計算的頻次是5分鐘一次，POC的結果是17秒分析50萬數據。對比之前Redis調用其他計算伺服器這種架構達到分鐘級來說，這是大批量的提升的。而且要注意，這裡 GemFire 計算的是50萬數據，之前Redis計算的是大概二三十萬數據。做數據的人知道，隨著數據量增加，響應時間是會翹尾的，不是線性的。之前Redis是20萬數據2分鐘計算完畢，到50萬的時候，可能要達到10分鐘，一定不是線性的。
在生產環境中，會是13秒。為什麼？生產環境的CPU性能比測試環境要好，所以這也驗證了，隨著計算資源的增加，在 GemFire 上你會獲得計算結果或者響應時間上非常好的回報，這也是 GemFire 平台的一個特點。你對 GemFire 平台的投資，它會持續給你回報，它不會到某一個時刻來說，「對不起，我到邊界了，你再另建一套吧」。GemFire不會，GemFire可以增加節點，也可以調高節點的配置。只要用戶目前有這樣的資源，GemFire 就可以承擔這樣的請求。這樣的平台，才可能滿足用戶目前只有50萬，以後可能增加到幾百萬、增加到上千萬，最終變成2700萬的目標。這是 GemFire 的平台可以做到的。
在這種場景中，通過GGC這樣的組件，GemFire 和 Greenplum 進行聯動，通過GemFire計算完結果，Greenplum把這些結果進行保存，同時業務中還可以對這些結果在Greenplum 中進行更詳細的分析。這是使用GGC這樣的組件帶來的一些好處。
結語：2 slogans
第一個，在GemFire的世界中，大家經常說的「Scale your data services on demand to support high-performance，real-time apps」。以前做技術的人經常會有這樣的對話，前端的業務人員或者項目經理跟技術人員說「你要把這個業務調整成什麼樣」。技術人員會直接跟他說不可能，因為數據架構做不到。但是隨著近十幾年或者近十年的數據方面的發展，使用 GemFire 或者使用 Greenplum 這樣的產品，會極大的擴展前端實現新業務的可能性，甚至技術人員會更主動的去跟業務人員說，我們的系統能承載更多的業務，這樣可以推動整個公司、整個集團的業務的向前發展，我們有信心來做到這樣的事情。
第二個，「Performance is key，Consistency is a MUST」。沒有一致性的性能是沒有任何意義的，因為這樣會導致在運維中造成更多的問題。另外，沒有穩定性的性能對於系統來說也沒有任何意義。沒有穩定性的性能意味著以後要無休無止的踩到同一個坑裡，需要不斷投入進行修復。
希望大家根據自己的需求，選擇適合自己的、性能最佳的，比如Greenplum和GemFire這類產品來為自己的系統保駕護航！
TAG:Pivotal |