背景

实时数据(乘坐请求的数量，可用司机的数量，天气，游戏)使运营团队能够做出明智的决定，比如浪涌定价那最大调度ETA计算，需求/供应预测关于我们改善Uber平台用户体验的服务。批处理数据可以通过识别中期和长期趋势提供强有力的见解，而Uber服务可以将流数据与实时处理结合起来，以每分钟为基础创建可操作的见解。

我们构建了Uber的实时数据处理、存储和查询平台Gairos，以促进精简和高效的大规模数据探索．它授权团队更好地理解和提高优步的效率市场通过数据情报。用例包括浪涌定价，最大调度ETA计算，需求/供电预测。

为了确保陶斯可以继续优化其在不断扩大的使用外用例的性能，我们重新架构了该平台，以实现更大的可扩展性，稳定性和可持续性。这些优化策略中的两个具有最大影响的策略包括数据驱动的分片和查询路由和智能缓存。

利用数据驱动的分片和查询路由，该平台可以支持比我们以前的解决方案多4倍的并发查询。一些关键集群甚至已经从每月一次停机稳定到每月零停机。自2018年12月上线以来，该平台已通过智能缓存扩展了十倍以上，缓存命中率达到80%以上。

为什么陶罗斯？

优步生态系统中有一些利用实时数据的服务。每个团队为他们的用例维护自己的数据管道和查询服务。他们必须在自己的团队中保持灯亮(监督、提醒、维护解决方案的流处理框架等)，而不是专注于优化他们的系统。Gairos的出现是为了创建一个统一的实时数据处理、存储和查询平台，以便可以装载这些用例。用户可以专注于定制系统的业务逻辑，而不是用于实时数据系统的更通用的任务。盖罗斯实现以下目的:

• 它允许用户在高层查询数据，而不必担心数据层的所有底层细节，如潜在的异构数据源、查询优化、数据处理逻辑和索引方案。
• 它允许Gairos团队在不影响消费者(通过特定领域的数据抽象层)的情况下试验和发展我们的数据层。
• 它将基于用例优化以处理高吞吐量低延长呼叫或离线批处理/建模的呼叫。

Gairos概述

下图1所示的Gairos从不同的Apache Kafka主题中摄取数据，并将数据写入不同的Elasticsearch集群。

Gairos查询服务是在这些Elasticsearch集群中查询数据的网关。Gairos客户端向Gairos查询服务发送查询以实时获取数据。数据也被持久化到HDFS，以便在Apache Hive和Presto中进行长期分析。

一些系统涉及到Gairos: Apache Kafka, Gairos摄入管道，Elasticsearch集群，Gairos查询服务等。如果他们中的任何一个有问题，一些客户将受到影响，这将是一个糟糕的体验。随着优步市场业务的不断扩大，盖罗斯的数据管道数量也在不断增加。需要向Gairos中添加越来越多的数据源以支持新的业务用例。

Uber使用案例

在优步，我们使用Gairos进行各种各样的insight收集用例，包括:

• 动态定价：浪涌定价服务正在读取基于六角形的需求和供应数据，以在特定位置和时间计算浪涌乘数。
• 驾驶员运动使用实时需求和供应数据来为驱动程序产生司机浪涌和碳建议。

我们将每个行程的数据作为会话引用，当用户打开Uber应用程序时开始。该动作触发了一串数据事件，从驾驶员实际接受乘坐到跳闸已经完成的点时。鉴于我们的系统的复杂性和规模，此数据分布在多个不同的事件流上。

例如，当司机打开Uber应用程序时，它会在司机事件流中触发一个事件。应用程序显示在该地理区域提供的行程(uberPOOL, uberX, UberBLACK等)，以及每个行程的价格，由我们的峰时价格系统生成，每个价格以离散事件的形式出现在印象事件流中。当该司机接受行程时，该请求将发送到我们的调度系统，该系统将骑手与驾驶员伙伴进行匹配，并将其车辆分配到该行程中。当司机搭档接起乘客时，他的应用程序会向调度系统发送“接人完成”的信息，有效地启动了旅程。当司机到达目的地并在其应用中显示乘客已经下车时，它会发送一个“旅行完成”事件。

像这样的典型旅程生命周期可能跨越6个不同的事件流，事件由骑手应用程序、司机应用程序和优步的后端调度服务器生成。这些不同的事件流贯穿在一次Uber出行中。

实时处理这些不同的数据流并查询它们，以便我们的服务能够根据数据洞察迅速采取行动，这是一项挑战。

