搜索客，搜索人自己的社区

ES的父子查询中如何使用scripts的来过滤数据

贡献

Elasticsearch • rochy 回复了问题 • 3 人关注 • 1 个回复 • 2153 次浏览 • 2018-12-19 09:10 • 来自相关话题

请问marvel或x-pack里面的监控数据有API直接获取吗？

贡献

Elasticsearch • rochy 回复了问题 • 2 人关注 • 2 个回复 • 1415 次浏览 • 2018-12-19 09:03 • 来自相关话题

Day 19 - 通过点击反馈优化es搜索结果排序

Advent • laigood 发表了文章 • 1 个评论 • 6068 次浏览 • 2018-12-19 00:15 • 来自相关话题

相信不少人都把es当做一个主要的搜索引擎来使用，但是对于搜索结果之后的点击反馈，es没有很好的方案。比如说用户搜索了某些关键词，点击了某些结果，而这些结果并不是排在最前面的，但确实是用户最想要的。那有没有什么方法可以使它们排在前面呢？一种简单的做法就是就是离线统计文档的点击率，然后在排序时根据这个点击率进行加权，但这样笼统的算法不一定适合所有情况。现在就来简单介绍下learning to rank，翻译过来就是学习排序，可以根据点击日志里面的记录，来反向影响搜索结果的排序。刚好这个库也有es的插件，下面以这个插件的官方demo来解释下如何使用。
demo的下载地址如下，都是python脚本，环境需求：python3+，es
https://github.com/o19s/elasti ... /demo
1.准备数据
python prepare.py
下载RankLib.jar (用来训练模型) 和tmdb.json (测试数据集，tmdb的电影数据)
2.导测试数据入es
python index_ml_tmdb.py
3.训练模型
python train.py
训练脚本很简单，但是脚本里面有丰富的实现，下面介绍下主要方法。
load_features(FEATURE_SET_NAME)
这个是读取特征信息，demo定义了两个特征，分别在1.json

{

    "query": {

        "match": {

            "title": "{{keywords}}"

        }

    }

}

和2.json

{

    "query": {

        "match": {

            "overview": "{{keywords}}"

        }

    }

}

1就是查title，2就是查overview，生成训练数据时就是需要根据特征的查询语法，去es里面匹配相关得分作为特征分数。

movieJudgments = judgments_by_qid(judgments_from_file(filename=JUDGMENTS_FILE))

读取生成训练数据的原始数据，官方称其为决策列表（Judgment list），第一列是数值为0-4的权重，数值越大，相关性越高。回到我们最初的需求就是越多人点击的文档，那么这个权重就越大。第二列是queryid，同次查询结果中的queryid一样，第三列是文档id，这里就是电影id，第四列是文档标题，这里就是电影名。
4   qid:1 #    7555   Rambo
3  qid:1 #    1370   Rambo III
3  qid:1 #    1369   Rambo: First Blood Part II
3  qid:1 #    1368   First Blood
0  qid:1 #    136278 Blood
4  qid:2 #    1366   Rocky
3  qid:2 #    1246   Rocky Balboa
3  qid:2 #    60375  Rocky VI
3  qid:2 #    1371   Rocky III
3  qid:2 #    1375   Rocky V

log_features(es, judgments_dict=movieJudgments, search_index=INDEX_NAME)

build_features_judgments_file(movieJudgments, filename=JUDGMENTS_FILE_FEATURES)

之后就是生成特征集，就是把上面的每条训练数据根据特征查询语句扔进es里面进行查询，把得分放到1和2特征后面，如:下面数据第一条中的，1:12.318446就表示1特征的分数，2:10.573845表示2特征的分数，然后把特征集写到文件。
生成完的特征集如下：
4   qid:1  1:12.318446    2:10.573845 # 7555 rambo
3  qid:1  1:10.357836    2:11.950331 # 1370 rambo
3  qid:1  1:7.0104666    2:11.220029 # 1369 rambo
3  qid:1  1:0.0  2:11.220029 # 1368 rambo
0  qid:1  1:0.0  2:0.0 # 136278 rambo
4  qid:2  1:10.686367    2:8.814796 # 1366  rocky
3  qid:2  1:8.985519 2:9.984467 # 1246  rocky
3  qid:2  1:8.985519 2:8.067647 # 60375 rocky
3  qid:2  1:8.985519 2:5.6604943 # 1371 rocky
3  qid:2  1:8.985519 2:7.3007236 # 1375 rocky
特征集出来后就是训练了，demo提供10总不同的算法，训练好之后把结果传到es提供服务

