京东OLAP从0到1构建史,横跨数据写、存、读、管全过程

李阳 2021-11-17 10:15:08
作者介绍

李阳,京东资深研发工程师,拥有超过10年研发经验,擅长OLAP相关服务研发及分布式系统设计。

 

一、导读

 

本文主要介绍京东在构建OLAP从无到有各环节考虑的重点,由需求场景出发,剖析当前存在的问题,并提供解决方案,最后介绍OLAP的发展过程。

 

二、需求场景

 

1. 京东数据入口
 

 

图片

 

1)业务数据:订单

 

京东作为一家电商企业,拥有自营商品销售平台和全链路物流通道。首先第一数据入口就是订单,针对不同订单进行多维度分析,比如:对订单分析、对店铺分析、对商品品类分析等等。

 

展开对订单维度来说,因为我们作为电商,订单是非常重要的一个维度分析和数据支撑,所以常结合订单SKU,计算品类下单转化率。

 

2)行为数据:点击和搜索

 

用户在京东商城的操作,比如点击和搜索,我们会将用户的这些行为结合订单信息,来做一些分析,比如分析商品的热销和滞销程度,以及转化情况,最常见的就是漏斗分析,来计算转化率。

 

3)广告和推荐

 

基于用户下单情况,我们会推送广告和推荐给到用户,然后进行计算,分析广告触达相关情况。

 

4)监控指标

 

对于监控指标,是我们一个巨大的场景,因为在我们这里,除了用户行为数据,还有很多运维的数据也需要管理起来。

 

2. 京东数据出口
 

 

图片

 

京东的数据出口,主要分类两大类:离线和实时

 

1)离线

 

 

  • 月报和周报

 

典型离线场景:财务报表经常需要月报周报。

 

  • 机器学习

 

会用到大量的一些训练数据,这些数据的生成也会用到OLAP的一些特性来把数据进行分析,产生一些训练的数据。

 

2)实时

 

  • 交互式查询

 

非研发同事,比如营运分析人员,经常需要临时查询业务数据,比如查询最近一周订单的汇总以及明细数据,对这些数据进行分析,辅助决策。

 

  • 实时大屏展示

 

平台做大促或者实时监控运营情况,会依照大屏的指标,实时动态调整资源。比如营销策略、广告费投入、供应链库存。尤其重要的是,在大促销的时候,可以进行动态资源的调整,比如车辆资源调度、根据促销效果决策活动是否需要进行调整等。

 

三、问题与解决方案

 

以上是京东的部分业务场景,和大多数阐述数据架构不同,我们本次将数据搭建的过程分为4个方面:数据怎么写进来;写进来以后怎么进行存储;存储以后又怎么进行取用;最后是如何管理前3个环节。

 

1. 写
 

 

图片

 

1)数据源及数据结构多样性

 

 

现状:

 

数据源来源多样化:文件系统(本地文件&分布式系统文件)& MQ

 

  • 本地文件,比如说服务器本地的数据,直接导入进来

  • 数据量比较大时,在用户本地存不了这么大的数据量,会将数据存储在HDFS上

  • Kafka或者MQ数据,上游将产生的数据直接存储到消息队列中,在京东内部,这种MQ的系统有多个,但是我们需要统一进行接入

  • 数据结构的多样化,最常见:CSV、TSV、JSON、AVRO、PARQUET、BINLOG等

 

问题:

 

多种数据源及数据类型,对于开发人员来说,进行数据分析的成本相对比较高,我们希望分析人员,只需要专注于业务逻辑本身,直接进行SQL查询,而无需关心数据来源。

 

解决方案:

 

建立统一导入数据服务,将多样化的数据源和数据类型进行封装,通过给用户配置权限,用户只需要在可视化界面直接进行操作,即可完成数据的导入操作,具体的操作也是比较简单,以MQ数据源举例:

 

  • 选择数据源的topic

  • 指定导入的目标源

  • 选择数据格式

  • 选择对应的数据字段类型等等

 

2)数据的时效性

 

现状:

 

实时的数据需要实时进行计算和展示;离线的数据,可以定时的推送并计算一次,对时效的要求比较低。

 

问题:

 

如何保证实时和离线数据的时效性,且不会相互影响?

 

解决方案:

 

对实时集群和离线集群进行物理隔离,防止互相干扰,这样做的好处有:

 

实时和离线对于资源的需求不同,实时数据写入非常频繁,而离线的数据只是在指定运行的时间点比较多,区分开便于管理。

 

3)数据的更新和删除

 

问题:

 

对于OLAP的架构来说,如何做到既要查询搜索又要更新呢?

 

