李阳:京东零售OLAP平台建设和场景实践

database

导读: 今天和大家分享京东零售OLAP平台的建设和场景的实践,主要包括四大部分:

  • 管控面建设
  • 优化技巧
  • 典型业务
  • 大促备战

--

01 管控面建设

1. 管控面介绍

管控面可以提供高可靠高效可持续运维保障、快速部署小时交付的能力,尤其是针对ClickHouse这种运维较弱但是性能很高的OLAP核心引擎,管控面就显示得尤其重要。

2. 架构设计

管控面的整体架构设计如上图所示,从开始请求、域名解析和分流规则,到达后端服务adminServer,adminServer有一层校验层,校验完成后会向队列中发送任务,worker会不断地消费队列中的任务,消费完成后会将任务的结果写到后端的存储。如果有大量的集群的部署、配额的更改,就会有一系列的任务在这里完成。完成之后,再到数据部门进行保存,这就是整体的架构设计。

3. 业务管理

在业务管理方面,管控面可以提供以下功能:

  • 可以用于用户的集群账号的申请;
  • 业务级别的登记;
  • 用户可以进行配额查询,这些配额主要包括查询数、执行的并发以及超时等;
  • 用户可以自定义监控告警,通过这些监控告警去实时探索自己的整体服务的可靠性和稳定性;
  • 慢查询统计告警,可以通过管控面看到当前集群业务有多少慢查询以及错误的查询、查询的总数等。

4. 运维管理

在运维管理方面:

第一,可以进行新集群的部署,比如物理资源或者容器资源已经申请好之后,可以及时进行创建资源,并及时给用户使用;

第二,比如ClickHouse有节点故障时(例如硬件故障如CPU、内存或磁盘故障),要进行及时的节点上下线或者节点替换,否则就会影响整个集群,一是影响DDL,二是影响写入。

第三,可以做配额的管控,这一点在大促中非常有用,它可以用于限制用户的查询数、并发还有超时等,防止突增的流量,导致集群的不稳定。

第四,可以进行集群的巡检,集群巡检之后,可以查看每个集群的服务状态,比如它是否可以创建表、删除表、插入数据、查询数据是否都正常等,也有实时告警集群巡检的服务状态。

以上就是我们京东零售OLAP管控面核心功能,它在集群运维方面不仅提升集群交付的效率,还节约运维的成本。

--

02 优化技巧

1. 场景难点

京东零售是以电商交易和用户流量为核心的场景,有以下两方面难点:

  • 第一点是交易的业务比较复杂,需要关联多张表、sql中的逻辑多,另外就是数据会实时更新,比如交易的状态和金额的变化、组织架构的变化等;
  • 第二点是流量数据,它有个特点,首先追加不修改,其次是量大,因为包含了用户的点击和浏览等各类行为的数据,以及衍生的各种指标,比如UV的计算。最后是它的数据质量也会经常变化。

针对以上场景难点,我们主要用到了实时的数据更新,还有物化视图、join的优化。接下来通过一些具体案例详细讲解。

2. 实时数据更新

首先看一下实时数据更新。我们创建了两张表,一张是本地表,还有一张是分布式表。

本地表主要采用ReplacingMergeTree去重的引擎,字段分别是create_time创建时间、ID、comment注释,还有数据的版本,分区是创建时间进行格式化得到的天分区,然后按照ID进行排序键去重。现在的需求是对相同的ID进行实时的数据更新。

我们在集群的两个分片中,比如分片1插入了三条数据,分片2插入了三条数据都是相同的ID(0),但是查询分布式表发现,数据并没有去重。

第一种解决方式是使用optmize去重。通过执行一个optmize去重之后,通过查询本地表就发现optmize在多分区间和分片间不能去重,只能在同一个分区中去重。

第二种方式是使用final去重。通过查询一个本地表的final,发现刚才的11日和12日的数据只保留了一条数据,这时再通过查询分布式表final去重,发现有两条12日的数据,所以我们的结论是final的方式在多个分区间可以去重,但是在多分片间不能去重。

因为我们的集群都是多分片的,所以还有第三种方式——使用argMax。我们通过argMax加了一个数据的版本,可以选择最大的一个版本号,然后通过去查询分布式表,发现argMax可以在多分片间去重,这也是我们推荐使用的一种方式。

