|
關注“大數據雜談”公眾號，點擊“加群學習”，更多大牛一手技術分享等著你。 大家好，非常高興能在這里給大家分享，首先簡單自我介紹一下，我叫曾勇，是Elastic的工程師。 Elastic 將在今年秋季的時候發布一個 Elasticsearch V5.0 的大版本，這次的微信分享將給大家介紹一下 5.0 版里面的一些新的特性和改進。 5.0？ 天啦嚕，你是不是覺得版本跳的太快了。 好吧，先來說說背后的原因吧。 為了未來更好的擴展性:) ELKBS？ELKBSU？..... 所以我們打算將產品線命名為 ElasticStack 同時由于現在的版本比較混亂，每個產品的版本號都不一樣， Elasticsearch和Logstash目前是2.3.4；Kibana是4.5.3；Beats是1.2.3； 版本號太亂了有沒有，什么版本的 ES 用什么版本的 Kibana ？有沒有兼容性問題？ 所以我們打算將這些的產品版本號也統一一下，即 v5.0 ，為什么是 5.0 ，因為 Kibana 都 4.x 了，下個版本就只能是 5.0 了，其他產品就跟著跳躍一把，第一個 5.0 正式版將在今年的秋季發布，目前最新的測試版本是： 5.0 Alpha 4 Elasticsearch5.0新增功能 首先來看看 5.0 里面都引入了哪些新的功能吧。 首先看看跟性能有關的。第一個就是Lucene 6.x 的支持。Elasticsearch5.0率先集成了Lucene6版本，其中最重要的特性就是 Dimensional Point Fields，多維浮點字段，ES里面相關的字段如date, numeric，ip 和 Geospatial 都將大大提升性能。 這么說吧，磁盤空間少一半；索引時間少一半；查詢性能提升25%；IPV6也支持了。 為什么快，底層使用的是Block k-d trees，核心思想是將數字類型編碼成定長的字節數組，對定長的字節數組內容進行編碼排序，然后來構建二叉樹，然后依次遞歸構建，目前底層支持8個維度和最多每個維度16個字節，基本滿足大部分場景。 說了這么多，看圖比較直接。 索引小了之后， merge 的時間也響應的減少了，看下圖： 我們再看看索引性能方面的其他優化。 ES5.0在Internal engine級別移除了用于避免同一文檔并發更新的競爭鎖，帶來15%-20%的性能提升 #18060 。
另一個 和 aggregation 的改進也是非常大， Instant Aggregations。Elasticsearch已經在Shard層面提供了Aggregation緩存，如果你的數據沒有變化，ES能夠直接返回上次的緩存結果， 但是有一個場景比較特殊，就是 date histogram，大家kibana上面的條件是不是經常設置的相對時間，如： from:now-30d to:now，好吧，now是一個變量，每時每刻都在變，所以query條件一直在變，緩存也就是沒有利用起來。 經過一年時間大量的重構，現在可以做到對查詢做到靈活的重寫： 首先，`now`關鍵字最終會被重寫成具體的值； 其次 ， 每個shard會根據自己的數據的范圍來重寫查詢為 `match_all`或者是`match_none`查詢，所以現在的查詢能夠被有效的緩存，并且只有個別數據有變化的Shard才需要重新計算，大大提升查詢速度。 另外再看看和Scroll相關的吧。 現在新增了一個：Sliced Scroll類型 用過Scroll接口吧，很慢？如果你數據量很大，用Scroll遍歷數據那確實是接受不了，現在Scroll接口可以并發來進行數據遍歷了。 每個Scroll請求，可以分成多個Slice請求，可以理解為切片，各Slice獨立并行，利用Scroll重建或者遍歷要快很多倍。 看看這個demo 我們再看看es在查詢優化這塊做的工作。 新增了一個Profile API。#https://www./guide/en/elasticsearch/reference/master/search-profile.html#_usage_3 都說要致富先修路，要調優當然需要先監控啦，elasticsearch在很多層面都提供了stats方便你來監控調優，但是還不夠，其實很多情況下查詢速度慢很大一部分原因是糟糕的查詢引起的，玩過SQL的人都知道，數據庫服務的執行計劃（execution plan）非常有用，可以看到那些查詢走沒走索引和執行時間，用來調優，elasticsearch現在提供了Profile API來進行查詢的優化，只需要在查詢的時候開啟profile：true就可以了，一個查詢執行過程中的每個組件的性能消耗都能收集到。 同時支持search和aggregation的profile。 還有一個和翻頁相關的問題，就是深度分頁 ，是個老大難的問題，因為需要全局排序（ number_of_shards * (from + size) ），所以需要消耗大量內存，以前的 es 沒有限制，有些同學翻到幾千頁發現 es 直接內存溢出掛了，后面 elasticsearch 加上了限制， from+size 不能超過 1w 條，并且如果需要深度翻頁，建議使用 scroll 來做。 但是 scroll 有幾個問題，第一個是沒有順序，直接從底層 segment 進行遍歷讀取，第二個實時性沒法保證， scroll 操作有狀態， es 會維持 scroll 請求的上下文一段時間，超時后才釋放，另外你在 scroll 過程中對索引數據進行了修改了，這個時候 scroll 接口是拿不到的，靈活性較差， 現在有一個新的 Search After 機制，其實和 scroll 類似，也是游標的機制，它的原理是對文檔按照多個字段進行排序，然后利用上一個結果的最后一個文檔作為起始值，拿 size 個文檔，一般我們建議使用 _uid 這個字段，它的值是唯一的 id 。 #（Search After https://github.com/elastic/elasticsearch/blob/148f9af5857f287666aead37f249f204a870ab39/docs/reference/search/request/search-after.asciidoc ） 來看一個Search After 的demo 吧，比較直觀的理解一下： 根據你的排序條件來的，三個排序條件，就傳三個參數。 再看看跟索引與分片管理相關的新功能吧。 新增了一個 Shrink API#https://www./guide/en/elasticsearch/reference/master/indices-shrink-index.html#_shrinking_an_index 相信大家都知道elasticsearch索引的shard數是固定的，設置好了之后不能修改，如果發現shard太多或者太少的問題，之前如果要設置Elasticsearch的分片數，只能在創建索引的時候設置好，并且數據進來了之后就不能進行修改，如果要修改，只能重建索引。 現在有了Shrink接口，它可將分片數進行收縮成它的因數，如之前你是15個分片，你可以收縮成5個或者3個又或者1個，那么我們就可以想象成這樣一種場景，在寫入壓力非常大的收集階段，設置足夠多的索引，充分利用shard的并行寫能力，索引寫完之后收縮成更少的shard，提高查詢性能。 這里是一個API調用的例子 有人肯定會問慢不慢？非常快！ Shrink的過程會借助操作系統的Hardlink進行索引文件的鏈接，這個操作是非常快的，毫秒級Shrink就可收縮完成，當然windows不支持hard link，需要拷貝文件，可能就會很慢了。 再來看另外一個比較有意思的新特性，除了有意思，當然還很強大。 新增了一個Rollover API。https://www./guide/en/elasticsearch/reference/master/indices-rollover-index.html#indices-rollover-index 前面說的這種場景對于日志類的數據非常有用，一般我們按天來對索引進行分割（數據量更大還能進一步拆分），我們以前是在程序里設置一個自動生成索引的模板，大家用過logstash應該就記得有這么一個模板logstash-[YYYY-MM-DD]這樣的模板，現在es5.0里面提供了一個更加簡單的方式：Rollover API API調用方式如下： 新增：Reindex。另外關于索引數據，大家之前經常重建，數據源在各種場景，重建起來很是頭痛，那就不得不說說現在新加的Reindex接口了，Reindex可以直接在Elasticsearch集群里面對數據進行重建，如果你的mapping因為修改而需要重建，又或者索引設置修改需要重建的時候，借助Reindex可以很方便的異步進行重建，并且支持跨集群間的數據遷移。 比如按天創建的索引可以定期重建合并到以月為單位的索引里面去。 當然索引里面要啟用_source。 來看看這個demo吧，重建過程中，還能對數據就行加工。 5.0里面提供了第一個Java原生的REST客戶端SDK，相比之前的TransportClient，版本依賴綁定，集群升級麻煩，不支持跨Java版本的調用等問題，新的基于HTTP協議的客戶端對Elasticsearch的依賴解耦，沒有jar包沖突，提供了集群節點自動發現、日志處理、節點請求失敗自動進行請求輪詢，充分發揮Elasticsearch的高可用能力，并且性能不相上下。 #19055 。 然后我們再看看其他的特性吧： 新增了一個 Wait for refresh 功能。簡單來說相當于是提供了文檔級別的Refresh： https://www./guide/en/elasticsearch/reference/master/docs-refresh.html。 索引操作新增refresh參數，大家知道elasticsearch可以設置refresh時間來保證數據的實時性，refresh時間過于頻繁會造成很大的開銷，太小會造成數據的延時，之前提供了索引層面的_refresh接口，但是這個接口工作在索引層面，我們不建議頻繁去調用，如果你有需要修改了某個文檔，需要客戶端實時可見怎么辦？ 在 5.0中，Index、Bulk、Delete、Update這些數據新增和修改的接口能夠在單個文檔層面進行refresh控制了，有兩種方案可選，一種是創建一個很小的段，然后進行刷新保證可見和消耗一定的開銷，另外一種是請求等待es的定期refresh之后再返回。 調用例子：
# 新增： Ingest Node ##https://www./guide/en/elasticsearch/reference/master/ingest.html# 再一個比較重要的特性就是IngestNode了，大家之前如果需要對數據進行加工，都是在索引之前進行處理，比如logstash可以對日志進行結構化和轉換，現在直接在es就可以處理了，目前es提供了一些常用的諸如convert、grok之類的處理器，在使用的時候，先定義一個pipeline管道，里面設置文檔的加工邏輯，在建索引的時候指定pipeline名稱，那么這個索引就會按照預先定義好的pipeline來處理了； Demo again：
上圖首先創建了一個名為my-pipeline-id的處理管道，然后接下來的索引操作就可以直接使用這個管道來對foo字段進行操作了，上面的例子是設置foo字段為bar值。 上面的還不太酷，我們再來看另外一個例子，現在有這么一條原始的日志，內容如下： { "message": "55.3.244.1 GET /index.html 15824 0.043” } google之后得知其Grok的pattern如下：） %{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration} 那么我們使用Ingest就可以這么定義一個pipeline： 再看看腳本方面的改變 #新增Painless Scripting#還記得Groove腳本的漏洞吧，Groove腳本開啟之后，如果被人誤用可能帶來的漏洞，為什么呢，主要是這些外部的腳本引擎太過于強大，什么都能做，用不好或者設置不當就會引起安全風險，基于安全和性能方面，我們自己開發了一個新的腳本引擎，名字就叫Painless，顧名思義，簡單安全，無痛使用，和Groove的沙盒機制不一樣，Painless使用白名單來限制函數與字段的訪問，針對es的場景來進行優化，只做es數據的操作，更加輕量級，速度要快好幾倍，并且支持Java靜態類型，語法保持Groove類似，還支持Java的lambda表達式。 我們對比一下性能，看下圖 再看看如何使用： def first = input.doc.first_name.0; def last = input.doc.last_name.0; return first + " " + last; 是不是和之前的寫法差不多 或者還可以是強類型（10倍速度于上面的動態類型） String first = (String)((List)((Map)input.get("doc")).get("first_name")).get(0); String last = (String)((List)((Map)input.get("doc")).get("last_name")).get(0); return first + " " + last; 腳本可以在很多地方使用，比如搜索自定義評分；更新時對字段進行加工等 如： 新增：Task Manager這個是5.0 引入任務調度管理機制，用來做 離線任務的管理，比如長時間運行的reindex和update_by_query等都是運行在TaskManager機制之上的，并且任務是可管理的，你可以隨時cancel掉，并且任務狀態持久化，支持故障恢復； 還新增一個： Depreated logging大家在用ES的時候，其實有些接口可能以及打上了Depreated標簽，即廢棄了，在將來的某個版本中就會移除，你當前能用是因為一般廢棄的接口都不會立即移除，給足夠的時間遷移，但是也是需要知道哪些不能用了，要改應用代碼了，所以現在有了Depreated日志，當打開這個日志之后，你調用的接口如果已經是廢棄的接口，就會記錄下日志，那么接下來的事情你就知道你應該怎么做了。 新增 : Cluster allocation explain API『誰能給我一個shard不能分配的理由』，現在有了，大家如果之前遇到過分片不能正常分配的問題，但是不知道是什么原因，只能嘗試手動路由或者重啟節點，但是不一定能解決，其實里面有很多原因，現在提供的這個explain接口就是告訴你目前為什么不能正常分配的原因，方便你去解決。 另外在數據結構這塊，新增 : half_float 類型https://www./guide/en/elasticsearch/reference/master/number.html 只使用 16 位 足夠滿足大部分存儲監控數值類型的場景，支持范圍：2負24次方 到 65504，但是只占用float一半的存儲空間。 Aggregation 新增 : Matrix Stats Aggregation # 18300金融領域非常有用的，可計算多個向量元素協方差矩陣、相關系數矩陣等等 另外一個重要的特性：為索引寫操作添加順序號 # 10708大家知道es是在primary上寫完然后同步寫副本，這些請求都是并發的，雖然可以通過version來控制沖突， 但是沒法保證其他副本的操作順序，通過寫的時候產生順序號，并且在本地也寫入checkpoint來記錄操作點， 這樣在副本恢復的時候也可以知道當前副本的數據位置，而只需要從指定的數據開始恢復就行了，而不是像以前的粗暴的做完整的文件同步 ，另外這些順序號也是持久化的，重啟后也可以快速恢復副本信息，想想以前的大量無用拷貝吧和來回倒騰數據吧。 Elasticsearch5.0其他方面的改進 我們再看看 mapping 這塊的改進 吧。 引入新的字段類型 Text/Keyword 來替換 String以前的string類型被分成Text和Keyword兩種類型，keyword類型的數據只能完全匹配，適合那些不需要分詞的數據， 對過濾、聚合非常友好，text當然就是全文檢索需要分詞的字段類型了。將類型分開的好處就是使用起來更加簡單清晰，以前需要設置analyzer和index，并且有很多都是自定義的分詞器，從名稱根本看不出來到底分詞沒有，用起來很麻煩。 另外string類型暫時還在的，6.0會移除。 還有關于 Index Settings 的改進Elasticsearch的配置實在太多，在以前的版本間，還移除過很多無用的配置，經常弄錯有沒有？ 現在，配置驗證更加嚴格和保證原子性，如果其中一項失敗，那個整個都會更新請求都會失敗，不會一半成功一半失敗。下面主要說兩點： 1.設置可以重設會默認值，只需要設置為 `null`即可 2.獲取設置接口新增參數`?include_defaults`,可以直接返回所有設置和默認值 集群處理的改進 : Deleted Index Tombstones在以前的es版本中，如果你的舊節點包含了部分索引數據，但是這個索引可能后面都已經刪掉了，你啟動這個節點之后，會把索引重新加到集群中，是不是覺得有點陰魂不散，現在es5.0會在集群狀態信息里面保留500個刪除的索引信息，所以如果發現這個索引是已經刪除過的就會自動清理，不會再重復加進來了。 文檔對象的改進 : 字段名重新支持英文句號，再 2.0 的時候移除過 dot 在字段名中的支持，現在問題解決了，又重新支持了。 es會認為下面兩個文檔的內容一樣：
Cluster state 的修改現在會和所有節點進行 ack 確認。 Shard 的一個副本如果失敗了， Primary 標記失敗的時候會和 Master 節點確認完畢再返回。 使用 UUID 來作為索引的物理的路徑名，有很多好處，避免命名的沖突。 _timestamp 和 _ttl 已經移除，需要在 Ingest 或者程序端處理。 ES 可直接用 HDFS 來進行備份還原（ Snapshot/Restore ）了 #15191 。 Delete-by-query 和 Update-by-query 重新回到 core ，以前是插件，現在可以直接使用了，也是構建在 Reindex 機制之上。 HTTP 請求默認支持壓縮，當然 http 調用端需要在 header 信息里面傳對應的支持信息。 創建索引不會再讓集群變紅了，不會因為這個卡死集群了。 默認使用 BM25 評分算法，效果更佳，之前是 TF/IDF。 快照 Snapshots 添加 UUID 解決沖突 #18156 。 限制索引請求大小，避免大量并發請求壓垮 ES #16011。 限制單個請求的 shards 數量，默認 1000 個 #17396。 移除 site plugins ，就是說 head 、 bigdesk 都不能直接裝 es 里面了，不過可以部署獨立站點（反正都是靜態文件）或開發 kibana 插件 #16038 。 允許現有 parent 類型新增 child 類型 #17956。 這個功能對于使用parent-child特性的人應該非常有用。 支持分號（；）來分割 url 參數，與符號（ & ）一樣 #18175 。 比如下面這個例子： curl http://localhost:9200/_cluster/health?level=indices;pretty=true 好吧，貌似很多，其實上面說的還只是眾多特性和改進的一部分， es5.0 做了非常非常多工作，本來還打算講講 bug 修復的，但是太多了，時間有限， 一些重要的 bug 在 2.x 都已經第一時間解決了，大家可以查看下面的鏈接了解更多更詳細的更新日志： https://www./guide/en/elasticsearch/reference/master/release-notes-5.0.0-alpha1-2x.html https://www./guide/en/elasticsearch/reference/master/release-notes-5.0.0-alpha1.html https://www./guide/en/elasticsearch/reference/master/release-notes-5.0.0-alpha2.html https://www./guide/en/elasticsearch/reference/master/release-notes-5.0.0-alpha3.html https://www./guide/en/elasticsearch/reference/master/release-notes-5.0.0-alpha4.html 下載體驗最新的版本 ： https://www./v5 升級向導：https://github.com/elastic/elasticsearch-migration/blob/2.x/README.asciidoc 如果有 es 相關的問題也歡迎前往 Elastic 中文社區 ： http:// 進行交流和討論， 可以加我微信單獨探討，也歡迎上 發帖討論，謝謝大家。 Q&A Q1： 是否有用es做hbase的二級索引的 A1： 這種案例說實話比較少，因為成本比較高，在兩套分布式系統里面做結合，并且要滿足足夠的性能，有點難度，不建議這樣去做。 Q2： 批量更新數據會出現少量數據更新不成功 A2： 這個首先要看少量失敗的原因是什么，es的返回信息里面會包含具體的信息，如果json格式不合法也是會失敗的。 Q3： ik插件有沒有計劃支持同義詞，專有名詞熱更新？對于詞庫更新比較頻繁的應用場景，只能采取全部重新建立索引的方式嗎？ A3： 同義詞有單獨的filter，可以和ik結合一起使用的，關于熱更新這個確實是需要重建，詞庫變化之后，分詞產生的term不一樣了，不重建的話，倒排很可能匹配不上，查詢會失敗。 Q4： 老師，你好，我有個問題想咨詢一下，我們原來的商品基本數據，商品評價數據，收藏量這些都在mysql里，但我們現在想上es，我們想把商品的基本數據放es，收藏、評價這些實時數據，還是放mysql，但做排序功能的時候，會參考一個商品的收藏量，評價量，這時候在還涉及數據分頁的情況下，怎么結合es和mysql的數據進行排序呢？ A4： 這個問題得具體看業務場景，如果更新頻繁，但是還在es承受能力范圍和業務響應指標內，可以直接放es里面，在es里面做排序，如果太大，建議放外部存儲，外部存儲和es的結合方式又有很多種，收藏評價是否真的需要那么實時？另外es的評分機制是可以擴展的，在評分階段使用自定義插件讀取外部數據源，進行混合打分也是可行的。 Q5： 現在大agg查詢可以cancel嗎? A5： 現在還不能。 Q6： 有考慮提供sql語法查詢嗎？ A6： 目前暫時還沒計劃。 Q7： 128g內存的機器，官方建議機器上放兩個es實例，目前也是推薦這樣做嗎? A7： 這個其實看場景的，單臺機器上面的索引比較大的話，建議多留一點給操作系統來做緩存，多個實例可以提供足夠吞吐。 Q8： 請問用于計算unique count的算法有變化嗎？ A8： 有的，elasticsearch里面叫cardinality。這里有篇文章：https://www./blog/count-elasticsearch。 Q9： 請問在es5中，每個服務器有256G內存，那每個服務器帶的存儲多少比較合適？是24T，48T還是可以更多？ A9： 這個看場景啦，有超過48T的。 Q10： 請問下Elastic Stack是只要安裝一次這個就行，還是要像原來elk一樣，分別安裝不同的組件？ A10： 安裝方式和之前一樣的. Q11： 請問es中的如何做到按某個字段去重？具體問題是這樣的，我們有一個文章索引，其中有2億數據量，每次搜索的結果總是存在大量重復的title，我們希望在查詢時能根據title進行去重。也就是Field Collapsing特性，官方有一個通過terms aggregation進行去重的方案，但效果不是很理想，仍然會有很多重復，我們希望哪怕是按title嚴格相等來去重也可以接受。 另外我們有一個通過simhash來去重的思路，就是計算title的simhash，一并存入索引，在搜索階段通過simhash計算相似性，但這需要全量重新計算，數據量太大。所以還是希望能在不動現有索引的情況下，通過某種技巧，實現這個功能。 A11： 直接去重，這個目前沒有比較好的方案，不過很多變通的做法，首先你的場景需要確認，title重復是不是不允許的，如果是，那么建索引的時候就可以hash掉作為主鍵，這樣就不會有重復的了，如果你覺得原始數據也要，那么索引階段產生一個獨立的去除title的索引，來做join，當然還是要看你業務的場景具體研究。 Q12： 硬件受 限的情況下，清理過期數據的策略。 A12： 如果你的數據結構固定，結合5.0的Rollover接口，估計能夠承載的最大索引量，定期檢測刪索引就行了。 講師介紹：曾勇(Medcl), Elastic開發工程師與技術布道師。曾勇是Elasticsearch國內首批用戶，自2010年起就開始接觸Elasticsearch并投入到生產環境中使用，并編寫過一系列的中文處理相關的插件，是Elasticsearch中文社區發起人，籌辦了一系列線上線下的Elasticsearch技術分享與交流活動，出于對Elasticsearch的喜愛，目前已全職加入Elasticsearch項目背后的Elastic公司。微信號：medcl123。 |
|
|
相信大家都聽說 ELK 吧，是 Elasticsearch 、 Logstash 、 Kibana 三個產品的首字母縮寫，現在 Elastic 又新增了一個新的開源項目成員： Beats。 
有人建議以后這么叫： ELKB ？
目前各團隊正在緊張的開發測試中，每天都有新的功能和改進，本次分享主要介紹一下 Elasticsearch 的主要變化。
圖中從 2015 /10/32 total bytes 飆升是因為 es 啟用了 docvalues ，我們關注紅線，最近的引入新的數據結構之后，紅色的索引大小只有原來的一半大小。
相應的 Java 堆內存占用只原來的一半： 
再看看 索引的性能 ，也是飆升： 
當然 Lucene6 里面還有很多優化和改進，這里沒有一一列舉。
以上截圖來自 ES 的每日持續性能監控： https://benchmarks./index.html
可以看到兩個 scroll 請求， id 分別是 0 和 1 ， max 是最大可支持的并行任務，可以各自獨立進行數據的遍歷獲取。