for modelType in [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]:

    # 0, MART

    # 1, RankNet

    # 2, RankBoost

    # 3, AdaRank

    # 4, coord Ascent

    # 6, LambdaMART

    # 7, ListNET

    # 8, Random Forests

    # 9, Linear Regression

    Logger.logger.info("*** Training %s " % modelType)

    train_model(judgments_with_features_file=JUDGMENTS_FILE_FEATURES, model_output='model.txt',

                which_model=modelType)

    save_model(script_name="test_%s" % modelType, feature_set=FEATURE_SET_NAME,       model_fname='model.txt')

4.最后搜索数据
python search.py Rambo
搜索时主要用到了es里面的rescore特性，就是对前面topn条记录根据模型进行再排序，查询dsl如下：

{

  "query": {

      "multi_match": {

          "query": "Rambo",

          "fields": ["title", "overview"]

       }

   },

  "rescore": {

      "query": {

        "rescore_query": {

            "sltr": {

                "params": {

                    "keywords": "Rambo"

                },

                "model": "test_1",

            }

         }

      }

   }

}

得到结果
Rambo
Rambo III
Rambo: First Blood Part II
First Blood
In the Line of Duty: The F.B.I. Murders
Son of Rambow
Spud
当然这个是最简单的一个例子，深入研究可以参考官方文档，很详细：https://elasticsearch-learning ... test/

单机硬盘160T如果写满对应32G内存如何？

贡献

Elasticsearch • HelloClyde 回复了问题 • 5 人关注 • 3 个回复 • 1974 次浏览 • 2018-12-18 22:58 • 来自相关话题

老生常谈ES heap问题；

贡献

Elasticsearch • HelloClyde 回复了问题 • 3 人关注 • 2 个回复 • 3291 次浏览 • 2018-12-18 17:14 • 来自相关话题

....................

贡献

Elasticsearch • rochy 回复了问题 • 2 人关注 • 1 个回复 • 1413 次浏览 • 2018-12-18 16:24 • 来自相关话题

如何选择在ES之前处理写入的中间件？

贡献

Elasticsearch • God_lockin 回复了问题 • 4 人关注 • 2 个回复 • 3376 次浏览 • 2018-12-18 14:48 • 来自相关话题

大家有碰到过这个异常吗can not write type [class java.math.BigDecimal]

贡献

Elasticsearch • rochy 回复了问题 • 2 人关注 • 1 个回复 • 4066 次浏览 • 2018-12-18 14:18 • 来自相关话题

社区日报第482期 (2018-12-18)

社区日报 • kimichen123 发表了文章 • 0 个评论 • 1287 次浏览 • 2018-12-18 13:27 • 来自相关话题

Kibana查询结果根据字段进行去重

贡献

Kibana • insist_93 回复了问题 • 3 人关注 • 2 个回复 • 14500 次浏览 • 2018-12-18 09:21 • 来自相关话题

filebeat采集可以采集多少个文件

贡献

Beats • cao 回复了问题 • 2 人关注 • 2 个回复 • 3687 次浏览 • 2018-12-17 17:45 • 来自相关话题

使用search-guard 后java代码连接不上

贡献

Elasticsearch • ly898197688 回复了问题 • 2 人关注 • 2 个回复 • 2331 次浏览 • 2018-12-17 16:09 • 来自相关话题

Day 18: 记filebeat内存泄漏问题分析及调优

Beats • 点火三周发表了文章 • 1 个评论 • 11873 次浏览 • 2018-12-17 14:55 • 来自相关话题

目前beats工具只有官网列出来的8种吗？

贡献

Beats • medcl 回复了问题 • 3 人关注 • 1 个回复 • 2595 次浏览 • 2018-12-17 12:05 • 来自相关话题

Day 17 - 关于日志型数据管理策略的思考

Elasticsearch • kennywu76 发表了文章 • 7 个评论 • 5645 次浏览 • 2018-12-17 11:19 • 来自相关话题

