Elasticsearch解决问题之道——请亮出你的DSL

0、引言

在业务开发中，我们往往会陷入开发的细枝末节之中，而忽略了事物的本源。

经常有同学问到：

等等等等…

以上的看似复杂的问题，如果转换成DSL，清楚的写出来，梳理清楚问题的来龙去脉，问题就自然解决了一大半。

所以，请亮出你的dsl,不论什么语言的检索，转换到es查询都是sql查询，在es中对应dsl语法，es再拆解比如：分词match_phrase拆解成各term组合，最终传给lucene处理。

亮出你的dsl,确保编程里的实现和你的kibana或者head插件一致是非常重要、很容易被忽视的工作。

如果对dsl拆解不理解，那就再 加上 profile:true或者explain:true拆解结果一目了然。

维基百科定义：领域特定语言（英语：domain-specific language、DSL）指的是专注于某个应用程序领域的计算机语言。又译作领域专用语言。

Elasticsearch提供基于JSON的完整查询DSL来定义查询。 将Query DSL视为查询的AST（抽象语法树），由两种类型的子句组成：

1、叶子查询子句

叶查询子句查找特定字段中的特定值，例如匹配，术语或范围查询。 这些查询可以单独使用。

2、复合查询子句

复合查询子句可以组合其他叶子或复合查询，用于以逻辑方式组合多个查询（例如bool或dis_max查询），或更改其行为（例如constant_score查询）。

给个例子，一看就明白。

看到这里，可能会有人着急了：“我X，这不是官网定义吗？再写一遍有意思吗？”

引用一句鸡汤话，“再显而易见的道理，在中国，至少有一亿人不知道”。同样的，再显而易见的问题，在Elasticsearch技术社区也会有N多人提问。

基础认知不怕重复，可怕的是对基础的专研、打磨、夯实。

Elasticsearch相关的核心 *** 作，广义上可做如下解读，不一定涵盖全，仅抛砖引玉，说明DSL的重要性。

从大到小。

集群的管理，一般我们会使用Kibana或者第三方工具Head插件、cerebro工具、elastic-hq工具。

基本上硬件的（磁盘、cpu、内存）使用率、集群的 健康 状态都能一目了然。

但基础的DSL会更便捷，便于细粒度分析问题。

如：集群状态查询：

如：节点热点线程查看：

如：集群分片分配情况查看：

索引生命周期是一直强调的概念，主要指索引的“生、老、病、死”的全过程链条的管理。

创建索引我们优先使用较单纯index更灵活的template模板。

创建索引类似Mysql的创建表的 *** 作，提前设计好表结构对应ES是提前设计好M app ing非常重要。

两个维度：

举例：

如：索引清理缓存。

如：某原因导致分片重新分配，_recovery查看分片分配状态。

高版本的索引生命周期管理推荐使用：ILM功能。

这个是大家再熟悉不过的了。

举例：

删除数据包括：指定id删除 delete和批量删除delete_by_query（满足给定条件）。

更新 *** 作。包括：指定id的update/upsert或者批量更新update_by_query。

这是ES的重头戏。包含但不限于：

1、支持精确匹配查询的：term、range、exists、wildcard、prefix、fuzzy等。

2、支持全文检索的：match、match_phrase、query_string、multi_match等

1、Bucketing分桶聚合

举例：最常用的terms就类似Mysql group by功能。2、Metric计算聚合

举例：类比Mysql中的： MIN, MAX, SUM *** 作。3、Pipeline针对聚合结果聚合

举例：bucket_script实现类似Mysql的group by 后having的 *** 作。

留给大家 结合 业务场景思考添加。

这里把开头提到的几个问题逐一解答一下。

实际Mysql业务中，我们一般是先验证sql没有问题，再写业务代码。

实际ES业务中，也一样，先DSL确认没有问题，再写业务代码。

写完java或者python后，打印DSL，核对是否完全一致。

不一致的地方基本就是结果和预期不一致的原因所在。

第一步：借助analyzer API分析查询语句和待查询document分词结果。

这个API的重要性，再怎么强调都不为过。

第二步：可以借助profile:true查看细节。第三步：核对match_phrase词序的原理。

63版本后已经支持sql，如果不会写，可以借助translate 如下API翻译一下。

不够精确，但足够参考用了，需要根据业务细节微调。

