【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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:002157

评论

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

Terraform 新手村指南,萌新必读!

SEAL安全

Terraform 企业号 3 月 PK 榜

ChatGPT作者John Schulman:我们成功的秘密武器

OneFlow

人工智能 深度学习 ChatGPT

浪潮 KaiwuDB x 山东重工 | 打造离散制造业 IIoT 标杆解决方案

KaiwuDB

数据库 iiot 制造业

帆软、永洪BI、瓴羊Quick BI等工具,都有哪些特点呢?

小偏执o

瓴羊Quick BI更合适“中国式报表”需求!

巷子

数据安全特点有哪些?现在企业如何保障数据安全?

行云管家

数据安全 堡垒机 数据泄露

「降本」有可能,「增效」不确定

Java 架构 程序人生 职场

规模化企业BI分析用哪家?帆软、永洪BI、瓴羊Quick BI深度对比

巷子

瓴羊Quick BI怎么样,BI工具数据看板见分晓!

小偏执o

物联网平台提醒欠费该如何查询和处理?——普及类

阿里云AIoT

物联网

喜马拉雅基于DeepRec构建AI平台实践

阿里云大数据AI技术

人工智能 深度学习 推理 企业号 3 月 PK 榜 稀疏学习

中小企业需要统一的快速开发平台吗?

力软低代码开发平台

什么是大前端技术?微信小程序用户占比达25%

没有用户名丶

IoTLink 版本更新 v1.8.0

山东云则信息科技

物联网平台 物联网 springboot

自动化离线交付在云原生的应用和思考

京东科技开发者

云原生 离线 企业号 3 月 PK 榜 自动化交付

【实践篇】教你玩转微服务--基于DDD的微服务架构落地实践之路

京东科技开发者

架构 后端 企业号 3 月 PK 榜 微服务器

复杂业务架构设计方法论的思考

FluttySage

架构

配运基础数据缓存瘦身实践

京东科技开发者

数据库 redis 缓存 key 企业号 3 月 PK 榜

面向新时代,海泰方圆战略升级!“1465”隆重发布!

电子信息发烧客

架构实战营模块三作业

null

Chrome 无魔法使用新必应(New Bing)聊天机器人

kcodez

chrome ChatGPT newbing 新必应

云计算生态该怎么做?阿里云计算巢打了个样

云布道师

云计算 阿里云

defi质押LP流动性挖矿dapp系统开发详情(案例)

开发微hkkf5566

易观分析:银保监会成为“历史”,金融行业将面临哪些重点影响?

易观分析

金融 经济

排序算法 Quick Sort

控心つcrazy

JavaScript 面试 前端 数据结构算法 算法、

IoT平台设备标签功能和规则引擎组合最佳实践——设备接入类

阿里云AIoT

sql 监控 物联网 API 定位技术

喜讯!阿里云数据库PolarDB荣获第12届PostgreSQL中国技术大会“开源数据库杰出贡献奖”

阿里云数据库开源

开源数据库 polarDB 阿里云数据库 PolarDB-PG PolarDB for PostgreSQL

二本毕业,靠学姐帮助混进大厂,女朋友却离我而去

程序员晚枫

程序员 女朋友 大厂 校招

当TO B客户说“没有预算”时,怎么卖SaaS|SaaStr观点

B Impact

三天吃透消息队列面试八股文

程序员大彬

Java 消息队列

matlab实现形态学图像处理

timerring

matlab 图像处理

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