Elastic Podcast 第二期来啦, 这一次我们来到了位于上海的携程旅行网，携程内部大量运用了 Elasticsearch来进行集中式的运维日志管理和为业务部门提供统一的搜索服务平台， 目前线上总共部署了多达 94 个 Elasticsearch 集群和超过 700 多个 Elasticsearch 节点，每天新增日志 1600 亿条，峰值达到 300 万每秒，存放在 Elasticsearch里面的索引文档达到 2.5 万亿，磁盘存储达到 PB 级。 想知道携程是如何应对这些海量数据下的挑战，以及最佳实践，让我们一起来收听这一期的 Podcast，跟随携程的两位技术负责人吴晓刚和胡航来一探究竟。

音频地址：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最喜欢的特性

Wood大叔： 丰富的扩展能力，用户不必关心底层的实现。通过服务器增加节点，方便大数据量查询。

胡航： ES可视化、可调试特性。 举例： 1）出现问题排查DSL是不是合适？Mapping是不是合适？

2）相信ES的社区，不必关心底层，更多的时间做业务（解放双手）。

3）ES中做好数据模型，实现业务需求。

7、ELK Stack最需要完善的

Wood大叔： 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: 权威指南》，我们没有理由不努力。

共勉，加油！

• SoundCloud：https://soundcloud.com/elastic ... ctrip
• 喜马拉雅：http://m.ximalaya.com/111156131/sound/89571047 
• 蜻蜓 FM：http://m.qingting.fm/vchannels ... 45776

有 SQL 背景的同学在学习 Elasticsearch 时，面对一个查询需求，不由自主地会先思考如何用 SQL 来实现，然后再去想 Elasticsearch 的 Query DSL 如何实现。那么本篇就给大家讲一条常见的 SQL 语句如何用 Elasticsearch 的查询语言实现。

1. SQL语句

假设我们有一个汽车的数据集，每个汽车都有车型、颜色等字段，我希望获取颜色种类大于1个的前2车型。假设汽车的数据模型如下：

{
    "model":"modelA",
    "color":"red"
}

假设我们有一个 cars 表，通过如下语句创建测试数据。

INSERT INTO cars (model,color) VALUES ('A','red'); 
INSERT INTO cars (model,color) VALUES ('A','white'); 
INSERT INTO cars (model,color) VALUES ('A','black'); 
INSERT INTO cars (model,color) VALUES ('A','yellow'); 
INSERT INTO cars (model,color) VALUES ('B','red'); 
INSERT INTO cars (model,color) VALUES ('B','white'); 
INSERT INTO cars (model,color) VALUES ('C','black'); 
INSERT INTO cars (model,color) VALUES ('C','red'); 
INSERT INTO cars (model,color) VALUES ('C','white'); 
INSERT INTO cars (model,color) VALUES ('C','yellow'); 
INSERT INTO cars (model,color) VALUES ('C','blue'); 
INSERT INTO cars (model,color) VALUES ('D','red');
INSERT INTO cars (model,color) VALUES ('A','red'); 

那么实现我们需求的 SQL 语句也比较简单，实现如下：

SELECT model,COUNT(DISTINCT color) color_count FROM cars GROUP BY model HAVING color_count > 1 ORDER BY color_count desc LIMIT 2;

这条查询语句中 Group By 是按照 model 做分组， Having color_count>1 限定了车型颜色种类大于1，ORDER BY color_count desc 限定结果按照颜色种类倒序排列，而 LIMIT 2 限定只返回前3条数据。

那么在 Elasticsearch 中如何实现这个需求呢？

2. 在 Elasticsearch 模拟测试数据

首先我们需要先在 elasticsearch 中插入测试的数据，这里我们使用 bulk 接口 ，如下所示：

POST _bulk
{"index":{"_index":"cars","_type":"doc","_id":"1"}}
{"model":"A","color":"red"}
{"index":{"_index":"cars","_type":"doc","_id":"2"}}
{"model":"A","color":"white"}
{"index":{"_index":"cars","_type":"doc","_id":"3"}}
{"model":"A","color":"black"}
{"index":{"_index":"cars","_type":"doc","_id":"4"}}
{"model":"A","color":"yellow"}
{"index":{"_index":"cars","_type":"doc","_id":"5"}}
{"model":"B","color":"red"}
{"index":{"_index":"cars","_type":"doc","_id":"6"}}
{"model":"B","color":"white"}
{"index":{"_index":"cars","_type":"doc","_id":"7"}}
{"model":"C","color":"black"}
{"index":{"_index":"cars","_type":"doc","_id":"8"}}
{"model":"C","color":"red"}
{"index":{"_index":"cars","_type":"doc","_id":"9"}}
{"model":"C","color":"white"}
{"index":{"_index":"cars","_type":"doc","_id":"10"}}
{"model":"C","color":"yellow"}
{"index":{"_index":"cars","_type":"doc","_id":"11"}}
{"model":"C","color":"blue"}
{"index":{"_index":"cars","_type":"doc","_id":"12"}}
{"model":"D","color":"red"}
{"index":{"_index":"cars","_type":"doc","_id":"13"}}
{"model":"A","color":"red"}

其中 index 为 cars，type 为 doc，所有数据与mysql 数据保持一致。大家可以在 Kibana 的 Dev Tools 中执行上面的命令，然后执行下面的查询语句验证数据是否已经成功存入。

