布景
Databend 是一款根据目标存储的存算别离湖仓产品，已成为云上大数据剖析中高效且低本钱的首选解决计划。现在，Databend 在多个用户场景中得到广泛应用，包含：
- 新媒体行业数据剖析及大屏数据展示
- 云上 CDH 代替以削减本地磁盘和资源占用
- 性能显着提高的云上 Greenplum 代替计划
- 下降用户管理复杂度的云上 Clickhouse 代替计划
- …
Databend 将数据持久化存储在目标存储中，核算层无状态且可随意扩展。一同，Databend 还充分使用云上目标存储的无需虚拟专用网络（VPC）的特性，完成了一个统一化的湖仓解决计划。
在云上构建大数据环境时，有两个昂贵的本钱需求考虑：
- 本地磁盘本钱，包含很多的闲置存储空间和冗余副本。
- 流量本钱，跨 VPC 通信的带宽费用，一般 1G 带宽的本钱都超越 0.5 元。
越来越多的云上用户选择使用 Databend 结合目标存储构建湖仓，以节约本地磁盘本钱。因为目标存储无需 VPC，全球写入无需费用，内网请求无带宽费用，然后下降了云上大数据相关费用。
本文将介绍怎么经过私有化布置 Databend 和结合公有云上的 Databend Cloud，将中心事务布置在私有环境中，然后凭借 Databend Cloud 进行大规模核算和发掘，用户能够削减 IT 建造本钱，并完成强大的云端核算才能。
客户事例：
咱们以一家坐落阿里云杭州区的短视频内容工业客户为例。其间心事务涉及多渠道内容投进，如抖音、快手、微信视频号等。客户在现有系统中布置了 Databend 服务，用于收集多个渠道的数据投进状况和订单数据，并在数据渠道上展示。这不只让管理层直观地看到事务数据，也为营销战略提供了数据支持。
事务特征：
-
多个渠道的数据投进：或许呈现多个渠道回来的订单数据，以及多个 API 的数据回传
-
数据全网打通：剖析用户群体的活跃状况和投进作用
-
投进的留存剖析及转化剖析
-
挖倔剖析及数据整理
应战与解决计划：
该客户面对的主要应战包含数据去重、多渠道数据整合、投进留存剖析和数据发掘。
-
数据去重：因为多渠道数据回传，或许存在重复数据。客户现在选用创建暂时表的方式，接收传输的数据，并经过 SQL 与已入库数据进行比较，入库不重复数据，丢掉重复数据。
-
全网数据打通：需求对来自多个渠道的用户进行匹配，核算用户活跃度和投进状况。因为事务只要 3 台 Databend 机器，有时会面对资源瓶颈。
-
投进留存和转化剖析：可使用 Databend 的 bitmap 和漏斗函数进行便利的剖析。
-
数据发掘剖析：使用 Databend 的索引特性，经过各种 SQL 查询完成高效的数据发掘剖析。
客户现在的应战是处理大型 SQL 请求对现有资源形成较大压力，但又不希望扩大环境规模（受限于 IT 本钱）。因而，结合 Databend Cloud 的使用，能够优化私有化 Databend 布置的本钱。
接下来以 TPCH 中的表举例
基本架构如下
-
从阿里云商场相关 Databend Cloud
-
用户所在的区有对应的 Databend Cloud，核算和存储不要跨区
-
私有化环境表对应的 URI
-
在 Databend Cloud 中创建 attach 只读表
获取原表在存储上的方位
具体操作如下：
- 获取用户对应表的 URI
例如这儿需求找到 tpch_100.lineitem 对应的 uri ，首要
SELECT
regexp_substr(snapshot_location, '^d /d /') AS table_path FROM
fuse_snapshot('tpch_100', 'lineitem')
LIMIT 1;
┌──────────────────┐
│ table_path │
│ Nullable(String) │
├──────────────────┤
│ 28/33/ │
└──────────────────┘
1 row read in 0.013 sec. Processed 1 row, 227 B (79.57 row/s, 17.64 KiB/s)
其间 snapshot_location 是对应的 bucket 下的 root 下指定的方位，默认 root 为：空。
例如我的 oss 配为：
SELECT * FROM system.configs WHERE name LIKE '%bucket' OR name LIKE '%root';
┌───────────────────────────────────────────────────┐
│ group │ name │ value │ description │
│ String │ String │ String │ String │
├─────────┼──────────────┼────────────┼─────────────┤
│ storage │ gcs.bucket │ │ │
│ storage │ gcs.root │ │ │
│ storage │ s3.bucket │ │ │
│ storage │ s3.root │ │ │
│ storage │ azblob.root │ │ │
│ storage │ hdfs.root │ │ │
│ storage │ obs.bucket │ │ │
│ storage │ obs.root │ │ │
│ storage │ oss.bucket │ wubx-bj01 │ │
│ storage │ oss.root │ wubx202310 │ │
│ storage │ webhdfs.root │ │ │
│ storage │ cos.bucket │ │ │
│ storage │ cos.root │ │ │
└───────────────────────────────────────────────────┘
13 rows read in 0.009 sec. Processed 155 rows, 9.21 KiB (16.51 thousand rows/s, 981.20 KiB/s)
针对这个环境的 URI 为：
语法: [oss://bucket[/root]/table_path/]
oss://wubx-bj01/wubx202310/28/33/
- 创建只读表
-
进入 worksheet
-
创建或是切换到指定库下创建表
attach table lineitem 'oss://wubx-bj01/wubx202310/28/33/' connection=(
endpoint_url='https://oss-cn-beijing-internal.aliyuncs.com'
access_key_id='x'
access_key_secret='x'
) READ_ONLY;
-
经过 show tables; 确认表存在
show tables;
select count(*) from lineietm;
测验 SQL
把 tpch100sf 中 lineitem 挂载到 Databend Cloud 中，测验 Q1 作用为：
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) AS sum_qty,
sum(l_extendedprice) AS sum_base_price,
sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 l_tax)) AS sum_charge,
avg(l_quantity) AS avg_qty,
avg(l_extendedprice) AS avg_price,
avg(l_discount) AS avg_disc,
count(*) AS count_order
FROM
lineitem
WHERE
l_shipdate <= add_days(to_date('1998-12-01'), -90)
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus;
效果展示
| 规格 | TPCH-100 Q1 响应时间 |
|---|---|
| 阿里云 S6-8C32G | 38.956s |
| Databend Cloud(medium) | 10.1s |
| Databend Cloud(xlarge) | 2.6s |
总结
经过 Databend Cloud，用户能够完成私有化大数据处理与公有云渠道的一致性，充分使用 Databend Cloud 的弹性核算才能，快速完成大规模的剖析 SQL 核算，使用后即能够开释。这种方法不只提高了效率，还在本钱操控方面提供了明显优势，为用户在数据驱动决议计划方面提供了强有力的支持。
Connect With Us
Databend 是一款开源、弹性、低本钱，根据目标存储也能够做实时剖析的新式数仓。期待您的关注，一同探究云原生数仓解决计划，打造新一代开源 Data Cloud。
Databend Cloud：databend.cn
Databend 文档：databend.rs/
WeChat：Databend
