Fork me on GitHub

​阿里 | ClickHouse 在手淘流量分析业务实践

分享嘉宾:Jason Xu@阿里巴巴
编辑整理:夏仙森
出品平台:DataFunTalk

导读: 本文主要介绍手淘流量分析业务发展过程中,实时性业务分析需求的产生,实时分析目标的设定,如何进行技术的选型,以及如何基于ClickHouse构建系统架构和未来的业务预期。主要内容包括:

  • 流量分析与业务背景:什么是流量分析,以及我们的业务背景
  • "大数据"带来的难题:当你的数据量是守恒的时候,需要怎么处理你的数据
  • 技术选型与产品考虑:在以上背景下,我们在技术选择和产品考虑时,都做了哪些考虑,以及为什么最终选择ClickHouse,并给大家介绍一些技术解决方案

01 流量分析与业务背景

1. 流量分析

首先,流量分析到底是什么? 从最基本的角度来说流量分析就是底层的数据模型加上指标体系。

底层数据模型:

底层数据模型是把不同的用户行为数据,先放到一个最基本的叫做“事件”的数据模型中,这是一个单事件的数据模型。与此单个事件数据模型的上一层,形成一个路径的实现模型,可以把一些数据,比如一些流量数据或者一些业务内部数据同交易数据做关联。在此基础上,可以做规定的分析,后续也可以做更多的不同分析。既可以从企业整体来看,也可以从单个业务着手,例如:淘宝有很多个行业,可以从行业视角来分析数据;淘宝有许多新用户和老用户,可以从用户角度来分析数据。所以,一旦有了这个底层数据后, 我们用很多不同的方法来分析这些数据,每一种分析方法产出的指标其实是一样的。

指标体系:

我们通常用以下四种指标来分析数据:

  • 流量规模是多少,有多少UV,PV。
  • 参与度,比如说停留时长,浏览深度。以目前火爆的直播为例,我们要看下直播的参与度,例如:在一次直播中,交互多少次,点击多少次等一系列操作。
  • 转化,行业对转化的理解就是让用户做你想让他做的事情,比如说转发、收藏、购买。此外,还有一些其他类型的转化:对于视频产品, 转化就是电视剧的完播率;对与社交产品,转化是用户注册或者分享页面;以及根据业务场景定义的转化。
  • 粘性,就是你花了多长时间把用户拉过来,让用户完成一件事情,并且了解用户对此具体业务有没有粘性。

由于业务的复杂度,我们会理解这些不同的数据,并且按照不同的维度来做切分和汇总。在大数据背景下,很多东西和ClickHouse自有技术是密切相关的,这也是为什么最终选择了ClickHouse做我们的技术方案。

通常我们在底层数据模型的基础上创建一些指标体系,由于我们拥有很多业务方以及众多的用户,所以需要非常灵活的切分这些数据模型和指标体系,从而为每个个体提供对他本人最有价值的指标分析功能。

2. 全域消费者互动与触达

从业务角度来看,现在的全域消费者都在做什么?消费者可以在抖音、小红书或者淘宝店铺搜索一件商品,与此同时消费者也可以从其他网站继续浏览该商品,并且有可能从多个渠道来购买该商品,这就形成了一个网状型的路径。这就存在一个很大的问题,就是按照这个路径,数据复杂度会变得非常高,在没有大数据或者很多数据量的情况下,很难回答消费者到底浏览了此商品多少次,最后在哪购买的。

对广告主而言,需要投入多少广告,才能让消费者记住或者购买这件商品。同样的,现在广告投放渠道多种多样,比如说微信、抖音;哪个投放渠道成本最低,哪个渠道能达到最高的投入产出比,是大部分广告主需要关注的问题。因为,目前的现状是流量成本确实比较高,如果能降低获客成本,并且提高转化率,就为其在竞争上提供了很大的优势。比如说一个企业,可以通过众多的渠道通过更低的价格来获取更多的用户,获取用户之后,就可以吸引更多的电商入驻,或者更多的商家入驻, 通过卖更多的货,从而形成一个很好的闭环。在开通电商业务前,至少需要考虑是否在微信,抖音,淘宝,或者其他地方深耕某一渠道,当面临非常复杂的选择时来决定到底做哪个渠道,卖什么商品。

3. 流量分析的难题