所以实时数据更新方式一般有以上三种,但是各种方案更新的范围不同,我们可以根据自己的业务场景去使用不同的去重方式,optmize可以在分区范围内去重,final可以在本地表范围内驱动,而argMax可以在分布式表范围内去重。

3. 物化视图

接下来,我们看一下物化视图。使用物化视图的场景,比如:业务最近3小时看小时的数据,三天之前想看天粒度的数据,这时候物化视图,就是很好的选择。那么物化视图该如何使用?我们看一下这个案例,有一张明细表test,它大概有13亿行左右,直接实时的count聚合进行查询,发现它的耗时大概是2.1秒左右,怎样能让查询变得更快一些?

我们创建了一张物化视图,对原始表进行预聚合,物化视图选用了SummingMergeTree,这是聚合的一种引擎,大家也可以选择其他引擎去聚合。它会根据排序键进行二次聚合,也就是 Date 字段。还有一个select语句,它的作用是通过批次写入,把这个select语句写入到物化视图列表中。

我们创建物化视图之后,再去执行相同的语句,查询性能提升了大概113倍,耗时0.002秒左右,所以物化视图在比如量大而且可以预聚合的这种场景下非常好用。

那么物化视图就又是什么原理能够达到这样的效果?整体如图所示。

物化视图会创建一个隐藏的内表来保存视图里面的数据,然后物化视图会将写入原始表的数据,也就是通过select第一次聚合后的结果,写入物化视图的内表中列表,再根据排序键进行二次聚合,这样原始表的数据量会大量减少,查询就可以得到加速。

4. join优化

在正式介绍join优化前先补充一点基础知识:对本地表的查询我们称之为部分查询,以下划线L为结尾的表称为本地表。在做这种优化之前,先看一下整体的分布式表执行的流程。

首先分布式表会将查询拆分成对本地表的查询。比如city在精确去重之后,查询分布式表,通过路由下发到各个分片的本地表上面进行查询,然后第一个接收到的查询的节点,再将本地的查询部分的结果进行合并,返回给用户,这是整体分布式表执行的流程。

join的执行过程如上图所示。比如select id, name, score from student join score,首先展开分布式表,向每个分片分发请求,计算左表的每个本地表join的结果,第二步当分片收到1中的请求后,需要计算右表的结果,向每个分片再发送请求。这样假如集群有100个分片,就需要100×100的部分查询,每一次展开都要通过磁盘网卡,都会有耗时。

第一种优化是global join。在原始的查询中,会先计算右表结果,展开第一个分布式表,然后合并,成为一个临时表,假设命名为b_004,这是第一次展开。第二次展开时,它会将临时表b_004发送,所有的分片计算部分的join结果,就是第二次展开的分布式表,然后第三步,合并2中的结果,为最终的结果。这样整体的global join就是,假如我们有100个分片,就只需要2×100次的部分查询,大大减少了查询。

第二种优化方案就是本地join,将右表的分布式表改成本地表。这种方式的执行流程是,我们展开左表,只需要把左表的分布式表下发到各个分片上面,而右边它本身就是本地表,就直接进行合并计算,最后会合并整个部分结果即为最终的结果。假如总共有100个分片,只需要展开100次,下发每个分片,100次的查询就行了,这样就减少了带宽消耗,提升了性能。

可以优先使用本地join,其次是global join,最后要小表放在右边,这样就可以提升join的性能。

以上就是我们针对业务场景难点的一些优化技巧。

--

03 典型业务

我们也希望实现高并发查询,有大吞吐的写入,但是ClickHouse在默认的配置下,不支持高并发的查询,而且写入也很慢,这是我们业务上的两大痛点。下面具体看一下两种场景。

1. 高并发查询

以广告实时跟单项目为例,它是用于实时产生广告效果,最终数据报表展示,帮助广告主执行营销计划落地。如图所示,可以看到每秒的QPS达到将近2000,这是618时候的一个截图。我们的集群整体的配置是7分片6副本1进程,硬件的配置是42台32C128G,900G*3的SSD的磁盘,整个集群的QPS可以达到2000。当然这个配置如果要达到2000的话,我们要进行一系列的技术优化。

