作者：京东零售 崔健

0.前言

• 系统概要：BIP采购系统用于京东采销部门向供应商采购商品，并且提供了多种创建采购单的方式以及采购单审批、回告、下传回传等业务功能

• 系统价值：向供应商采购商品增加库存，满足库存周转及客户订单的销售，供应链最重要的第一环节

1.背景

采购系统在经历了多年的迭代后，在数据库查询层面面临巨大的性能挑战。核心根因主要有以下几方面：

• 复杂查询多，历史上通过MySQL和JED承载了过多的检索过滤条件，时至今日很难推动接口使用方改变调用方式

• 数据量大，随着业务的持续发展，带来了海量的数据增长（日均150万单左右，订单主表/子表/渠道表/扩展表分别都是：6.5亿行，订单明细表/分配表：9.2亿行，日志表：60亿行）

• 数据模型复杂，订单完整数据分布在20+张表，经常需要多表join

引入的主要问题有：

• 业务层面：

  • 订单列表页查询/导出体验差，性能非常依赖输入条件，尤其是在面对订单数据倾斜的时候，部分用户无法查询/导出超过半个月以上的订单

  • 查询条件不合理，1.归档筛选条件，技术词汇透传到业务，导致相同周期的单子无法一键查询/导出，需要切换“是否归档”查询全部；2.无法区分“需要仓库收货”类的单子，大部分业务同事主要关注这类单子的履约情况

• 技术层面：

  • 慢SQL多，各种多表关联复杂条件查询导致，索引、SQL已经优化道了瓶颈，经常出现数据库负载被拉高

  • 大表多，难在数据库上做DDL，可能会引起核心写库负载升高、主从延迟等问题

  • 模型复杂，开发、迭代成本高，查询索引字段散落在多个表中，导致查询性能下降

2.目标

业务层面：提升核心查询/导出体验，加强查询性能，优化不合理的查询条件

技术层面：1.减少慢SQL，降低数据库负载，提高系统稳定性；2.降低单表数据量级；3.简化数据模型

3.挑战

提升海量数据、复杂场景下的查询性能！

• 采购订单系统 VS C端销售订单系统复杂度对比：

4.方案

思路

优化前



优化后

4.1 降低查询数据量

4.1.1 前期调研

基于历史数据、业务调研分析，采购订单只有8%的订单属于“需要实际送货至京东库房”的范围，也就是拥有完整订单履约流程、业务核心关注时效的。其余订单属于通过客户订单驱动，在采购系统的生命周期只有创建记录



基于以上结论，在与产品达成共识后，提出新的业务领域概念：“入库订单” ，在查询时单独异构这部分订单数据（前期也曾考虑过，直接从写入层面拆分入库订单，但是因为开发成本、改动范围被pass了）。异构这部分数据实际也参考了操作系统、中间件的核心优化思路，缓存访问频次高的热数据

4.1.2 入库订单异构

执行流程





• “入库”订单数据打标

  • 增量订单在创建订单完成时写入；存量订单通过离线表推数

  • 需要订单创建模块先完成改造上线，再同步历史，保证数据不丢

  • 如果在【数据解析模块】处理binlog时无法及时从JimKV获取到订单标识，会补偿反查数据库并回写JimKV，提升其他表的binlog处理效率

• binlog监听

  • 基于公司的【数据订阅】任务，通过消费JMQ实现。其中订阅任务基于订单号进行MQ数据分区，并且在消费端配置不允许消息重试，防止消息时序错乱

  • 其中，根据订单号进行各个表的MQ数据分区，第一版设计可能会引起热分区，导致消费速率变慢，基于这个问题识别到热分区主要是由于频繁更新订单明细数据导致（订单(1)->明细(N)），于是将明细相关表基于自身id进行分区，其他订单纬度表还是基于订单号。这样既不影响订单数据更新的先后顺序，也不会造成热分区、还可以保证明细数据的准确性

