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在手淘流量分析业务实践