CarbonData2.0-A New Era in Mutable Big Data

CarbonData 2.0
一个支持ACID和索引的全场景数据湖的存储底座
解决两个场景:
1、ACID:传统数据秒级入湖 2、索引:一份数据同时满足海量数据精确查询、聚合分析
10 PB数据精确查询 30秒内返回
聚合分析场景秒级响应(预聚合),比Parquet优化30%(无索引)

展开查看详情

1. CarbonData 2.0: A New Era in Mutable Big Data 2020-6

2. 目录 • 背景 • 快速体验CarbonData 2.0 • 性能 • 案例 2

3. 数据库的简要发展 3

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

6.6

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

14. CarbonData 2.0 14

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

27. 案例一:某电商平台 27

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

CarbonData是一种高性能大数据融合存储方案,以一份数据同时支持多种应用场景,通过多级索引、字典编码、预聚合、动态Partition等特性提升了IO扫描和计算性能,已在30+企业生产环境上部署应用,其中最大的单一集群数据规模达到十万亿。