• 数据同步

  • 增量数据同步可以采用源库的增量binlog进行解析即可，存量数据通过申请新库/表，进行DTS的存量+增量同步写入，完成binlog生产

  • 以上是在上线前的临时链路，上线后需要切换到源库同步binlog的增量订阅任务，此时依赖“位点回拨”+“数据可重入”。位点回拨基于订阅任务的binlog时间戳，数据可重入依赖上文提到的MQ消费有序以及SQL覆盖写

• 数据校对

  • 以表为纬度，优先统计总数，再随机抽样明细进行比对

  • 目前入库订单量为稳定在5000万，全部实时订单量级6.5亿，降低92%

4.2 提升复杂查询能力

4.2.1 数据准备

• 考虑到异构“入库”订单到JED，虽然数据查询时效性可以有一定保障，但是在复杂查询能力以及识别“非入库”订单还没有支持

• 其中，“非入库”订单业务对于订单数据时效性要求并不高（1.订单创建源于客户订单；2.没有履约流程；3.无需手动操作订单关键节点）

• 所以，考虑将这部分查询能力转移到ES上

ES数据异构过程





• 首先，同步到ES的数据的由“实时+归档”订单组成，其中合计20亿订单，顺带优化了先前归档ES大索引（所有订单放在同一个索引）的问题，改成基于“月份”存储订单，之所以改成月份是因为根据条件查询分两种：1.一定会有查询时间范围（最多3个月）；2.指定单号查询，这种会优先检索单号对应的订单创建时间，再路由到指定索引

• 其次，简化了归档程序流程，历史方案是程序中直接写入【归档JED+归档ES】，现在优化成只写入JED，ES数据通过【数据解析模块】完成，简化归档程序的同时，提高了归档能力的时效性

• 再次，因为ES是存储全量订单，需要支持复杂条件的查询，所以在订单没有物理删除的前提下，【数据解析模块】会过滤所有delete语句，保证全量订单数据的完整性

• 接着，为了提升同步到ES数据的吞吐，在MQ消费端，主要做了两方面优化：1.会根据表和具体操作进行binlog的请求合并；2.降低对于ES内部refresh机制的依赖，将2分钟内更新到ES的数据缓存到JimKV，更新前从缓存中获取

• 最后，上文提到，同步到入库JED，有的表是根据订单号，有的表是根据自身id。那么ES这里，因为NoSQL的设计，和线程并发的问题，为了防止数据错误，只能将所有表数据根据单号路由到相同的MQ分区

4.2.2 查询调度策略设计

优化前，所有的查询请求都会直接落到数据库进行查询，可以高效查询完全取决于用户的筛选条件是否可以精准缩小数据查询范围

优化后，新增动态路由层

• 离线计算T-1的采销/供应商的订单数据倾斜，将数据倾斜情况推送到JimDB集群

• 根据登陆用户、数据延迟要求、查询数据范围，自动调度查询的数据集群，实现高性能的查询请求

查询调度



5.ES主备机制&数据监控

1.主/备ES可以通过DUCC开关，实现动态切换，提升数据可靠性

2.结合公司的业务监控，完成订单数据延迟监控（数据同步模块写入时间-订单创建时间）

3.开启消息队列积压告警

5.1 ES集群主/备机制

1：1ES集群进行互备，应急预案快速切换，保证高可用



5.2 数据监控



6.灰度上线

• 第一步，优先上线数据模块，耗费较多时间的原因：1.整体数据量级以及历史数据复杂度的问题；2.数据同步链路比较长，中间环节多

• 第二步，预发环境验证，流量回放并没有做到长周期的完全自动化，根因：1.项目周期相对紧张；2.新老集群的数据还是有一些区别，回放脚本不够完善

• 第三步，用户功能灰度，主要是借助JDOS的负载均衡策略结合用户erp完成

• 第四部，对外接口灰度，通过控制新代码灰度容器个数，逐步放量



7.成果

平稳切换，无线上问题

8.待办

• 主动监控层面，新增按照天纬度进行数据比对、异常告警的能力，提高问题发现率

