用户行为分析UV存储解决方案之ClickHouse

迷南。 2022-10-06 10:55 172阅读 0赞

### 用户行为分析UV存储解决方案之ClickHouse ###

*  1 基础理论篇
 *   *  1.1 序
     *  1.2 什么是ClickHouse？
     *  1.3 什么是列式存储？
     *  1.4 OLAP场景的关键特征
     *  1.5 列式数据库更适合OLAP场景的原因
     *   *  输入/输出
         *  CPU
 *  2 实操篇之 ClickHouse 安装与运行
 *   *  2.1 Clickhouse 安装
     *  2.2 创建启动脚本
     *  2.3 启动Clickhouse 服务端
     *  2.4 启动客户端

# 1 基础理论篇 #

## 1.1 序 ##

在科技不断发展的今天,千人千面的推荐算法变得越来越重要，而要实现推荐算法，检测，记录与分析用户行为是非常重要的一个指标。

就拿短视频业务来说,如果只是统计视频的pv播放量，那么用传统的关系型数据库MySQL即可，但是如果想存储和统计视频的UV播放量,就变得极为困难。

这是因为用户每天对视频的播放记录增长是一个非常恐怖的数据，传统的关系型数据库无法承载存储这么多的用户行为日志记录。

为此，博主一直在为公司试图寻找一种能够解决这种业务问题的技术,经过多方调研，找到了ClickHouse.

当然还有一种百度改造开源捐献给Apache 社区的Apache Doris , 不过目前来看，ClickHouse 的技术比较成熟，已经在抖音和快手落地，唯一遗憾是join 查询支持不够友好, 而且由于各个组件可定制化程度高, 维护相对复杂点，Apache Doris 则支持join并维护相对较容易。

所以总之，如果有join需求考虑尝试Apache Doris, 如果没有join场景需求建议ClickHouse.

## 1.2 什么是ClickHouse？ ##

> 官网介绍: ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

ClickHouse 是一个面向列存储的在线实时查询分布式数据库，适合做用户行为分析存储和查询。

> **据说，抖音，快手的用户行为记录UV相关存储就是采用的ClickHouse 集群。**

ClickHouse 之所以适合处理UV存储记录，根据博主理解主要因为满足如下几点：

*  面向列存储,适合这种类型的数据存储
 *  借鉴了Google 论文HDFS 分布式文件存储技术
 *  借鉴了Google 论文MapReduce 分布式计算查询技术
 *  借鉴了Google 论文BigTable技术

当然，ClickHouse 不是用户行为分析UV存储的唯一解决方案，除此之外，还有基于Hadoop 生态体系的HBase,等。

阿里云的云原生数仓也提供了付费解决方案：MaxCompute（离线） 和 HoleGress（实时）

>  *  大数据计算服务([MaxCompute][]，原名ODPS)是一种快速、完全托管的TB/PB级数据仓库解决方案。MaxCompute向用户提供了完善的数据导入方案以及多种经典的分布式计算模型，能够更快速的解决用户海量数据计算问题，有效降低企业成本，并保障数据安全。
>  *  MaxCompute交互式分析（[Hologres][]）是为大数据设计的实时交互式分析产品，它与MaxCompute无缝打通，支持数据实时写入，支持PB级数据进行高并发、低延时的分析处理，兼容PostgreSQL协议，可以使用您最熟悉的BI工具对海量数据进行自助的多维分析透视和业务探索，同时也支持超高QPS点查能力，满足数仓分析、服务一体化需求。

## 1.3 什么是列式存储？ ##

在传统的行式数据库系统中，数据按如下顺序存储：

<table> 
 <thead> 
  <tr> 
   <th>Row</th> 
   <th>WatchID</th> 
   <th>JavaEnable</th> 
   <th>Title</th> 
   <th>GoodEvent</th> 
   <th>EventTime</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>#0</td> 
   <td>89354350662</td> 
   <td>1</td> 
   <td>Investor Relations</td> 
   <td>1</td> 
   <td>2016-05-18 05:19:20</td> 
  </tr> 
  <tr> 
   <td>#1</td> 
   <td>90329509958</td> 
   <td>0</td> 
   <td>Contact us</td> 
   <td>1</td> 
   <td>2016-05-18 08:10:20</td> 
  </tr> 
  <tr> 
   <td>#2</td> 
   <td>89953706054</td> 
   <td>1</td> 
   <td>Mission</td> 
   <td>1</td> 
   <td>2016-05-18 07:38:00</td> 
  </tr> 
  <tr> 
   <td>#N</td> 
   <td>…</td> 
   <td>…</td> 
   <td>…</td> 
   <td>…</td> 
   <td>…</td> 
  </tr> 
 </tbody> 
</table>

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：`MySQL`、`Postgres`和`MS SQL Server`。

在列式数据库系统中，数据按如下的顺序存储：

<table> 
 <thead> 
  <tr> 
   <th>Row:</th> 
   <th>#0</th> 
   <th>#1</th> 
   <th>#2</th> 
   <th>#N</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>WatchID:</td> 
   <td>89354350662</td> 
   <td>90329509958</td> 
   <td>89953706054</td> 
   <td>…</td> 
  </tr> 
  <tr> 
   <td>JavaEnable:</td> 
   <td>1</td> 
   <td>0</td> 
   <td>1</td> 
   <td>…</td> 
  </tr> 
  <tr> 
   <td>Title:</td> 
   <td>Investor Relations</td> 
   <td>Contact us</td> 
   <td>Mission</td> 
   <td>…</td> 
  </tr> 
  <tr> 
   <td>GoodEvent:</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
   <td>…</td> 
  </tr> 
  <tr> 
   <td>EventTime:</td> 
   <td>2016-05-18 05:19:20</td> 
   <td>2016-05-18 08:10:20</td> 
   <td>2016-05-18 07:38:00</td> 
   <td>…</td> 
  </tr> 
 </tbody> 
