Day82_ELK（一）
ElasticSearch
1、搜索的介紹
搜索是指搜尋檢索，指代使用一定手段來檢索到我們自己需要的信息，包括從文件當中檢索，百度當中檢索，網站內部搜索等等
2、全文檢索的介紹
1、全文檢索的需求介紹
首先我們談幾個公司，如雷貫耳的：百度、谷歌、維基百科；這些公司都有一個相似性就是門戶網站，可以提供我們通過關鍵字搜索，然后快速的檢索出我們想要的信息；
【網頁百度展示】
比如我們檢索優就業，百度后臺就會按照這個關鍵字進行查找（里面有搜索庫，以及爬蟲庫），然后按照權重來進行從上到下的排序，給我們高亮的展示出現
【京東或者淘寶展示】
隨便搜索東西，就會高精度的展示我們想要的；就會根據關鍵詞進行海量數據的快速的檢索
比如我們查找：”護手霜“ ， 那么這期間內部會經過大體的：1、分詞（護手，手霜，護等）2、根據這些詞去海量的數據中檢索 3、然后根據權重把檢索出來的信息進行排序展示給我們
【傳統做法】
那么對于一般的公司，初期是沒有那么多數據的，所以很多公司更傾向于使用傳統的數據庫：mysql；比如我們要查找關鍵字”優就業“，那么查詢的方式大概就是:select * from table where field like ‘%優就業%’; 但是隨著業務發展，數據會不斷的膨脹，那么問題就來了；mysql單表查詢能力即便經過了優化，它的極限也就是400W左右的數據量。而且還會經常出現查詢超時的現象；
然后很多公司開始對數據庫進行橫向和縱向的擴容，開始進行數據庫表的“拆分”：橫向拆分和縱向拆分；但是即便這樣操作，仍然會出現很多問題，比如：
1、數據庫會出現單點故障問題，于是先天主從復制關系，于是增加了運維成本
2、因為對表的拆分，增加了后期維護的難度，同樣也是增加了運維成本
3、即便做了大量的維護，但對于大數據的檢索操作，依然很慢，完全達不到期望值
于是出現了lucene，全文檢索的工具。但是lucene對外暴露出的可用接口對于開發人員來說，操作是非常的復雜，而且沒有效率的；于是在lucene的基礎上進一步的封裝，有了一個叫做solr的高性能分布式檢索服務框架，但是，solr有一個致命的缺點就是：在建立索引期間，solr的搜索能力會極度下降，這就在一定程度上造成了solr在實時索引上效率并不高；
最后，出現了一個叫做elasticsearch的框架，同樣是以lucene為基礎，并且吸收了前兩代的教訓而開發出的分布式多用戶能力的全文搜索引擎，elasticsearch是基于RESTful web接口進行發布的，那么這就意味著，我們開發人員操作起來更方便快捷；同時es拓展節點方便，可用于存儲和檢索海量數據，接近實時搜索能力，自動發現節點、副本機制保障可用性
2、非結構化數據查找方法
1：順序掃描法(Serial Scanning)?
所謂順序掃描，比如要找內容包含某一個字符串的文件，就是一個文檔一個文檔的看，對于每一個文檔，從頭看到尾，如果此文檔包含此字符串，則此文檔為我們要找的文件，接著看下一個文件，直到掃描完所有的文件。如利用windows的搜索也可以搜索文件內容，只是相當的慢。
2：全文檢索(Full-text Search)?
將非結構化數據中的一部分信息提取出來，重新組織，使其變得有一定結構，然后對此有一定結構的數據進行搜索，從而達到搜索相對較快的目的。這部分從非結構化數據中提取出的然后重新組織的信息，我們稱之索引。?
例如：字典。字典的拼音表和部首檢字表就相當于字典的索引，對每一個字的解釋是非結構化的，如果字典沒有音節表和部首檢字表，在茫茫辭海中找一個字只能順序掃描。然而字的某些信息可以提取出來進行結構化處理，比如讀音，就比較結構化，分聲母和韻母，分別只有幾種可以一一列舉，于是將讀音拿出來按一定的順序排列，每一項讀音都指向此字的詳細解釋的頁數。我們搜索時按結構化的拼音搜到讀音，然后按其指向的頁數，便可找到我們的非結構化數據——也即對字的解釋。?
這種先建立索引，再對索引進行搜索的過程就叫全文檢索(Full-text Search)。?
雖然創建索引的過程也是非常耗時的，但是索引一旦創建就可以多次使用，全文檢索主要處理的是查詢，所以耗時間創建索引是值得的。
3、如何實現全文檢索
可以使用Lucene實現全文檢索。Lucene是apache下的一個開放源代碼的全文檢索引擎工具包（提供了Jar包，實現全文檢索的類庫）。它提供了完整的查詢引擎和索引引擎，部分文本分析引擎。Lucene的目的是為軟件開發人員提供一個簡單易用的工具包，以方便地在目標系統中實現全文檢索的功能。?
注意：Lucene只是一個引擎，只是一個工具包，如果使用Lucene開發全文檢索功能，要記住Lucene是不能單獨運行的。
4、lucene實現全文檢索流程
1. 綠色表示索引過程，對要搜索的原始內容進行索引構建一個索引庫，索引過程包括：確定原始內容即要搜索的內容→采集文檔→創建文檔→分析文檔→索引文檔。?
2. 紅色表示搜索過程，從索引庫中搜索內容，搜索過程包括：用戶通過搜索界面→創建查詢→執行搜索，從索引庫搜索→渲染搜索結果。
從上面了解到的知識點也可看出，索引和搜索流程圖也可表示為：
?
總結：全文檢索過程分為索引、搜索兩個過程：
- 索引?
- 從關系數據庫中、互聯網上、文件系統采集源數據(要搜索的目標信息)，源數據的來源是很廣泛的。
- 將源數據采集到一個統一的地方，要創建索引，將索引創建到一個索引庫（文件系統）中，從源數據庫中提取關鍵信息，從關鍵信息中抽取一個一個詞，詞和源數據是有關聯的。也即創建索引時，詞和源數據有關聯，索引庫中記錄了這個關聯，如果找到了詞就說明找到了源數據（http的網頁、pdf電子書等……）。
- 搜索?
- 用戶執行搜索（全文檢索）編寫查詢關鍵字。
- 從索引庫中搜索索引，根據查詢關鍵字搜索索引庫中的一個一個詞。
- 展示搜索的結果。
5、全文檢索框架介紹
市面上全文檢索的框架很多，較早期的一個框架就是lucene，基本上所有的全文檢索的工作都交給lucene來實現，但是lucene最大的弊端就是API太原生，沒有經過任何封裝，不太好使用。所以后來出現一個叫做solr的框架，它也是基于lucene進行改造封裝和包裝，將服務端單獨提取出來，客戶端進行請求即可。
另外一個框架就是大名鼎鼎的elasticsearch了，es也是一個基于lucene打造的全文檢索的框架，且一經推出就迅速被市場認可，市場占有率越來越多，現在首選的全文檢索的框架基本就是ES了
3、ELK日志協議棧
1、ELK協議棧基本介紹
1、集中式日志系統
日志，對于任何系統來說都是及其重要的組成部分。在計算機系統里面，更是如此。但是由于現在的計算機系統大多比較復雜，很多系統都不是在一個地方，甚至都是跨國界的；即使是在一個地方的系統，也有不同的來源，比如，操作系統，應用服務，業務邏輯等等。他們都在不停產生各種各樣的日志數據。根據不完全統計，我們全球每天大約要產生 2EB的數據。
面對如此海量的數據，又是分布在各個不同地方，如果我們需要去查找一些重要的信息，難道還是使用傳統的方法，去登陸到一臺臺機器上查看？看來傳統的工具和方法已經顯得非常笨拙和低效了。于是，一些聰明人就提出了建立一套集中式的方法，把不同來源的數據集中整合到一個地方。
一個完整的集中式日志系統，是離不開以下幾個主要特點的。
- 收集－能夠采集多種來源的日志數據
- 傳輸－能夠穩定的把日志數據傳輸到中央系統
- 存儲－如何存儲日志數據
- 分析－可以支持 UI 分析
- 警告－能夠提供錯誤報告，監控機制
2、ELK 協議棧介紹及體系結構
ELK 其實并不是一款軟件，而是一整套解決方案，是三個軟件產品的首字母縮寫，Elasticsearch，Logstash 和 Kibana。這三款軟件都是開源軟件，通常是配合使用，而且又先后歸于 Elastic.co 公司名下，故被簡稱為 ELK 協議棧。
- Elasticsearch
-
- 實時分析
- 分布式實時文件存儲，并將每一個字段都編入索引
- 文檔導向，所有的對象全部是文檔
- 高可用性，易擴展，支持集群（Cluster）、分片和復制（Shards 和 Replicas）。
- 接口友好，支持 JSON
- Logstash
-
- 幾乎可以訪問任何數據
- 可以和多種外部應用結合
- 支持彈性擴展
-
- Shipper－發送日志數據
- Broker－收集數據，缺省內置 Redis
- Indexer－數據寫入
- Kibana
?3、Elk整體架構
?
4、參考文檔
ELK官網：https://www.elastic.co/
ELK官網文檔：https://www.elastic.co/guide/index.html
ELK中文手冊：https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html
ELK中文社區：https://elasticsearch.cn/
4、Elasticsearch介紹
1、什么是ElasticSearch
Elaticsearch，簡稱為es， es是一個開源的高擴展的分布式全文檢索引擎，它可以近乎實時的存儲、檢索數據；本身擴展性很好，可以擴展到上百臺服務器，處理PB級別的數據。es也使用Java開發并使用Lucene作為其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的復雜性，從而讓全文搜索變得簡單。
2、ElasticSearch使用案例
- 2013年初，GitHub拋棄了Solr，采取ElasticSearch 來做PB級的搜索。 “GitHub使用ElasticSearch搜索20TB的數據，包括13億文件和1300億行代碼”
- 維基百科：啟動以elasticsearch為基礎的核心搜索架構
- SoundCloud：“SoundCloud使用ElasticSearch為1.8億用戶提供即時而精準的音樂搜索服務”
- 百度：百度目前廣泛使用ElasticSearch作為文本數據分析，采集百度所有服務器上的各類指標數據及用戶自定義數據，通過對各種數據進行多維分析展示，輔助定位分析實例異常或業務層面異常。目前覆蓋百度內部20多個業務線（包括casio、云分析、網盟、預測、文庫、直達號、錢包、風控等），單集群最大100臺機器，200個ES節點，每天導入30TB+數據
- 新浪使用ES 分析處理32億條實時日志
- 阿里使用ES 構建挖掘自己的日志采集和分析體系
3、ElasticSearch對比Solr
- Solr 利用 Zookeeper 進行分布式管理，而 Elasticsearch 自身帶有分布式協調管理功能;
- Solr 支持更多格式的數據，而 Elasticsearch 僅支持json文件格式；
- Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高級功能多由第三方插件提供；
- Solr 在傳統的搜索應用中表現好于 Elasticsearch，但在處理實時搜索應用時效率明顯低于 Elasticsearch
4、ElasticSearch架構圖以及基本概念(術語)
1、es概述
Elasticsearch是面向文檔(document oriented)的，這意味著它可以存儲整個對象或文檔(document)。然而它不僅僅是存儲，還會索引(index)每個文檔的內容使之可以被搜索。在Elasticsearch中，你可以對文檔（而非成行成列的數據）進行索引、搜索、排序、過濾。
Elasticsearch比傳統關系型數據庫如下：
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices?? -> Types? -> Documents -> Fields
2、ES架構模塊
?
Gateway是ES用來存儲索引的文件系統，支持多種類型。
Gateway的上層是一個分布式的lucene框架。
Lucene之上是ES的模塊，包括：索引模塊、搜索模塊、映射解析模塊等
ES模塊之上是 Discovery、Scripting和第三方插件。
Discovery是ES的節點發現模塊，不同機器上的ES節點要組成集群需要進行消息通信，集群內部需要選舉master節點，這些工作都是由Discovery模塊完成。支持多種發現機制，如 Zen 、EC2、gce、Azure。
Scripting用來支持在查詢語句中插入javascript、python等腳本語言，scripting模塊負責解析這些腳本，使用腳本語句性能稍低。ES也支持多種第三方插件。
再上層是ES的傳輸模塊和JMX.傳輸模塊支持多種傳輸協議，如 Thrift、memecached、http，默認使用http。JMX是java的管理框架，用來管理ES應用。
最上層是ES提供給用戶的接口，可以通過RESTful接口和ES集群進行交互。
3、Elasticsearch核心概念
1、索引 index
一個索引就是一個擁有幾分相似特征的文檔的集合。比如說，你可以有一個客戶數據的索引，另一個產品目錄的索引，還有一個訂單數據的索引。一個索引由一個名字來標識（必須全部是小寫字母的），并且當我們要對對應于這個索引中的文檔進行索引、搜索、更新和刪除的時候，都要使用到這個名字。在一個集群中，可以定義任意多的索引。
2、類型 type
在一個索引中，你可以定義一種或多種類型。一個類型是你的索引的一個邏輯上的分類/分區，其語義完全由你來定。通常，會為具有一組共同字段的文檔定義一個類型。比如說，我們假設你運營一個博客平臺并且將你所有的數據存儲到一個索引中。在這個索引中，你可以為用戶數據定義一個類型，為博客數據定義另一個類型，當然，也可以為評論數據定義另一個類型。
3、字段Field
相當于是數據表的字段，對文檔數據根據不同屬性進行的分類標識
4、映射 mapping
mapping是處理數據的方式和規則方面做一些限制，如某個字段的數據類型、默認值、分析器、是否被索引等等，這些都是映射里面可以設置的，其它就是處理es里面數據的一些使用規則設置也叫做映射，按著最優規則處理數據對性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能對性能更好。
5、文檔 document
一個文檔是一個可被索引的基礎信息單元。比如，你可以擁有某一個客戶的文檔，某一個產品的一個文檔，當然，也可以擁有某個訂單的一個文檔。文檔以JSON（Javascript Object Notation）格式來表示，而JSON是一個到處存在的互聯網數據交互格式。
在一個index/type里面，你可以存儲任意多的文檔。注意，盡管一個文檔，物理上存在于一個索引之中，文檔必須被索引/賦予一個索引的type。
6、集群 cluster
一個集群就是由一個或多個節點組織在一起，它們共同持有整個的數據，并一起提供索引和搜索功能。一個集群由一個唯一的名字標識，這個名字默認就是“elasticsearch”。這個名字是重要的，因為一個節點只能通過指定某個集群的名字，來加入這個集群
7、節點 node
一個節點是集群中的一個服務器，作為集群的一部分，它存儲數據，參與集群的索引和搜索功能。和集群類似，一個節點也是由一個名字來標識的，默認情況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啟動的時候賦予節點。這個名字對于管理工作來說挺重要的，因為在這個管理過程中，你會去確定網絡中的哪些服務器對應于Elasticsearch集群中的哪些節點。
一個節點可以通過配置集群名稱的方式來加入一個指定的集群。默認情況下，每個節點都會被安排加入到一個叫做“elasticsearch”的集群中，這意味著，如果你在你的網絡中啟動了若干個節點，并假定它們能夠相互發現彼此，它們將會自動地形成并加入到一個叫做“elasticsearch”的集群中。
在一個集群里，只要你想，可以擁有任意多個節點。而且，如果當前你的網絡中沒有運行任何Elasticsearch節點，這時啟動一個節點，會默認創建并加入一個叫做“elasticsearch”的集群。
8、分片和復制 shards&replicas
一個索引可以存儲超出單個結點硬件限制的大量數據。比如，一個具有10億文檔的索引占據1TB的磁盤空間，而任一節點都沒有這樣大的磁盤空間；或者單個節點處理搜索請求，響應太慢。為了解決這個問題，Elasticsearch提供了將索引劃分成多份的能力，這些份就叫做分片。當你創建一個索引的時候，你可以指定你想要的分片的數量。每個分片本身也是一個功能完善并且獨立的“索引”，這個“索引”可以被放置到集群中的任何節點上。分片很重要，主要有兩方面的原因：? 1）允許你水平分割/擴展你的內容容量。? 2）允許你在分片（潛在地，位于多個節點上）之上進行分布式的、并行的操作，進而提高性能/吞吐量。
至于一個分片怎樣分布，它的文檔怎樣聚合回搜索請求，是完全由Elasticsearch管理的，對于作為用戶的你來說，這些都是透明的。
在一個網絡/云的環境里，失敗隨時都可能發生，在某個分片/節點不知怎么的就處于離線狀態，或者由于任何原因消失了，這種情況下，有一個故障轉移機制是非常有用并且是強烈推薦的。為此目的，Elasticsearch允許你創建分片的一份或多份拷貝，這些拷貝叫做復制分片，或者直接叫復制。
復制之所以重要，有兩個主要原因： 在分片/節點失敗的情況下，提供了高可用性。因為這個原因，注意到復制分片從不與原/主要（original/primary）分片置于同一節點上是非常重要的。擴展你的搜索量/吞吐量，因為搜索可以在所有的復制上并行運行。總之，每個索引可以被分成多個分片。一個索引也可以被復制0次（意思是沒有復制）或多次。一旦復制了，每個索引就有了主分片（作為復制源的原來的分片）和復制分片（主分片的拷貝）之別。分片和復制的數量可以在索引創建的時候指定。在索引創建之后，你可以在任何時候動態地改變復制的數量，但是你事后不能改變分片的數量。
默認情況下，Elasticsearch中的每個索引被分片5個主分片和1個復制，這意味著，如果你的集群中至少有兩個節點，你的索引將會有5個主分片和另外5個復制分片（1個完全拷貝），這樣的話每個索引總共就有10個分片。
總結
以上是生活随笔為你收集整理的Day82_ELK（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Qt纯代码实现菜单栏、工具栏、状态栏
- 下一篇： GCC详解的-Wl选项说明