• 优化数据模型，对历史无用订单表进行精简，降低开发、运维成本，提升需求迭代效率

• 精简存储集群

  • 逐步下线其他非核心业务存储集群，减少外部依赖，提高系统容错度

  • 目前全量订单ES集群已经可以支持多场景的外部查询，未来考虑是否可以逐步下线入库订单JED

• 识别数据库隐患，基于慢日志监控，重新梳理引入模块，逐步优化，持续降低数据库负载

• MySQL减负，探索其他优化方案，减少数据量存储，提升数据灵活性。优先从业务层面出发，识别库里进行中的僵尸订单的根因，进行分类，强制结束

• 降级方案，当数据同步或者数据库存在异常时，可以做到秒级无感切换，提升业务可用率

9.写在最后

• 为什么没考虑Doris？因为ES是团队应用相对成熟的中间件，处于学习、开发成本考虑

• 未来入库的JED相关表是否可以下掉，用ES完全替代？目前看可以，当初设计冗余入库JED也是出于对于ES不确定性以及数据延迟的角度考虑，而且历史的一部分查询就落在了异构的全量实时订单JED上。现在，JED官方也不是很推荐非route key的查询。最后，现阶段因为降低了数据量和拆分了业务场景，入库JED的查询性能还是非常不错的

• 因为项目排期、个人能力的因素，在方案设计上会有考虑不周的场景，本期只是优化了最核心的业务、技术痛点，未来还有很大持续优化的空间。中间件的使用并不是可以优化数据库性能的银弹，最核心的还是要结合业务以及系统历史背景，在不断纠结当中寻找balance

使用painless脚本为文档自定义打分是很常见的场景，对新人来说也是最容易造成性能问题的地方。本文中使用两个例子简单谈一下脚本性能优化。

目标

ES本身是基于倒排等数据结构实现的查询，因此在做类似Term、Match等可以利用底层数据结构的场景进行查询时，性能是很好的。

脚本和term等查询不一样，无法利用现有的各种数据结构，可以简单理解成循环：

docs = getDocs(xxx); // 获取满足条件的文档列表
for(Doc doc : docs) {
    score = getScoreByScript(doc);
}

因此脚本的性能取决于两个地方：脚本的复杂度和满足条件的文档数。

例子1

我们有个场景是查询指定坐标指定范围内的POI列表，例如5公里内的景点列表。

由于我们的距离公式和ES默认的都不一致，如下：

/**
 * 计算距离，返回单位：米
 */
public static Double getDistance(Double lat1, Double lng1, Double lat2, Double lng2) {
    double diffLon = Math.abs(lng1 - lng2);
    if (diffLon > 180)
        diffLon -= 360;
    return Math.sqrt(Math.pow(diffLon, 2) + Math.pow(lat1 - lat2, 2)) * 110.0 * 1000;
}

所以该同学把这段Java代码转成了Painless，在sort里使用这个该方法计算出距离。上线以后发现ES有了很多慢查询，对应的服务也95线、99线也比较高。

原因是其他脚本没有有效地缩小数据量，导致有几百万的数据需要使用该脚本做距离计算，给ES的CPU造成很大压力，查询性能也比较差。

该例子优化起来很简单，即使用ES自带的distance做较大范围的限制，例如需要5公里的数据，可以用ES的plain距离做限制，再加上之前的自定义脚本逻辑。由于ES的plain距离计算性能好很多，因此经过该过滤以后，自定义脚本的文档量少了很多，因此整体性能有了很大提升。

例子2

有个场景是对文章进行搜索，如果文章关联的城市是指定的几个城市，则给额外的加分。例如：

{
    "query": {xxx},
    "sort": [
    {
      "_script": {
        "script": {
          "source": "def score = 0;def cityIds = doc['cityIds']; def paramCityIds = params.cityIds; for (int i=0; i<cityIds.size(); i++){if (paramCityIds.contains(cityIds[i])){score += 100;}} return score;",
          "lang": "painless",
          "params": {
            "cityIds": [2,1,3]
          }
        },
        "type": "number",
        "order": "desc"
      }
    }
    ]
}