当然，还是 建议 ，从业务出发，自己写DSL。

从大往小，逐步细化排解

END

公众号 ( zhisheng )里回复 面经、ES、Flink、 Spring、Java、Kafka、监控 等关键字可以查看更多关键字对应的文章

1、《从0到1学习Flink》—— Apache Flink 介绍

2、《从0到1学习Flink》—— Mac 上搭建 Flink 160 环境并构建运行简单程序入门

3、《从0到1学习Flink》—— Flink 配置文件详解

4、《从0到1学习Flink》—— Data Source 介绍

5、《从0到1学习Flink》—— 如何自定义 Data Source ？

6、《从0到1学习Flink》—— Data Sink 介绍

7、《从0到1学习Flink》—— 如何自定义 Data Sink ？

8、《从0到1学习Flink》—— Flink Data transformation(转换)

9、《从0到1学习Flink》—— 介绍 Flink 中的 Stream Windows

10、《从0到1学习Flink》—— Flink 中的几种 Time 详解

11、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 ElasticSearch

12、《从0到1学习Flink》—— Flink 项目如何运行？

13、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 Kafka

14、《从0到1学习Flink》—— Flink JobManager 高可用性配置

15、《从0到1学习Flink》—— Flink parallelism 和 Slot 介绍

16、《从0到1学习Flink》—— Flink 读取 Kafka 数据批量写入到 MySQL

17、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 RabbitMQ

18、《从0到1学习Flink》—— 你上传的 jar 包藏到哪里去了

19、大数据“重磅炸d”——实时计算框架 Flink

20、《Flink 源码解析》—— 源码编译运行

21、为什么说流处理即未来？

22、OPPO数据中台之基石：基于Flink SQL构建实数据仓库

23、流计算框架 Flink 与 Storm 的性能对比

24、Flink状态管理和容错机制介绍

25、原理解析 | Apache Flink 结合 Kafka 构建端到端的 Exactly-Once 处理

26、Apache Flink 是如何管理好内存的？

27、《从0到1学习Flink》——Flink 中这样管理配置，你知道？

28、《从0到1学习Flink》——Flink 不可以连续 Split(分流)？

29、Flink 从0到1学习—— 分享四本 Flink 的书和二十多篇 Paper 论文

30 、360深度实践：Flink与Storm协议级对比

31、Apache Flink 19 重大特性提前解读

32、如何基于Flink+TensorFlow打造实时智能异常检测平台？只看这一篇就够了

33、美团点评基于 Flink 的实时数仓建设实践

34、Flink 灵魂两百问，这谁顶得住？

35、一文搞懂 Flink 的 Exactly Once 和 At Least Once

36、你公司到底需不需要引入实时计算引擎？

游戏 行业是阿里云最早聚焦的行业之一，近年来 游戏 行业的变化、云计算产品技术的变化都与日俱进。随着行业业务的变化、技术架构的演进以及阿里云产品的迭代演进，整体的产品技术选型在不同的 游戏 场景、业务场景也不尽相同。本文将聚焦阿里云d性计算产品在 游戏 行业的方案实践经验。

当前， 游戏 行业的各种场景和行业发展密不可分。简单回顾电子 游戏 的发展，80年代的黑白机，90年代的PC单机 游戏 ，00年代前夕随着互联网的发展网络 游戏 开始盛行，2010年后随着移动设备的逐渐普及，手游在国内开始兴起。

从 游戏 终端来区别，主要有：主机 游戏 （往往是3A 游戏 ）、PC 游戏 、移动 游戏 和网页 游戏 等。目前出现跨平台多端 游戏 ，以及云 游戏 化的趋势。

关于 游戏 的品类区别会有非常多的维度：RPG（角色扮演）、MOBA类、竞技类、FPS（射击类）、休闲类、卡牌类、棋牌类、SLG（策略类）等等。目前有多品类融合玩法裂变的趋势。

随着国内防沉迷、版号因素，近年来 游戏 行业诞生了越来越多的精品 游戏 ，出海全球化乃至区域化，以及整体存量用户增速放缓，长线运营、精细运营以及私域社区等运营方式也在悄然变化。

不同的业务场景技术架构不尽相同，如竞技类 游戏 和卡牌类 游戏 对计算的需求就有所区别，云 游戏 与常规的网络 游戏 架构也有所区别。这里主要从 游戏 服和 游戏 平台、大数据、云 游戏 这四个目前常见的场景简单介绍其架构。

