数据侠客江湖流 ⎮ 来自“MPP 大侠”Vertica 的演讲
作者⎪大数据模型
编辑⎪Vertica 中国团队
(文章谨代表作者意见)
作者自述
Vertica 是数据分析领域的一个大杀器,为了描绘这朵鲜花,我写了它旁边的绿叶,以及周围的小草小树;并对天下数据分析引擎做一个归纳分类,分为三派,各有各擅长的特点,后面写了这朵鲜花辅助业界大的数据集成商和商业智能的故事。
希望诸君阅有所感受。本人能力有限,笔力不到之上请批评指正。
‣ 前方导读
对 Vertica 的回忆要回到 2015 年,那时候的我不只 18 岁。当时,根据项目需求,我调研实践了 Vertica,模糊记忆印象中当时 Vertica 的社区免费上限是 100 G,而不是现在的 1000 GB。
当时我向技术领导反映这个东西不错,可以应用于大数据系统项目。然而,项目进行之中突然有一天却被要求下架,原因是它是一个商业版的软件。
商务领导发话了:公司发你们 IT 部门高薪,就是为了解决 IT 问题,为什么额外花钱购买一个商业版软件?领导的思维更想你用开源的工具,然后是 lambda 框架也好、kappa 框架也好或者 unifield 架构去解决大数据项目相关的问题。
多年工作经历,倍觉感受做一个 IT 项目关键核心取决于三要素,那就是人、方法论和工具。的人才和的方法,使用三流的工具也能“三个臭皮匠顶个诸葛亮”。
Vertica,是一款即使你只是 p1 的水平也能轻松实现撑起企业级数据分析解决方案的好工具。
我凭借对 Vertica 的技术本质理解,结合行业相关产品的对比,对未来数据分析技术方向做了一个探索。希望我把数据分析关键核心技术的那一点说清楚了,希望我把 Vertica 关键的空间技术点也说清楚了,也希望各位展开 OLAP 的话题讨论。基于本人能力水平有限,技术描绘不清或者笔力不及之处请批评指正。
/ 开场白 /
一年一度的天下数据分析比武演讲大会正式开始,擂台上灯光闪烁,台下选手摩拳擦掌,活动筋胳,跃跃欲试,面向耀眼的舞台中心。
一个全身肌肉发达,胡子拉碴的大汉正在激情四射的演讲:“我是 Oracle RAC,我 90 年代就把业务分析遍及全球,我的客户包括制造业、金融业、通讯行业等的巨头,我有点贵,但是我的性能很强大。”说完就要脱衣服秀肌肉,引起台下观众的一阵骚动。
众所周知,Oracle 家族的确有实力,占据了大半壁的江山,一直是所有数据产品的公认的对手,近十年云计算和新技术兴起,很多数据产品在不同业务场景都能与 Oracle 分庭抗礼,越来越敢和它叫板。
司仪赶紧出来救场,清了清嗓子大喊:“有请下一位选手,Vertica!”大伙齐唰唰朝着一位小伙子看去。
“大家好,我是美国选手 Vertica,出生在美国麻萨诸塞州...我的父亲是 Michael Stonebraker!”
喧闹的人群立刻安静下来,Michael Stonebraker 是一位获得图灵奖的计算机科学家,地位超群。
他在关系数据库方面的理论造诣和数据库产品的应用贡献至今对现今市场上的产品有很深的影响,同时也是众多 IT 公司的创始人,包括 Ingres, Illustra, Cohera, StreamBase Systems 以及 VoltDB 等。
/ 天下数据分析流派 /
Vertica 的演讲
我出生在 2005年,至今 16 岁。我致力于解决当前数据分析平台日益增长的“大数据”和实时分析要求所带来的挑战,可以缩减传统解决方案 30% 的成本,实现 50-1000 倍的性能提高。
今天我的演讲主题是《天下数据分析流派调研》,给各位数据分析产品定义一个标签,穿插介绍我能干什么,给谁做了什么。我看,天下数据分析势力可以分为三个流派,传统的数据集中式流派, 分布式计算流派、 新兴技术的预处理流派,按照性质划分我属于分布式计算流派。
01 数据集中式流派
数据集中式流派的功夫以软硬件一体结合为主,代表作 Oracle exadata、SAP HANA,它们重视硬件建设,通过优化硬盘、内存、网络达到更高的数据处理性能,但是成本太高,普通的中小企业用户根本根本承受不起,数据集中式流派正在走下陂路,2019年 SAP HANA大裁员就是一个预兆。
▶︎ 说完,Vertica 指着 Oracle Rac:它也是数据集中式门派中的一员。Oracle Rac 红着脸坐立不安,观众响起热烈的掌声。Vertica 润了润喉咙,继续道:
02 预处理流派
我介绍下预处理流派,中国的 Kylin 和美国的 Druid 都属于这个派别。预处理门派的运功法门是把大数据变成小数据,首先确定数据的维度边界,再通过集群强大计算能力综合处理后放在另外一个高性能数据库上。Druid 和 Kylin 的区别在于:Druid 使用批理引擎处理历史全量数据,同时也通过实时引擎处理实时增量数据,而 Kylin 没有对实时增量数据做处理,如果业务涉及的维度有变化,它重新预计算一遍。两者很好,都能以廉价的方式,在不增长硬件的成本给予业务支持。
但是,预处理是一个蓄力的方式,需要了解业务维度,只能支持固定的分析业务场景,无法满足自定义分析的需求。业务瞬息万变,数据实时更新,预处理跟不上数据的变化。
03 数据集中式流派
下面我介绍我所属的分布式计算流派,分布式计算流派也有分支,分为非 MPP 家族和 MPP 族,我就是属于 MPP 家庭。
非 MPP 成员有 Hadoop、Mapredcue、Spark 等等。而我们 MPP 家庭有 Greeplum、Hawq、Impala、Presto、Clickhouse 等。我们与 Hadoop 既对立又合作,更多时候我们 MPP 是弥补他们不足的缺陷,我们分布式计算门派是解决单点性能不足的问题,通过把任务分解成多个子任务分配给分布式廉价多个机器,达到性能提升的目标。
与 Hadoop 不同的我们是并行计算,他们是两阶段计算,两阶段计算把全部业务逻辑分成两部分处理,上部分业务抽像成为 MAP 进行处理,下部分业务进行 REDUCE 处理。如果数据质量不好或者系统参数欠优甚至算子上的程序容易发生数据倾斜,造成计算时大量的数据集中指定的机器上。
▶︎ 人群中一阵骚动,那些使用 Hadoop 遭遇数据倾斜的人都交头接耳讨论,的确,MPP 引擎很少发生 Shuffle 情况。
那么,MPP 是怎么做到避免 Shuffle 的呢? 当然,分布式系统终肯定是会发生数据传输,我们是把全部业务逻辑都在每一个计算节点执行,执行结果提交服务节点进行归并。相对于两阶段而言,我们是全部业务放在 MAP 端进行处理,后提交到指定的的 REDUCE 端,这样就避免了大数据倾斜的数据热点计算。
Greenplum
下面介绍下我们的家族成员 Greenplum:它是基于 Postgre SQL 的基础开发的,组件包括 master、segment、interconnect。
简单概括精要如下:
master 是 Greenplum 的主节点,是集群的入口,主要负责接收客户端连接请求,对 SQL 语句生成查询计划,计划分解成任务均匀分给每个计算节点。
segment 是 Greenplum 的执行节点,每个 segment 可以视为一个独立的 Postgre SQL 数据库。
interconnect 是 Greenplum 的网络节点,负责汇聚合并数据,主要解决查询执行中 segment 实例之间或者 segment 和 master。
Greenplum 的亮点创新:一般而言,Greenplum 集群有 master 和 segment 就足够了,但是 Greenplum 额外开了 interconnect,通过 interconnect 减轻了 master 压力,并减低内部网络转输性能开销,而且它继承 Postgre SQL,所以有效获得 PostgreSQL 原始社会生态,让开发者能轻松使用上手。
也是因为继承 PostgreSQL,Greenplum 使用还是传统关系数据库的 B 树索引结构,这里汲及性能理论上限到磁盘传输速度和网络传输速度的技术问题,这也是为什么会研发 HAWQ。我们再简单聊一下磁盘传输速度和网络传输速度的技术理论问题 ,每一次分布式任务运行都会产生磁盘查找和网络传输数据的动作。而 PostgreSQL 是一个基于 B 树页存储的数据,基本页单元是 8 KB,如果任务汲及大量的数据查找,系统内部会有大量的硬盘数据查找动作。为了充分发挥硬盘的性能,我们会把存储基本单元调大一点,让它可以勉强跟上网络的速度性能,否则分布式任务都会发生更多的数据查找,影响全局性能。HDFS 不擅长小数据的处理,它的基本数据单元都是 64 M 以上,Hadoop1 的 block 设置默认是 64 MB,后来 Hadoop2 的 block 设置默认是 128 MB,目标是磁盘运转速度跟上网络传输速度。
Hawq
技术上来说,hawq 有一个很大的改变,它替换了 segment 轮子,换上了 Hadoop 牌,融进当前大数据主流的 Hadoop 生态。
hawq 还有一个有意思的改变,它支持 ACID 特性,为了做到这一点。它使用 orc 存储引擎,orc 并非是一个纯粹的列式压引擎,它先按行组划分,再按列组划分。对于数据分析引擎来说,这个性能不会好。
Impala
另外一个同样基于 Hadoop 的 MPP 家族成员Impala,提到核心处理技术,不得不说 Google dremel。
Google dremel 是谷歌的实时处理系统,深刻理解了 MPP 的精髓,它的查询树是金字塔状的多层次查询结构,由根节点、多个中间节点和多个叶子节点组成。叶子节点执行有部分结果直接向中间节点输出,中间节点向顶部根节点汇报,顶部根节点后统一输出,大化发挥数据贴近计算的特性。Impala 是基于 dremel 论文实现的 MPP 查询引擎,底层默认用的是 Parquet,这是真正的列式引擎,更适合数据分析的业务场景。
Presto
Presto 也是很出名的基于 Hadoop 的 MPP 执行引擎,它完全基于内存计算,在处理数据上有一个质的提升。相对于处理引擎的独特之处,Presto 不是充分利用了内存,是完全使用了数据,通过接入数据源把数据全量加载到内存上,再对内存里的数据进行分析计算。
缺点是多个节点的内存总量决定处理的数据大小,如果数据比内存大,Presto 容易挂掉。虽然,Presto 一直在内存硬盘交换寻找方法,但是多年来没有重大突破,截至2021年12月17日的新版本 0.266.1,还没有到标准的 1.0 版本。即使如此,Presto 仍然表现出强大的表现力,华为 Openleekeng 就是基于 Presto 基础研发的。
Clickhouse
Clickhouse 是一款非常出色的 MPP 处理引擎,特立独行,不走主流路线。它一开始就不打算融入 Hadoop,从索引到分区,从存储引制到算法调度,它是从零开始自我探索建设。它的杰作就是 MergeTree。
MergeTree 是一个强大单机存储引擎表,派生了 ReplaceingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree、GraphiteMergeTree 六个引擎表。
六个引擎表与 MergeTree 的关系,就像数据间中间件与数据库的关系,中间件赋予数据去重、数据排序、数据聚合等特性。MergeTree 的 MPP 特性本质就是多个 MergeTree 通过中间件分发路由组成的。
MergeTree 的性能很强,列式存储、数据压缩、向量化执行引擎是标配,存储机制采用时间范围分段的合并方式,能够达到很高的压缩比。
Clickhouse 擅长个性化的大宽表数据集市业务场景。但是关联多表业务场景性能不佳,甚至功能都达不到要求,经典的 tpc-h 基准测试和新型 tpc-ds 基准测试,Clickhouse 都没法通过。
关于我 - Vertica!
下面,终于轮到自我介绍啦。Vertica 就是我,是一个基于列式存储、实现MPP、去中心化、分布式、可扩展、高可用、多映射数据分布的数据库。针对各种数据分析业务场景问题,我的绝招是数据映射(Projection),牺性空间换取时间的方式实现数据处理性能提升。
举例说,一个表数据里面有 A、B、C、D、E 一共 5 个列字段,该表会针对不同的列名会冗余存储多个物理视图,每一个物理视图是一个数据映射,Vertica 称其为 Projection。
数据映射里面,针对业务规则对相关字段打索引和构建分区,如图表所示,表数据有三个数据映射,一个数据映射以 A、B 做主键索引,一个数据映射以 A、E 做主键索引,一个数据映射以 B、D 做主键索引。
Vertica 维护不同排序有重叠的映射,尽量使得每个查询只来自于一个映射,为提高查询性能,表查询需要的列至少在一个映射中。用户发起3个 SQL 请求,每个请求挟带不同的过滤条件,因为数据映射,Vertica 将自动选择用于该查询的,都能击中数据库索引,不会造成回表追溯查找或者全盘扫描。
举一个两表关联查询的例子,table1 表有 5 个字段,table2 有 3 个字段 ,两表关联过滤查询返回结果。一般的数据库根据过滤条件遍列所有的列,包括A 列、B 列、D 列、E 列、F 列,选择 B 列、D 列、F 列返回。而 Vertica 是访问指定的数据映射 Project2,Project2 只包括 B 列、D 列、F 列,耗时 I O 远比全盘扫描快。
而创建 Projection2 的步骤很简单,如下:
(B ENCODING RLE,D,F // Column List and Encodings) ASSELECTt1.B,t1.D,t2.FFROM table1 t1INNER JOIN table2 t2 on t1.C = t2.CORDER BY t1.C
MPP 流派的运功法门
MPP 流派的运功法门,要点就是如何让数据贴近计算,第二是如何实现数据分布。
数据贴近计算是 MPP 任务运行过程如何把存储数据装入进行计算,而数据分布则是数据的物理存储方式,是选择离散的哈希分布还是集中的范围分布的方式,是纯列式还是半列式。以 MPP“运气”为内功的根基,我们各有各的招式。
Impala 和 Vertica 的集群架构都是去中心化,每一个节点都是平等的。当外面发出请求,会有一个节点上升成为协调主节点,根据你的准备好的资源,如果该节点宕掉,根据内部算法选举出新的协调节点,此举相对中心架构的 master/slave 模式无疑充分利用了集群性能。
Impala 背靠 Hadoop 大树好乘凉,开发了属于自己的独立的存储引擎机制。而 Presto 采用全量数据加入内存,即使表数据没有实现索引分区,它依然运行很快,但是大于内存的数据量业务场景,它束手无策,实验室测试环境同样的硬件配置表明,当数据量大于内存总和的条件下,Spark 能比 Presto 处理更多的数据。Clickhouse 追求技术,基于硬盘的 DBMS 在空间、压缩、CPU 指令、合并都用上优的算法,但是它的权衡却忽略了用户关联多表的基本需求,笛卡尔乘积是数据库连接操作普通的存在。
Greeplum 和 Hawq 同属一家公司,它们的市场定位方向开始向 OLTP 发展,在 OLAP 领域方面,他们存在共同的痛点,随着数据量不断滚大,数据处理能力下降,需要水平扩展机器提高处理性能,预处理派流派的 Druid 的研发公司 Metamarket,就是因为 Greeplum 无法满足业务需求而研发了 Druid。
而我,Vertica,我的架构设计权衡多个因素,考虑了硬盘、内存、空间、压缩、读写优化、算法、数据库的基本关系代数操作、集合操作、连接操作等等,没有为某个特定的业务场景放弃任何东西。我们愿意牺牲的是空间,数据映射的本质是通过牺牲空间换取额外的物理视图和索引的技术方式。
助力 Denodo
数据虚拟化建设
Denodo 创立于1999年,2019年正式进入中国,2020年获评 Gartner 数据集成工具魔力象限和 Forrester Wave 企业数据结构“”。
凭借 20 余年的创新历程及行业领先的数据虚拟化解决方案,它致力于在金融、制造、汽车、医疗等领域,通过实时统一数据资产、转变国内企业的创新和业务运营方式,为广大范围的企业、云端、大数据和非结构化数据来源,提供灵活、高性能的数据集成、数据抽象化和实时数据服务。见公开声明,官方强烈建议用 Vertica 作为 Denodo 的缓存管理使用工具。
为什么 Denodo 需要 Vertica?Denodo 面对的是真正千万吨海量数据压力,它可以对接中台,对接数仓或者各种不同的数据产品。在数据整合充分流动的过程中,数据源 Hadoop 不断在增大,Oracle 随着业务增长也会上升,面对数据源不断水涨船高,Denodo 需要一个稳定可靠的数据管理系统,对数据进行高效存储管理。
特别是多源异构的数据整合时,Denodo 需要开辟一个暂存区和多模状态数据存储区区域 ,对数据进行有效的分类分级管理存放。Denodo 的缓存数据管理系统需要达到以下指标要求:
数据暂存区支持的数据存储空间能够支持数据源。
支持分布式部署使用
支持分布式扩展
支持高可用,意外集群意外宕机能够继续使用。
随着数据增长,能够不增加节点的方式提高算力
支持自动自助查询和即席查询。
支持数据分析有关的所有函数和SQL操作
数据管理系统本身能与自治数据源有统一共识的接口。
可靠性、稳定性、轻捷的使用性
这一切 Vertica都做到了,所以高规格的Denodo 选择 Vertica 作为推荐的缓存数据管理系统。
助力 SmartBI
SmartBI 是民族 BI 软件领先品牌,有效支撑了天问一号火星探测任务、神舟十二号载人飞行任务等高标准航天项目,为中国构建自主创新格局强根筑基。2017,SmartBI Insight 与 Vertica 正式携手,达成战略合作,打造新一代 MPP 大数据自助分析方案,为客户提供“基于新一代 MPP 的高性能大数据自助分析解决方案”。
对用户来说,实现大数据分析需要同时具备功能易用的前端 BI 工具和性能强劲的数据平台,Smartbi Insight 专注于前端功能十几年,形成了以电子表格、自助探索、分析报告为特色的数据展现分析功能。而 Vertica 作为新一代 MPP 数据库软件,从设计原理上有天然的性能优势。因此,Smartbi Insight + Vertica的强强联合,将为客户带来必不可少的应用价值,也为广大解决方案提供商提供了完备的产品组合。
从数据到信息,从信息到知识,技术和相关工具必须提供基本的数据的存储能力和数据的处理能力,目前所有的数据广泛产品都包含这两个能力,只是强弱高低之分已。单机分析能力弱,分布式能力强,MPP 能力更强,计算能力是商业智能考察的一个重要指标,数据挖掘发现数据的规律也是商业智能重点考察的指标。
过去,BI 产品为了预测性分析和规范性分析,都会集成开源或者成熟的学习框架,例如 tensorflow 或者 Deeplearning4j,显然机器学习框架与 BI 产品融合需要二次开发,即使融合成功,如果数据结果很多或者数据持续不断的输出,存在计算不一致性或者读取数据错误等挑战,发生错误后,需要重新对数据源读取。
Vertica 数据库内的机器学习算法,让预测性分析和规范性分析有了新的选择。数据库内算法可以在每个计算节点独立的执行,因此可以在计算节点级别实现新形式的分析处理,提供数据、统计的功能,确保移动是在数据库内完成的,不是库外接口数据传输在应用端完成的。通过移动计算接近数据,可显著提高减少复杂算法(如K-means、逻辑或线性回归)的计算时间。下面是库外计算和库内计算的对比图。
附 Vertica 聚类算法实现的例子:
Clustering Data Using k-meansThis k-means example uses two small data sets named agar_dish_1 and agar_dish_2. Using the numeric data in the agar_dish_1 data set,you can cluster the data into k clusters. Then, using the created k-means model,you can run APPLY_KMEANS on agar_dish_2 and assign them to the clusters created in your original model.Before you begin the example, make sure that you have loaded the Machine Learning sample data.1.Clustering Training Data into k ClustersUsing the KMEANS function, run k-means on the agar_dish_1 table.=> SELECT KMEANS('agar_dish_kmeans', 'agar_dish_1', '*', 5USING PARAMETERS exclude_columns ='id', max_iterations=20, output_view=agar_1_view,key_columns='id');KMEANS---------------------------Finished in 7 iterations(1 row)The example creates a model named agar_dish_kmeans and a view containing the results of the model named agar_1_view. You might get different results when you run the clustering algorithm. This is because KMEANS randomly picks initial centers by default.2.View the output of agar_1_view.=> SELECT * FROM agar_1_view;id | cluster_id-----+------------2 | 45 | 47 | 49 | 413 | 4...(375 rows)3.Because you specified the number of clusters as 5, verify that the function created five clusters. Count the number of data points within each cluster.=> SELECT cluster_id, COUNT(cluster_id) as Total_countFROM agar_1_viewGROUP BY cluster_id;cluster_id | Total_count------------+-------------| 762 | 801 | 743 | 734 | 72(5 rows)From the output, you can see that five clusters were created: , 1, 2, 3, and 4.You have now successfully clustered the data from agar_dish_1.csv into five distinct clusters.Summarizing Your ModelYou can also view a summary of the model you created using the SUMMARIZE_MODEL function. This summary tells you how many cluster centers your model contains, along with other metrics.=> SELECT SUMMARIZE_MODEL('agar_dish_kmeans');-[ RECORD 1 ]---+-------------------------------------------------------------------------------------------------SUMMARIZE_MODEL | k-Means Model Summary:Number of clusters: 5Input columns: x, yCluster centers:: {x: -7.4811859, y: -7.5257672}1: {x: -3.5061558, y: -3.5570295}2: {x: -5.5205715, y: -5.4919726}3: {x: -1.5623823, y: -1.5056116}4: {x: 0.4970753, y: 0.5111612}Evaluation metrics:Total Sum of Squares: 6008.4619Within-Cluster Sum of Squares:Cluster : 12.389038Cluster 1: 11.210146Cluster 2: 12.994356Cluster 3: 12.639238Cluster 4: 12.083548Total Within-Cluster Sum of Squares: 61.316326Between-Cluster Sum of Squares: 5947.1456Between-Cluster SS / Total SS: 98.98%Number of iterations performed: 6Converged: TrueCall:kmeans(model_name=agar_dish_kmeans, input_table=agar_dish_training, input_columns=*, num_clusters=5,exclude_columns=id, max_iterations=20, epsilon=0.0001, init_method=random, initial_centers_table=,distance_method=euclidean, outputView=agar_training_view, key_columns=id)Clustering Data Using a k-means ModelUsing agar_dish_kmeans, the k-means model you just created, you can classify the agar_dish_2 data set.Create a table named kmeans_results, using the agar_dish_2 table as your input table and the agar_dish_kmeans model for your initial cluster centers.Add only the relevant feature columns to the arguments in the APPLY_KMEANS function.=> CREATE TABLE kmeans_results AS(SELECT id,APPLY_KMEANS(x, yUSING PARAMETERSmodel_name='agar_dish_kmeans') AS cluster_idFROM agar_dish_2);The kmeans_results table shows that the agar_dish_kmeans model correctly clustered the agar_dish_2 data.
SmartBI 支持各种各样的数据产品、数据处理引擎等,万花丛中一点红,唯独 Vertica 与 SmartBI 结成了战略合作伙伴关系。它不但看中了 Vertica 强大的计算能力,更重要的是 Vertica 对商业智能业务的理解。
未来数据分析
技术展望
在物理学里,抖动是一种物理现象,物体彼此之间互有联系需要进行交互,如果物体太多产生的传输和通讯会破坏原来的系统的秩序稳定,导致熵混乱。
用中国人的老话说,林子大了什么鸟都有。分布式系统技术存在的数据传输、节点通信、心跳感应、计算监控、计算调度和计算分布时刻都在发生,随着集群节点不断扩大,量变导致质变,集群的复杂度不断提升,发生在 DBA 上面的事,抖动引起的故障级别叫做闪断。闪断就是有时候故障现象会出现,有时候故障现象不出现,有时候日志打印错误信息,有时候什么信息也没有,你根本无法一下子定位到是系统问题、硬件问题、软件问题、网络问题。
从这个角度来看,集中式流派有独特之处。虽然昂贵,但是它可靠、稳定、高效,重要是健壮,如果有世界末日发生洪水灾害,人们登上诺亚方舟逃难,因为方舟空间有限,船上必然安放的是一个集中式流派的系统。如果地球还有几千年的技术发展和文明进步,未来数据分析技术必然是分布式流派的世界,但是分布式集群越做越大,必然要面对抖动现象。例如 Greeplum 集群上升到 1000 个节点,再往上扩展会有更多的问题和挑战,例如你需要要考虑网段分配和长网络传输耗时,其中一个节点的网卡异常或者系统不稳定,都会影响整个集群。在抖动问题的方案上,预处理和空间处理是较成熟理想的选择,面对不断增长的大数据隐式派生新空间,通过新空间的访问减少 IO,而不是全局空间接触。
空间技术不但可以避免抖动,同时也是未来数据分析技术的主流方向。现在的数据中台框架,从原始数据源层到数据域层、轻汇到重汇、个性化大表、数据集市其实就是空间技术的理念,通过对数据提前有效整合,做到应用需要时拿来就用,数据分析的比较其实就是如何对数据源实现高效的数据集成。不计较硬件成本的前提下, Presto 应该是快的 MPP 利器,但是它只能处理内存范围内的数据为人诟病。Presto 另辟蹊径,借助 Alluxio 在数据层面的优势,通过集成提供给客户更优质的体验。Alluxio 通过管理内存和本地存储,实现不同存储系统之间的高效数据管理,达到加速数据访问的目标。DorisDB 的核心的秘密武器就是物化视图,就是优化后的数据放进新空间,以至大数据增速下依然能保障原来的运行性能。
结尾词
我相信,以后的数据分析技术发展,MPP 是宏观必备的基本条件,空间技术是细节的关键核心技术,永不过时。近出现的中国选手DorisDB 也是 MPP的。
我是 Vertica,专业 OLAP 16 年,会继续深耕数据分析领域,围绕数据仓库、信息管理、数据管理 、主数据管理、商业智能、数据中台、仓湖建设、数字化转型领域刻苦“修行”,大放异彩,希望我的经验和能力能够帮到大家,谢谢大家!
来源 https://mp.weixin.qq.com/s/vOeS3nBiM9UBmNo4eoOE9A
相关文章