1、用ElasticSearch搭建自己的搜索和分析引擎
http://t.cn/E4n6of8
2、Elasticsearch 集群性能的最佳实践
http://t.cn/E4n6M3v
3、海量数据下Elasticsearch搜索引擎分析与搭建
http://t.cn/R3bde2J

编辑：叮咚光军
归档：https://elasticsearch.cn/article/6223
订阅：https://tinyletter.com/elastic-daily

欢迎来到 Elastic 社区电台的第九期节目，我们本期节目的嘉宾是来自于 vivo 互联网负责搜索业务研发的杨振涛，vivo 从 Elasticsearch 2.1.1 版本开始，如今使用 100 多个 Elasticsearch 集群来支撑全球 2 亿多台手机每天的各种搜索请求，如 vivo 的应用商店、游戏、音乐、主题、壁纸、铃声等各种手机服务背后的搜索服务，也包括产品配件、售后、FAQ 等企业门户官网的搜索请求。今天让我们一起走进 vivo，看看 vivo 具体是如何使用 Elasticsearch 来解决这些搜索问题的。

可以点击下面的任意链接来收听（时长约 50 分钟）：

• Apple iTunes: [https://itunes.apple.com/cn/podcast/elastic-社区电台/](https://itunes.apple.com/cn/po ... %25B0/)
  
• 喜马拉雅：[https://www.ximalaya.com/keji/14965410/146649768](https://www.ximalaya.com/keji/14965410/146649768)
  
• 蜻蜓 FM：[https://www.qingting.fm/channe ... 96421](https://www.qingting.fm/channe ... 396421)
  
  

  嘉宾
  

  
  

  

  
  
  杨振涛，vivo 互联网搜索引擎架构师，专注于数据的存储、检索与可视化，以及 DevOps 与软件过程改进。Elastic 中文社区深圳地区负责人，发起并组织 Elasticsearch、Redis、Jenkins 等主题的技术沙龙，并参与多个开源项目的文档翻译和中文化工作。 技术翻译爱好者，InfoQ 中文社区编辑，TED Translator。
  
  

  主持人
  

  Elastic 技术布道师，曾勇（Medcl）。
  
  

  关于 vivo
  

  vivo为一个专注于智能手机领域的手机品牌，vivo和追求乐趣、充满活力、年轻时尚的群体一起打造拥有卓越外观、专业级音质、极致影像、愉悦体验的智能产品，并将敢于追求极致、持续创造惊喜作为vivo的坚定追求。
  
  

  关于 Elastic 社区电台
  

  Elastic 开源社区举办的一款播客类节目， 邀请来自开源社区的用户，一起聊聊 Elastic 开源产品的使用案例、经验分享、架构变迁等等。
  
  

  相关链接
  

  
  

• [社区活动计划](https://meetup.elasticsearch.c ... 9.html)
  
  
• [vivo 招聘页面](https://hr.vivo.com)
  

​首先还是祝大家圣诞快乐，既然是节日，我们就讨论一个比较轻松的话题。如何使用6.5引入[数据管道处理器](https://www.elastic.co/guide/e ... r.html)来更好的治理预定义好的数据管道。

背景

2018这一年来拜访了很多用户，其中有相当一部分在数据摄取时遇到包括性能在内的各种各样的问题，那么大多数在我们做了ingest节点的调整后得到了很好的解决。Ingest节点不是万能的，但是使用起来简单，而且抛开后面数据节点来看性能提升趋于线性。所以我一直本着能用ingest节点解决的问题，绝不麻烦其他组件的大体原则 ：-）

下面快速回顾一下ingest节点的角色定位。

使用场景

通过上面的图纸我们很容易看到ingest节点可以在数据被索引之前，通过预定义好的处理管道对其进行治理。但这里一直存在一个局限性，就是只能通过一条管道。那么一直以来应对这个不便的方案就是把所有的处理器和细节全部配置到当前管道下。那么带来的问题也是比较明显的：

• 复制、粘贴很多相同的管道配置在不同数据管道里
  
• 非常难管理、维护冗长的管道
  
• 如果要更新一个处理细节的话要找到定位所有使用过这个逻辑的管道
  
  其实这块对于开发的同学们很好理解，当你经常复制、粘贴代码的时候，就是时候好好思考一下了。我想说到这里大家其实已经明白了，这个管道处理器实际就是提供了一个允许你在一个管道内调用其他管道的方案。
  
  他的使用非常简单，就像函数调用一样只有一个必要参数name：
  
  <br /> {<br /> "pipeline": {<br /> "name": "<其他管道的名称 - 英文字符>"<br /> }<br /> }<br />
  
  当然，也像其他处理器一样提供了on_failure参数来处理错误，并且还有一个非常实用的if参数来判断是否执行这个管道，这里就不做详细介绍了。
  
  

  举例
  

  
  这里我们用一个非常简单的案例来看看如何使用管道处理器。
  
  假设在Elastic公司，我们使用员工卡来作为进入公司和各个部门以及房间的钥匙，并且这些刷卡事件也会被记录下来。那么由于上班卡机和门禁供应商不同，数据格式也不一样。但是最后都有一个通用的逻辑，就是除了事件发生的时间，我们还会记录下数据录入到Elasticsearch的时间。
  
  首先我们看一下原始数据：
  
  ```
  

  公司正门卡机数据
  

  2018-12-25T08:59:59.312Z,front_door,binw,entered
  
  

  架构部门禁数据
  

  @timestamp=2018-12-25T09:15:34.414Z device_id=recreation_hall user=binw event=entered
  ```
  
  那如果在6.5之前，我们定义2条管道是这个样子
  
  

  1. 正门卡机管道
     
• grok 解析数据
  
• 打上数据录入的时间戳
  
• 明确录入时间戳的处理器
  
  
  2. 门禁数据管道
     
• KV 解析数据
  
• 打上数据录入的时间戳
  
• 明确录入时间戳的处理器
  
  很明显又66.67%的配置都是重复的，所以这里我们可以更优雅的解决这个问题
  
  
  1. 统一的数据录入时间戳处理器
     
• 打上数据录入的时间戳
  
• 明确录入时间戳的处理器
  
  <br /> PUT _ingest/pipeline/pl_cmn<br /> {<br /> "description": "刷卡数据通用管道",<br /> "processors": [<br /> {<br /> "set": {<br /> "field": "ingest_timestamp",<br /> "value": "{{_ingest.timestamp}}"<br /> }<br /> },<br /> {<br /> "set": {<br /> "field": "cmn_processed",<br /> "value": "yes"<br /> }<br /> }<br /> ]<br /> }<br />
  
  
  2. 正门卡机管道
     
• grok 解析数据
  
• <调用管道 pl_cmn>
  
  <br /> POST _ingest/pipeline/_simulate<br /> {<br /> "pipeline": {<br /> "description": "正门打卡机数据处理管道",<br /> "processors": [<br /> {<br /> "grok": {<br /> "field": "message",<br /> "patterns": [<br /> "%{TIMESTAMP_ISO8601:@timestamp},%{WORD:device_id},%{USER:user},%{WORD:event}"<br /> ]<br /> }<br /> },<br /> {<br /> "pipeline": {<br /> "name": "pl_cmn"<br /> }<br /> }<br /> ]<br /> },<br /> "docs": [<br /> {<br /> "_source": {<br /> "message": "2018-12-25T08:59:59.312Z,front_door,binw,entered"<br /> }<br /> }<br /> ]<br /> }<br />
  
  
  3. 门禁数据管道
     
• KV 解析数据
  
• <调用管道 pl_cmn>
  
  <br /> POST _ingest/pipeline/_simulate<br /> {<br /> "pipeline": {<br /> "description": "架构部门禁数据处理管道",<br /> "processors": [<br /> {<br /> "kv": {<br /> "field": "message",<br /> "field_split": " ",<br /> "value_split": "="<br /> }<br /> },<br /> {<br /> "pipeline": {<br /> "name": "pl_cmn"<br /> }<br /> }<br /> ]<br /> },<br /> "docs": [<br /> {<br /> "_source": {<br /> "message": "@timestamp=2018-12-25T09:15:34.414Z device_id=recreation_hall user=binw event=entered"<br /> }<br /> }<br /> ]<br /> }<br />
  
  好啦，这个例子非常简单。但当面对复杂业务场景的时候，会让你整个数据管道的管理比以前整齐很多。再结合合理的架构和数据治理，ingest节点也可以让你的整个数据处理能力有所提升。
  
  

  写在最后
  

  
  在文章的例子里，我们往索引里灌注的是一个个的事件数据。那要如何对数据中的实体进行有效的分析呢？那不得不说到面向实体的数据模型设计。Elasticsearch本身也提供了工具能让我们快速实现，让我们明年有机会的时候再与大家分享吧。最后还是祝愿大家度过一个愉快的圣诞节和元旦！

1.聊聊 ElasticSearch 使用场景
http://t.cn/E4QEI6q
2.让 Elasticsearch 飞起来：性能优化实践干货
http://t.cn/E4Q3cbj
3.Filebeat issue 排查  ： i/o timeout
http://t.cn/E4Q3Bhz

编辑：cyberdak
归档：https://elasticsearch.cn/article/6220
订阅：https://tinyletter.com/elastic-daily