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

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

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

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

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

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

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

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

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

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

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

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

现状：

问题：

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

解决方案：

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

现状：

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

问题：

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

解决方案：

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

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

问题：

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

解决方案：

问题：

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

解决方案：

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

问题：

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

解决方案：

问题：

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

解决方案：

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

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

解决方案：

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

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

问题：

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

解决方案：

问题：

如何实现系统的易用性？

解决方案：

问题：

如何提高QPS？

解决方案：

现状：

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

问题：

如何降低运维成本？

解决方案：

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

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

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

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

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

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

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

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

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

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：Doris和ClickHouse是自动选择，还是需要用户自己去选，如果是自动选的话，识别机制是什么样的？

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

Q4：数据接入CK方面，京东目前是什么样的方案？

A4：目前有两条路线。

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

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

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