导读：本文主要介绍手淘流量分析业务发展过程中，实时性业务分析需求的产生，实时分析目标的设定，如何进行技术的选型，以及如何基于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 ，几天后可以把这些数据删除，从而减少整个查询所消耗的集群成本。
今天的分享就到这里，谢谢大家。
嘉宾介绍：
Jason Xu阿里巴巴 | 高级数据产品专家
Jason Xu ( 花名：森森 ) ，阿里巴巴数据技术产部高级产品专家。
分享嘉宾：Jason Xu@阿里巴巴
编辑整理：夏仙森
出品平台：DataFunTalk
