数仓进阶篇@记一次BigData-OLAP分析引擎演进思考过程 | 社区征文

社区征文

开篇

想必大家都有一个疑问?何为OLTPOLAP?它又能够给我们带来什么?

image.png

引入 | 图解那些OLAP分析引擎中的DBMS

DB-Engines Ranking.jpg

资讯

元宇宙(Metaverse),数据湖(Data Lake),信创自主可控,互联互通,数字化建设......

这些概念越来越火热,前些时候大部分工作集中在信创自主可控,现阶段已告一段落。信息化,数字化建设也是不可或缺的一环,遇到挑战,勇于迎对,不断的攻克技术难关是技术人的一种追求!数仓多维数据模型详细设计,欢迎一起加入交流探讨,希望能给读者在实际业务场景-OLAP分析演进过程中有些不一样的IDea。

场景

目前数据存储的业务类型-OLTPOLAP......

1、 其中一种是企业知识库,权限系统,数据由本系统产生,数据量不是很大,但是数据增删改较多;

2、 另一种是统计分析类型,数据不由本系统产生,来自医院各生产系统,数据集规模极其庞大,并且数据查询较多。

思考

数据每天在源源不断产生,音视频,影像图片,文本......

1、 海量数据存储出现瓶颈,单台机器无法负载大规模数据集;

2、 单台机器IO读写请求,成为海量数据存储时高并发-大规模请求的瓶颈;

3、 随着时间的推移,数据规模越来越庞大-加并发MPP架构,数据存储横向水平扩展,存储服务增加/删除,但若所有节点参与运算,水平扩展到一定程度硬件必然很难hold,很容易出现短板,并且容量也有明显天花板,可结合批处理与MPP架构;

4、 大数据给传统的关系型数据库-DBMS带来巨大挑战,在海量数据场景下,数据实时分析-时延低、并发数高、支持SQL或类SQL,变得尤为重要!

现状

Oracle,ElasticSearch,MySQL集群架构

目前,Oracle中多个业务库,数据集极其庞大,MySQL中多个业务库,单表数据量超过千万级别......

image.png

随着数据一直在不断增长,往水平方方向扩展节点,虽然能在一定程度上缓解大数据带来的压力,但长久来看,数据库查询性能无疑受到了巨大的冲击! image.png

传统关系型数据库+NOSQL型数据库,暂时存储的都是结构化类型数据(非结构化数据会经过一系列技术转化为结构化数据),当然,未来肯定还会有大量的非结构化数据存储。

image.png

基于es倒排索引+宽表模型,数据检索性能大幅度提升,上一组案例效果。

image.png

随着查询越来越复杂,数据规模持续增长,我们的数据分析目前也越来越复杂,数据规模也需考虑集中存储。

猜想

是否能够在数据库中,通过一系列高级分析算法,对数据进行分析与处理?

预期

成熟的海量数据解决方案

1、 生态圈丰富,成功案例较多,开源;

2、 统一数据中心,支持未来数据增长,动态扩展;

3、 支持目前业务体系,标准化接口,助力科学计算,支持Python,ETL,R,BI......

回到DB-Engines Ranking,Hive、HBase、Vertica、Impala、Greenplum、 ClickHouse.

其中,

Hive: 使用一种类似SQL查询语言,作用在分布式存储系统的文件之上,通常用于进行离线数据处理操作-MapReduce,支持多种不同的执行引擎-Hive on MapReduce、Hive on Tez、Hive on Spark.

image.png

HBase: 分布式、面向列开源数据库,不同于一般的关系型数据库,HBase基于列的而不是基于行的模式。

image.png

Java接入:

image.png

Impala: 开源,基于HDFS/HBase的MPP SQL引擎,拥有和Hadoop一样的可扩展性、它提供了类SQL-类Hsql语法,在多用户场景下亦能拥有较高的响应速度和吞吐量,兼顾数据仓库,具有实时,批处理,多并发等优点。

