华为云大数据存储技术创新——CarbonData解密及实践介绍

陈亮

CarbonData助力华为云服务

CarbonData

MRS

CarbonData

云Serverless场景• 按需付费• 动态伸缩

云租户场景• 免运维，低成本• 租户隔离

企业版/私有云场景• 自主部署• 自运营维护

Apache CarbonData

CarbonData

CarbonData

CarbonData

UQuery等

CarbonData

CarbonData

Agenda

• CarbonData项目背景

• CarbonData关键技术介绍

• DEMO和案例介绍

企业中包含多种数据应用，从商业智能、批处理到机器学习

Big Table

Ex. CDR, transaction,

Web log,…

Small table

Small table

Unstructured

data

data

Report & Dashboard OLAP & Ad-hoc Batch processing Machine learning Realtime Analytics

来自数据的挑战

• Data Size 数据规模

• Single Table >10 B 单表大于100亿行

• Fast growing 快速增长

• Nested data structure for complex object 数据结构复杂

• Multi-dimensional 数据维度多

• Every record > 100 dimensions 分析的维度超过100

• Add new dimension occasionally 维度不断增长

• Billion level high cardinality 不同值范围在亿级别

来自应用的挑战

• Enterprise Integration

• SQL 2003 Standard Syntax

• BI integration, JDBC/ODBC

• Flexible Query

• Any combination of dimensions

• OLAP Vs Detail Record

• Full scan Vs Small scan

• Precise search & Fuzzy search

交互式分析，详单过滤业务

各种指标计算、KPI统计业务

任意维度组合的在线分析

企业应用集成

灵活查询无固定模式

How to choose unified storage?

如何构建大数据统一存储平台？

社区各种大数据方案分析

1. NoSQL Data(适合实时应用，不适合分析型应用)•只支持单列key value查询 <5ms•不支持标准SQL

2. MPP Data(适合中小规模数据分析) •Shared-nothing架构，并行计算•不支持大集群 <100节点，没有容错，扩展能力有上限，不能与大数据生态集成

3. Cube Data(适合BI类MOLAP应用)

•预聚合，查询快•但数据膨胀大，支持维度少，不支持查明细数据

4. Search Engine Data(适合文本类分析)•通过索引快速找到数据•数据膨胀大2-4倍，不支持标准SQL

5. SQL on Hadoop•聚焦计算引擎的分布式扫描•存储效率不高

架构师的苦恼：不同应用不同数据存储，如果让数据存储统一？

Loading

Data

App1 App2 App3

Replication

Data

App1 App2 App3

Choice 1: Compromising Choice 2: Replicating of data

做出妥协，只满足部分应用 复制多份数据，满足所有应用

CarbonData: Unified Storage

CarbonData目标：一份数据满足多种业务需求，与大数据生态无缝集成

一份数据满足多种分析场景详单过滤，海量数仓，数据集市，…

交互式分析，详单过滤业务

各种指标计算、KPI统计业务

任意维度组合的在线分析

Agenda

• CarbonData项目背景

• CarbonData关键技术介绍

• DEMO和案例介绍

数据统一存储：一份数据支持多种业务场景，减少数据孤岛和冗余，通过数据共享产生更大价值。

大集群：区别于以往的单机系统，企业客户希望新的大数据存储方案能应对日益增多的数据，随时可以通过增加资源的方式横向扩展，无极扩容。

易集成：提供标准接口，新的大数据方案与企业已采购的工具和IT系统要能无缝集成，支撑老业务快速迁移。与大数据生态软件能无缝集成。

高性能：数据分析要求越来越高效、实时。

开放生态：通过开源开放，让更多的客户和合作伙伴的数据连接在一起，发挥更大的价值，与当前大数据生态无缝集成。

CarbonData设计思路

•数据布局•Block：对应一个HDFS block块/CarbonData文件，默认1GB，创建表时可配置BLOCKSIZE：

•Blocklet：每个CarbonData文件切分成多个blocklet，默认是64M，可配置carbon.blockletgroup.size.in.mb

•Page：每个Blocklet切分成多个page数据块，最小的粒度，32000行(不需配置，系统最佳值)

CarbonData文件格式介绍：https://github.com/apache/carbondata/blob/master/docs/file-structure-of-carbondata.md

