展开查看详情
1 . CarbonData 2.0:
A New Era in Mutable Big Data
2020-6
2 . 目录
• 背景
• 快速体验CarbonData 2.0
• 性能
• 案例
2
4 .BIG DATA: 60s ISAM / VSAM
根据索引任意地访问任何记录。
1. 文件包含排序的记录
2. client-server模式访问磁盘上的文件
4
5 .MUTABLE DATA: 1972 A Relational Model of Data for
Large Shared Data Banks (Codd)
“关系” 定义了数据的变化模型、ACID实现数据变化的正确性
“数据库不是数据的集合，而是事实的集合”——Codd
为什么是关系？而不是表？ 因为数据库是我们针对事实的陈述，是现实世界的反映和
记录，是世间万物之间的关系和联系
为什么是关系变量？而不是值？ 关系变量是现实世界的一部分，体现数据的MUTABLE
关系 ID 供应商 经销商 订单 关系变量
S1 Jose StonedHill 3100
S2 Alice BigHead 2900
S3 Lin DoneAudy 2700
S4 Joyce Atlanta 1800
5
7 . 数据库的进一步发展
是不是真的需要索引?
是不是真的需要ACID?
7
8 . 2006 BigTable: A Distributed Storage System for
Structured Data (Google)
NoSQL = SQL – ACID 好处：写入/更新性能高
缺点：不支持事务，不能支持MUTABLE
DATA的正确性
8
9 . 2006 BigTable: A Distributed Storage System for
Structured Data (Google)
9
10 . 2012 Processing a Trillion Cells per Mouse Click.
Parquet、ORC = SQL – ACID – 索引
在暴力扫描场景，减少了不必要的索引维护开销，
缺点是原本索引可以快速搞定的事情，现在也需要暴力扫描了
索引有场景
客户声音一：某互联网
在S3上存储了20PB数据，结果想从中间找到一个指定用户数据，完全不可能
客户声音二：某网安
没有一个系统可以同时满足大数据下的精确查询和聚合分析
10
11 .2012 Spanner: Google's Globally-Distributed Database
NewSQL的发展证明了ACID的重要性
11
12 . CarbonData 2.0
一个支持ACID和索引的全场景数据湖的存储底座
解决两个场景：
1、ACID：传统数据秒级入湖
2、索引：一份数据同时满足海量数据精确查询、聚合分析
10 PB数据精确查询 30秒内返回
聚合分析场景秒级响应（预聚合），比Parquet优化30%（无索引）
12
13 . 目录
• 背景
• 快速体验CarbonData 2.0
• 性能
• 案例
13
15 . 传统数据入湖演示
MRS
• 基于行级Delta文件，IO小，面向实时更新优化
• 对比“重写”方式，更新时间缩短50%-70%.
• Segment1~10 查询时合并Delta
• Row1 v3
表空间
元数据
MySQL 更新日志采集
数据
数据 数据 数据 索引
数据同步 文件 文件 文件 文件
MongoDB Kafka (Spark应用)
Delta Delta
文件 文件
只追加Delta文件，IO冲击小
…
15
16 . 一份数据到处使用
MRS
入库 更新 查询 查询 写入 查询 AI
Flink Spark Presto Hive TF
演示
Metadata
|--segment1 CarbonData表
|--segment2
|--segment3
16
17 . 精确查询
演示
使用指南请阅：https://github.com/apache/carbondata/tree/master/docs
17
18 . 交互式分析和ETL
演示
构建时序聚合，语法示例：
CREATE MATERIALIZED VIEW carbondata_col3_timeseries AS
SELECT timeseries(col3, 'minute'),count(keyid)
FROM carbondata_table
GROUP BY timeseries(col3, 'minute');
18
19 .Parquet、ORC数据迁移
1TB数据迁移时间8秒钟
ALTER TABLE person ADD SEGMENT options('path'='s3a://obs-
haomarch/warehouse/sample.db/parquet_table', 'format'='parquet');
CREATE MATERIALIZED VIEW parquet_table_countid_gb_country
AS SELECT country,count(id) FROM parquet_table GROUP BY country;
19
20 . 目录
• 背景
• 快速体验CarbonData 2.0
• 性能
• 案例
20
21 . Benchmark查询性能对比
环境：3*16core
100GB TPCDS CarbonData性能优50%
1TB TPCDS CarbonData性能优25%
21
22 . Benchmark查询性能对比
1. CarbonData元数据缓存
避免访问HiveMetastore；
2. OBS Seek优化
3. 避免访问文件Footer
4. Minmax RuntimeFilter等
22
23 . Benchmark压缩率对比
CarbonData TPCDS
存储空间开销优化 21%
23
24 . 传统数据入湖
CarbonData
当前相比Hudi性能优20%
相比Hive优化10倍
24
25 . 目录
• 背景
• 快速体验CarbonData 2.0
• 性能
• 案例
25
26 .某电商现有数据平台
痛点1：同一份数据存储在三套系统里面，成本增加至少三倍。需要
掌握多套系统运维。
痛点2： ES不支持计算存储分离，难以支撑PB级全量历史数据
痛点3： Oracle/MySQL是单机系统，无法满足海量数据场景
痛点4： 数据同步场景，Spark/Hive无法做数据更新/删除/去重
ElasticSearch ① 通过ElasticSreach进行日志分析
② 通过传统DB进行交互式分析
数据注入 Oracle/MySQL
③ 数据写入Hive，周期性计算BI报表。
对于要更新的数据，定期全量重写
Spark/Hive 批处理计算 DB 可视化
26
28 . 相比ES性价比提升6倍
查询时间是ES的两倍，而成本下降到1/12
成本优化点1：存储从本地盘（接近100万/PB/月）改为对象存储(8万/PB/月)
成本优化点2：ES计算存储不分离，为了存储1PB数据，需要200台计算节点（160万/月）
CarbonData计算按需弹性，每天仅有8小时计算节点开机时间，每次开机50台（13万）
EB级数据，是业界唯一成本和性能都可接受的方案！
28
29 . 相比ES性价比提升6倍
查询时间是ES的两倍，而成本下降到1/12
成本优化点1：存储从本地盘（接近100万/PB/月）改为对象存储(8万/PB/月)
成本优化点2：ES计算存储不分离，为了存储1PB数据，需要200台计算节点（160万/月）
CarbonData计算按需弹性，每天仅有8小时计算节点开机时间，每次开机50台（13万）
EB级数据，是业界唯一成本和性能都可接受的方案！
29
热门城市