</table>

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。

不同的数据存储方式适用不同的业务场景，数据访问的场景包括：进行了何种查询、多久查询一次以及各类查询的比例；每种类型的查询(行、列和字节)读取多少数据；读取数据和更新之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等。

系统负载越高，依据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统能够同时适用所有不同的业务场景。如果系统适用于广泛的场景，在负载高的情况下，要兼顾所有的场景，那么将不得不做出选择。是要平衡还是要效率？

## 1.4 OLAP场景的关键特征 ##

>  *  绝大多数是读请求
>  *  数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
>  *  已添加到数据库的数据不能修改。
>  *  对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
>  *  宽表，即每个表包含着大量的列
>  *  查询相对较少(通常每台服务器每秒查询数百次或更少)
>  *  对于简单查询，允许延迟大约50毫秒
>  *  列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
>  *  处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
>  *  事务不是必须的
>  *  对数据一致性要求低
>  *  每个查询有一个大表。除了他以外，其他的都很小。
>  *  查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中

很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求

## 1.5 列式数据库更适合OLAP场景的原因 ##

列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：

**行式**

![Row oriented][]  
**列式**  
![Column oriented][]

看到差别了么？下面将详细介绍为什么会发生这种情况。

### 输入/输出 ###

> 1.  针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
> 2.  由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
> 3.  由于I/O的降低，这将帮助更多的数据被系统缓存。

例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

### CPU ###

由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效。同时这将有助于实现一个几乎没有调用成本的查询引擎。如果你不这样做，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。

有两种方法可以做到这一点：

> 1.  向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内部循环。
> 2.  代码生成：生成一段代码，包含查询中的所有操作。

这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，例如，MemSQL使用代码生成来减少处理SQL查询的延迟(只是为了比较，分析型数据库通常需要优化的是吞吐而不是延迟)。

请注意，为了提高CPU效率，查询语言必须是声明型的(SQL或MDX)， 或者至少一个向量(J，K)。 查询应该只包含隐式循环，允许进行优化。

# 2 实操篇之 ClickHouse 安装与运行 #

这里分享下Centos7 环境下clickhouse 的安装,其他方式的安装请参考[官方文档][Link 1]。

clickhouse 官方Docker 镜像地址[传送门][Link 2]

## 2.1 Clickhouse 安装 ##

ClickHouse 在Centos7 上的安装很简单，通过如下命令即可：

sudo yum install yum-utils
    sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
    sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/clickhouse.repo
    sudo yum install clickhouse-server clickhouse-client

## 2.2 创建启动脚本 ##

sudo /etc/init.d/clickhouse-server start

如果重复执行会报错如下：

Init script is already running

## 2.3 启动Clickhouse 服务端 ##

*  重启clickhouse-server

clickhouse-server start

>  *  在这种情况下，日志将被打印到控制台，这在开发过程中很方便。
>  *  日志文件将输出在`/var/log/clickhouse-server/`文件夹。
>  *  如果配置文件在当前目录中，则不需要指定——config-file参数。默认情况下，它的路径为./config.xml。
>  *  如果服务器没有启动，检查`/etc/clickhouse-server/config.xml`中的配置。
>  *  如果需要手动指定配置文件,输入命令如下即可
> 
>     clickhouse-server --config-file=/etc/clickhouse-server/config.xml
> 
>  *  ClickHouse支持访问限制设置。它们位于`users.xml`文件(与`config.xml`同级目录)。
>  *  默认情况下，允许default用户从任何地方访问，不需要密码。可查看`user/default/networks`[更多信息][Link 3]

## 2.4 启动客户端 ##

由于服务端启动不是使用后台守护线程启动，因此这里需要新开一个窗口，执行如下命令：

clickhouse-client

> 注意：  
> 如果没有2.3 启动Clickhouse 服务端这一步骤，会报错如下：
> 
>     ClickHouse client version 21.6.4.26 (official build). 
>     Connecting to localhost:9000 as user default. Code: 210. 
>     DB::NetException: Connection refused (localhost:9000)
> 
>  *  默认情况下，使用default用户并不携带密码连接到`localhost:9000`。还可以使用`--host`参数连接到指定服务器。
>  *  终端必须使用UTF-8编码

示例：

$ ./clickhouse-client
    ClickHouse client version 0.0.18749.
    Connecting to localhost:9000.
    Connected to ClickHouse server version 0.0.18749.
    
    :) SELECT 1
    
    SELECT 1
    
    ┌─1─┐
    │ 1 │
    └───┘
    
    1 rows in set. Elapsed: 0.003 sec.
    
    :)

--------------------

本篇完～

[MaxCompute]: https://help.aliyun.com/product/27797.html
[Hologres]: https://www.aliyun.com/product/bigdata/hologram?spm=a2c4g.11174283.J_8058803260.54.6f02590ecsBk3n
[Row oriented]: /images/20221005/bac8b718007b4ad3badd9eec552d632d.png
[Column oriented]: /images/20221005/2cf540e0ff7f446a8bacb4223baa5552.png
[Link 1]: https://clickhouse.tech/#quick-start
[Link 2]: https://hub.docker.com/r/yandex/clickhouse-server/
[Link 3]: https://clickhouse.tech/docs/zh/operations/configuration-files/