天天看點

業務資料遷移至ES方案3      關鍵設計

1.1 目的

Elasticsearch是一個基于Lucene的實時分布式的搜尋與分析引擎,是目前主流的企業級搜尋引擎。提供了一個分布式服務,可以快速的近乎于準實時的存儲、查詢和分析超大資料集,可以快速的檢索并提升使用者的檢索體驗。

2.1 技術架構

業務資料遷移至ES方案3      關鍵設計

ES資料操作

黑-1/黑-2:  前端/業務中心通過ES-SDK插件對ES表對像進行CRUD操作

PorlarDB到ES資料同步

Ø  藍-1/藍-2部分: 通用方案通過edas上的dts元件針對單表或簡單join表從porlardb同步全量或是增量資料至ES,以供業務側查詢,全量同步擇時進行,會影響業務,增量準時間處理。

Ø  紅-1/紅-2部分: 寬表方案,業務中心如需使用寬表,則在porlardb中建立和es中同結構的寬表,業務中心自身訂閱binlog日志,通過binlog日志觸發生成相應的資料至對應的寬表中,DTS元件配置對該寬表的增量同步至ES

Ø  紅-1/紅-3:  非寬表方案,業務中心定時或自身訂閱binlog日志,直接生成相應的資料吐至ES中(按實際的增量業務量可以業務中心和porlardb之間追加kafka解耦)

2.2 管理功能

ES運維: 

https://help.aliyun.com/document_detail/90391.html?spm=a2c4g.11186623.6.665.57572ff7FnTKQ7

EDAS内元件ES本身提供了較多的管理運維功能,如下圖,針對ES的運維功能通過EDAS的ES控制台操作

業務資料遷移至ES方案3      關鍵設計
業務資料遷移至ES方案3      關鍵設計

ES元件叢集示例圖

業務資料遷移至ES方案3      關鍵設計

資料入ES後,可能過ES自帶的查詢工具kibana作檢索查詢

業務資料遷移至ES方案3      關鍵設計

2.3 部署架構

業務資料遷移至ES方案3      關鍵設計

2.3.1      ES叢集規格評估

   ES預設的主分片數為5個,副本數為1個,是以如ES跨3個可用區部署中,當其中一個可用區或兩個可用區不可用時,剩下的可用區需要繼續提供服務,是以索引的副本個數至少為2

阿裡雲ES的單機規格在一定程度上限制了叢集的能力,本文根據測試結果和使用經驗給出如下建議:

  • 叢集最大節點數:

    叢集最大節點數 = 單節點CPU * 5

  • 單節點最大資料量。

使用場景不同,單節點最大承載資料量也會不同,具體如下:

    • 資料加速、查詢聚合等場景:

      單節點最大資料量 = 單節點存儲空間(G) * 10

    • 日志寫入、離線分析等場景:

      單節點最大資料量 = 單節點存儲空間(G) * 50

    • 通常情況:

      單節點最大資料量 = 單節點存儲空間(G) * 30

叢集規格參考清單如下。

規格 最大節點數 單節點最大磁盤(查詢) 單節點最大磁盤(日志) 單節點最大磁盤(通常)
2核4G 10 40 GB 200 GB 100 GB
2核8G 80 GB 400 GB
4核16G 20 160 GB 800 GB 512 GB
8核32G 40 320 GB 1.5 TB 1 TB
16核64G 50 640 GB 2 TB

2.3.2      Shard評估

ES 6.x版本的索引預設包含5個主shard,1個副shard;

基于以上問題,下文對shard規劃提供了一些建議。這些建議僅供參考,實際業務中還需根據需求進行調整:

  • 建議在配置設定shard前,對ES進行資料測試。當資料量很大時,要減少寫入量的大小,降低ES壓力,建議選擇多主1個副本;當資料量較小,且寫入量也比較小時,建議使用單主多副本或者單主一副本。
  • 建議一個shard的存儲量保持在30G以内(最優),特殊情況下,可以提升到50G以内。如果評估結果超過該容量,建議在建立索引之前,合理進行shard配置設定,後期進行reindex,雖然能保證不停機,但是比較耗時。

說明對于評估資料量低于30GB的業務,也可以使用1主多備的政策進行負載均衡。例如20GB的單索引,在5個資料節點中,可以考慮1主4副本的shard規劃。

  • 對于日志分析或者超大索引場景,建議單個shard大小不要超過100GB。
  • 建議shard的個數(包括副本)要盡可能等于資料節點數,或者是資料節點數的整數倍。

說明主分片不是越多越好,因為主分片越多,ES性能開銷也會越大。

  • 建議單個節點上同一索引的shard個數不要超5個。
  • 建議單個節點上全部索引的shard的數量不要超過100個(可以提升ES的性能開銷)。
  • 建議按照1:5的比例添加獨立的協調節點(2個起),CPU:Memory為1:4或1:8。例如10個8核32G的資料節點,建議配置2個8核32G的獨立協調節點。

3      關鍵設計

3.1 關聯查詢設計