Carbon Data File

Blocklet 1

Column 1 Chunk

Column 2 Chunk

…

Column n Chunk

Blocklet N

File Footer

…

Blocklet Offset, Index & Stats

CarbonData文件格式介绍

File Header

Version

Schema

Page1 …Page2 Page3

TBLPROPERTIES ('TABLE_BLOCKSIZE'='512')

CarbonData丰富索引和字典编码技术介绍

• 多维KEY索引

• Min/Max索引

• 倒排索引

• Lucene索引

从表级，文件级，列级等多个层级逐级快速找到目标数据，避免SQL-on-Hadoop引擎常见的“暴力扫描“，从而大幅提升性能。

• 全局字典编码

CarbonData应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要做跨节点数据交换的业务来说性能提升非常明显。

Years Quarters Months Territory Country Quantity Sales2003 QTR1 Jan EMEA Germany 142 11,4322003 QTR1 Jan APAC China 541 54,7022003 QTR1 Jan EMEA Spain 443 44,6222003 QTR1 Feb EMEA Denmark 545 58,8712003 QTR1 Feb EMEA Italy 675 56,1812003 QTR1 Mar APAC India 152 29,7492003 QTR1 Mar EMEA UK 570 51,0182003 QTR1 Mar Japan Japan 561 55,2452003 QTR2 Apr APAC Australia 525 50,3982003 QTR2 Apr EMEA Germany 144 11,532

[1,1,1,1,1] : [142,11432]

[1,1,1,3,2] : [541,54702]

[1,1,1,1,3] : [443,44622]

[1,1,2,1,4] : [545,58871]

[1,1,2,1,5] : [675,56181]

[1,1,3,3,6] : [152,29749]

[1,1,3,1,7] : [570,51018]

[1,1,3,2,8] : [561,55245]

[1,2,4,3,9] : [525,50398]

[1,2,4,1,1] : [144,11532]

•数据即索引•全局字典编码

Blocklet (Columnar view)

Sort

(MDK Index)

[1,1,1,1,1] : [142,11432]

[1,1,1,1,3] : [443,44622]

[1,1,1,3,2] : [541,54702]

[1,1,2,1,4] : [545,58871]

[1,1,2,1,5] : [675,56181]

[1,1,3,1,7] : [570,51018]

[1,1,3,2,8] : [561,55245]

[1,1,3,3,6] : [152,29749]

[1,2,4,1,1] : [144,11532]

[1,2,4,3,9] : [525,50398]

建立MDK Index

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

2

2

1

1

1

2

2

3

3

3

4

4

1

1

3

1

1

1

2

3

1

3

142

443

541

545

675

570

561

152

144

525

11432

44622

54702

58871

56181

51018

55245

29749

11532

50398

C1 C2 C3 C4 C5 C6 C7

1

3

2

4

5

7

8

6

1

9

字典编码

举例：MDK索引建立过程（一）

举例：MDK索引建立过程（二）

Blocklet 1

1 1 1 1 1 1 12000

1 1 1 2 1 2 5000

1 1 2 1 1 1 12000

1 1 2 2 1 2 5000

1 1 3 1 1 1 12000

1 1 3 2 1 2 5000Blocklet 2

1 2 1 3 2 3 11000

1 2 2 3 2 3 11000

1 2 3 3 2 3 11000

1 3 1 4 3 4 2000

1 3 1 5 3 4 1000

1 3 2 4 3 4 2000Blocklet 3

1 3 2 5 3 4 1000

1 3 3 4 3 4 2000

1 3 3 5 3 4 1000

1 4 1 4 1 1 20000

1 4 2 4 1 1 20000

1 4 3 4 1 1 20000Blocklet 4

2 1 1 1 1 1 12000

2 1 1 2 1 2 5000

2 1 2 1 1 1 12000

2 1 2 2 1 2 5000

2 1 3 1 1 1 12000

2 1 3 2 1 2 5000

Blocklet Index

Blocklet1

Start Key1

End Key1Start Key1

End Key4

Start Key1

End Key2

Start Key3

End Key4

Start Key1

End Key1

Start Key2

End Key2

Start Key3

End Key3

Start Key4

End Key4

File FooterBlocklet