解决方案:

 

  • 数据更新,采用覆盖写的方案。以订单为例,用户下了一个订单1,此时下单状态为1,后面用户进行了支付操作,订单状态为2,那么我们会重新推送一条全量的数据,只是状态的字段值发生看变化。

 

  • 数据删除,采用删除分区然后重新导入这个分区数据,或者采用版本管理方式,因为通过新版本的数据会覆盖原来的版本,起到删除的作用。

 

4)高吞吐

 

问题:

 

以京东现在的体量,每天的数据是很大的,如何解决高吞吐问题呢?

 

解决方案:

 

机房配置万兆网络,另外对于实时场景,配备SSD;离线场景,配备HDD。

 

2. 存
 

 

图片

 

 

1)海量数据

 

问题:

 

京东的数据,TB数据量是非常常见的,有些时候会达到PB级别,那么采用单机的方式肯定是行不通的,那么如何解决数据存储的问题呢?

 

解决方案:

 

  • 采用分布式解决大规模数据的问题。

  • 为了提高效率,采用了列式存储,对后续指标的计算效率也有提升,其实在OLAP的架构中,大多数都是列式存储。

  • 采用不同类别的压缩方式,比如snappy等。

 

2)容错性

 

问题:

 

数据现在是科技类企业非常重要的资产,那么如何保障数据的安全性性呢?

 

解决方案:

 

其一:多副本的容错方式,我们的OLAP采用三副本的方式,所以其中1个或2个副本损坏或迁移时做扩容都比较容易处理。

 

其二:RAID独立磁盘冗余阵列(RAID,redundant array of independent disks),因为磁盘金属机器经常会坏,加上有一些机器过保存在损坏的风险,所以我们也通过raid解决一部分数据容错性的问题,防止磁盘坏掉之后整个机器不能提供服务的情况。

 

3)一致性

 

解决方案:

 

解决数据的一致性的问题,需要使用到分布式协调和本地事务机制。

 

  • 分布式协调,比如zookeeper

  • 本地事务机制:对于本地的提交,是否通过事务来保证数据的一致性

 

通过两者的结合,来实现数据的一致性。

 

3. 读
 

 

图片

 

1)查询速度

 

问题:

 

数据存储到系统中以后,如何高效的进行取用呢?

 

解决方案:

 

  • 通用方式,数据进行分区分片,在很多场景,对数据的分析都是按照时间进行分区,分区以后,再进行分片或者分桶。

 

比如:订单信息,我们可能按天查询,那么就可以按照实际日期进行分区;比如,存储10年的数据,不可能全部查询,我们按照统计则按月进行分区。

 

  • 预聚合,提前进行预计算,减少一次性计算的数据量,提高性能。

  • 索引,大部分场景下会使用索引,比如做明细查询,可能会到hash索引、betree、范围查询或者倒排。

  • 物化视图,其实和预聚合的功能类似,数据进入到物化视图中时,提前进行一些预计算。

 

2)易用性

 

问题:

 

如何实现系统的易用性?

 

解决方案:

 

  • 需要OLAP系统兼容JDBC和ODBC,同时支持标准的SQL。

  • 提供界面化的操作,这种方式可以避免所有的运营分析人员都具备MySQL等数据库的环境,可以直接登入图形化界面进行查询的操作。

 

3)QPS

 

问题:

 

如何提高QPS?

 

解决方案:

 

  • 缓存,使用Doris时,增加比如partitioncache,或者结果级缓存,或者分区缓存机制来提升查询效率。

  • 多副本,设置多副本的方式,通过牺牲部分存储空间,来提升QPS,但是这个效果有限。

  • 提升机器的规模。

 
4. 管理
 

 

图片

 

现状:

 

早期我们碰到磁盘坏了,搞得手忙脚乱,替换磁盘或者是下机器操作时间很长,而且这个操作完成之后还涉及重新平衡数据或者数据迁移,这个过程非常麻烦。

 

问题:

 

如何降低运维成本?

 

解决方案:

 

  • 建设监控和报警机制,进行提前预防。

  • 优化节点的下线,在京东系统中,有两种方式:

 

方式1:通过黑名单的方式,如果监控到某个节点经常不健康,我们会把它纳入黑名单,并将他踢下线了。

 

方式2:通过脚本操作,但是从最开始我们需要替换一个节点,估计从发现到替换完成得三小时,现在通过一些比较自动化的东西,现在大概十分钟左右能做到一个节点的替换。

 

四、发展历程

 

1. 1.0时代
 

 

图片

 

1.0时代的场景比较少,数据量也比较少,主要是订单相关的一些数据,分析通过关系型数据库就能搞定,比如说Oracle或者MySQL。

 

