音頻位址：
http://m.ximalaya.com/111156131/sound/89571047主持人：Elastic 技術布道師，曾勇（Medcl）。
嘉賓：
1、吳曉剛（Wood大叔），攜程技術保障部系統研發總監， Elasticsearch 國内早期實踐者，中文社群活躍使用者。 曾在 eBay, Morgan Stanley, PPTV 等國内外公司從事系統軟體研發、系統內建與技術支援工作。對于大規模 IT 系統的運維自動化、可視化、性能優化具有濃厚的興趣。在技術方面一直抱有知其然知其是以然的态度。
2、胡航，攜程旅行網進階技術經理，負責相關搜尋實作、SOA服務的開發。曾供職于騰訊、盛大等公司，對新技術持有強烈的好奇心，目前關注于 Elasticsearch 的業務實作、JVM 性能優化等。
1、攜程Elasticsearch使用曆史
1.1 運維組Wood大叔：
2014年，ES0.9版本。
選型對比：MongoDB——資料量級大了以後，出現性能瓶頸。
調研後，選型：ELK（Elasticsearch、Logstash、Kibana）。
實作效果：實時看效果、查詢、聚合。
1.2 胡航業務組：
業務場景：酒店價格。
選型依據：ES分布式、可調試性能好。
版本：ES2.3。
時間：2017年中，逐漸轉向ES，5.3版本。
效果：顯著。專注于後端開發，業務交由業務團隊自己去做。
2、攜程Elasticsearch規模
2.1 運維組Wood大叔：
叢集：94個。最小三個節點，最大：360+節點。
節點：700+。
每日增量：1600億條。
峰值：300W/s。
總資料量：2.5萬億，PB數量級。
面對挑戰：
1）實時寫入。
2）業務流程相關，幾個月-2年的曆史資料。
2.2 胡航業務組：
業務場景：3叢集，每叢集6個節點。
單個索引：最大1000W-2000W。
關注：ES基礎架構，幫業務部分實作寫入、查詢、DSL調優。
查詢：3000-4000/s。
攜程ES規模量全國數一數二，有很大挑戰。
3、攜程Elasticsearch淌過的坑
3.1 運維組Wood大叔：
3.1.1 痛點1：記憶體溢出。
原因：早期版本，對查詢限制做的不充分；資料量上了規模，查詢、聚合會非常耗記憶體。
更新版本後，ES做了很多處理，叢集層面做了限制。越來越穩定。
3.1.2 痛點2：叢集故障無法恢複。
3.1.3 痛點3：translog做不完。
3.1.4 痛點4：叢集的平台化管理。
需要：研究底層工作機制，找到規避方法。
經驗豐富後，運維效率提升。
3.2胡航業務組：
3.2.1 痛點1：ES基礎不熟悉帶來的問題；
3.2.2 痛點2：性能問題——最終排查是ES5.X keyword類型的原因。
4、架構
4.1運維組Wood大叔：
1、早期：ELK+redis（中間緩存）
挑戰：
1）redis承受能力差。
2）redis單線程。
改善：
1）redis改為kafka（磁盤級别），資料暢通了。
2）Logstash記憶體消耗大。——改為：logstash forward，推薦官方Beats。
3）資料規模後，需要很多伺服器，Logstash非常耗記憶體。
優化：用golang開發了一個gohangout (https://github.com/childe/gohangout ) ，
記憶體比java 版的hangout(https://github.com/childe/hangout) 記憶體大幅降低。
4.2 胡航搜尋業務組：
1）單點叢集壓力瓶頸。
改為：業務資料導入ES，提供定制用戶端。
2）搜尋平台，接入更多業務需求。
不友善在kibana做定制開發，自己做了簡單網站查詢資料、監控，滿足業務的貼切需求。
5、ES6.3最新特性（搶先看）
5.1 ES6.3 支援Sql接口
Wood大叔：
kibana看DSL，拷貝後修改。新使用者不熟悉，會不友善。
BI部分也需要，類似sql的查詢。
優點：更簡單，發揮更大的作用。
攜程BI部門——應用場景：搜尋的關鍵詞、 統計熱詞，目的地等資訊。
Kibana滿足不了需求，就要寫代碼。如果有了sql，會非常快的開發。
胡航搜尋業務組：
寫DSL，還是稍微複雜。借助 NLPChina ElasticsearchSql插件實作。
實際應用發現插件還是有問題，期待ES官方推出Sql查詢。
5.2 增加kibana豐富表現力
5.3 更快的索引速度
refresh優化：提升吞吐。
6、ELK Stack最喜歡的特性
豐富的擴充能力，使用者不必關心底層的實作。通過伺服器增加節點，友善大資料量查詢。
胡航：
ES可視化、可調試特性。
舉例：
1）出現問題排查DSL是不是合适？Mapping是不是合适？
2）相信ES的社群，不必關心底層，更多的時間做業務（解放雙手）。
3）ES中做好資料模型，實作業務需求。
7、ELK Stack最需要完善的
1）叢集的保護待更進一步完善
資料丢失後的處理？
節點損毀後的處理？
目的：減輕運維的負擔；
2）甄别壞查詢，Slow log存在缺陷。
很難判定真正故障是哪個慢查詢。
叢集發下故障的時候，有API實時分析會更好（比單純查slow log）。
1）ES坑還很多，比較耗費時間。
2）期待社群對常見問題整理。
3）期待官方總結完善的向導，類似：Cookbook。
初級上手的話可以參考借鑒（大家缺乏經驗）
8、初學者的建議
1）初學者必讀——《Elasticsearch: 權威指南》（英文、中文）
WOOD大叔至少看了3遍。
2）不斷的實踐。
3）帶着問題，再去找文檔，建構知識體系。
4）多參與社群，嘗試了解和解決社群問題，不斷學習，以提升自己。
互幫互助，共同成長！
5）中文社群的小建議：問題精華版收集——新手通讀，學習前人經驗。
9、如何看待Elasticsearch在國内的發展？
1）參與和貢獻，國内做的不足；
2）中文分詞插件等，如：分詞品質要求高，專業語義搜尋支援（提高搜尋相關性等）、情感标注、NLP等。
3）在中文應用場景應用更加豐富。
4）社群問題比較分散，社群需要意見領袖，加強某領域讨論、深入交流等。
5）medcl：ElasticTips成立，大家都去參與，以圖檔形式分享。
6) 社群還會做更多的事情，大家多分享、互相交流。
10、小結
非常震驚，wood大叔看了3遍《Elasticsearch: 權威指南》，我們沒有理由不努力。
共勉，加油！
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)