构成下面的Multi-Dimension-Key索引树

C1(Min, Max)

….

C7(Min, Max)

Blocklet4

Start Key4

End Key4

C1(Min, Max)

….

C7(Min, Max)

C1(Min,Max)

…

C7(Min,Max)

C1(Min,Max)

…

C7(Min,Max)

C1(Min,Max)

…

C7(Min,Max)

C1(Min,Max)

…

C7(Min,Max)

利用两级索引架构减少Spark Task数和磁盘IO

Spark Driver

Executor

Carbon File

Data

Footer

Carbon File

Data

Footer

Carbon File

Data

Footer

Blocklet Index

Block Index

Executor

Blocklet Index

Catalyst

• 第一级：文件级索引用于过滤文件（HDFS Block），避免扫描不必要的文件，减少多达95%的Spark Task

• 第二级：Blocklet索引用于过滤文件内部的Blocklet，避免扫描不必要的Blocklet，减少磁盘IO

Spark Executor

Spark Driver

Blocklet(many pages for each column)

HDFS

File

Footer

Blocklet

Blocklet

…

…

C1 C2 C3 C4 Cn

1. File pruning

File

Blocklet

Blocklet

Footer

File

Footer

Blocklet

Blocklet

File

Blocklet

Blocklet

Footer

Blocklet Blocklet Blocklet Blocklet

Task Task

2. Blockletpruning

3. Read and decompress filter column ‘c2’4. Binary search using inverted index, skip tonext page if no matching

…

5. Decompress projection column6. Return decoded data(real value) to spark

SELECT c3, c4 FROM t1 WHERE c2=’xxx’

一个完整的过滤查询过程

预聚合

灵活预聚合，无需建模：与传统BI系统的CUBE方案最大区别是，用户不需要预先进行Cube建模以及修改任何SQL语句，既可加速OLAP分析性能，又可查询明细数据，做到一份数据同时满足多种应用场景，具体用法如下：

（主表） （主表sales创建预聚合表）

（当用户做查询时，首先用户不需要改SQL查询语句，仍然使用主表进行查询。当收到查询请求后，CarbonData会对SQL做基于代价的自动优化，将SQL改写为预聚合表上的查询，例如下列语句会命中预聚合表，可显著提升查询性能）

预聚合性能结果

• 支持的预聚合表达式有：SUM、AVG、MAX、MIN、COUNT

• 在1亿数据量上实测性能可提升10+倍以上，数据越大，性能提升效果越好。大家可以参考例子…/examples/PreAggregateTableExample.scala

流式准实时入库，提升数据时效性同时避免小文件问题

• 数据准实时入库，准实时查询(秒级)

• 无小文件问题

• 一张表可同时查询实时数据和历史数据，避免多个表格间来回切换

• 支持多种流处理框架：SparkStreaming, Structured Streaming等

• SQL

• Dataframe

df.write

.format(“carbondata")

.options("tableName“, “t1"))

.mode(SaveMode.Overwrite)

.save()

CREATE TABLE tablename (name String, PhoneNumber String)

STORED BY “carbondata”

TBLPROPERTIES (...)

LOAD DATA [LOCAL] INPATH 'folder path' [OVERWRITE] INTO TABLE tablename

OPTIONS(...)

INSERT INTO TABLE tablennme select_statement1 FROM table1;

数据入库

• SQL

• Dataframe

SELECT project_list FROM t1

WHERE cond_list

GROUP BY columns

ORDER BY columns

df = sparkSession.read

.format(“carbondata”)

.option(“tableName”, “t1”)

.load(“path_to_carbon_file”)

df.select(…).show

数据查询

UPDATE table1 A

SET (A.PRODUCT, A.REVENUE) =

(

SELECT PRODUCT, REVENUE

FROM table2 B

WHERE B.CITY = A.CITY AND B.BROKER = A.BROKER

)

WHERE A.DATE BETWEEN ‘2017-01-01’ AND ‘2017-01-31’

table1 table2

UPDATE table1 A

SET (A.REVENUE) = (A.REVENUE – 10)

WHERE A.PRODUCT = ‘phone’

DELETE FROM table1 A

WHERE A.CUSTOMERID = ‘123’

123, abc

456, jkd

phone, 70 60

car,100