近两年随着Elastic Stack的愈发火热，其近乎成为构建实时日志应用的工业标准。在小型数据应用场景，最新的6.5版本已经可以做到开箱即用，无需过多考虑架构上的设计工作。然而一旦应用规模扩大到数百TB甚至PB的数据量级，整个系统的架构和后期维护工作则显得非常重要。借着2018 Elastic Advent写文的机会，结合过去几年架构和运维公司日志集群的实践经验，对于大规模日志型数据的管理策略，在此做一个总结性的思考。文中抛出的观点，有些已经在我们的集群中有所应用并取得比较好的效果，有些则还待实践的检验。抛砖引玉，不尽成熟的地方，还请社区各位专家指正。

对于日志系统，最终用户通常有以下几个基本要求:

数据从产生到可检索的实时性要求高，可接受的延迟通常要求控制在数秒，至多不超过数十秒
新鲜数据(当天至过去几天)的查询和统计频率高，返回速度要快(毫秒级，至多几秒)
历史数据保留得越久越好。

针对这些需求，加上对成本控制的必要性，大家通常想到的第一个架构设计就是冷热数据分离。

冷热数据分离

冷热分离的概念比较好理解，热结点做数据的写入，保存近期热数据，冷数据定期迁移到冷数据结点，就这么简单。不过实际操作起来可能还是碰到一些具体需要考虑的细节问题。
冷热结点集群配置的JVM heap配置要差异化。热结点无需存放太多数据，对于heap的要求通常不是太高，在够用的情况下尽量配置小一点。可以配置在26GB左右甚至更小，而不是大多数人知道的经验值31GB。原因在于这个size的heap，可以启用zero based Compressed Oops，JVM运行效率是最高的，参考: [heap-size](https://www.elastic.co/guide/e ... e.html)。而冷结点存在的目的是尽量放更多的数据，性能不是首要的，因此heap可以配置在31GB。
数据迁移过程有一定资源消耗，为避免对数据写入产生显著影响，通常定时在业务低峰期，日志产出量比较低的时候进行，比如半夜。
索引是否应该启用压缩，如何启用？最初我们对于热结点上的索引是不启用压缩的，为了节省CPU消耗。只在冷结点配置里，增加了索引压缩选项。这样索引迁移到冷结点后，执行force merge操作的时候，ES会自动将结点上配置的索引压缩属性套用到merge过后新生成的segment，这样就实现了热结点不压缩，冷结点merge过后压缩的功能。极大节省了冷结点的磁盘空间。后来随着硬件的升级，我们发现服务器的cpu基本都是过剩的，磁盘IO通常先到瓶颈。因此尝试在热结点上一开始创建索引的时候，就启用压缩选项。实际对比测试并没有发现显著的索引吞吐量下降，并且因为索引压缩后磁盘文件size的大幅减少，每天夜间的数据迁移工作可以节省大量的时间。至此我们的日志集群索引默认就是压缩的。
冷结点上留做系统缓存的内存一般不多，加上数据量非常巨大。索引默认的mmapfs读取方式，很容易因为系统缓存不够，导致数据在内存和磁盘之间频繁换入换出。严重的情况下，整个结点甚至会因为io持续在100%无法响应。实践中我们发现对冷结点使用niofs效果会更好。

实现了冷热结点分离以后，集群的资源利用率提升了不少，可管理性也要好很多了. 但是随着接入日志的类型越来越多（我们生产上有差不多400种类型的日志)，各种日志的速率差异又很大，让ES自己管理shard的分布很容易产生写入热点问题。针对这个问题，可以采用对集群结点进行分组管理的策略来解决。

热结点分组管理

所谓分组管理，就是通过在结点的配置文件中增加自定义的标签属性，将服务器区分到不同的组别中。然后通过设置索引的index.routing.allocation.include属性，控制改索引分布在哪个组别。同时配合设置index.routing.allocation.total_shards_per_node，可以做到某个索引的shard在某个group的结点之间绝对均匀分布。

比如一个分组有10台机器，对一个5 primary ，1 replica的索引，让该索引分布在该分组的同时，设置total_shards_per_node为1，让每个节点上只能有一个分片，这样就避免了写入热点问题。该方案的缺陷也显而易见，一旦有结点挂掉，不会自动recovery，某个shard将一直处于unassigned状态，集群状态变成yellow。但我认为，热数据的恢复开销是非常高的，与其立即在其他结点开始复制，之后再重新rebalance，不如就让集群暂时处于yellow状态。通过监控报警的手段，及时通知运维人员解决结点故障。待故障解决之后，直接从恢复后的结点开始数据复制，开销要低得多。

