ELK--介绍及特点

1、ELK介绍

• 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/

ElasticSearch：实现存储和分析

• 特点
  • 分布式存储
    • 存储数据的索引
    • 存储在ES中的数据，进行分布式存储的
  • 全文索引工具
    • 只要存储在ES中的数据，任何数据都可以构建索引
    • 查询ES中的任何数据，都可以走索引
    • 什么玩意都走索引就叫全文索引

Logstash：实现数据采集

• 类似于Flume，用于实现数据采集，一般搭配ES使用，将数据采集到ES中，可以独立使用
• Flume：source、Channel、SInk
• Logstash：input、Filter、Output
• Flume是Java开发，灵活性、扩展性都比较好，允许用户自定义开发
• Logstash是Ruby语言开发的，开发比较麻烦，Logstash本身提供了非常全面的采集的功能
  • Flume + Sqoop = Logstash
  • 工作中除非使用ELK，不然一般不会使用Logstash
  • 性能或者维护都不如Flume

Kibana：用于可视化工具

• 类似于Hue或者Superset
• 可以作为可视化的ES的客户端
• 可以对ES中的数据进行可视化报表分析展示
• Kibana主要应用于ELK，不能独立使用
• 一般不用ES，也不会用Kibana

2、应用场景

• 构建统一日志搜索引擎
• 构建其他业务搜索引擎
• 分布式存储，将所存储的所有数据，构建索引【数据】
  • 日志：将所有日志内容构建索引
    • 只要搜索任何一个在日志中出现的 关键词：INFO，WARN、ERROR
    • 就可以返回包含这个关键词的所有日志
  • 业务：将所有业务数据，订单存储在ES
    • 订单存储在ES中，订单中的任何一个数据都可以构建成索引
    • 根据任何 一条件查询，都可以走索引
    • Hbase：唯一索引rowkey
      • 应用场景：高性能的实时读写
      • 解决大数据量数据读写问题
    • ElasticSearch：全文索引
      • 应用场景：基于大数据量构建索引
      • 解决大数据量索引存储问题
    • 工作中
      • 用HBASE存储数据
      • 用ES构建Hbase的二级索引
      • 先查询ES，通过索引来找到数据在Hbase中的Rowkey

3、ES特点

• 分布式：大数据量
• 全文索引：将每个数据都可以分词构建每个词的索引
• 使用Java开发的
• NRT：近实时
  • 近实时的读写
• 以document为导向，实现数据索引的存储，所有的数据对象都是document
  • 理解为这就是一条数据，类似于Hbase中一个rowkey的数据
  • 1个documentid + data[field] = 1个rowkey + data[field]
• 高可用可扩展的架构
  • 不依赖于Zookeeper
  • 自己实现了类似于zookeeper的分布式集群的管理机制
  • zen-discovery
• 数据安全
  • 分片shards：就是分区
  • 每个分区都有副本：replicas
  • 一个分片可以有多个副本
  • 分区有主从关系
    • primary shard：主副本
    • replicas shard：从副本
• 交互性友好
  • Json形式实现数据交互，这是最通用最常用的数据格式

总结

ELK功能以及应用场景

• 组成
  • ElasticSearch：用于实现数据的存储和分析
  • Logstash：用于数据采集
  • Kibana：可视化开发以及报表
• ElasticSearch：分布式存储，构建全文索引
  • Zookeeper：用于解决分布式架构中数据一致性问题
    • 只能存储关键性的小数据
  • HDFS：用于解决大量数据无法存储问题
    • 通过分布式方案解决大数据存储
  • Hbase：用于解决大量数据高性能读写的问题
    • 基于内存分布式、有序文件……
  • ElasticSearch：大量数据基于全文检索索引的访问问题
    • 构建全文索引，分词构建索引
  • Kafka：大量数据如何高性能的临时存储，消息队列，分布式缓存机制
  • Redis：小量数据如何高性能的快速持久化读写的问题
• 应用场景
  • 日志搜索引擎
  • 业务搜索引擎

ES中的存储概念

Index

• 索引库
• 当做数据库来看
• 里面存储的是所有数据的索引

Type

• 索引类型
• 当做表来看
• 这是一个逻辑上的概念，物理上没有区分
• 注意：与数据库不同 的是
  • 一个index只能有一个type
  • 6.x开始：每个Index中只能有一个Type
  • 后期Type这个概念会被取消
• 问题：如果一个 索引库中的两个索引类型中出现了相同的列名，但类型不一样
  • 物理上属于同一列
  • 逻辑上属于不同列
  • 读取数据时就会出现问题
• 任何一条Document，虽然在物理上属于Index，但是在访问时必须加上Type才能访问

Document：一条数据

• 就是存储在ES中的一条数据，类似于Hbase 中的一条Rowkey的数据
• Document = DocumentId + data【fields】
• DocumentId类似于Rowkey，是ES为每个索引类型都自带的一列，值由我们自己定义
  • 用于作为唯一标识
  • 用于分区规则：按照documentId的hash取余分区的个数

Fields：真正数据中存储的列

Shard：分片

• 默认每个索引库都会有5个主分区

Replicas：副本

• 默认每个主分区都会有1个副本分区
• 如果我们创建一个索引库，这个索引库会创建10个分区
• 角色
  • 主分区：对外提供读写服务
  • 副本分区：与主分区同步数据
• 注意
  • 任何一个分区的总个数【主分区+副本分区】不允许超过机器个数