游戏 服，从 游戏 类型来看有RPG、FPS、MOBA、SLG、棋牌、休闲等等；从 游戏 平台来看通常有主机、手机、PC等；从业务发行来看有全球、国内、海外，从部署架构来看有集中部署和分区部署；从技术架构来看， 游戏 行业也有逐渐分层解耦的趋势，但与互联网应用相比，有一定其独特性。

因为 游戏 的强交互性特点， 游戏 技术架构与其他互联网应用相比有一定独特性。 游戏 需要保持会话连接，也就是从一个客户端到服务端的长连接，便于对客户端中玩家的 *** 作、行为等进行及时的反馈以及推送给共同 游戏 或对战的其他玩家,所以 游戏 普遍对网络质量更加敏感，网络质量较差的情况会使长连接断开或重连，引起玩家掉线。 游戏 也需要保持会话的状态，既服务端会保持一份玩家的实体，当玩家进行 *** 作时，下次通信的数据会依赖之前的通信的数据，这也是一些MMO（多人在线）大型 游戏 对网络吞吐性能要求较高的原因之一。再比如FPS、MOBA类等多人对战类 游戏 ，交互性更强，对网络延迟容忍度更低，要求低延迟。因为 游戏 需要比较高密度的记录玩家的 *** 作以及结果，所以有频繁写入数据的特点，这类场景需要较强的IO性能。因为 游戏 强交互性、低延迟的特点，其技术架构也和互联网应用不同，在逐渐分层解耦的同时，需要保证 游戏 玩家的交互效果，同时也会依赖到底层服务器的计算能力。

这些都是 游戏 场景普遍存在的特点：长连接保持会话、保持状态、低延迟网络、高IO吞吐、高计算性能。

游戏 的部署架构会结合 游戏 业务特点、 游戏 运营需求来制定 游戏 服务，有分区分服、全区全服业务逻辑，分区分服还是全区全服，最大的架构差异在于数据是不是一套。而从部署方式看，主要是集中式部署和分区域部署。

集中部署就是不论 游戏 玩家在哪里， 游戏 服务集中在一个区域，适合对网络延迟要求通常不高的 游戏 类型，如休闲类；分区部署是指 游戏 服务器根据 游戏 玩家地域分布，分区域部署，方便就近接入，适合对网络延迟要求较高的 游戏 类型，如MOBA、FPS类。

典型架构

MMO类有高并发特点，大量玩家并发的高计算量负载对服务器的计算能力和稳定性有着极高的要求。同时MMO类 游戏 有着比较强的PVE或PVP特性，对网络延迟的容忍度较低。

其中网关服务器负责所有网络数据包的转发，通常是网络负载较集中的点，对于网络吞吐能力要求较高。单个 游戏 区承载玩家数量高，逻辑服务器通常按照场景地图来划分，规模再大会通过分区的方式实现。

数据中心服务器负责缓存玩家数据并异步入库，保障玩家客户快速获取和写入数据，对于可用性要求较高，需要配合应用层实现数据容错机制。

日志服务器承载了大区所有业务行为的日志收集及处理的压力，对磁盘写入性能要求较高，通常采用多台分组方式实现。

（1）MMO 游戏 服性能与稳定需求，建议使用最第7代ECS实例，根据实际需求选型c计算型（CPU与内存配比1:2）/g通用型（1:4）/r内存型（1:8），Intel Ice Lake 29GHz基频35GHz睿频提供超高性能，能更好地优化 游戏 体验。

（2）异步落库以及日志服务器，对于磁盘读写性能要求高的场景，建议云上使用ESSD PL 0/1/2/3根据业务性能需要选择，避免磁盘读写瓶颈。

（3）在 游戏 日常版本更新中，需要各个地域Region镜像的快速复制，基于ESSD快照异地复制的能力，能够提升镜像复制效率。

（4）分区分服等场景往往需要快速地开服滚服合服，通过CADT云速搭、ESSd性伸缩、OOS运维编排、ROS资源编排等云上运维工具搭配产品使用，能够提升云上运维效率。

ii FPS、MOBA类 游戏 架构介绍

MOBA类 游戏 主要包括PVP系统、PVE系统、 游戏 平台等几个主要部分，其中PVP战斗是MOBA/FPS 游戏 的核心。

