開源最大的特征就是開放性，雲生态則讓開源技術更具開放性與創造性，Elastic 與阿裡雲的合作正是開源與雲生态共生共榮的典範。值此合作三周年之際，我們邀請業界資深人士相聚雲端，共話雲上Elasticsearch生态與技術的未來。
本篇内容是Elastic中文社群副主席吳斌帶來的基于流式計算平台搭建實時分析
分享人：Elastic中文社群副主席吳斌
本文将通過三個部分展開分析基于流式計算平台搭建的實時分析應用中Elasticsearch的實戰分享：
- 面向開源産品的架構設計
- Elasticsearch在流式平台中的角色功能
- 雲原生與k8s叢集管理經驗分享
衆所周知，Elasticsearch本身是一個搜尋引擎，随着演變和發展，現在它的資料分析能力也非常強大，但它并不是一個萬能的引擎，它也需要借助生态的支撐。然後把整個實時分析應用的平台搭建起來也是非常重要的一點，是以今天我們分析的角度是在于Elasticsearch本身是如何借助生态的，在這個生态當中自己又處于一個什麼樣的位置，最後我們會聚焦到Elasticsearch本身應該如何去實作快速簡單、具備彈性、通用性的一些部署。
一、面向開源産品的架構設計
為什麼要面向開源産品去做架構設計？很重要的一點是增加平台的通用性和一緻性。如果想讓整體的架構變得易于維護，不可避免地要借助雲平台的一些能力，但又不能跟這個平台完全綁死，這種情況開源産品在這些平台上的一些實作，就是一個更好的選擇。
輕松定制化業務，專注低學習成本
面向開源做架構設計，除了它的開放性和靈活性之外，你還能輕松地定制你的産品，我們的開發和運維人員也可以更多地專注在業務本身上，而不是花更多的成本去學習一些商業産品。開源産品的學習成本本身就比較低，因為在網際網路上，很多視訊網站上，都能擷取到很多有用的資源，在中國針對Elasticsearch我們也有一個自己的中文社群，這上面不管是針對于初學者，還是對于一些非常深入的大咖們，相信都能有你所需要的一些内容。
透明、安全、合規
中國企業逐漸對安全合規的屬性變得更加敏感和重視，開源産品能使安全合規這些規則變得更加透明，因為代碼都是公開的，能快速地幫助我們通過合規性的一些稽核，和安全機制并加強。
高度靈活性，無平台綁定
過去Elasticsearch本身不能完成所有流式平台的搭建，還需要借助生态。生态上，越多的元件引入進來，系統就會變得越複雜，維護成本就會穩健升高，如果能借助雲平台的力量，運維和後期靈活的擴充就會變得相對容易，對未來假設去做移植工作也不會有太大的障礙。
【平台元件構成】
我們在搭建流式計算平台時的架構還是非常清晰的，在這裡做一個簡單的剖析。
首先，資料采集通常來講是一個分布式的消息隊列，它采用的釋出或者訂閱是一種消息的分發機制，同時還能在後面的計算和存儲引擎出現問題時把消息緩存在消息隊列裡面。這個分布式的消息隊列本身也是高可用的，當出現流量峰值，它也能對後面的存儲引擎有保護作用。
當資料流進來之後，第二步就是分布式計算引擎。首先需要對進來的資料做校驗，判斷資料是否合法，格式是否是我期待的，有沒有髒資料等等，同時還可以去業務資料庫引擎裡拉取一些資料，把它變得更加豐富，來輔助後期的分析。另外，現在的流式計算平台能讓資料計算更加精确，這一點基于事件時間開窗的計算。而流式的分布式計算引擎本身在雲上也具備彈性，且可以做熱更新，這對整個平台的穩定性和擴充性來說都是非常友好的。
除了消息隊列和分布式計算引擎之外，後面我們還會選擇三個比較關鍵的引擎，其中一個就是我們主要要讨論的引擎Elasticsearch。除此之外可能還會引入高IO的KW列存，最常用的是HBase。這兩個引擎在這個組合裡面扮演的是對于非常熱的資料的一些處理和計算，是實時的一部分。第三個引擎我們引入的通常來講是線下的比如資料倉庫或者一些MPP引擎。大家的選擇面是非常廣的，比如傳統的HIVE，還有開源的Greenplum等等，甚至一些商業産品都可以是在我們選擇清單裡的一些存儲，這些存儲的角色更傾向于一些偏線下的計算，或者是比較溫的一些資料的計算，比如過去七天的一些資料的計算，基于每天去繪制的報表和計算。在熱資料這一部分，Hbase通常來講不是一個非常必要的引擎，隻是在我們有非常高IO的吞吐的場景下不得不引入它，它的核心的實時資料分析這一部分通常來講我們還是用Elasticsearch去完成的。
基于上面這一套引擎，下面還會有兩個非常重要的基礎元件，這個在雲端實際上也都給大家封裝非常好的一些成熟的産品和底座。 如果大家是在on-premise自己的IDC機房裡去部署的，還需要維護這兩套系統，在本地需要有一個高性能的網絡，能夠支撐比如消息隊列之間的消息傳遞，還有分布式計算引擎之間worker節點的一些shuffling的操作，也都需要通過高性能網絡及交換資料，資料引擎之間的資料交換，節點之間的shuffle也都需要高性能的網絡來支撐。
另外就是底層的分布式存儲，這個存儲的選擇當然也非常多，在雲端我們通常會借助對象存儲來做比如分布式計算引擎的檔案輸出，或者資料的輸出，還有錯誤資料的一些落地，後面的資料引擎比如Elasticsearch就會做一些資料的備份，比如說snapshots。分布式存儲可以作為我們資料的一些archive，比如一些老舊資料的備份，或者在關鍵時刻需要重塑，可以很快地從這些snapshots裡面恢複資料。
這個平台的組建實際上是非常簡單的，那麼在根據這些元件搭建真正的架構的時候，就可以看到上圖這樣的一張架構圖。中間虛線部分上面是真正的業務引擎，裡面有我們的伺服器，還有處理業務的關系型資料庫。真正的資料就是從我們服務上來的，通常來講，比如說可能有這些伺服器的日志，監控，業務上來講，從這個業務伺服器上我們可能會采集很多使用者端的一些行為，比如說使用者在你的平台上購買什麼樣的商品，或者社交類的産品、内容類的産品都點開了哪些内容等等。這些資料就會被實時地發送到剛才介紹的消息隊列裡面（圖中左邊信封的圖示），在這個隊列緩存裡進行緩存之後，就會把它放到後面的Streaming引擎裡面去。這個引擎用到了Beam這樣一個驅動層，分布式計算的一個架構，它也是一個開源的分布式計算引擎的架構，隻是一個驅動層。在這一方面，我們想把這個平台打造的通用性好一些，是以在這個關鍵的分布式計算環節，我們選擇了這樣一個驅動層。 它所帶來的好處是比如我在一次編碼之後，可以驅動不同的分布式計算引擎去幫我完成計算任務，而且它是批流一體的引擎，Beam的代碼就可以驅動Flink去完成計算任務，也可以驅動很多其他的driver。你可以去做流式的處理，也可以做線下的Bash處理，這是我們選擇Beam的一個原因。 當然，Beam也會有它一定的局限性，可能每個引擎之間有不同的非常獨立的calculator，沒有能很好地移植到Beam裡面，它就不支援。是以大家在真正使用的時候，還是要根據自己的業務看Beam是不是一個非常好的選擇，目前在我們服務的客戶當中Beam基本上是可以滿足絕大多數的需求的。
既然Beam是一個批流一體的引擎，并且分布式計算已經會做一些ETL，然後從我們的業務資料裡我們可能會拉取一些業務表，來跟我們實時采集的使用者行為資料或者日志資料做一些關聯，友善我們日後去做分析。這個時候我們會把一些不符合或者有問題的資料輸送到對象存儲上面去做備份，與此同時還會把明細資料也都打包壓縮備份一份放在對象存儲上面以備不時之需。
接下來後面接的引擎我們就會把一些實時的資料直接注入到Elasticsearch引擎裡面，去支撐我們的業務包括實時分析業務。在非常高吞吐的情況下，我們會引入HBase，就是下面介入的KV型的列存。它的列存表的設計有寬表或高表兩種，是完全取決于我們的業務的，但是一旦我們引入Hbase這種KV引擎的話有一點需要注意，就是明細的資料才可能會錄到HBase裡面去，為了減少Elasticsearch本身的IO，我們會把一部分計算任務放在中間的分布式計算引擎裡面去做。舉個簡單的例子，假設打車這樣一個場景，使用者或車輛的實時地理位置資訊是非常海量的資料注入到系統裡面，在這個訂單目前沒有完成的時候，我們都可以把這些實時高IO的資料放到HBase裡面進行查詢，或支撐你的業務，當這個session結束之後，把它歸攏成一條資料放到ES裡面去，我們在Elasticsearch裡面就可以做一些實時訂單的分析，軌迹，金額，或者官方的一些客服人員去對這個訂單做查詢和服務我們的客戶。這就是ES加HBase在實時的場景是這樣配合工作的，并不是同樣的資料全部錄入到兩個引擎裡面去。
第三個與此同時我們還會做的事情就是放到Data Warehouse裡面去做一些線下的分析。另外，可以看到Beam還會承擔一部分BASH的工作，也許我們會有一部分這種批處理的工作，在實時的資料落到對象存儲之後，我們也可以定時地讓Beam去驅動Flink等引擎完成後面的一系列批處理的工作。
二、Elasticsearch在流式平台中的角色功能
這個平台架構實際上也是非常清晰的，在這個平台裡面我們再具體地去看一下Elasticsearch到底承載一個什麼樣的角色和哪些功能。
1、文字檢索
首先它最主要的功能就是文本的檢索，他适用的場景主要是日志，運維，開發，還有一些實時業務的客服，客服可以根據這個日志快速地找到一些訂單的線索。
2、已知資料的計算
第二個功能是已知資料的計算，是一些實時名額的計算，固定的報表，實時的大屏展示等等。這些資料通常來講，schema是我們已經設定好的，我們知道後面根據哪些名額次元進行分析，比如把它做成一張報表或者做成一個大屏等。
3、未知線索探索
另外一個非常重要的Elastic的特點，就是對未知線索的一些探索，這也是為什麼我們要在實時業務中使用Elastic search的非常重要的原因，因為Elasticsearch非常的快。 當你發現業務當中有些異常的名額出現的時候，你會拿到這個線索，但你并不知道是由于什麼原因導緻的，可能是完全未知的一種攻擊手段，并不能通過規則引擎去發現它。這個時候我們需要拿着這個線索作為一個輸入，在實時的資料裡面去探索，甚至結合一部分我們的曆史資料，快速地進行一些複雜的過濾和篩選，然後找到跟這些資料相關的其他可能的次元和資料，甚至很快能夠找到一些歸因，這個是搜尋引擎在做資料探索過程當中非常重要的一個特點。
是以當你的業務或分析平台需要有這樣的需求時，就可以從這三個次元去思考，是不是有些實時要檢索的文本，是不是有一些已知的報表的計算要展示，或者說會不會要對一些未知的線索進行快速的探索，這些都是Elasticsearch本身的一些功能和特點。
三、雲原生與k8s叢集管理經驗分享
1、Elastic Stack部署方式
首先我們看一下Elastic Stack的部署方式，基本上是以下三種。
過去我們常用的是最左和最右兩種，左邊的這種是我們自己去部署，不管是在雲平台的虛機上，還是在我們自己的機房裡面，它的優點顯然是非常通用，一緻性非常好，也非常透明，你甚至可以編譯自己的Elasticsearch去部署。它的缺點也是顯而易見，比如大叢集或叢集多的時候，它維護和更新會相當困難，包括多叢集的更新和資料之間的導入導出等等，并且當它出現錯誤時，恢複周期會變得非常長且複雜。這個對于大叢集來講不是一個推薦的方案，小叢集十個節點以内就還可以。
再看最右的方案，就是以SaaS的部署方案，它的優點也是非常顯而易見的，在這個浏覽器裡輕松地點一下就可以完成叢集的一個部署和後期的運維，甚至包括更新和資料之前的導出等等。它的缺點是它的細節不透明，并且網絡的一些拓樸結構，甚至自己的網絡都會受一些限制，叢集的入口網關的性能也是受限的。是以SaaS的好處就是非常簡單，但是後面的定制化，甚至靈活性，甚至第一時間能不能得到ES的更新來講可能都不是最好的一個選擇。
根據我們去年一年的經驗來看，Kubernetes上的部署會是一個非常好的選擇，并且也比較成熟，這個取決于Kubernetes上支援的兩個好的技術。
最早期實際上Kubernetes并不是對這種資料層産品非常友好的平台，因為它都是無狀态的應用。随着operator概念的引入，它才把整個資料平台放到Kubernetes上，變成一個具有可執行性的方案。再加上ES本身自己的設計，反而讓Elasticsearch本身對Kubernetes平台是非常友好的。它的優點也是顯而易見的，後面會用一些典型的場景去展示。另外一點是Infrastructure as code的概念，你可以把你叢集的描述放到一個壓縮檔案裡，它就變成一個你的叢集部署的結構了，後期隻需要改變這個樣本檔案就可以改變你的部署和架構等等。第三點，在Kubernetes上的彈性非常好，隻要資源夠，你可以瞬間釋出出大量Elasticsearch的節點。 而且相對于SaaS的方案來講它的資源也是獨顯的，不會出現你不知道你的容器是否跟其他的容器部署在一個實體主機上，他們在共享、競争着CPU的使用等等場景。
Kubernetes固然好，但是使用率并不高，主要是因為在一般的中小企業裡面引入Kubernetes從某種意義上實際上是給自己平添了不少麻煩，因為不管是應用層還是資料層，都需要更多地去維護一套Kubernetes系統。 是以，這個可能簡化了ES和上面應用的使用場景，但是對你的運維團隊帶來了另外一個次元的負擔，那就是對于Kubernetes叢集的維護，是以我們也是比較推薦大家在雲上面去做Kubernetes，使用雲端托管的Kubernetes服務來部署Elasticsearch。目前來講，我們社群維護的Kubernetes這個版本首先還是受限于Kubernetes，因為沒有Kubernetes就部署不了。第二，目前還隻是一個開源的版本，ES官方在未來應該會逐漸推出商業版本，大家可以時刻保持關注，我們也會第一時間來更新社群。
2、ES叢集架構的預置
這裡我們給出一個場景，在後面給大家預置的項目裡面可以看到我們對ES的叢集架構做了一個預置。我們提供了三種方案，第一個是單節點的，通常隻是對開發人員的，可以讓整個開發，測試，還有線上的環境完全保持在同樣一個版本。第二個是全角色的節點（左上角第一張圖），這裡面我們對于每個節點做了一些深度的優化，不同角色的節點都應該有哪些相應的參數的調整。 可以看到，在全角色的部署上面我們把它分布到兩個區裡面了，如果你是在自己機房裡面的Kubernetes上，你可以把它當做兩個機架，我們對于資料的分布做了一個高可用，也就是說我們會讓你的主分片和replica分别分布在兩機架之上。
除此之外，我們還封裝了一個分角色節點的部署（右下圖），這個通常可能會應對一些比較大規模的叢集，就是我們把主節點，資料節點，還有coordinating，Ingest界面全部分離出來，這樣做的好處就是當叢集遇到高峰資料的時候，你可以相應地去調整Ingest node，Coordinating node或是Data node，是以這個叢集的彈性是存在的。另外我們還給大家預置了很多存儲的方案，不同平台提供的底層塊存儲或者磁盤是不一樣的，是以說這裡需要根據自己所選用的平台做一些靈活的調整。
3、恢複政策
左圖是資料在計算平台上的一個有向無環圖，資料從上面的節點流進來之後，經過後面的計算節點做一些簡單的ETL，最重要的是下面的兩個輸出，左邊的輸出是錯誤資料和明細資料的備份的輸出，右邊的資料是計算完整理後的一些資料或者是聚合後的一些資料，把它輸出到ES。左邊這張圖就是分布式計算引擎在做的事情。
Elasticsearch本身就是中間這張圖，我們會跟存儲做一個關聯，不管下面是什麼樣的存儲方案，還是雲上的對象存儲，我們都會定期去做Snapshot。
有些人可能會提出疑問：左邊備份了明細資料，中間為什麼還要去做Snapshot呢？是否有些多此一舉？
實際上是這樣的，我們的明細資料備份之後可能不光是給ES去用，由于ES本身的Snapshot也是定時去做的，有些人可能一天做一個增量備份，有些人可能一小時做一個增量備份，假設今天這個時間節點出現問題，我用Snapshot恢複隻能恢複到昨天的資料，是以說我在真正重建這個叢集快速恢複我的資料的時候，在有必要的前提條件下，是Snapshot加明細這樣一個恢複的政策，能讓我的資料恢複到剛才叢集出問題的狀态。這些消息都會緩存或者阻塞在分布式消息隊列那一層，是以大家完全不用擔心。
右上角代碼的截圖是我們在Kubernetes引擎給大家做了一個叫Snapshotter的容器，它會定時給Elasticsearch做一個類似快照的URL , endpoint，然後定時地把資料備份到你的目标存儲上面去。但是最新版本的Kibana裡面我們現在好像也可以通過policy去做這件事了，也就是說現在Kibana或者是ES本身自己的功能确實越來越豐富了。右下角的截圖大家可以看到，我們封裝好了Elasticsearch的docker，自身部署到Kubernetes上的container可以在初始化容器的時候去裝一些相應的插件，比如用來對接交換資料的對象存儲或HDRS插件等等。是以如果大家有需要備份到雲平台的某個對象儲存，你需要去找這樣的插件然後把它安裝到ES裡去，就可以通過Snapshotter做一個定時備份。
4、叢集架構調整
除了恢複之外，在SaaS裡面另外一個我們經常做的操作就是對叢集的架構進行調整。
首先左圖是我們在調整節點或規模的時候，比如我想在目前的這個叢集裡面把我的節點從兩個調整到二十個，這個動作如果在Kubernetes叢集資源足夠的前提條件下，基本上一分鐘之内就可以完成，其實跟節點的多少關系并不是很大，當然越多可能會稍微慢一些，總體還是非常快的。你隻需要改一個數字，直接apply你的部署，叢集的規模立刻就可以增長上來。但是需要注意的是，要縮小這個叢集可能會慢一些，不過它至少不是一個手動工作，且是由ES官方的operator幫你逐個把節點拿掉的，這個動作一定要非常小心。首先是要做資料的遷移，把目前的資料移到其他的節點上去，做一系列的check之後再把這個節點拿掉。 但對于我們這些使用者來講，我們隻需要簡單地改一下數字就可以。
同理，更新也是，左圖大家能看到version 7.10.2現在已經是最新的版本了，如果未來有新的版本release的時候我們也隻需要改一個版本号，你的叢集會通過operator自動更新。是以調整架構規模是非常簡單的一件事情，如果在調整過程當中出現了任何問題，你也可以選擇去重建整個叢集，當然資料越多需要的時間也會相對更多。
右圖是架構的調整，上面是資料Ingest的攝入節點，下面是主節點，與左邊的節點調整同理。比如從一個全角色的節點引入Ingest node然後把master節點分離出來，實際上你需要做的隻是增加更多的node sets。在node sets下面我們定義node set在Kubernetes裡面扮演什麼樣的角色，分别有master節點、熱資料節點、冷資料節點等，都可以通過Elasticsearch去做一些标記，然後在node set裡面把它分離出來。我們在實際線下的操作過程當中，會根據實際情況進行調整。比如有些使用者剛開始給20個叢集做了角色分離，後來他發現了叢集的性能受限，有太多的節點去扮演master，ingest或者coordinating，他們的壓力并不高，資料節點偏少，這時我們就會讓這20個節點全部變成資料節點，變成同樣一個角色，來提高整個叢集的性能和使用率。
還有一種情況，假設随着同等節點的個數調整，比如從20個調整到40個，你發現utilization的不均勻之後又想把它分離出來，同樣沒有問題，也是通過node set的模式去調整就好了。
5、專用網關
我們為Elasticsearch量身打造了一個專用的網關，因為不管線上下操作還是在SaaS做都會有非常大的限制，但是如果你在Kubernetes裡面做，Kubernetes自身有非常好的預定義的ingress，ingress本身自己也會有一些限制。
我們給大家打造的Elasticsearch專用網關具備以下特性：
- 高可用，不停機索引，自動處理後端Elasticsearch的故障，不影響資料的正常攝取
- 寫入加速，可自動合并獨立的索引請求為批量請求，降低後端壓力，提高索引效率
- 查詢加速，可配置查詢緩存，Kinbana 分析儀表闆的無縫智能加速，全面提升搜尋體驗
- 透明重試，自動處理後端Elasticsearch節點故障和對查詢請求進行遷移重試
- 流量克隆，支援複制流量到多個不同的後端Elasticsearch叢集，支援流量灰階遷移
- 一鍵重建，優化過的高速重建和增量資料的自動處理，支援新舊索引的透明無縫切換
- 安全傳輸，自動支援TLS/HTTPS，可動态生成前證書，也可指定自簽可信證書
- 精準路由，多種算法的負載均衡模式，索引和查詢可分别配置負載路由政策，動态靈活
- 限速限流，支援索中限速和限流規則，可以實作索引級别的限速，保障後端叢集的穩定性
- 并發控制，支援叢集和節點級别的TCP并發連接配接數控制，保障後端叢集和節點穩定性
- 無單點故障，内置基于虛拟IP的高可用解決方案，雙機熱備，故障自動遷移，避免單點故障
- 請求透視，内置日志和名額監控，可以對Elasticsearch請求做全面的資料分析
6、相關資源
關于如何落地，這裡給大家提供了三個項目。
1、中文社群裡維護的項目Elasticsearch on Kubernetes，如果大家想快速地在Kubernetes上部署Elasticsearch，不管你的平台是什麼樣的，都可以參考這個項目，或者裡面有很多預置的腳本，你可以來實作快速的部署。
2、流式計算平台搭建所在Beam的執行方案，我們在這裡寫了一個Beam的架構代碼，有了這個架構之後，很快就可以把一個非常複雜的流式計算任務或者一個平台搭建起來，真正在做開發的時候隻需要填充中間的業務邏輯和一些相關的代碼就可以了，這是我們建構這個項目的一個目的。
3、最後一個是還在持續完善中的極限網關，歡迎大家去試用，如果大家想知道更多的資訊，歡迎到我們的中文社群裡面來留言。
【
阿裡雲Elastic Stack】100%相容開源ES，獨有9大能力，提供免費 X-pack服務（單節點價值$6000）
相關活動
更多折扣活動，請
通路阿裡雲 Elasticsearch 官網 阿裡雲 Elasticsearch 商業通用版，1核2G ,SSD 20G首月免費 阿裡雲 Logstash 2核4G首月免費 下載下傳白皮書：Elasticsearch 八大經典場景應用