phone, 30 20

Modify one column in table1

Modify two columns in table1 with values from table2

Delete records in table1

更新和删除

更多的Features：

• Segment管理（数据老化，指定批次查询等）

• 标准Partition

• Compaction

• Alter Table

• 支持与多引擎集成(Presto，Hive等)

• 等等……

Agenda

• CarbonData项目背景

• CarbonData关键技术介绍

• DEMO和案例介绍

金融详单分析：提升查询性能和扩展性

复制

银行交易详单

Impala：1.只适合Join/Orderby的业务，多维过滤性能不足；2.扩展性不足，难以扩展

上百节点、无法支撑海量数据查询

HBase：1、对6个关键维度查询，需要建立4个二级索引，数据膨胀太大，数据同步复杂2、无法用YARN统一资源管理

HBaseImpala

优化后

1. 一份数据完成复杂分析和多维点查，简化存储

2. 支持万亿数据量分析，秒级响应，高扩展性

3. 统一资源管理

CarbonData方案优化

优化前

电信详单、交易详单

Spark

电信：数仓分析场景，替换SybaseIQ和磁盘阵列

新方案

使用Carbon替换：整个产品融合为

一个HDFS存储，不依赖磁阵。

性能提升：Carbon索引提升IO效率

和分布式计算效率，提升整体性能

3~8倍

规模：迁移15个业务，1000+张表；

每15分钟、1小时、1天加载一次数据

原方案

成本高：需要部署光交换机、

磁盘阵列

无法云化：数据存储在磁阵上，

无法支持容器、VM部署

查询性能差：在忙时查询性能

无法满足要求，需要扩容磁阵

物理机或云IaaS

光交换机

磁盘阵列

服务器业务 SQL特征 优化前 优化后 提升

业务1 多过滤（IO型） 10~20S 3S 5倍

业务2 高维计数TopN（全表扫描+用户数统计）

15S 7S 3倍

业务3 多过滤（IO型） 20S-30S 3S 8倍

业务3 高维聚合（千万级汇聚+全表扫描）

超时 20~30S --

典型业务场景优化对比：SybaseIQCarbonData

结果

过滤查询：5倍数据量，时间增加<1倍。

汇总分析：有效利用计算资源，可线性扩展

数据：2000亿到1万亿数据 (中国某省份半年数据)

集群: 70 nodes, 1120 cores

查询:Q1: filter (c1~c4), select *Q2: filter (c10), select *Q3: full scan aggregate

0.00%

100.00%

200.00%

300.00%

400.00%

500.00%

200B 400B 600B 800B 1000B

Response Time (% of 200B)

Q1 Q2 Q3

大数据集Scale out测试

• 在Spark-Shell里由以下语句生成10亿条数据，每条数据四个字段组成（ID,

country,city,population）：

val r = new Random() //创建随机数

val df = spark.sparkContext.parallelize(1 to 1000 * 1000 * 1000).map(x =>

("No."+r.nextInt(1000000), "country" + x%8, "city"+x%50,

x%300)).toDF("ID","country","city","population") //创建10亿数据的dataframe

• 过滤查询（索引）：select * from table where ID='No.xxx';

select * from table where ID='No.xxx' and country='countryxxx' and city='cityxxx' and

population < 10000;

• 计算查询（字典编码）： select country, sum(population) from table group by country;

DEMO

总结：CarbonData方案适合的场景

1.有明确查询条件的，如：交互式分析、主题分析场景。

2.数据量大，动态无极扩展，如：历史库分析场景。（XX企业达到万亿数据，所有过滤查询业务可达秒级响应）。

3.希望数据统一存储，共享；一份数据同时满足多种业务场景需要（查询类+复杂应用开发+机器学习等场景）。

4.需要无缝与大数据生态集成，利用已有Hadoop集群资产。

更多技术细节，可关注Apache CarbonData社区：

• 主页: http://carbondata.apache.org

• Code托管: https://github.com/apache/carbondata.git

• Mailing list，技术讨论: dev@carbondata.apache.org

(先发邮件到dev-subscribe@carbondata.apache.org，加入mailing list)

欢迎大家使用云上强大的CarbonData功能，一份数据满足您的多种业务场景需求

http://www.huaweicloud.com/

THANK YOU