在我们的生产环境主要有两种类型的结点分组，分别是10台机器一个分组，和2台机器一个分组。10台机器的分组用于应对速率非常高，shard划分比较多的索引，2台机器的分组用于速率很低，一个shard（加一个复制片）就可以应对的索引。

这种分组策略在我们的生产环境中经过验证，非常好的解决了写入热点问题。那么冷数据怎么管理？冷数据不做写入，不存在写入热点问题，查询频率也比较低，业务需求方面对查询响应要求也不那么严苛，所以查询热点问题也不是那么突出。因此为了简化管理，冷结点我们是不做shard分布的精细控制，所有数据迁移到冷数据结点之后，由ES默认的shard分布则略去控制数据的分布。

不过如果想进一步提高冷数据结点服务器资源的利用率，还是可以有进一步挖掘的的空间。我们知道ES默认的shard分布策略，只是保证一个索引的shard尽量分布在不同的结点，同时保证每个节点上shard数量差不多。但是如果采用默认按天创建索引的策略，由于索引速率差异很大，不同索引之间shard的大小差异可能是1-2个数量级的。如果每个shard的size差异不大就好了，那么默认的分布策略，基本上可以保证冷结点之间数据量分布的大致均匀。能实现类似功能的是ES的rollover特性。

索引的Rollover

Rollover api可以让索引根据预先定义的时间跨度，或者索引大小来自动切分出新索引，从而将索引的大小控制在计划的范围内。合理的应用rollver api可以保证集群shard大小差别不会太大。只是集群索引类别比较多的时候，rollover全部手动管理负担比较大，需要借助额外的管理工具和监控工具。我们出于管理简便的考虑，暂时没有应用到这个特性。

索引的Rollup

我们发现生产有些用户写入的“日志”，实际上是多维的metrcis数据，使用的时候不是为了查询日志的详情，仅仅是为了做各种维度组合的过滤和聚合。对于这种类型的数据，保留历史数据过多一来浪费存储空间，二来每次聚合都要在裸数据上跑，非常浪费资源。 ES从6.3开始，在x-pack里推出了rollup api，通过定期对裸数据做预先聚合，大大缩减了保存在磁盘上的数据量。对于不需要查询裸日志的应用场景，合理应用该特性，可以将历史数据的磁盘消耗降低几个数量级，同时rollup search也可以大大提升聚合速度。不过rollup也有其局限性，即他的实现是通过定期任务，对间隔期数据跑聚合完成的，有一定的计算开销。如果数据写入速率非常高，集群压力很大，rollup可能无法跟上写入速率，而不具有实用性。所以实际环境中，还是需要根据应用场景和资源使用情况，进行灵活的取舍。

多集群的便利性

数据量大到一定程度以后，单集群由于master node单点的限制，会遇到各种集群状态数据更新时得性能问题。由此现在一些大规模的应用已经开始利用到多集群互联和cross cluster search的特性。这种结构除了解决单集群数据容量限制问题以外，我们还发现在做容量均衡方面还有比较好的便利性。应用日志写入量通常随着业务变化也会剧烈变化，好不容易规划好的容量，不久就被业务的增长给打破，数倍或者数10倍的流量增长很可能就让一组结点过载出现写入延迟。如果只有一个集群，在结点之间重新平衡shard比较费力，涉及到数据的迁移，可能非常缓慢，还会影响写入。但如果有多集群互联，切换就可以做到非常的快速和简单。原理上只需要在新集群中加入对应的索引配置模版，然后更新写入程序的配置，写入目标指向新集群，重启写入程序即可。并且，可以进一步将整个流程工具化，在GUI上完成一键切换。

通知设置 新通知

发现

问题场景和配置

index.codec: best_compression

_source.enabled: false

监控文件过多

非常频繁的rotate日志

因为multiline导致内存占用过多

模拟场景

如何观察filebeat的内存

通过filebeat的日志

filebeat文件解读

filebeat日志解析

通过pprof

启动pprof监测

远程连接

top 命令

查看堆栈调用图

查看源码

如何调优

max_message_bytes: 1000000

queue.mem.events: 256

queue.mem.flush.min_events: 128

冷热数据分离

热结点分组管理

索引的Rollover

索引的Rollup

多集群的便利性

热门话题

通知设置新通知