从产品角度分析后,我们发现如下几个问题:

  • 数据时效性:比如说传统的解决方案,都是次天(T+1)看数据,今天做该做的事情,第二天看数据的结果。在传统的方案里,由于当时无法查看实时数据,所以只能这么做。现在的方式不同以往,大家希望根据更及时、更实时的数据来做决定。及时数据就是当想观察数据时,快速产生数据;实时数据就是在运营或者做活动时,可以参考当天的数据,而不是今天需要运营,却查看昨天的数据。
  • 通用的指标体系:数据仓库的技术壁垒,比如说在抖音上,能观察到一些指标,那么在其他的渠道或行业中运营,这些指标体系是不通用的。这里一部分指标是场景所特有的,但另一部分指标是数据对特定的技术要求。如果主要的指标体系是不通用的,很难在不同渠道进行对比。比如说,在渠道A,提供的指标是1,2,3,但是渠道B和渠道C提供的指标是A,B,C,从而对哪个指标更好,产生疑惑。所以,在建设数据分析时, 需要使用一些通用的指标,比如刚才的例子,如果是大宽表的话,通过一些技术就能很好的解决这个问题;而在传统研发模式中,只能分别对每一个渠道做一个报表的口径,若是有不一致,或者存在其他一些小问题,就会在后续运营中产生很多问题。
  • 灵活的OLAP分析:在传统的行业或者方法中,需要一个BI, 让他产出数据,这里产生的问题就是如果你有很多业务,每个团队都需要这个BI来支持,让他产出数据,然后这个人每天就写sql,无暇顾及其他业务。我们希望赋能我们的每个行业,比如说分析师,或者小二,当卖家想问问题时,可以通过我们的产品进行交互式的分析,来解决问题。未来,我们希望小二能通过语音,说“今天卖的最好的东西是什么?”。当然了,解决这个问题可能需要五到十年的时间,这是我们未来的发展方向。对于当下,迫切需要解决的问题是一大堆小伙伴们天天只写sql,无暇顾及其他的业务。
  • 流量+业务数据:目前存在的痛点是我们有一些流量数据,但是对于业务,例如一个具体的BU,或者说一个BU再加上他的三方代理商准备做一个活动,我们需要观察这个活动的效果。其中存在的问题是,需要先把目前已有数据和外部数据做一个关联,然后,再做这个事情。这就从一个业务问题变成了一个技术问题,我们希望能让这种问题通过技术来快速解决,来降低门槛。同时,我们也希望能从产品的角度来解决问题,虽然不能完全解决问题,但是至少能快速的配置解决问题,所以这些是我们当时在流量分析前考虑的事情和需要做的事情。

4. 问题思考

针对这些难点,我们做了一些思考:



  • 时效性:传统的方案时效性受限,不过可以通过Flink或者Blink来产出一些简单的指标,但是这些指标,又和后面离线的数据不一致。可能是由于只有一个指标,但是没有其他分析维度,所以就需要依赖ClickHouse的其他功能,比如说实时计算功能来解决这些问题。
  • 指标体系:是一个与业务紧密相关的设计问题,在此不再赘述。
  • OLAP分析:关于分析宽表和明细数据,首先简单介绍一下宽表,通常前面可能有十个维度的数据,后面可能有十个指标,然后,我们通过宽表跨数据库来做查询。其实我们更想做的是一个明细的数据,例如ClickHouse有一个功能,可以把半加工的数据放到数据库里,当需要再做查询的时候,其往往可以做更复杂的查询。所以,我们可以把一层数据压缩好,从而服务更多的业务。同样,也可以通过物化视图materialized view来做出复杂的查询,我们最后的解决方案是materialized view和明细数据一起应用。如果需要一个定制的查询,就采取materialized view解决方案,如果说需要一个灵活的查询,就用明细数据方案。
  • 自定义维度:动态的schema,是一个比较复杂的问题, 如何让用户自定义维度而且不需要我们事先设定好,这是一个比较头疼的问题。

02 "大数据"带来的难题

接下来介绍的,就是大数据以及淘宝流量数据带来的一些问题:

  • 计算和存储的成本
  • pipeline管理:比如有很多数据在前面的表格里已经计算完毕,然后需要在其它的表格中重复计算,这其中包含了非常复杂的management,如果你需要在规定的时间产出数据的话,你需要管理好pipeline,一旦其中某一个pipeline失败的话,你至少需要知道,这个pipeline失败到重启,下游会有哪些延迟。
  • 高峰QPS与95%查询时间:是内部做产品的一个标准,在高峰QPS时,95%的查询时间应小于8s。

03 技术选型与产品考虑

下图来源于官网,主要通过其中几个功能来解决我们所遇到的问题。

1. 计算&存储成本

关于计算存储成本,ClickHouse有非常高的数据压缩比例,其本身就是一个列的数据库,在这里着重介绍一些ClickHouse比较有效的功能:

Data Compression:Encoding本身具有很多数据,并且支持ClickHouse做出来的Unicode,例如:Delta,delta其本质就是时间差,在很多事件中如果使用date encoding,通常可以省很多时间,可以在后续做一些优化。另外就是lowcardinality,假设其有一个string,但是这个string变得不会太大,通过使用这种encoding可以减少它的查询和存储的时间。然后还有很多类似date-time function的方式,比如yyyydd格式的时间,其通常会把一些时间的function事先压缩好,允许在计算的时候,做许多优化。

