写点什么

ClickHouse 在手淘流量分析业务实践

  • 2020 年 12 月 05 日
  • 本文字数:5517 字

    阅读完需:约 18 分钟

ClickHouse在手淘流量分析业务实践

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


  • 流量分析与业务背景:什么是流量分析,以及我们的业务背景

  • "大数据"带来的难题:当你的数据量是守恒的时候,需要怎么处理你的数据

  • 技术选型与产品考虑:在以上背景下,我们在技术选择和产品考虑时,都做了哪些考虑,以及为什么最终选择 ClickHouse,并给大家介绍一些技术解决方案


流量分析与业务背景

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,是一个比较复杂的问题, 如何让用户自定义维度而且不需要我们事先设定好,这是一个比较头疼的问题。


"大数据"带来的难题


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


  • 计算和存储的成本

  • pipeline 管理:比如有很多数据在前面的表格里已经计算完毕,然后需要在其它的表格中重复计算,这其中包含了非常复杂的 management,如果你需要在规定的时间产出数据的话,你需要管理好 pipeline,一旦其中某一个 pipeline 失败的话,你至少需要知道,这个 pipeline 失败到重启,下游会有哪些延迟。

  • 高峰 QPS 与 95%查询时间:是内部做产品的一个标准,在高峰 QPS 时,95%的查询时间应小于 8s。


技术选型与产品考虑


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



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 ,几天后可以把这些数据删除,从而减少整个查询所消耗的集群成本。



本文转载:DataFunTalk(ID:datafuntalk)

原文链接:ClickHouse在手淘流量分析业务实践

2020 年 12 月 05 日 10:001691

评论

发布
暂无评论
发现更多内容

一篇文章快速搞懂 Atomic(原子整数/原子引用/原子数组/LongAdder)

学习Java的小姐姐

Java 并发编程 并发 synchronized Atomic

食堂就餐卡系统设计

Young

UML用例图组件图部署图

熊威

架构师训练营 第一周 学习总结

RZC

作业一:食堂就餐卡系统设计

而立斋

食堂就餐卡 最用心

UML作业

王志祥

极客大学架构师训练营

食堂就餐卡系统设计

慢慢来的比较快

孤狼王兴 | 互联网大佬往事

刘燕

AI 企业管理 美团

第一周学习总结

Young

架构师成长心得

熊威

2020年6月10日 异常、断言和日志

瑞克与莫迪

【架构师训练营】1 - 食堂就餐卡系统设计

悬浮

架构 UML 部署图

第一章作业-学习总结

李白

架构师 week 1 作业一

iLeGeND

【架构思维-学习总结】week01

chun1123

学习 架构 思维方式

食堂就餐卡系统设计

Linkin

架构作业-UML图

铁血杰克

第一章作业

李白

作业一:食堂就餐卡系统设计

晨光

【架构思维学习】week01

chun1123

软件架构 UML

week1学习总结

慢慢来的比较快

食堂就餐卡系统设计

Thrine

架构师训练营 第一周 命题作业

RZC

架构师如何做架构-开篇

铁血杰克

架构师训练营Week1总结

sunnywhy

学习总结--Week1

吴炳华

极客大学架构师训练营

人工智能之机械基

码农神说

人工智能 程序员 加班

【架构】— 一个简单系统的UML模型

不二架构

极客大学架构师训练营 UML 架构总结

Week1命题作业

星河寒水

部署图 时序图 组件图 用例图

GitHub 热榜:轻量级无 Agent 的自动化运维平台!

JackTian

GitHub 开源 spug 运维自动化 监控管理平台

食堂就餐卡系统设计(第一周作业)

Geek_237932

WAVE SUMMIT 2022 深度学习开发者峰会

WAVE SUMMIT 2022 深度学习开发者峰会

ClickHouse在手淘流量分析业务实践_文化 & 方法_DataFunTalk_InfoQ精选文章