问题和例子1一样，该功能的性能比较差。虽然脚本简单，但是满足的文档量比较大，带来的计算量也比较多，因此性能上不去。

这是一个比较常见的场景，问题的根源还是对ES的机制不够了解，优化起来也很简单，想办法利用到倒排就可以了。

ES里有个专门针对改场景的查询：constant_score，因此以上查询可以修改为：

{
    "query": {
        "should": [
            {
                    "constant_score": {
                        "filter": {
                            "term": {
                                    "cityIds": 2
                            }
                        },
                        "boost": 5
                     }
            },
            {
                    "constant_score": {
                        "filter": {
                            "term": {
                                    "cityIds": 1
                            }
                        },
                        "boost": 5
                     }
            },
            {
                    "constant_score": {
                        "filter": {
                            "term": {
                                    "cityIds": 3
                            }
                        },
                        "boost": 5
                     }
            }
        ]
    },
    "sort": [
    {
      "_score": "desc"
    ]
}

性能即可得到极大改善。

从2018年7月在开始在某阿里云数据中心部署Elasticsearch软件，到2018年12月共创建了15个集群，服务于客户的文档检索、交通视频检索、地理信息检索、日志安全审计等业务。其中数据规模最大的一个业务，共有800张表，7万亿条数据，每天新增500亿条记录，数据要求存储半年，单条记录大小1KB左右，存储规模约10PB，需要支持1000并发查询。

一、数据存储空间规划。

数据中心能用于搭建Elasticsearch集群的SSD盘共700TB，SATA盘共50PB。根据业务类型、时间范围划分热数据和冷数据，一部分重要数据存储在SSD盘的热数据集群，其它数据存储在SATA盘的冷数据集群。热数据集群主要存储各类实体信息，包括人员、物品、事件、地址、组织数据，以及最新轨迹数据。冷数据集群主要存储历史轨迹信息。热数据和冷数据按照业务拆分多个小集群，每个集群规模保持在50个节点左右，单个集群最大不超过200个节点。利用阿里云平台弹性伸缩的能力，每个Elasticsearch集群可以先从小规模创建，根据资源使用情况来弹性扩展节点规模。

Elasticsearch集群节点配置

二、索引设计。

1.索引别名(alias)。每类数据根据数据源表名建立索引(index)，索引中只包含一个类型(type)。配置索引别名(alias),业务上根据别名写入、查询数据，索引重建等数据维护操作可以通过别名切换对业务透明。

2.按时间分表。轨迹类数据按时间(日/月)拆分，每个索引存储数据量保持在1TB(10亿)左右，索引名带上日期/月份后缀，拆分后的索引配置别名区分冷热数据。配置索引模板，指定索引分片数和副本数、字段类型、分词器。配置Linux crontab定时任务，通过shell脚本创建索引。

3.分片(shard)设置。索引按照单个分片10-40GB数据大小设计分片数，数据量少于10GB(1000万)的索引设置1个分片即可，数据量大于1TB(10亿)的索引设置分片数为集群节点数整数倍(例如50个节点的集群配置50个分片)。

4.副本(replica)设置。数据首次批量导入时索引副本数设置为0，快速写入数据。生产环境索引副本数设置为1，避免集群节点故障数据丢失。

三、索引mapping设计。

1.精心设计索引字段类型。在开发环境配置Elasticsearch允许自动创建索引，从数据源每张表取1000条记录批量写入Elasticsearch，自动创建索引mapping，然后再根据业务需要修改mapping配置合适的字段类型，指定字段索引分词器、是否存储、是否索引、是否合并至全文检索字段。 对于数据量大的表尤其要精心设计字段类型，尽量减少索引存储空间占用。在生产环境中建议配置不允许自动创建索引。

2.配置全文检索字段。如果业务需要全文检索，可以配置开启全文字段，同时需要占用更多存储空间；如果业务上只是按字段查询，可以配置禁用全文字段，减少存储空间。Elasticsearch5.X及之前的版本默认启用_all字段，合并所有字段的值。Elasticsearch6.X及之后的版本默认禁用_all字段，可以通过copy_to将多个字段值合并成一个全文字段。对于数据查全率要求高的业务场景，建议对全文字段配置cjk分词器(Elasticsearch和Lucene中自带，对中日韩文进行二元分词的分词器)。

3.通用字段统一命名。各个索引中的姓名、证件号码、时间（开始时间、结束时间）、地点（始发地、目的地）等常用字段统一命名。用户指定证件号、时间范围等精确字段查询条件时，可以使用统一的查询条件并行查询多个索引。

四、分词设置。

1.选择合适的分词器。Elasticsearch中内置了很多分词器：standard、cjk、nGram等,也可以安装ik、pinyin等开源分词器, 可以根据业务场景选择合适的分词器。 常用分词器： standard：Elasticsearch默认分词，英文按空格切分，中文按单个汉字切分。 cjk：根据二元索引（两个相邻的字作为一个词条）对中日韩文分词，可以保证查全率。 NGram：可以将英文按照字母切分，结合Elasticsearch的短语搜索（match_phrase）使用。 ik：比较热门的中文分词，能按照中文语义切分，可以自定义词典。 pinyin：可以让用户输入拼音，就能查找到相关的关键词。 对于查全率要求较高的场景，建议使用cjk分词，同时能支持比较快的响应速度。对于查准率要求较高的场景，建议使用ik分词。

CJK分词和IK分词对比(测试环境：Elasticsearch5.5.3，8335万条人员档案信息，10节点集群，单节点16核CPU、64G内存、2T SSD盘，1个线程批量写入，1个并发查询)

测试分词效果： curl -XPOST "http://localhost:9200/_analyze" -H 'Content-Type: application/json' -d' { "analyzer": "ik_max_word", "text": "南京市长江大桥" }'

2.NGram分词。对于像车牌号之类数字和字母连在一起的字符，默认会被切成一个完整词条，但是业务上又需要支持前缀、后缀模糊匹配，可以根据业务需求进行分词。车牌号建议增加一个分词字段，配置NGram分词器，切分1元至7元的组合。身份证号码建议增加分词字段，根据业务需要切分18位完整词条、前2位（省）、前4位（省市）、前6位（省市区县）、后4位、出生年月日、出生年份、出生年月、出生月日等组合。

3.单字分词。对于像姓名类字段，业务上需要支持完整匹配，又需要支持单字查询。可以配置1个keyword字段（不分词）；1个text字段（分词），分词器选择Elasticsearch默认分词器standard，按单个汉字切分。

五、数据写入策略。

1.批量离线数据导入。各类业务数据源主要在数据仓库MaxCompute(原ODPS)，为了把表数据从MaxCompute表导入到ElasticSearch集群中， 我们基于MaxCompute MapReduce开发了MaxCompute到ElasticSearch的数据导出作业，通过简单的配置就可以把数据导入到ElasticSearch中。 数据源在关系数据库RDS或者NoSQL的数据，可以通过配置DataWorks(dataX企业版)导入Elasticsearch集群。

2.实时数据导入。实时数据源主要是流式数据服务DataHub， 配置DataHub任务即可同步至Elasticsearch集群。也可以自己开发程序调用DataHub的SDK获取实时数据，经过业务处理后，调用ES Rest Client SDK批量写入Elasticsearch。

3.冷热数据自动迁移。轨迹类实时数据默认先写入热数据集群(SSD盘Elasticsearch集群)，对于热数据集群过期的索引(例如1个月前的索引)需要迁移到冷数据集群(SATA盘Elasticsearch)。为了实现数据跨集群迁移，我们开发了snapshot插件将索引备份到对象存储服务OSS或分布式文件系统盘古。配置定时任务，将热数据集群索引备份后，从冷数据集群恢复，然后再删除热集群中的过期索引，保持热数据集群只存储较小规模数据。冷数据集群的索引如果超过半年，则关闭索引，减少JVM堆内存占用。

4.配置索引主键字段。为了保证Elasticsearch集群和数据源记录的一致性，建议所有索引配置主键字段，而不是让Elasticsearch自动生成主键。配置数据业务主键字段作为Elasticsearch主键字段。如果没有主键字段，则将原始数据能确定记录惟一性的几个字段合并为主键，或者将所有字段值合并起来计算MD5值作为主键。

5.配置写入路由。如果业务上需要经常根据某个字段查询，例如用户ID、车牌号等的字段，写入时可以指定路由字段。

6.写入参数调优。调整数据写入任务参数，避免写入操作占用过多磁盘IO和CPU。使用批量请求，配置合理的写入线程数，调大索引刷新时间间隔refresh interval，调整事务日志translog同步策略。

六、数据查询策略。

1.冷热库异步查询。用户输入关键词查询时，优先从热数据集群查询，有结果立即返回，并估算命中记录条数。热数据集群命中结果集不足时，再查询冷数据集群。

2.跨集群搜索。业务上需要多个Elasticsearch集群一起参与检索时，可以通过Cross Cluster Search同时对多个集群发起检索请求合并检索结果。单独创建一个5节点的Cross Cluster，设置远程集群节点信息，用于跨集群搜索，不存储业务数据。

3.快速返回和超时设置。查询请求中设置参数teminate_after指定每个分片(shard)最多匹配N条记录后返回(例如10000)，设置查询超时时间timeout(例如10s)，避免查询一些宽泛的条件时耗费过多系统资源。

4.查询语法解析。解析用户查询条件，识别用户的查询类型，例如用户输入车牌号、证件号、年龄段等条件时，查询条件改写为字段精确匹配，无法识别的查询条件默认从全文字段匹配。

5.查询条件调优。查询结果不需要相关度排序时使用过滤器(filter),尽量使用路由(routing),设置较少的查询读取记录条数和字段,避免前缀模糊匹配,设置search_after规避深度翻页性能问题。

七、数据写入、查询性能测试。

SSD盘集群写入性能测试（测试环境：Elasticsearch6.3.2集群，单节点16核CPU、64G内存、2T SSD盘，写入10亿条记录，单条记录1KB，副本数为0，1台写入服务器）：

SSD盘集群查询性能测试

SATA盘集群写入性能测试（测试环境：Elasticsearch5.5.3集群，单节点56核CPU、128G内存、12块 6T SATA盘，分别写入1亿、3亿、5亿、30亿、300亿条记录，单条记录1KB，0副本，50台写入服务器）：

SATA盘集群查询性能测试

参考文档：

1. 阿里云Elasticsearch帮助文档 https://help.aliyun.com/product/57736.html
2. Elasticsearch参考 https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
3. 《Elasticsearch: 权威指南》 https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html
4. 《深入理解Elasticsearch》https://detail.tmall.com/item.htm?id=551001166567
5. 《死磕Elasticsearch方法论》https://blog.csdn.net/laoyang360/article/details/79293493
6. Elasticsearch索引别名和零停机 https://www.elastic.co/guide/cn/elasticsearch/guide/current/index-aliases.html
7. Elasticsearch自动按天创建索引脚本 https://blog.csdn.net/reblue520/article/details/80553317
8. Elasticsearch NGram分词器 https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-ngram-tokenizer.html
9. Elasticsearch开源权限管理认证插件Search Guard https://github.com/floragunncom/search-guard
10. Elasticsearch开源可视化管理插件cerebro https://github.com/lmenezes/cerebro
11. Elasticsearch开源SQL插件 https://github.com/NLPchina/elasticsearch-sql
12. Elasticsearch快照及恢复 https://help.aliyun.com/document_detail/65675.html

Elasticsearch技术交流钉钉群