image.png

Java接入:

image.png

在阐述Vertica(简称V)、 ClickHouse(简称C)、Greenplum(简称G)这三款MPP之前,我们不妨以北京地铁线路图为例:

image.png

北京地铁一天的吞吐量多大,周末的吞吐量又是多少?想象-地铁就好比MPP-海量数据的并行处理。

image.png

拍摄于中关村-鼎好大厦(北京大学正对面)2019-01

达到预期可选择的方案

image.png

对现状的构思

海量的数据并行处理,标准的SQL,成熟的案例V-C-G......

image.png

BigData-OLAP分析引擎演进

image.png

image.png

基于VCG构建离线/实时数仓生态-OLAP体系,可综合场景择优选取

image.png

其中,

image.png

引入大宽表分析性能优异

Vertica: 无Master的MPP架构

基于列存储的MPP架构的数据库管理系统(DBMS),可以支持存放多至PB(Petabyte)级别的结构化数据。

1、 无共享的MPP体系架构-集群中的所有节点对等,没有主节点或其他共享资源,通过增加节点,即可线性地扩展集群的计算能力和数据处理容量;

2、 列式存储和计算-通过列式计算和强大的主动数据压缩,大幅降低成本高昂的磁盘,执行查询的速度大幅度提升;

3、 实时分析-内存与磁盘混合存储架构,原生支持kafka消息系统的连接,数据实时装载,秒级分析;

4、 数据库内分析库-开箱即用的数据库内时序插值和关联、事件窗口和会话处理等众多分析功能包;

5、 标准SQL支持-支持关系数据库事务处理和ACID规范,提供ODBC、JDBC等接口规范驱动,兼容传统关系型数据库系统的开发、使用以及管理习惯,与现有的ETL和报表工具相集成;

6、 可扩展的数据库内分析框架-采用面向用户定义的过程式分析的强大开发框架,数据库内部处理->开放式访问。

ClickHouse: 面向列的数据库管理系统 (DBMS)

不同列的值分别存储,同一列的数据存储在一起。而面向行的DBMS-

MySQL、Postgres、SQL Server......

简言之,与一行相关的所有值在物理上彼此相邻存储。当然,不同的数据存储顺序更适合不同的场景。系统负载越高,定制系统设置以匹配使用场景的要求就越重要,并且这种定制变得越细粒度。

近期,ClickHouse的Star数量也不断持续增长,热度也一直不减-后起新秀。

image.png

Greenplum: 有Master的MPP架构

image.png

Greenplum本身自带HA,虽然不能代替目前OLTP 的数据存储,但是它对OLAP却是方向,OLAP可以先做成统─数据存储,使得业务系统可以稳步的切入使用Greenplum,ETL也可使用Greenplum,实现统一的数据存储方案。

1、 大规模并行处理架构-提供了横向扩展,无共享体系结构的数据和查询并行化设计;

2、 PB规模数据加载-高性能加载使用MPP技术,加载速度随着增加节点而不断增加;

3、 创新的查询优化器-针对大数据工作负载而设计的基于成本的查询优化器。可将交互式和批处理模式应用到PB级别的大型数据集上,但不会降低查询性能和吞址量;

4、 多态数据存储和执行-表或者分区存储,执行和压缩设置可以按照数据访问方式进行配置。用户为每个表或者分区选择面向行或者列的存储和处理;

5、 高级的机器学习-可扩展的数据库内分析库,通过用户定义的函数扩展了SQL功能;

6、 外部数据访问-通过外部表语法访问和查询所有数据,支持传统的内部部署和下一代公共数据湖。

接下来,详看其执行计划分析。

image.png

延伸思考

OLTP,OLAP,HTAP可支撑对应业务体系规模?TB || PB?OLAP,HTAP在数据分析领域,相比OLTP能够给我们带来?  

    在高并发海量数据场景下,数据实时分析、批处理、预计算都有着极其重要的意义。


343
2
1
0
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论