大原則: 設計時盡可能使用扁平的文檔模型

3.1.1      應用層做關聯

資料歸屬于不同的索引中,從某一索引中查詢出關聯字端後從其它索引繼續查詢出相關資料,應用層對多個索引中查詢出來資料作整合,适用于查詢出資料量較小的情況,結構相對清晰,但要多次查詢

3.1.2      ES中寬表化處理

按業務需求整合porlardb中多表中的關鍵字段整合成寬表存儲至ES中,在ES中查詢即不需要關聯查詢,但需要前期資料整合處理

3.1.3      嵌套對象(nested)

Ø  備援度大,查詢隻能傳回符合條件的整個文檔,不能部分傳回嵌套文檔中的資料,但查詢時無需關聯操作

       注意點:

u  單個索引中最大允許擁有50個nested類型的資料。

u  單個文檔中所有nested類型json對象資料的總量是10000。

3.1.4      Join文檔存儲

Ø  每個索引隻允許一個Join類型Mapping定義,父文檔和子文檔必須在同一個分片上編入索引,當進行删除、更新、查找子文檔時候需要提供相同的路由值。

Ø  一個文檔可以有多個子文檔,但隻能有一個父文檔。

Ø  可以為已經存在的Join類型添加新的關系,當一個文檔已經成為父文檔後,可以為該文檔添加子文檔。

Ø  一個索引中隻能有一個join類型字段,join 類型可以是一種父文檔對應多種子文檔,子文檔可以作為父文檔,關聯關系需在導入資料前提前建立并确認正确

Eg:  "info": {

         "type": "join",

         "relations": {

           "one": ["two-1","two-2"],

           " two-1": " three-1"

         }

       }

Ø  子文檔資料量要明顯多于父文檔的資料量,存在1 對多量的關系,子文檔更新頻繁的場景

u  索引時,主分片的數量一經定義就不能改變

u  routing是一個可變值,預設是文檔的_id

3.1.5      Nested與Join簡單比對

對比 Nested Json
優點 文檔獨立存儲,讀取性能高 父子文檔可以獨立更新,互不影響
缺點 更新父或子文檔時要更新整個文檔 為維護join關系,要占用部分記憶體,讀取性能較差
應用場景 子文檔偶爾更新,查詢頻繁 子文檔更新頻繁

3.2 資料同步 參考

3.2.1      阿裡雲元件

3.2.1.1     DTS同步(binlogs準時實同步-單表操作)

因目前DTS不支援DRDS(Porlardb)直接同步到ElasticSearch,因為同步會配置各個分庫分表的資料分别同步到ES的同一個type下作歸集。

業務組如需選用DTS則送出各分庫賬号,分庫表名至DBA側統一添加

        注: DTS同步不會作下劃線和駝峰的轉換,是以如資料庫表中字段是以下劃線區分,同步至ES中字段名仍是下劃線,如果讀取的實體類字段名為駝峰,可添加注解作轉換,但存資料時仍和實體字段名一緻,可能會存在不一緻情況,如資料入ES有多個源: DTS,Dataworks,業務代碼,注意保持三者字段名是一緻的。

3.2.1.2     DataWorks同步(定時任務最小五分鐘-單表操作)

需有更新SQL控制,局限性:

Ø  表中需要有modify字段為更改時間戳,包括新增、更新、删除(邏輯删除)

Ø  非準實時(觸發機制非binlog方式)

DRDS-Reader:

https://help.aliyun.com/knowledge_detail/74310.html?spm=a2c4g.11186631.2.1.48974c072XoEBC

ElasticSearch-Write:

https://help.aliyun.com/knowledge_detail/74362.html?spm=a2c4g.11186631.2.18.3a474c0782SNCw

樣例及說明

 略

3.2.2      開源元件

3.2.2.1     Canal/Canal adapter

https://github.com/alibaba/canal/tree/master/client-adapter

該方案的優點  

1、 可支援并發,github源碼友善調整,支援sql條件導出,并有對應的es6,es7版本,友善版本适配

該方案的缺點

1、  相關功能需依據具體的遷入表結構作更詳細的功能驗證,如相關遷入表對應的分詞,查詢建議名段等

2、  插件分頁邏輯需調整優化下,目前代碼内部直接是limit分頁,改動量小

簡單驗證(550萬記錄數),調整插件的分頁邏輯後大概可以提高百分之十五速度

原方式:sql + " LIMIT " + offset + "," + size;

調整後方式: SELECT * FROM xxx WHERE ID > =(select id from xxx limit 1000000, 1) limit 20;

3.2.2.2     logstash

Logstash是es元件套餐中用來同步資料的,本身支援全量的從mysql同步至es

該方案的優點:

1、 本身和es屬同一家産品,與es無縫對接

2、 支援SQL方式指定同步資料

3.2.2.3     datax

該方案的優點

1、 執行效率高,可支援并發

1、 目前并不支援es6.0版本以上的寫入,需添加相關的插件支援

方案建議

選擇方案一/方案二,基于方案一主要是元件方式,需在阿裡雲上購買