关于云原生:以-100GB-SSB-性能测试为例通过-ByteHouse-云数仓开启你的数据分析之路

30次阅读

共计 5771 个字符，预计需要花费 15 分钟才能阅读完成。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群

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

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

随着数据量级和复杂度的增大，数据分析解决的技术架构也在一直演进。在面对海量数据分析时，传统 OLAP 技术架构中的痛点变得越来越显著，如扩容缩容耗时长，导致资源利用率偏低，老本居高不下；以及运维配置简单，须要业余的技术人员染指等。

为了解决这类问题，云数仓的概念应运而生。和传统数仓架构不同的是，云原生数仓借助于云平台的根底资源，实现了资源的动静扩缩容，并最大化利用资源，从而达到 Pay as you go 按理论用量付费的模式。

ByteHouse 作为云原生的数据平台，从架构层面动手，通过存储和计算拆散的云原生架构完满适配云上基础设施。在字节跳动外部，ByteHouse 曾经反对 80% 的剖析利用场景，包含用户增长业务、广告、A/B 测试等。除了极致的剖析性能之外，ByteHouse 开箱即用，按理论应用付费的个性也极大地升高了企业和集体的上手门槛，可能在短短数分钟内体验到数据分析的魅力。

Talk is cheap, 接下来就让咱们通过一个实战案例来体验下 ByteHouse 云数仓的弱小性能。

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

本章节通过应用 ByteHouse 云数仓进行 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，而后按创立。反复步骤为其余四个工作表数据加载。

数据源中存储的数据条数如下所示。用于导入实现后，对数据表的行数进行统计，进行准确性校验。

创立导入工作实现后，点击“开始”启动导入工作，工作启动后会在几秒钟内分配资源并初始化导入工作，并在导入过程中展现预估的工夫和导入进度。在导入工作的执行详情中，能够查看导入状态、导入具体日志、配置信息等。

步骤五：数据处理及剖析

1. 原始查问测试
通过执行 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 云原生数据仓库 理解更多

正文完
云原生
发表至： 云原生
2023-04-03
 0
关于云原生:新一代云原生实时数仓-SelectDB-发布会精华干货五大核心特色解读
关于云原生:超大模型工程化实践打磨百度智能云发布云原生-AI-20-方案
关于云原生:我们被一个-kong-的性能-bug-折腾了一个通宵
关于云原生:云原生技术实践营微服务X消息队列专场