Support for Approximated Calculations:ClickHouse其实是支持多种HL算法优化的:比如准确度和查询时间,假设业务方在查询结果上能接受百分之一的不准确,那么ClickHouse可以在三到五秒内得出结果,我们认为这是个合理的过程。因为在很多时候,有些BI是做一种探索性分析的,而在做探索性分析时,假如要考察红袜和蓝袜哪个更受市场欢迎,如果两种品类的偏差只有百分之一,也没有达到一个绝对性的结论证明红袜比蓝袜卖的好,鉴于这种情况,我们用HL算法来支持用户体验,是值得的。如果真需要一个精准的数据,可以通过uniq,uniqexact来算出一个精准的数据,通常情况下,uniq能直接得出很好的结果,会得到一个很好的体验。

Disk Srorage of Data:storage policy可以按照disk storage policy把部分数据,比如一个星期的数据,放在硬盘或者ssd上,其中包含storage policy与data TTL, TTL就是在数据失败的时候,能暂时控制一下。其中哪些数据,我们允许做热查询,哪些数据,可以做冷查询,这些都是我们在优化解决计算和存储成本的一些事情。

2. Pipeline,HA,时效性

Data Replication and Data Integrity Support:在做Pipline管理,HA,时效性时,还可以把clusters和sharding一起使用,我们可以通过底层的不同的sharding 来快速导入数据,然后在上面通过replication来增加查询的性能。

Real-time Data Updates:另外就是上文提到的实时,在insert distributed中我们可以通过各种不同的接口,直接把数据导入。其次,materialized view的一个优点是自动计算,每次有insert时都会check上面的计算。在大部分的情况下,其都是定制的distributed,可以在减少pipeline管理的情况下,直接把数据导入并且计算出结果。除此之外,其他的方面通常属于具体的技术层面,都是用来辅助我们管理数据的导入情况。

3. 查询性能&灵活性

接下来就是在做查询性能和灵活性时,采用的一些方法:

高峰:

  • materialized view宽表:使用materialized view来做一个大宽表,通过此宽表可以快速服务60%-70%的查询
  • aggregatingMergeTree:可以把state放在其中,其本质上是半加工的半加工体,后续每当需要做复杂查询时就可以直接从这里查询,merge起来。
  • quota:可以控制一下在每次查询时所使用的rom,memory等,就是类似primary的功能, 控制查询的结果,或者是资源的消耗。
  • primary index:当在做表设计时,考虑好将需要的字段作为primary index,那么在扫描时候能快速扫描。

灵活性:

针对灵活性有以下几个功能:

  • Dictionary:可以解决很多在做join时的问题,是TB的一个字典,支持放在sql里,也可以放在memory里,比较灵活
  • join:ClickHouse旧版本的join操作不是特别好用,但是现在做的不错,现在我们可以通过dictionary,做很多灵活的汇总和join。可惜的是,以前没有这项功能,join就是普通的join
  • external tables:是指可以把ClickHouse和mysql同时使用,通常我们会把很多的尾表,或者其他的东西存储在mysql上,因为mysql成本更低,并且ClickHouse支持mysql的表可以在上面直接进行查询,因此允许它们一起使用
  • 嵌套性模型数据和JSONAsString:在自定义维度的时候,可以通过嵌套式的数据格式来支持自定义维度,然后通过ClickHouse快速完成解析,从而得出查询结果

4. 产品考虑

最后,需要从产品方面考虑选择的技术,我需要做什么?

  • 查询:我们知道大部分的人通常采取高准度查询,在这种情况下,通过materialized view的功能,就可以把大部分的查询推到materialized view。materialized view,也支持实时计算功能,所以我们就可以通过materialized view对用户解释,延迟三到五分钟就可以得出结果。
  • 复杂查询:很多复杂的查询都是近期数据,而不是几年前的数据,table中通常只是三个月或者几个月的数据,我们通过table ttl,就能进行自动的管理。从而,节约了我们维护的成本。
  • 灵活查询:可以通过各种不同的功能,比如树引擎、字典、mysql,来支持移动灵活的查询。由于这些功能,我们也可以进行快速的配置,不需要像以前一样进行开发。
  • 表格优化:在设计表格时,需要适量补充表格,哪些表格选择index合适,哪些表格选择group by合适,然后做一些测试实验。
  • 按需数据加工:因为ClickHouse压缩数据比例非常高,可以把它放到底层。当在复杂的查询情况下,按客户的需求,进行复杂的查询;然后再把一些数据从某一些数据库挪到其他任何的数据库中,从而加工出来一个单独的表格,之后把这个表格,落到客户的odps上。我们能否通过这种方式来更好的服务我们的用户,而不像传统的方案那样,需要维护一个很大的集群用来支持所有的查询或者计算;能否严格按照用户需要调动任务,从而调动此任务所产出的数据,就可以直接把结果数据分享给客户,这份数据可以通过下面table的TTL ,几天后可以把这些数据删除,从而减少整个查询所消耗的集群成本。

本文地址:https://www.6aiq.com/article/1607120455390
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出