GET cars/_search

3. Group By VS Terms/Metric Aggregation

SQL 中 Group By 语句在 Elasticsearch 中对应的是 Terms Aggregation，即分桶聚合，对应 Group By color 的语句如下所示：

GET cars/_search
{
  "size":0,
  "aggs":{
    "models":{
      "terms":{
        "field":"model.keyword"
      }
    }
  }
}

结果如下：

{
  "took": 161,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 13,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "models": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "A",
          "doc_count": 5
        },
        {
          "key": "C",
          "doc_count": 5
        },
        {
          "key": "B",
          "doc_count": 2
        },
        {
          "key": "D",
          "doc_count": 1
        }
      ]
    }
  }
}

我们看 aggregations 这个 key 下面的即为返回结果。

SQL 语句中还有一项是 COUNT(DISTINCT color) color_count 用于计算每个 model 的颜色数，在 Elasticsearch 中我们需要使用一个指标类聚合 Cardinality ，进行不同值计数。语句如下：

GET cars/_search
{
  "size": 0,
  "aggs": {
    "models": {
      "terms": {
        "field": "model.keyword"
      },
      "aggs": {
        "color_count": {
          "cardinality": {
            "field": "color.keyword"
          }
        }
      }
    }
  }
}

其返回结果如下：

{
  "took": 74,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 13,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "models": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "A",
          "doc_count": 5,
          "color_count": {
            "value": 4
          }
        },
        {
          "key": "C",
          "doc_count": 5,
          "color_count": {
            "value": 5
          }
        },
        {
          "key": "B",
          "doc_count": 2,
          "color_count": {
            "value": 2
          }
        },
        {
          "key": "D",
          "doc_count": 1,
          "color_count": {
            "value": 1
          }
        }
      ]
    }
  }
}

结果中 color_count 即为每个 model 的颜色数，但这里所有的模型都返回了，我们只想要颜色数大于1的模型，因此这里还要加一个过滤条件。

4. Having Condition VS Bucket Filter Aggregation

Having color_count > 1 在 Elasticsearch 中对应的是 Bucket Filter 聚合，语句如下所示：

GET cars/_search
{
  "size": 0,
  "aggs": {
    "models": {
      "terms": {
        "field": "model.keyword"
      },
      "aggs": {
        "color_count": {
          "cardinality": {
            "field": "color.keyword"
          }
        },
        "color_count_filter": {
          "bucket_selector": {
            "buckets_path": {
              "colorCount": "color_count"
            },
            "script": "params.colorCount>1"
          }
        }
      }
    }
  }
}

返回结果如下：

{
  "took": 39,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 13,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "models": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "A",
          "doc_count": 5,
          "color_count": {
            "value": 4
          }
        },
        {
          "key": "C",
          "doc_count": 5,
          "color_count": {
            "value": 5
          }
        },
        {
          "key": "B",
          "doc_count": 2,
          "color_count": {
            "value": 2
          }
        }
      ]
    }
  }
}

此时返回结果只包含颜色数大于1的模型，但大家会发现颜色数多的 C 不是在第一个位置，我们还需要做排序处理。

5. Order By Limit VS Bucket Sort Aggregation

ORDER BY color_count desc LIMIT 3 在 Elasticsearch 中可以使用 Bucket Sort 聚合实现，语句如下所示：

GET cars/_search
{
  "size": 0,
  "aggs": {
    "models": {
      "terms": {
        "field": "model.keyword"
      },
      "aggs": {
        "color_count": {
          "cardinality": {
            "field": "color.keyword"
          }
        },
        "color_count_filter": {
          "bucket_selector": {
            "buckets_path": {
              "colorCount": "color_count"
            },
            "script": "params.colorCount>1"
          }
        },
        "color_count_sort": {
          "bucket_sort": {
            "sort": {
              "color_count": "desc"
            },
            "size": 2
          }
        }
      }
    }
  }
}

返回结果如下：

{
  "took": 32,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 13,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "models": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "C",
          "doc_count": 5,
          "color_count": {
            "value": 5
          }
        },
        {
          "key": "A",
          "doc_count": 5,
          "color_count": {
            "value": 4
          }
        }
      ]
    }
  }
}

至此我们便将 SQL 语句实现的功能用 Elasticsearch 查询语句实现了。对比 SQL 语句与 Elasticsearch 的查询语句，大家会发现后者复杂了很多，但并非无章可循，随着大家对常见语法越来越熟悉，相信一定会越写越得心应手！

1. es主节点的垃圾回收配置经验分享 http://t.cn/R3YGdzY

2. ES工程师使用Elastic Stack记录弟弟的旅行轨迹 http://t.cn/R3YGdzl

3. 一周热点：技术人最重要的能力是什么？ http://t.cn/RuPYCdR

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/627

• 订阅：https://tinyletter.com/elastic-daily

1. 基于elk和zipkin的分布式追踪系统。 http://t.cn/R3CO5BM

2. Elasticsearch的选举机制。 http://t.cn/R3COV8R

3. 各大厂分布式链路跟踪系统架构对比。 http://t.cn/R3COiRs

• 编辑：金桥

• 归档：https://elasticsearch.cn/article/624

• 订阅：https://tinyletter.com/elastic-daily