PVP、PVE、 游戏 平台功能部署于同一VPC中，构成 游戏 大区；战斗服务器（往往）单独跨地域部署。

游戏 客户端首先接入到登录服务器中，完成登录认证、计费等 游戏 平台逻辑。为避免单点问题，所以 游戏 平台服务往往需要高可用方案。可利用云上高可用方案，包括便捷的运维工具满足业务高可用需求。

FPS/MOBA竞技 游戏 ，往往对延迟特别敏感，可以想象，竞技类 游戏 中对战的 游戏 场景：玩家 *** 控人物，在地图里步伐飘逸，q声密集，每一颗子d都是一次时间加上空间的矢量计算，而且需要在主进程中完成计算，那么算力需求就随着房间玩家数量上升而指数爆炸，5V5的房间和大房间100人（吃鸡）对算力的需求完全不同。

游戏 这部分重算力场景，推荐阿里云7代高主频或七代实例，更高的单核性能提供更好的战斗效果。

战斗房间类 游戏 ，因为业务本身峰谷特性，灵活地使用云上资源的d性能力，往往会较好地优化整体的资源使用成本。阿里云d性计算本身提供了非常灵活的付费方式，包括常规的按量实例、包月包年实例、以及通过节省计划/预留实例券去抵扣按量实例资源，兼顾资源灵活使用的同时达到更优的成本。

此外，为更进一步释放开发运维的效率，当前一些 游戏 也采用了容器化技术架构，阿里云的ACK+ECS/ECId性容器实例组合搭配使用，更进一步释放了基础资源的灵活性和d性能力。

业务场景

游戏 平台（不限于FPS、MOBA类）主要提供的服务：官网、客服、注册、登录、充值、兑换、商城、推送、公告、社区、SDK及邮件、短信等公共服务；包括内容审核、视频录制、d幕、转码、剪辑、RTC这些业务需要的基础服务，以及运维监控、发布平台、测试平台这些运维等平台服务。

这部分更接近于通用的互联网技术架构，以服务为颗粒度解耦，接入->网关->应用->数据库。

技术特点

这往往通常需要构建高可用基础架构来提升稳定性，业务突发期往往需要一定的d性能力。相比于 游戏 服务这部分容器化就更加普及，也更容易通过云上的比如d性容器实例去应对流量峰值场景。在视频录制场景，对实时性要求较高时，往往会基于GPU能力构建，这部分阿里云也提供了vGPU/cGPU能力，释放GPU的灵活性。

大数据是当前 游戏 业务经营、 游戏 运营主要的技术手段，主要面向平台数据运营、 游戏 数据分析、广告转化分析、安全运营分析等 游戏 核心运营场景。不同的场景对实时性要求不同，实时查询检索通常是经营分析、客户受理、玩家监测、在线等场景；离线报表通常是玩家行为分析、用户画像、特征挖掘等场景。

总体而言，实时性业务更多是业务查询类、简单计算类任务，比如买量转化的分析；离线类基本是分析类、预测类任务，比如 游戏 玩法分析。

从技术架构来看，得益于开源社区技术栈的高丰富度，大数据具体的技术选择非常之多，整体从存算一体到存算分离，也诞生像数据仓库、数据湖乃至湖仓一体等概念。

从数据架构流程来看，从数据源->数据采集、传输->数据计算、存储->数据应用，其中可选看技术方案也需要因地制宜。

从部署架构来看，不同的 游戏 公司处在不同的数据建设阶段，会有不同的选择倾向，包括完全自建、基于云自建大数据、基于云上托管、以及利用更多云上成熟的产品技术去丰富整体的大数据能力集，而后者也成为越来越多客户的选择。

拿云上大数据方案举例来讲，比如实时计算部分，选择SLS采集、Kafka数据网关通道，通过Flink做数据计算，通过ES或CK做数据分析，通过ADB以及QuickBI做数据应用展示。离线方案通过OSS做冷数据存储，Spark、Hive、HDFS等组件做数据计算存储，通过CK汇聚分析，通过Dataworks做数据应用。

具体计算存储的产品选型，主要根据不同的业务特性以及大数据应用特性来区分，根据数据容量、IOPS、吞吐、读写特点以及性价比来选择。

