以 100GB SSB 性能测试为例，通过 ByteHouse 云数仓开启你的数据分析之路-六虎

更多技能交流、求职机会，欢迎重视字节跳动数据渠道微信公众号，回复【1】进入官方交流群

I. 传统数仓的演进：云数仓

近年来，跟着数据“爆炸式”的增加，越来越多的数据被产生、收集和存储。而挖掘海量数据中的实在价值，从其间提取商机并洞见未来，则成了现代企业和组织不可忽视的命题。

跟着数据量级和杂乱度的增大，数据剖析处理的技能架构也在不断演进。在面对海量数据剖析时，传统 OLAP 技能架构中的痛点变得越来越明显，如扩容缩容耗时长，导致资源利用率偏低，成本居高不下；以及运维装备杂乱，需求专业的技能人员介入等。

为了解决这类问题，云数仓的概念应运而生。和传统数仓架构不同的是，云原生数仓借助于云渠道的根底资源，完结了资源的动态扩缩容，并最大化利用资源，然后达到 Pay as you go 按实践用量付费的形式。

ByteHouse 作为云原生的数据渠道，从架构层面下手，经过存储和核算分离的云原生架构完美适配云上根底设施。在字节跳动内部，ByteHouse 已经支撑 80% 的剖析使用场景，包括用户增加事务、广告、A/B 测验等。除了极致的剖析功用之外，ByteHouse 开箱即用，按实践运用付费的特性也极大地降低了企业和个人的上手门槛，能够在短短数分钟内体验到数据剖析的魅力。

Talk is cheap, 接下来就让我们经过一个实战事例来体验下 ByteHouse 云数仓的强壮功用。

II. 快速上手 ByteHouse——轻量级云数仓

本章节经过运用 ByteHouse 云数仓进行 SSB 基准测验，在带领读者了解产品功用的一起，也同时了解产品中各个模块的功用，开启你的数据剖析之路，经过剖析海量数据，加快数据洞察。ByteHouse 的架构总览如下。

以 100GB SSB 性能测试为例，通过 ByteHouse 云数仓开启你的数据分析之路

SSB 基准测验

SSB（Star Schema Benchmark）是由麻省州立大学波士顿校区的研究员界说的基于实际商业使用的数据模型。SSB 是在 TPC-H 规范的根底上改善而成，首要将 TPC-H 中的雪花模型改成了更为通用的的星型模型，将基准查询从杂乱的 Ad-hoc 查询改成了结构愈加固定的 OLAP 查询，然后首要用于模仿测验 OLAP 引擎和轻量数仓场景下的查询功用。因为 SSB 基准测验较为中立，并贴近实际的商业场景，因此在学界及工业界有广泛的使用。

SSB 基准测验中对应的表结构如下所示，能够看到 SSB 首要选用星型模型，其间包含了 1 个现实表 lineorder 和 4 个维度表 customer, part, dwdate 以及 supplier，每张维度表经过 Primary Key 和现实表进行相关。测验经过履行 13 条 SQL 进行查询，包含了多表相关，group by，杂乱条件等多种组合。更多具体信息请参阅 SSB 文献。

过程一：官网注册并注册 ByteHouse

拜访ByteHouse 云数仓火山引擎官网，注册火山引擎账户，完结实名认证后，即可登录到产品操控台。注册产品进行测验，现在 ByteHouse 支撑包年包月和按量付费两种形式的实例，便于您根据事务需求进行挑选。

过程二：创立核算组

登录到操控台后，能够看到数据库表办理、数据加载、SQL 作业表、核算组、查询历史和人物办理等几大模块。分别具有如下作用：

数据库表办理：用于创立和办理数据库、数据表以及视图等数据目标
数据加载：用于从不同的离线和实时数据源如目标存储、Kafka 等地写入数据
SQL 作业表：在界面上编辑、办理并运行 SQL 查询
核算组：创立和办理虚拟的核算资源，用于履行数据查询等操作
查询历史：用于检查 SQL 的历史履行记载、状况和查询详情等

为了便利进行后续的建库建表和查询等操作，首先在 ByteHouse 操控台创立型号为 L 的核算组，如下图所示

核算组是 Bytehouse 中的核算资源集群，可按需进行横向扩展。核算组供给所需的资源如 CPU、内存及暂时存储等，用于履行数据查询 DQL、DML 等操作。ByteHouse 核算组能够完结弹性扩缩容，读写分离、存算分离等，并且能对资源进行细粒度的权限操控。

过程三：创立数据库表

在操控台页面中创立名为 ssb_``100 的数据库