可通过数据储备同步到备库做分析,或者MySQL一个是slave库,主库做一些利用线上业务,然后备库对存货的一些分析和查询。

 

2. 2.0时代
 

 

图片

 

到了2.0场景,不再是简单处理订单问题,还要处理物流、供应链、客服、支付等等场景。

 

场景大增,数据量也爆发式增长,从原来的G到现在的TB甚至PB级别。传统关系性数据库,已经不能满足需求了。

 

这个时候我们开始搭建了离线数仓,在数仓中进行分析,主要用Hive和Spark进行计算,数据都是T-1,临时查询数据的体验非常差,需要耗时分钟级别且还是昨天的数据。

 

3. 3.0时代
 

 

图片

 

为提升查询数据的速度和数据的时效性,开始做实时查询。我们现在使用统一OLAP服务,从最开始使用Kylin处理一些离线的业务,到现在我们用了Doris和ClickHouse结合起来,同时处理实时和离线,统一服务接口,对用户和开发人员开放。

 

同时针对不同的业务,提供不同的计算引擎,我们现在提供一个整体打包解决方案,业务只需要在OLAP的服务上,进行统一部署到数据技术平台即可,大大减少了开发成本。

 

五、未来规划

 

图片

 

1. 管理平台优化
 

 

  • ClickHouse的动态伸缩。

  • 智能化运维。智能优化节点上下线或者数据均衡这些方面的工作。主要想要通过减少人工干预操作,降低时间的浪费。在京东的系统中,现在拥有上千台的服务器,如果一直由人工来处理的话,那么成本非常高。

 
2. 优化查询速度
 

 

  • 优化实时计算缓存。在Doris中,使用partitioncacahe或者sqlcache在离线场景中比较有效,后续将考虑在实时计算中引入缓存进行优化。

 
  • 索引智能化管理。索引的引擎有非常多种,如果需要开发人员了解所有的引擎,学习成本是比较高的,我们能不能做成智能化的索引引擎呢?这样的话用户不需要再去关心类似的一个索引怎么建的问题,而是我们在通过用户的一些查询行为分析,自动的来给他做索引的创建,这样简化工作成本,让开发人员有更多的心思去做好运营和分析。

 

六、问答环节

 

Q1:请问老师贵司有用过Druid引擎吗?

 

A1:没有,我们调研发现,第一,Druid对SQL的支持不是很友好;第二,Druid擅长于持续性的数据场景,但是京东订单是一个频繁发生状态变化的一个场景,它是不太好处理的,所以当时我们也没有选Druid。

 

Q2:ClickHouse和Doris如何根据业务场景选型,有哪些坑?

 

A2:第一,查询性能:在查询表不多即没有太多表关联情况下,ClickHouse查询速度比较快,但是在做大表关联查询时,Doris的性能会好于ClickHouse

 

第二,QPS:ClickHouse是在极限使用CPU的性能,但是Doris的QPS性能在某些场景下会比ClickHouse好。

 

第三,运维成本:Doris的运维成本会小于ClickHouse,至少现在对我们来看,因为它会有节点自动上下线扩容收容会很方便,但是ClickHouse做这个方面比较麻烦。

 

第四,数据更新:ClickHouse数据更新的引擎有三种,用户在使用的时候比较麻烦,但是Doris,它直接进行数据覆盖,就能做到一个更新,操作更方便。

 

Q3:DorisClickHouse是自动选择,还是需要用户自己去选,如果是自动选的话,识别机制是什么样的?

 

A3:目前还没有做到自动选。当前先整体提供解决方案,我们为用户提供技术支撑,未来可能会想着如何去打通统一化,因为它的模型创建不太一样,它的SQL是有差异的。

 

Q4:数据接入CK方面,京东目前是什么样的方案?

 

A4:目前有两条路线。

 

一个是用户自己业务侧接入,因为有些历史原因,用户他已经用了很久的ClickHouse,他自己有比较成熟的一套接入系统。

 

一个是使用ClickHouse来接入,不管是从离线还是从Kafka中,这种方式是我们在平台侧,在平台侧开发了统一的OLAP服务,用户可以上面操作。就如前面所说,用户选择数据源,再选一个目标源,点击它执行导入,就可以完成。

 

今天的分享就到这里,谢谢大家。 

 

作者丨李阳
来源丨公众号:DataFunTalk(ID:datafuntalk)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2021年09月03日

有没有1000多张表

访客 2021年08月28日

metrics =》 metrix 错误

访客 2021年08月25日

只看到如何避免,如何减少书写慢 sql

访客 2021年08月25日

没看到如何治理呀

访客 2021年07月23日

果然k8s不是神!

活动预告