首先第一点技术优化就要增加副本,因为增加副本可以提升整个集群的并发能力。第二是max_threads,减少每一个查询所用的线程数,ClickHouse如果不设置这个参数,会用物理内核的所有线程去进行查询,这样就会导致有些任务无法调度,所以要设置这个参数。第三就是要调整query_thread_log的存储,因为大量的QPS过来,会有很多的请求日志,如果我们不调整存储,很快就会将磁盘打满,造成集群的不可用。

上图展示了优化前后的最大稳定运行并发数。优化前,大概只能达到1000QPS,同样的集群下优化后可以稳地运行在2000QPS左右,可以满足业务需求。

2. 大吞吐写入

第二个典型业务是大吞吐的写入。以京东云监控项目为例,它负责京东云负载均衡访问日志的存储,日志量极其大,单集群写作的峰值可以达到6000亿条/天,还可以保持数据的强一致。可以看到集群日常大概是3G/秒,大促可达到6G/秒。我们的集群配置是60分片两副本1进程,硬件配置是120台64核的256G1T*1的SSD。

这样集群配置下,我们可以实现这6000亿条每天的写入。为支持这个写入量,我们也需要一系列的技术优化。

第一点就是引入了chproxy流量负载均衡,请求粒度细化至每条sql,这样每一个sql请求都会路由到不同的节。如果不引入chproxy,就会通过域名的方式直连客户端,直连集群,如果连接不及时释放,就会一直往节点里写,很容易就把集群单节点打爆了。引入了chproxy的流量负载平衡之后,sql就可以均衡地路由到各个节点。

第二点就是本地表的写入,可以提升整体的写入性能,大概是分布式表的两到三倍左右。

最后我们看一下优化前后,每天最大的写入量,优化前大概是1000亿每天,优化后可以达到6000亿每天,这样就实现了大吞吐的写入。

--

04 大促备注

电商场景下,经常遇到大促备战,需要保证olap服务的稳定性。

大促备战的整体流程如图所示,我们在不同的时间段需要做不同的事情。一开始是启动备战制定备战方案,收集业务的资源需求,梳理业务等级,接下来是集群的扩容压测,还有故障演练优化等,最后迎来开门红,决战618。

我们的OLAP是如何保证业务的呢?

第一,业务资源收集以及等级确认。大促前,我们平台会向业务收集有资源的需求以及等级确认,并做合理的规划和分配,来保障大促的流量急增时有足够的资源支撑运转。比如资源需求,可能有新上线的业务、扩容的业务、迁移的业务,还有替换已有集群的业务,这些都是我们大促之前要进行梳理的,这样可以提前做好预案。

第二,业务方要及时的订阅监控和报警。比如监控有CH系统层的、服务层的,还有CH查询和写入层的监控。我们有两个告警系统:一个是服务层的,比如监控CH的一些重要的指标,ZK的一些监控告警,以及chproxy流量负载的一些监控报警等;另一个是系统层的MDC告警,例如CPU、内存、磁盘、连通性,这些主要是监控硬件是否有故障。右图就是报警和监控的样例,我们可以通过它们来及时修复集群故障,也需要业务方去订阅这些监控和报警,来一起监督整个集群的稳定性和可靠性。

大促集群是如何保障的呢?

第一点是压测。我们要进行高保真的一些压测,压测的结果,要设置合理的配额,比如我们共享集群的CPU一般是40%,独占集群是80%,我们通过这些目标值设置业务的合理的配额。如果压测有问题,我们可以及时的协助业务方进行优化,来满足他们的QPS和集群的稳定性。

第二点是故障演练。我们的故障演练有很多,其中第一就是双流切换。比如我们的零级业务就是非常核心的业务,要进行主备双流,在不同的机房分别部署了两个集群,如果同一个机房有问题,要及时切到备用集群去。另外就是故障的修复。故障发生后,我们要通过管控面进行及时下线或者替换,来保证集群的稳定性和业务的可用性。

第三点就是降级措施。我们的降级措施会针对不同的业务等级进行合理分配,尤其是大促的时候不参加压测的业务。如果不参加压测,我们就会在大促前期进行业务降级,防止他们的突增流量影响大促核心业务,以保证大促时整体的集群稳定性。

以上三点就是我们集群保障最核心的三个步骤,从一开始的高保真压测,到故障的演练,再到最后的降级措施,我们都会和业务方一起去完成,以保证整体稳定运行。

--

05 精彩问答

Q:请问老师您在这个话题中遇到的最大的挑战是什么?