创立结束后，进入到 SQL 作业表模块，经过如下建表句子建立四个数据表（现实表），并保存对应的 SQL 句子。

CREATE TABLE ssb_100.customer
(
        C_CUSTKEY       UInt32,
        C_NAME          String,
        C_ADDRESS       String,
        C_CITY          LowCardinality(String),
        C_NATION        LowCardinality(String),
        C_REGION        LowCardinality(String),
        C_PHONE         String,
        C_MKTSEGMENT    LowCardinality(String),
        C_PLACEHOLDER   Nullable(String)
)
ENGINE = CnchMergeTree ORDER BY (C_CUSTKEY);
CREATE TABLE ssb_100.lineorder
(
    LO_ORDERKEY             UInt32,
    LO_LINENUMBER           UInt8,
    LO_CUSTKEY              UInt32,
    LO_PARTKEY              UInt32,
    LO_SUPPKEY              UInt32,
    LO_ORDERDATE            Date,
    LO_ORDERPRIORITY        LowCardinality(String),
    LO_SHIPPRIORITY         UInt8,
    LO_QUANTITY             UInt8,
    LO_EXTENDEDPRICE        UInt32,
    LO_ORDTOTALPRICE        UInt32,
    LO_DISCOUNT             UInt8,
    LO_REVENUE              UInt32,
    LO_SUPPLYCOST           UInt32,
    LO_TAX                  UInt8,
    LO_COMMITDATE           Date,
    LO_SHIPMODE             LowCardinality(String),
    LO_PLACEHOLDER          Nullable(String)
)
ENGINE = CnchMergeTree PARTITION BY toYear(LO_ORDERDATE) ORDER BY (LO_ORDERDATE, LO_ORDERKEY);
CREATE TABLE ssb_100.part
(
        P_PARTKEY       UInt32,
        P_NAME          String,
        P_MFGR          LowCardinality(String),
        P_CATEGORY      LowCardinality(String),
        P_BRAND         LowCardinality(String),
        P_COLOR         LowCardinality(String),
        P_TYPE          LowCardinality(String),
        P_SIZE          UInt8,
        P_CONTAINER     LowCardinality(String),
        P_PLACEHOLDER   Nullable(String)
)
ENGINE = CnchMergeTree ORDER BY P_PARTKEY;
CREATE TABLE ssb_100.supplier
(
        S_SUPPKEY       UInt32,
        S_NAME          String,
        S_ADDRESS       String,
        S_CITY          LowCardinality(String),
        S_NATION        LowCardinality(String),
        S_REGION        LowCardinality(String),
        S_PHONE         String,
        S_PLACEHOLDER   Nullable(String)
)
ENGINE = CnchMergeTree ORDER BY S_SUPPKEY;
CREATE TABLE ssb_100.dwdate
(
        D_DATEKEY            UInt32,
        D_DATE               String,
        D_DAYOFWEEK          String,    -- defined in Section 2.6 as Size 8, but Wednesday is 9 letters
        D_MONTH              String,
        D_YEAR               UInt32,
        D_YEARMONTHNUM       UInt32,
        D_YEARMONTH          String,
        D_DAYNUMINWEEK       UInt32,
        D_DAYNUMINMONTH      UInt32,
        D_DAYNUMINYEAR       UInt32,
        D_MONTHNUMINYEAR     UInt32,
        D_WEEKNUMINYEAR      UInt32,
        D_SELLINGSEASON      String,
        D_LASTDAYINWEEKFL    UInt32,
        D_LASTDAYINMONTHFL   UInt32,
        D_HOLIDAYFL          UInt32,
        D_WEEKDAYFL          UInt32,
        S_PLACEHOLDER        Nullable(String)
)
ENGINE=CnchMergeTree() ORDER BY (D_DATEKEY);

SQL 履行结束后，在操控台左边对应的数据目标页面会展示出创立完结的五个作业表，分别为 customer,dwdate,lineorder以及part 和 supplier

过程四：从目标存储中导入 SSB 数据

经过预先生成 SSB_100 GB 的数据集并存储在目标存储（如 AWS S3 或者火山引擎 TOS），我们能够便利且快速的将数据导入到 ByteHouse 中进行剖析。本次实践中经过装备火山引擎 TOS 的数据源对数据进行导入。

首先在数据加载模块，新建目标存储数据源，并装备对应的秘钥衔接火山引擎目标存储

衔接新的数据源后，挑选 bytehouse-shared-dataset 的贮存桶和ssb_100/lineorder.csv 相应的途径