如刚刚举例的实时计算/近实时计算场景，Flink具备高性能、低延迟特点，所以是计算密集、网络性能高场景，推荐选型七代ECS实例或6代增强实例；如HDFS需要超大存储容量，高吞吐，推荐D系列本地盘实例，如D2S存储型本地盘实例。Remote Shuffle Service等处理结果多的场景，读写处理频繁如大量的join计算，需要综合来看计算、网络、存储性能以及综合成本来选择通用实例（如第7代ECS实例）或i系列本地盘实例。所以，最终在云上的资源选型，在性能满足的前期下，需要评估通过网络传输数据成本高（云盘），还是就地取材计算成本高（本地盘），不同模型、不同量级选择不同。

从内存处理（成本最高、性能最好、存储容量最小）、SSD本地盘、HDD本地盘、ESSD云盘、OSS对象存储（成本最优、性能一般、存储容量最大），逐渐分层解耦，还带来一个好处：充分释放了云上d性的能力，可以利用更轻巧的d性计算产品（如SPOT抢占式实例方式，或ECI容器实例）进行大数据计算，达到更好的d性能力去满足业务需求的同时也能节约更多的成本。

云 游戏 主要分终端和云端。终端部分基于Windows、iOS、Linux等 *** 作系统的终端设备包括手机、平板、电脑、电视机、VR一体机等。云端架构主要是 游戏 应用层、云 游戏 平台层、IaaS基础资源层，应用层包括PC 游戏 、手游、VR 游戏 、H5 游戏 等多种类型的 游戏 应用；平台层云 游戏 必须的运营平台、支撑平台、流化技术平台等；IaaS基础资源层包括基础网络、基于X86架构以及ARM架构的GPU服务器。

云 游戏 落地，在技术上也经历了诸多挑战，为满足端到端高性能低时延，网络调度、指令串流、编解码、多终端的SDK适配等等都是云 游戏 场景中不可避免的技术问题。

对于云端算力来讲，阿里云解决了云端渲染、串流以及编解码问题，并通过全系列GPU产品来满足云手游、端游、VR乃至企业级视觉渲染场景的需求。

总结来讲，阿里云d性计算通过云上的串流、编码加速、渲染加速等全套的技术帮助 游戏 客户给云 游戏 玩家提供更好的性能体验，通过基于阿里云全球数据中心可以帮助云 游戏 客户覆盖更多的用户，通过GPU多种产品形态和整体的d性能力，也帮助到 游戏 客户去更快捷更灵活的构建其云 游戏 业务。

阿里云通过多年的技术积累和持续的运营，提供了大规模的基础设施云服务，目前在全球部署了26个地域、82个可用区，通过优异稳定的性能表现帮助 游戏 客户高效稳定地运行 游戏 业务，为玩家提供极致顺滑的 游戏 体验，并通过技术手段不断地帮助 游戏 客户优化用云成本。

国内的业务出海、 游戏 出海也是现阶段大的趋势之一，很多 游戏 公司已经把出海从业务可选项变成了必选项之一。在2022年3月，阿里云上线了韩国和泰国两大Region，能够为本地化的 游戏 业务提供更流畅、更稳定的 游戏 体验，以此希望能在 游戏 客户出海的业务领域，提供更多的帮助。

当然，作为内容与 科技 两大热门领域的交叉领域， 游戏 产业日新月异，架构也随着前端业务的需要不断改变。阿里云d性计算也针对 游戏 厂商的不同架构，陆续推出了不同的云服务器类型和付费方式，以及云上运维套件，以帮助客户降本增效。

原文链接：>在local模式下，不需要启动任何的进程，仅仅是使用本地线程来模拟flink的进程，适用于测试开发调试等，这种模式下，不用更改任何配置，只需要保证jdk8安装正常即可

将我们编译之后的压缩包，上传到node01服务器的/kkb/soft路径下，然后进行解压

cd /kkb/soft/

tar -zxf flink-181targz -C /kkb/install/

flink在处于local模式下，不需要更改任何配置，直接解压之后启动即可

执行以下命令直接启动local模式

cd /kkb/install/flink-181

bin/start-clustersh

启动成功之后，执行jps就能查看到启动了两个进程

18180 StandaloneSessionClusterEntrypoint

18614 TaskManagerRunner

启动两个进程成功之后，访问8081端口号即可访问到flink的web管理界面

>