A:我遇到的最大挑战就是解决高并发的问题,因为高并发瞬间QPS能达到2000以上,而我们的ClickHouse默认就是100个并发。我们在高并发方面做出了很多技术调优,可以让业务达到高并发的场景。高并发的场景,遇到过很多问题,我们首先增加了多副本(一般默认情况下就是三副本或者两副本来保证数据的安全),因为每增加一台副本,就可以提升整体的一个分片的查询能力。我们还进行了一些参数调优,比如如果高并发过来,有很多的队列,这些线程我们都要去控制好,不然很容易就无法调度了。另外,高并发场景会很容易把集群的一些日志给打满,因为我们的每一条查询都会记录一条日志,我们要把日志的表的存储周期设置小一点。还要加快它的merge,因为如果不加快merge,删除数据就很慢,也很容易将磁盘打满,这是查询日志的方面。第三点就是高并发很容易触发我们的一些配额的限制,我们要对它进行一些放大。我们要进行内存的一些限制,如果不进行这些限制,或者是不放大这些限制都会引发QPS达不到,造成整体的稳定性和可用性不够。

还有一个难点是join的优化,效能优化里面其中有一个是本地join,本地join我们也做了很多的测试。比如和字典表做对比,我们发现字典表在100万以下的数据量,就是使用字典表做join性能较好,100万以上我们发现用本地join就非常好,我们通过一系列的测试实验才得到这个结论。一开始我们都是用字典表去进行黄金眼刷,但是我们最后发现在一定的性能之上,字典表还不如本地表的join。大量的POC才得到了这个结论。所以大家在字典表和本地join,也可以自己做一下全面的性能测试。

以上就是我们的两点挑战。

Q:OLAP是什么?主要用哪些引擎?

A:OLAP是在线的多维高性能实时分析服务,专业术语就是在线联机查,和mysql OLTP在线事务查询是两种不同的类型。OLAP主要面向海量数据。

我们京东零售主要用clickhouse为主、doris为辅的两个引擎。现在最流行的就是ClickHouse,其次是doris和druid这两个引擎,但是现在很多大厂,包括腾讯阿里字节都在往ClickHouse上面转,当然京东零售也应用ClickHouse两三年了。我们也进行了一系列的内核的研发,解决一些zookeeper的性能,还有在线弹性伸缩系统的一些东西,因为ClickHouse在弹性伸缩系统方面不太好,所以我们也在做这方面的工作。

Q:看到有一个业务场景中使用了120台高配置的机器,那么如果申请到这么多的资源进行业务支持,怎么考虑投入产出?

A:我们投入了120台,产出就是可以把整个京东云的所有的负载均衡。第一,我们为什么要用120台,为什么要用SSD的机型?还有为什么这么高配的机器?因为它的写入量很大,平均每天大概6000亿,算出每秒大概有1000万的数据量在往集群里写,如果不用这么高配的机器,磁盘已经是SSD了,它的性能永远达不到这个效果。第二点就是投入产出比,我们可以通过这个集群监控整个京东云的日志,还有负载均衡的效果。比如京东云,一是对外,二是对内,监控和负载均衡都是非常重要的,所以用了我们的京东零售的OLAP来实监控京东云的一个整体效果,还有整体稳定性,这样产出比就非常大。

Q:主备库切换时数据有延迟吗,如何做到让用户感知最小?

A:主备库切换,我们采用的是双写的流程,我们核心的业务都是双写的,就算在日常也都是双写,然后分流去查询,不会造成主备储备的集群的空闲。大促的时候,会采用一个百分比,比如说或者100%在主机型另一个集群就是当做备用,或者是会按照一定的比例80%-20%左右采用双写。业务方切换的时候基本上没有任何延迟,只是将域名切换了一下,数据都是在实时写入,两个集群,基本上没有延迟。这是我们准备切换的一个功能。

Q:想问一下咱们的调优过程是怎么样的?

A:我们的调优过程先是结合自己的经验,去优化一些参数,业务再进行压测。因为想达到这么大的QPS和这么高的大吞吐的写入,要时常进行压测,压测时如果遇到问题,会进行内核源码的分析,然后再进行一系列参数调优或者内核优化。

本文首发于微信公众号“DataFunTalk”。

以上是 李阳:京东零售OLAP平台建设和场景实践 的全部内容, 来源链接: utcz.com/z/536548.html

回到顶部