挑选之前建的数据库ssb_100和对应标表lineorder，然后按创立。重复过程为其他四个作业表数据加载。

数据源中存储的数据条数如下所示。用于导入完结后，对数据表的行数进行核算，进行准确性校验。

创立导入使命完结后，点击“开端”发动导入使命，使命发动后会在几秒钟内分配资源并初始化导入使命，并在导入过程中展示预估的时间和导入进度。在导入使命的履行详情中，能够检查导入状况、导入具体日志、装备信息等。

过程五：数据处理及剖析

原始查询测验

经过履行 SSB 的 13 条查询句子，对于多表相关和排序等场景进行功用测验。查询句子如下所示：

打平表测验

为了便利对 SSB 数据集进行测验，我们能够经过改写 SSB，将星型模型打平转换为大宽表进行剖析

注：为了确保打平表的履行，需求装备参数 SET max_memory_usage = 20000000000; 此外需求在 ByteHouse 操控台中装备查询超时为 3600s，防止履行超时导致的失利。

SET max_memory_usage = 20000000000;
create table ssb_100.lineorder_flat
engine = CnchMergeTree
partition by toYear(lo_orderdate)
order by (lo_orderdate, lo_orderkey) as
select
    l.lo_orderkey as lo_orderkey,
    l.lo_linenumber as lo_linenumber,
    l.lo_custkey as lo_custkey,
    l.lo_partkey as lo_partkey,
    l.lo_suppkey as lo_suppkey,
    l.lo_orderdate as lo_orderdate,
    l.lo_orderpriority as lo_orderpriority,
    l.lo_shippriority as lo_shippriority,
    l.lo_quantity as lo_quantity,
    l.lo_extendedprice as lo_extendedprice,
    l.lo_ordtotalprice as lo_ordtotalprice,
    l.lo_discount as lo_discount,
    l.lo_revenue as lo_revenue,
    l.lo_supplycost as lo_supplycost,
    l.lo_tax as lo_tax,
    l.lo_commitdate as lo_commitdate,
    l.lo_shipmode as lo_shipmode,
    c.c_name as c_name,
    c.c_address as c_address,
    c.c_city as c_city,
    c.c_nation as c_nation,
    c.c_region as c_region,
    c.c_phone as c_phone,
    c.c_mktsegment as c_mktsegment,
    s.s_name as s_name,
    s.s_address as s_address,
    s.s_city as s_city,
    s.s_nation as s_nation,
    s.s_region as s_region,
    s.s_phone as s_phone,
    p.p_name as p_name,
    p.p_mfgr as p_mfgr,
    p.p_category as p_category,
    p.p_brand as p_brand,
    p.p_color as p_color,
    p.p_type as p_type,
    p.p_size as p_size,
    p.p_container as p_container
from ssb_100.lineorder as l
inner join ssb_100.customer as c on c.c_custkey = l.lo_custkey
inner join ssb_100.supplier as s on s.s_suppkey = l.lo_suppkey
inner join ssb_100.part as p on p.p_partkey = l.lo_partkey;

建表完结后，经过履行查询句子进行 SSB 功用测验，如下所示：

III. 查询结果和成本剖析

履行结束后，核算查询结果如下所示：

注：查询结果因装备参数和资源装备的不同，耗时也有差异，欢迎联系 ByteHouse 进行查询优化。

查询完结后，在 ByteHouse 核算组详情页面能够检查作业负载，包括总查询条数和 CPU/Mem 利用率等，然后承认核算资源的运用情况。

根据本次压测进行预估，耗费核算和存储资源如下表所示，因为 ByteHouse 云数仓版别按运用量计费的能力，在空闲时支撑自动封闭核算组并不收取搁置费用，然后能够极大的节约资源。测验完结后，预估的总体耗费约为 31.23 元。

点击跳转 ByteHouse云原生数据仓库了解更多

以 100GB SSB 性能测试为例，通过 ByteHouse 云数仓开启你的数据分析之路

I. 传统数仓的演进：云数仓

II. 快速上手 ByteHouse——轻量级云数仓

SSB 基准测验

过程一：官网注册并注册 ByteHouse

过程二：创立核算组

过程三：创立数据库表

过程四：从目标存储中导入 SSB 数据

过程五：数据处理及剖析

III. 查询结果和成本剖析

相关文章

筑基篇：设置界面的开发利器Preference Library，了解一下~

百度 APP iOS 端包体积 50M 优化实践 (四) 代码优化

冲突管理最佳实践

从 Linux Crontab 到 K8s CronJob，定时任务正在经历怎样的变革

作者信息