司机的司机司机过渡

下图(图2.）显示用户定义的时间窗口中SF中的驱动程序的聚合状态转换。它是单个查询的结果在秒内返回。

单个驱动程序的状态转换

下图(图3.）在用户定义的时间窗口中显示了在SF中的单个驱动程序的所有状态转换。查询与前一个函数相同，只是它有一个匹配给定驱动程序uuid的一个滤波器。

按地理位置分组的驱动程序利用率

下图(图4.)根据地理位置显示驱动程序的使用情况。

最后但同样重要的是，让我们看看峰时价格是如何与来自盖罗斯的数据一起工作的。

有时候，有这么多人请求搭车，以至于路上没有足够的汽车来帮助他们。例如，恶劣天气、高峰时间和特殊事件可能会导致异常多的人同时想要使用优步。在需求非常大的情况下，票价可能会提高，以确保那些需要搭车的人能够得到一辆车。这个系统被称为峰时价格。

计算由六边形定义的六角形的浪涌乘数H3，请求（需求）和可用驱动程序数量（供应）的数量将从Gairs查询以获取最新数据。这些数据将输入定价模型，定价模型将为该位置产生浪涌乘法器。图5.显示了有比赛时奥克兰体育场周围不同六角形的激增倍增器。

可扩展性/可靠性的挑战

我们对Gairos的第一个实现带来了一些技术挑战和不可预见的问题。

随着利用陶斯的用例增加，流经系统的实时数据量也是如此。对于上下文，Gairos服务的查询数据的总大小为1,500 + TB，生产管道的数量超过30次。记录总数超过4.5万亿，群集总数超过20.超过100万次活动每秒流入陶罗斯。使系统更稳定，可扩展，可持续，以越来越多的使用情况，越来越重要。

下面，我们突出了一旦我们开始规模陶博斯的一些技术挑战：

• 共享同一个集群的多个用例会导致集群变得不稳定。一个用例中的一些戏剧性变化可能会影响该集群中的所有其他用例。例如，如果一个用例的输入数据量增加了一倍，那么它可能会影响其他用例的数据可用性。
• 摄入管道滞后。这对所有实时管道来说都是一个普遍的挑战。SLA(服务水平协议)通常非常严格，从几秒钟到几分钟不等。如果管道中的任何组件变慢，可能会导致一些延迟和SLA丢失。
• 由于某些客户端的流量尖峰，查询性能降低。由于它是一个多租户系统，因此一些突然的流量尖峰可能会影响在同一群集中运行的一些查询。
• 不再使用一些数据源。一旦用案例被播放到Gairs，就没有自动检查了这些用例的使用方式。如果数据不再使用数据，可以更好地释放其他用例的资源。
• 一些重质查询导致整个弹星群集群减速。
• ES集群主节点宕机。这可能是由于各种原因:网络不稳定，元数据的大小太大，难以管理等。
• 某些节点的CPU负载过高。这些节点存在热点问题，换句话说，它们正在处理比我们的资源(CPU/内存/网络)能够合理处理的更多的分片或读写流量。
• 一些节点崩溃。这可能是由于磁盘故障或其他硬件故障。
• 一些碎片丢失。如果多个节点同时完成，一个分片只在这些节点中可用。我们可能会丢失碎片中的数据。

我们的随叫随到的工程师经常被呼叫，维护这些管道和系统的成本很高。

然而，我们第一次迭代Gairos时的主要问题是，如何使用Gairos数据并没有返回到Gairos来指导优化和持续改进系统。Gairos不会主动检查数据是否按照指定的方式使用，也不会根据更改(流量模式更改、查询模式更改等)进行调整。在Gairos自优化项目中，我们关闭了循环(图6.)，并让用户查询驱动优化，使Gairos更稳定、可扩展和可持续。

为了使Gairos平台在不同的用例中更加稳定和可扩展，并降低维护成本，我们必须使系统更加高效和智能。

Gairos优化架构

修订后的高级架构如图所示图7.,以上。系统的主要组成部分如下:

• 客户：Gairos的客户可以是服务、仪表板、数据分析师等。
• Apache Kafka.我们使用Apache Kafka作为服务中的事件、RT-Gairos查询和Gairos平台指标和事件的消息队列系统。
• Gairos-Engestion.：Gairos-Engestion组件从不同数据来源摄取数据并将事件发布到Gairos。
• 弹星科学集群：这些集群存储来自Gairos-Ingestion管道的输出数据。
• RT-Gairos.（实时 - 陶罗斯）：RT-Gairs是Gairs查询服务。它用作所有Elasticsearch集群的网关。
• 查询分析仪：Gairos查询分析仪分析从RT-Gairos收集的查询，并为我们的优化引擎提供了一些见解。
• 优化引擎：Gairos Optimization引擎根据查询见解和系统统计，优化Gairos的摄取管道，弹性型群集/索引设置和RT-Gairs。例如，用于摄取管道的最小数量的容器数量是多少，因此它可以满足SLA 99％的时间？使用多少碎片使其可以处理写入/读流量？

下面，我们将详细讨论这些组件在整个盖罗斯生态系统中负责什么。

客户

客户端可以是服务用户，也可以是非服务用户，比如数据分析师。

服务客户包括所有依赖于Gairos来服务用户请求的实时服务，包括我们的动态定价和行程预测服务。这些服务将一些事件发送到Apache Kafka，以便下游服务和管道进行处理。当提供一个请求时，他们可以从Gairos查询一些数据来做出决定。例如，预测服务可能需要查询以改进预测，以预测高流量事件期间司机合作伙伴的需求和供应，或者我们的动态定价服务可能需要利用Gairos根据需求、供应和一些预测输入来决定激增乘数。

Apache Kafka.

Apache Kafka是一个分布式的流式流平台，可让客户发布/订阅事件流。所有实时服务都可以向下游服务/管道发送一些重要事件来消费。RT-Gairs还用于收集陶斯中的所有查询。

Gairos-Ingestion(处理层)

Gairos-摄取是一个摄取框架，用于处理来自不同数据源的数据并将其发布给Gairos。Apache Spark流用于一些数据源。

Elasticsearch (Gairos存储层)

Elasticsearch，Gairos Storage层，来自Gairos-Engestion使用的超过30多个不同的数据源的索引数据，并将其用于查询的Gairos客户端。

RT-Gairos(查询层)

rt -盖罗斯是通往盖罗斯的门户。所有查询在到达Gairos存储层之前都要经过它。实时Gairos强制访问控制，提供路由，并缓存一些查询结果。RT-Gairos将收集所有对Gairos的查询，并将它们推送到Apache Kafka主题。

查询分析仪

查询分析器分析从RT-Gairos收集的查询，并生成见解，为Gairos优化引擎提供输入。首先，使用一些简单的技术(过滤指标、聚合、时间范围、分片数、索引数)来生成一些查询模式。

优化引擎

基于从query Analyzer获得的系统统计数据和查询洞察，Gairos Optimization Engine将使用其生命周期知识库来推荐一些优化。它将更新Gairos的设置:Ingestion管道、RT-Gairos和Elasticsearch。

某些设置更改可能需要基准测试测试，以查看KPI是否在应用给定的更改之前是否会改进。例如，给定数据源最佳分片是什么？这就是索引基准服务到位的地方。

指数基准测试服务

要使用Gairos进行设置进行优化，我们需要结合基准工具，以比较基于定义的KPI的不同设置（读/写吞吐量，延迟，内存使用等）。

图8.如下，我们概述了Gairos基准测试服务的不同组件：

这些组件包括：

• Elasticsearch生产集群生产集群包含生产数据，这些数据将被复制到登台以进行负载测试。生产指数可以用作基准的基线。
• 弹性研究分期集群:这些集群用于存储测试数据，即随机生成的数据或用于实验目的的生产数据。
• 基准服务:基准测试服务接受索引的不同设置，并针对具有不同设置的索引执行基准测试。测试完成后，其他服务可以使用测试结果。
• 负载测试工具:对于大量的读/写请求，该工具可以模拟不同数量的读/写QPS(查询每秒)，并记录kpi。读取将是从生产中的RT-Gairos中收集的查询。写入将从生产中使用的相关Apache Kafka主题或直接发布主题模拟。

盖罗斯基准测试服务将接受来自盖罗斯优化引擎的请求，并进行基准测试。基准测试服务复制一个索引，而不是从生产到登台的整个历史，从而提高性能并减少资源使用。如果单个索引的性能得到改善，则该数据源的整体性能也会得到改善，因为针对不同索引的查询是独立执行的。在评估测试结果之后，优化引擎可以决定是否在生产中更改索引设置。

中所描绘的一样图7.在整个系统中涉及到相当多的步骤。这些步骤包括:

1. Gairos客户端向RT-Gairos发送请求以获取数据。
2. Gairos-ingestion从Apache Kafka主题摄取数据并发布到Elasticsearch集群。
3. Gairos对数据进行索引，并为查询做好准备。
4. RT-Gairos将查询转换为Elasticsearch查询，并为数据查询Elasticsearch集群。
5. RT-Gairos将数据发送回客户端。
6. RT-Gairs将查询信息发送到Apache Kafka主题。
7. 示例Elasticsearch集群数据定期发送给Apache Kafka主题。
8. 查询分析器从查询Apache Kafka主题提取查询信息进行分析。
9. 优化引擎从Apache Kafka主题中提取Gairos平台统计数据进行分析。
10. 优化引擎从查询分析仪中拉动Gairs查询见解，以查看是否应该完成任何内容。
11. 优化引擎将优化计划推送到Gairos平台的不同组件上。

优化策略

我们应用一些其他组织可以使用的优化策略，以优化其实时智能平台。

• 分片和查询路由
• 基于查询模式和签名的缓存
• 合并指数
• 处理大量的查询
• 索引模板优化
• 碎片#优化
• 绑定指数范围
• 清除未使用的数据

我们将逐一阐述。

分片和查询路由

分片是由某个键分区数据，以便将具有相同键的数据放入一个碎片中。写入Elasticsearch指标时，必须提供键将DOC放入正确的碎片中。查询数据时，可以将查询发送到特定的碎片，而不是如果在查询中指定密钥，则可以发送到所有碎片。该查询所需节点数量的减少可以改善延迟，并提高弹性（如果单个节点关闭但查询不需要，则无关紧要）。

假设我们想向SF的所有司机发送促销要约，我们需要获得司机列表。在图9.如下，我们在SF中查询所有驱动程序。在顶部，数据不会基于城市分离出来，查询必须在所有四片碎片中运行，以检查是否有任何驱动程序。在底部，数据基于城市分叉。查询可以从SF中的包含驱动程序的碎片中检索数据。可以看出，RUN的查询数量从4到1减少。

分片的一个常见问题是热点问题(一些分片需要处理比其他分片更高的写/查询流量)。例如，如果我们按城市ID分发聚合的、匿名的驾驶员合作伙伴数据，一些城市(包括旧金山)比小城市大得多，导致特定的碎片或节点负担过重。重要的是保持碎片的大小和效用大致相等，以帮助进行分配决策和负载分配。

下面我们概述了当分片时需要考虑的因素:

• 写每秒：这个因素需要碎片应该能够处理峰值流量。
• 读每秒:这个因素要求分片应该能够处理峰值查询。
• 过滤器：在查询中使用顶部x频繁过滤器。顶部过滤器可被视为可能的分片关键候选。过滤器必须具有足够大量的不同值。
• SLA:无论是分析用例还是实时用例。
• 碎片尺寸:建议shard大小不超过60GB。

将根据写入/读取QP和碎片尺寸计算碎片数量。下面是找到分片键的过程(图10.）.一旦确定了分片键，我们就使用历史数据来检查分片分布是否在Gairos给定的阈值内。

我们检查了一个简化的分片示例图11.， 以下。对于此示例，假设每个节点可以处理3,000写QP，并且可以存储至多60GB的数据。仅考虑数据大小和峰值写QP。

分片必须满足以下约束:

• 每个shard的峰值写QPS <= 3000qps
• 每个shard的数据大小<= 60GB

目标是将数据尽可能均匀地分布到这些分片上。

根据每个城市的数据大小，我们可以估算出碎片的数量:

基于数据大小的碎片＃(30gb + 50gb + 80gb + 20gb)/ 60gb = 3

基于峰值QPS，我们可以获得碎片数量的另一个估计：

基于峰值QPS的碎片#（2k + 3k + 5k + 1k）/ 3k = 4

获取这两个估计的最大值：

碎片#最大（3,4）= 4

这四个城市将被放在四个碎片中。SFO和SD可以放在同一个分片中。洛杉矶可以在一个碎片中。NY可以被分成两个碎片。通过这种方式，数据可以更均匀地分布在不同的分片上，而每个节点可以保存数据并处理峰值QPS。

对于在SFO的驱动程序的查询，它们可以直接被定向到分片1。而对于NY的驱动程序查询，它们需要被定向到分片3和分片4。

为了缓解倾斜分片和热点问题，我们开发了一种自定义的Gairos分片算法。在图12.，下面，我们列出了默认分片(之前）和我们的分片算法（后）.

	每个shard的最大文档数	每个shard的最小文档数	最大/分钟
之前	4700万年	1700万	2.76倍
后	3000万年	2300万年	1.3倍

图12.:我们的分片算法生成的分片在文档数量上的差异更小，文档在分片之间的分布更均匀。

可以看出，文档在这些shard之间的分布更加均匀。对于Gairos的默认分片算法，每个分片比例的最大到最小文档数是2.76，而我们的自定义分片算法是1.3。

执行一些基准测试，以检查他们可以支持的延迟和并发用户。以下是需求数据源的结果。

图13.显示不同数量的客户端下的延迟。可以看出，具有分片的数据的延迟低于没有分片。随着客户端的数量增加，差异变大。

图14.显示在不同的客户机数量下它可以支持的并发用户数量。可以看出，有分片的最大QPS数大约是没有分片的最大QPS数的4倍。

下面我们将分享第二个数据源的一些优化结果supply_geodriver．与需求数据源（存储骑手请求）相比，文件数量越高，数据的大小较大。

它可以从图15.使用分片后，平均延迟变差了。对于它可以支持的并发用户的数量，它是没有分片的4倍，如中所示图16.下面:

第三个数据源是supply_status.．

图17.展示了当客户的数量低时，用分片的平均延迟更高。当客户的数量增加到200多个时，它较低。与分片相比，它可以支持的并发用户数量约为4x，如图所示图18.．

总之，对于一些大型数据源，当它支持的并发用户数量始终是没有分片的4倍时，延迟可能会更糟。为了获得一些大型数据源的延迟和可伸缩性，我们可以调优每个分片的分区大小。

作为分片策略的副产品，我们能够稳定我们的定价群体，如图所示图19.．我们的定价集群中节点的CPU负载显示了日模式，因为所有的指数都是日指数。在一天中，可以看到CPU负载随着时间的推移而增加。将分片策略应用于定价集群中的所有数据源后，CPU负载稳定。

基于查询模式和签名的缓存

缓存的最简单解决方案是缓存所有查询结果。但是，由于我们数据的大规模性质，这些结果的总大小将大于原始数据的大小。

此外，一些查询不经常执行，并且它们的缓存命中率将低。为了使缓存更多资源效率，我们介绍了两个额外的概念：查询签名和查询模式。让我们首先看看一个Gairos查询榜样，以查看Gairos查询的样子：

Gairs查询是一个JSON对象，它可以包含以下字段：数据源，粒度，筛选，滤波器，聚合，BUCKETBY，排序，限制，具有在定义签名时，仅使用以下字段：DataSource，粒度，by，过滤器，聚合，BucketBy，Sort，限制。使用每个字段排序的这些字段生成查询签名。

使用相同的字段定义查询模式。唯一的区别是查询模式只会考虑在不考虑过滤器中使用的运算符和值的同时考虑使用的列。通过查询模式和签名，可以更有效地分析Gairos查询。

基于查询模式，我们可以为RT-Gairs定义一些缓存规则，因此RT-Gairs可以缓存常用查询的结果。例如，客户端以某个固定间隔（1分钟，5分钟，1小时等）从最后两周拉动数据。如果可以在日期缓存数据，则索引命中率将要高得多，并且可以使用缓存来提高搜索性能。对于具有重叠范围的重复查询，可以应用类似的策略，并且可以基于查询模式的时间粒度。为了使高速缓存命中率较高，需要一个查询拆分，在此期间，如果查询是可分段的话，则每个查询将基于数据查询时间范围分成多个小型查询。对于某些聚合，我们无法从各个子查询结果获取聚合结果。这些查询将存储在Elasticsearch集群中，而不是存储在缓存中。

下面我们将突出显示缓存的一些基准测试结果rider_sessions，我们的示例数据集：

它可以从图20.在应用缓存的这些查询后，平均延迟要低得多。它可以支持的并发用户数量要高得多，如图所示图21.．由于大多数rider_sessions的查询都很繁重，我们将对其他数据源进行更多的测试来验证我们的结果。

supply_status的缓存统计数据显示在图22.．可以看出，supply_status的命中率超过80%。Hit的QPS大约是50，而set的QPS大约是10。

另一个数据源demand_jobs显示在图23.．命中率为80%。

最后但并非最不重要的，它可以从图25.缓存命中率为0。可以看出，缓存对不同数据源的改善有很大差异。我们计划做更多的调优来提高缓存命中率。

合并指数

Elasticsearch正在使用反向索引快速搜索。当删除一个文档时，该文档将被标记为已删除，并且它仍然存在于反向索引中。已删除的文档将从搜索结果中排除。如果有大量被删除的文档，索引的大小会大得多。

这些已删除的文档也会影响搜索性能。例如图26.，下面，驱动程序D1，D2和D3更新多次。可以看出，有8个文档，而只有3个驱动程序。合并索引后，将清除这些已删除的文档，索引大小将更小。

提高索引性能的另一个重要因素是索引中段的数量。将执行一些基准测试，以确定我们应该使用的最佳标准，以决定何时合并索引。用于基准测试的关键指标是索引大小(存储索引的存储空间有多大)和搜索延迟(查询数据所需的时间)。从实时系统收集的查询将用于搜索性能基准测试。

一旦为每个数据源确定了合并索引的条件，优化引擎就可以执行一些索引优化任务。合并索引任务的数量将根据集群进行调整，因此重建索引不会对集群性能造成太大影响。为了防止显著的性能下降，任何时候最多只能运行一个合并索引任务。如果观察到任何重要的影响，所有强制合并任务将被中止。

处理大量的查询

一些较大的查询可能会影响整个集群的性能。

可以采用以下策略使集群更加稳定:

1. 拆分查询:拆分查询将多个索引查询成多个小查询可以限制在任何时刻查询的分片的数量。
2. 速率限制识别重型查询模式和限制速度的重型查询可以提高集群性能。
3. 缓存或创建汇总表：对于具有高击中率的一些查询，可以考虑缓存或汇总表以提高性能。
4. 迁移到Hive / Presto:对于批处理用例，有些可能会迁移到Hive/Presto。

索引模板优化

从查询运行，可以在每个数据源中的每个字段获取以下信息，以便我们可以为每个字段决定索引设置：

1. 它是使用吗?
2. 它用于过滤吗？
3. 它是否用于聚合？
4. 模糊搜索是否需要？

对于每个数据源，必须回答以下问题:用户是否需要提取原始数据。基于这些输入，可以获得每个数据源的最佳索引设置。优化引擎可以更新为数据源存储的模板，这样我们就可以在磁盘空间或搜索性能方面获得更好的性能。一些设置(如禁用源代码)将不向后兼容，在执行之前需要一些批准。请注意，禁用源代码将使更新和重新索引不可能。如果业务逻辑需要更新文档，则不应该禁用源代码。

由于数据是自动持久化的，很容易被重放，它更容易使发布Apache Kafka主题一个热管主题禁用源，以便数据迁移可以通过在持久化的Apache Kafka主题中重放事件来完成。

图27.显示详细的工作流程以确定每个字段的设置。

碎片#优化

对于每个数据源，一个索引将被复制到登台集群，reindex工具将用于将复制的索引重新索引到不同数量的碎片。将对复制的索引和重新索引进行基准测试，以收集性能数据。使用的查询将来自过去收集的用户查询。一旦确定了每个数据源的最佳分片号，查询优化就可以在新索引中设置新的分片号。

绑定指数范围

观察到有很多非常小的指数在某些集群中创建。这些指数的碎片数量很大。它导致群集中的分片分配问题。一些节点可能有很多未使用的碎片，而某些节点具有相当多的繁忙碎片，这可能会导致节点之间的不平衡负载和低资源利用率。

这些小索引通常是由于时间戳超出范围的事件造成的。当写入到Elasticsearch集群时，数据将根据每个数据源的数据保留和数据预测进行过滤，这样就不会创建这些接近空的索引，并减少分片的数量。下面是一个集群的示例。图28.如下，展示了在我们的一个集群中清理这些小指数之后从大约40k到20k的分片从大约40k到20k下降：

清除未使用的数据

收集的查询可以确定数据源是否在最近X天内使用过。基于这些信息，Gairos Optimization Engine可以执行各种数据清除任务，比如触发通知和删除数据存储中的数据源索引。

未来的工作

这些优化策略已应用于几个主要数据来源。我们计划将优化覆盖范围扩展到所有数据来源，特别是用于分片和缓存。

整个过程不是自动化的。一旦我们从这些数据源的优化中积累了足够的领域知识并应用了这些优化，我们将把更多的精力放在自动化整个过程上。

对于查询分析仪，可以应用一些机器学习/深度学习方法。它在我们的路线图中，将在未来的迭代中探索。如果您有兴趣加入市场智能团队，解决大规模流媒体(如Flink、Samza)、OLAP(如ElasticSearch)和ML(如ETD预测)的挑战，请申请加入我们的团队！！