精华内容
参与话题
问答
  • 作者介绍温正湖,网易杭研高级数据库技术专家,数字产业事业部大数据产品中心OLTP和OLAP内核团队负责人。负责网易大数据OLAP系统和OLTP关系型数据库内核相关的开发和运维工作。毕业1...

    作者介绍

    温正湖,网易杭研高级数据库技术专家,数字产业事业部大数据产品中心OLTP和OLAP内核团队负责人。负责网易大数据OLAP系统和OLTP关系型数据库内核相关的开发和运维工作。毕业10+年一直从事数据和存储领域相关工作,有较丰富的设计、开发、线上问题定位和优化经验。

    前一篇文章从OLTP出发,通过对比引出OLAP,进一步介绍了数仓的基本概念,包括多维数据模型、数据立方体及其典型操作等。本篇再进一步,将介绍OLAP的类型及其代表产品,并分析主流开源OLAP产品的核心技术点。

    OLAP数仓入门问答-基础篇:https://zhuanlan.zhihu.com/p/144926830

    一、有哪些类型的OLAP数仓?

    1、按数据量划分

    对一件事物或一个东西基于不同角度,可以进行多种分类方式。对数仓产品也一样。比如我们可以基于数据量来选择不同类型的数量,如下图所示:

    本系列文章主要关注的是数据量处于百万到百亿级别的偏实时的分析型数仓,Cloudera的Impala、Facebook的Presto和Pivotal的GreenPlum均属于这类系统;如果超过百亿级别数据量,那么一般选择离线数仓,如使用Hive或Spark等(SparkSQL3.0看起来性能提升很明显);对于数据量很小的情况,虽然是分析类应用,也可以直接选择普通的关系型数据库,比如MySQL等,“杀鸡焉用牛刀”。

    这些系统均属于网易杭研大数据和数据库团队的研究范畴,对各系统均有深入研究和优化,对外提供网易猛犸、网易有数和网易云RDS等服务。

    2、按建模类型划分

    下面我们主要关注数据量中等的分析型数仓,聚焦OLAP系统。根据维基百科对OLAP的介绍,一般来说OLAP根据建模方式可分为MOLAP、ROLAP和HOLAP 3种类型,下面分别进行介绍并分析优缺点。

    1)MOLAP

    这应该算是最传统的数仓了,1993年Edgar F. Codd提出OLAP概念时,指的就是MOLAP数仓,M即表示多维(Multidimensional)。大多数MOLAP产品均对原始数据进行预计算得到用户可能需要的所有结果,将其存储到优化过的多维数组存储中,可以认为这就是上一篇所提到的“数据立方体”。

    由于所有可能结果均已计算出来并持久化存储,查询时无需进行复杂计算,且以数组形式可以进行高效的免索引数据访问,因此用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的,可以进行压缩/编码来减少存储占用空间。

    但高性能并不是没有代价的。首先,MOLAP需要进行预计算,这会花去很多时间。如果每次写入增量数据后均要进行全量预计算,显然是低效率的,因此支持仅对增量数据进行迭代计算非常重要。其次,如果业务发生需求变更,需要进行预定模型之外新的查询操作,现有的MOLAP实例就无能为力了,只能重新进行建模和预计算。

    因此,MOLAP适合业务需求比较固定,数据量较大的场景。在开源软件中,由eBay开发并贡献给Apache基金会的Kylin即属于这类OLAP引擎,支持在百亿规模的数据集上进行亚秒级查询。

    其架构图较直观得反映了基于cube的预计算模型(build),如下所示:

    2)ROLAP

    与MOLAP相反,ROLAP无需预计算,直接在构成多维数据模型的事实表和维度表上进行计算。R即表示关系型(Relational)。显然,这种方式相比MOLAP更具可扩展性,增量数据导入后,无需进行重新计算,用户有新的查询需求时只需写好正确的SQL语句既能完成获取所需的结果。

    但ROLAP的不足也很明显,尤其是在数据体量巨大的场景下,用户提交SQL后,获取查询结果所需的时间无法准确预知,可能秒回,也可能需要花费数十分钟甚至数小时。本质上,ROLAP是把MOLAP预计算所需的时间分摊到了用户的每次查询上,肯定会影响用户的查询体验。

    当然ROLAP的性能是否能够接受,取决于用户查询的SQL类型,数据规模以及用户对性能的预期。对于相对简单的SQL,比如TPCH中的Query响应时间较快。但如果是复杂SQL,比如TPC-DS中的数据分析和挖掘类的Query,可能需要数分钟。

    相比MOLAP,ROLAP的使用门槛更低,在完成星型或雪花型模型的构建,创建对应schema的事实表和维度表并导入数据后,用户只需会写出符合需求的SQL,就可以得到想要的结果。相比创建“数据立方体”,显然更加方便。

    有分析表明,虽然ROLAP的性能比如MOLAP,但由于其灵活性、扩展性,ROLAP的使用者是MOLAP的数倍

    The survey shows that ROLAP tools have 7 times more users than MOLAP tools within each company

    3)HOLAP

    MOLAP和ROLAP各有优缺点,而且是互斥的。如果能够将两者的优点进行互补,那么是个更好的选择。而HOLAP的出现就是这个目的,H表示混合型(Hybrid),这个想法很朴素直接。对于查询频繁而稳定但又耗时的那些SQL,通过预计算来提速;对于较快的查询、发生次数较少或新的查询需求,像ROLAP一样直接通过SQL操作事实表和维度表。

    目前似乎没有开源的OLAP系统属于这个类型,一些大数据服务公司或互联网厂商,比如HULU有类似的产品。相信未来HOLAP可能会得到进一步发展,并获得更大规模的使用。

    4)HTAP

    从另一个维度看,HTAP也算是一种OLAP类型的系统,是ROLAP的一个扩展,具备了OLAP的能力。最新发展显示,有云厂商在HTAP的基础上做了某种妥协,将T(transaction)弱化为S(Serving),朝HSAP方向演进。关于HTAP/HSAP,本文不做进一步展开,可自主查询其他资料。

    主流的OLAP数仓系统很多,包含上面所述的各种类型,下图是Gartner 2019 年发布的数据分析市场排名(数据来源):

    可以发现,传统的商业厂商和闭源的云服务厂商占据了绝大部分市场。大部分系统笔者只听过而没有研究过。作为屁股在互联网公司的数据库/数据仓库开发者,本文后续主要聚焦在基于Hadoop生态发展的开源OLAP系统(SQL on Hadoop)。

    二、有哪些常用的开源ROLAP产品?

    目前生产环境使用较多的开源ROLAP主要可以分为2大类,一个是宽表模型,另一个是多表组合模型(就是前述的星型或雪花型)。

    1、宽表模型

    宽表模型能够提供比多表组合模型更好的查询性能,不足的是支持的SQL操作类型比较有限,比如对Join等复杂操作支持较弱或不支持。

    目前该类OLAP系统包括Druid和ClickHouse等,两者各有优势,Druid支持更大的数据规模,具备一定的预聚合能力,通过倒排索引和位图索引进一步优化查询性能,在广告分析场景、监控报警等时序类应用均有广泛使用;ClickHouse部署架构简单,易用,保存明细数据,依托其向量化查询、减枝等优化能力,具备强劲的查询性能。两者均具备较高的数据实时性,在互联网企业均有广泛使用。

    除了上面介绍的Druid和ClickHouse外,ElasticSearch和Solar也可以归为宽表模型。但其系统设计架构有较大不同,这两个一般称为搜索引擎,通过倒排索引,应用Scatter-Gather计算模型提高查询性能。对于搜索类的查询效果较好,但当数据量较大或进行扫描聚合类查询时,查询性能会有较大影响。

    2、多表组合模型

    采用星型或雪花型建模是最通用的一种ROLAP系统,常见的包括GreenPlum、Presto和Impala等,他们均基于MPP架构,采用该模型和架构的系统具有支持的数据量大、扩展性较好、灵活易用和支持的SQL类型多样等优点。

    相比其他类型ROLAP和MOLAP,该类系统性能不具有优势,实时性较一般。通用系统往往比专用系统更难实现和进行优化,这是因为通用系统需要考虑的场景更多,支持的查询类型更丰富。而专用系统只需要针对所服务的某个特定场景进行优化即可,相对复杂度会有所降低。

    对于ROLAP系统,尤其是星型或雪花型的系统,如果能够尽可能得缩短响应时间非常重要,这将是该系统的核心竞争力。这块内容,我们放在下一节着重进行介绍。

    三、有哪些黑科技用于优化ROLAP系统性能?

    目前生产环境使用的ROLAP系统,均实现了大部分的该领域性能优化技术,包括采用MPP架构、支持基于代价的查询优化(CBO)、向量化执行引擎、动态代码生成机制、存储空间和访问效率优化、其他cpu和内存相关的计算层优化等。下面逐一进行介绍。

    1、什么是MPP架构?

    首先来聊聊系统架构,这是设计OLAP系统的第一次分野,目前生产环境中系统采用的架构包括基于传统的MapReduce架构加上SQL层组装的系统;主流的基于MPP的系统;其他非MPP系统等。

    2、MR架构及其局限

    在Hadoop生态下,最早在Hive上提供了基于MapReduce框架的SQL查询服务。

    但基于MR框架局限性明显,比如:

    • 每个MapReduce 操作都是相互独立的,Hadoop不知道接下来会有哪些MapReduce。

    • 每一步的输出结果,都会持久化到硬盘或者HDFS 上。

    第一个问题导致无法进行跨MR操作间的优化,第二个问题导致MR间数据交互需要大量的IO操作。两个问题均对执行效率产生很大影响,性能较差。

    3、MPP优缺点分析

    MPP是massively parallel processing的简称,即大规模并行计算框架。相比MR等架构,MPP查询速度快,通常在秒计甚至毫秒级以内就可以返回查询结果,这也是为何很多强调低延迟的系统,比如OLAP系统大多采用MPP架构的原因。

    下面以Impala为例,简单介绍下MPP系统架构。

    上图即为Impala架构图,展示了Impala各个组件及一个查询的执行流程。

    1)用户通过Impala提供的impala-shell或beeline等客户端/UI工具向Impala节点下发查询SQL;接收该SQL的Impala节点即为Coordinator节点,该节点负责进行SQL解析;

    2)首先产生基于单节点的执行计划;再对执行计划进行分布式处理,比如将Join、聚合(aggregation)等并行化到各Impala Executor节点上。执行计划被切分为多个Plan Fragment(PF),每个PF又由一到多个Operator组成;

    3)接着,下发经过优化后的执行计划的PF到对应的Executor节点,多个执行节点并行处理任务,缩短整个任务所需时间;

    4)执行节点扫描HDFS/Hbase等存储上的数据,并逐层进行处理,比如进行跨节点的数据shuffe,Join等操作;

    5)执行节点完成任务并将输出结果统一发送到Coordinator节点;

    Coordinator节点汇总各个执行节点数据,做最后处理,最终返回给用户想要的结果集。

    MPP架构之所以性能比MR好,原因包括:

    1)PF之间的数据交互(即中间处理结果)驻留在内存Buffer中不落盘(假设内存够大);

    2)Operator和PF间基于流水线处理,不需要等上一个Operator/PF都完成后才进行下一个处理。上下游之间的关系和数据交互式预先明确的。

    这样可以充分利用CPU资源,减少IO资源消耗。但事情往往是两面的,MPP并不完美,主要问题包括:

    3)中间结果不落盘,在正常情况下是利好,但在异常情况下就是利空,这意味着出现节点宕机等场景下,需要重新计算产生中间结果,拖慢任务完成时间;

    4)扩展性没有MR等架构好,或者说随着MPP系统节点增多到一定规模,性能无法线性提升。有个原因是“木桶效应”,系统性能瓶颈取决于性能最差的那个节点。另一个原因是规模越大,出现节点宕机、坏盘等异常情况就会越频繁,故障率提高会导致SQL重试概率提升;

    基于上述分析,MPP比较适合执行时间不会太久的业务场景,比如数小时。因为时间越久,故障概率越大。

    4、其他非MPP架构

    基于MR系统局限性考虑,除了采用MPP架构外,Hive和Spark均使用不同方式进行了优化,包括Hive的Tez,SparkSQL基于DAG(Directed Acyclic Graph)等。

    不同架构有不同优缺点,重要的是找到其适用的场景,并进行靠谱地优化,充分发挥其优势。

    四、什么是基于代价的查询优化?

    有了适合的系统架构并不一定能够带来正向收益,“好马配好鞍”,执行计划的好坏对最终系统的性能也有着决定性作用。执行计划及其优化,就笔者的理解来说,其来源于关系型数据库领域。这又是一门大学问,这里仅简单介绍。

    分布式架构使得执行计划能够进行跨节点的并行优化,通过任务粒度拆分、串行变并行等方式大大缩短执行时间。除此之外,还有2个更重要的优化方式,就是传统的基于规则优化以及更高级的基于代价优化。

    1、基于规则优化

    通俗来说,基于规则的优化(rule based optimization,RBO)指的是不需要额外的信息,通过用户下发的SQL语句进行的优化,主要通过改下SQL,比如SQL子句的前后执行顺序等。比较常见的优化包括谓语下推、字段过滤下推、常量折叠、索引选择、Join优化等等。

    谓语下推,即PredicatePushDown,最常见的就是where条件等,举MySQL为例,MySQL Server层在获取InnoDB表数据时,将Where条件下推到InnoDB存储引擎,InnoDB过滤where条件,仅返回符合条件的数据。在有数据分区场景下,谓语下推更有效;

    字段过滤下推,即ProjectionPushDown,比如某个SQL仅需返回表记录中某个列的值,那么在列存模式下,只需读取对应列的数据,在行存模式下,可以选择某个索引进行索引覆盖查询,这也是索引选择优化的一种场景;

    常量或函数折叠也是一种常见的优化方式,将SQL语句中的某些常量计算(加减乘除、取整等)在执行计划优化阶段就做掉;

    Join优化有很多方法,这里说的基于规则优化,主要指的是Join的实现方式,比如最傻瓜式的Join实现就是老老实实得读取参与Join的2张表的每条记录进行Join条件比对。而最普遍的优化方式就是Hash Join,显然效率很高。不要认为这是想当然应该有的功能,其实MySQL直到8.0版本才具备。另外Join的顺序及合并,有部分也可以直接通过SQL来进行判断和选择。

    2、基于代价优化

    基于规则的优化器简单,易于实现,通过内置的一组规则来决定如何执行查询计划。与之相对的是基于代价优化(cost based optimization,CBO)。

    CBO的实现依赖于详细可靠的统计信息,比如每个列的最大值、最小值、平均值、区分度、记录数、列总和,表大小分区信息,以及列的直方图等元数据信息。

    CBO的一大用途是在Join场景,决定Join的执行方式和Join的顺序。这里所说的Join我们主要是讨论Hash Join。

    3、Join执行方式

    根据参与Join的驱动表(Build Table)和被驱动表(Probe Table)的大小,Hash Join一般可分为broadcast和partition两种。

    广播方式适用于大表与小表进行Join,在并行Join时,将小表广播到大表分区数据所在的各个执行节点,分别与大表分区数据进行Join,最后返回Join结果并汇总。

    而分区方式是最为一般的模式,适用于大表间Join或表大小未知场景。分别将两表进行分区,每个分区分别进行Join。

    显然,判断大小表的关键就看是否能够通过某种方式获取表的记录数,如果存储层保存了记录数,那么可从元数据中直接获取。

    如果Join的两表都是大表,但至少有个表是带Where过滤条件的,那么在决定走分区方式前还可进一步看满足条件的记录数,这时候,物理上进行分区的表存储方式可发挥作用,可以看每个分区的最大值和最小值及其记录数来估算过滤后的总记录数。当然,还有种更精确的方式是列直方图,能够直接而直观得获取总记录数。

    如果上述的统计信息都没有,要使用CBO还有另一种方式就是进行记录的动态采样来决定走那种Join方式。

    4、Join顺序

    如果一个查询的SQL中存在多层Join操作,如何决定Join的顺序对性能有很大影响。这块也已是被数据库大佬们充分研究过的技术。

    一个好的CBO应该能够根据SQL 语句的特点,来自动选择使用Left-deep tree(LDT,左图)还是 bushy tree(BYT,右图)执行join。

    两种Join顺序没有好坏之分,关键看进行Join的表数据即Join的字段特点。

    对于LDT,如果每次Join均能够过滤掉大量数据,那么从资源消耗来看,显然是更优的。对于给每个列都构建了索引的某些系统,使用LDT相比BYT更好。

    一般来说,选择BYT是效率更高的模式,通过串行多层Join改为并行的更少层次Join,可以发挥MPP架构的优势,尽快得到结果,在多表模式ROLAP场景常采用。

    五、为什么需要向量化执行引擎?其与动态代码生成有何关系?

    查询执行引擎 (query execution engine) 是数据库中的一个核心组件,用于将查询计划转换为物理计划,并对其求值返回结果。查询执行引擎对系统性能影响很大,在一项针对Impala和Hive的对比时发现,Hive在某些简单查询上(TPC-H Query 1)也比Impala慢主要是因为Hive运行时完全处于CPU bound的状态中,磁盘IO只有20%,而Impala的IO至少在85%。

    什么原因导致这么大的差别呢?首先得简单说下火山模型的执行引擎。

    火山模型及其缺点:

    火山模型(Volcano-style execution)是最早的查询执行引擎,也叫做迭代模型 (iterator model),或 one-tuple-at-a-time。在这种模型中,查询计划是一个由operator组成的DAG,其中每一个operator 包含三个函数:open,next,close。Open 用于申请资源,比如分配内存,打开文件,close 用于释放资源,next方法递归的调用子operator的 next方法生成一个元组(tuple,即行row在物理上的表示)。

    下图描述了“select sum(C1) from T1 where C2 > 15”的查询计划,该查询计划包含Project,HashAgg,Scan等operator,每个 operator的next方法递归调用子节点的 next,一直递归调用到叶子节点Scan operator,Scan operator的next 从文件中返回一个元组。

    其缺点主要在于:

    1)大量虚函数调用:火山模型的next方法通常实现为一个虚函数,在编译器中,虚函数调用需要查找虚函数表, 并且虚函数调用是一个非直接跳转 (indirect jump), 会导致一次错误的CPU分支预测 (brance misprediction), 一次错误的分支预测需要十几个周期的开销。火山模型为了返回一个元组,需要调用多次next 方法,导致昂贵的函数调用开销

    2)类型装箱:对于a + 2 * b之类表达式,由于需要对不同数据类型的变量做解释,所以在Java中需要把这些本来是primitive(如int等类型)的变量包装成Object,但执行时又需要调用具体类型的实现函数,这本质上也是虚函数调用的效率问题;

    3)CPU Cache利用效率低:next方法一次只返回一个元组,元组通常采用行存储,如果仅需访问第一列而每次均将一整行填入CPU Cache,将导致Cache Miss;

    4)条件分支预测失败:现在的CPU都是有并行流水线的,但是如果出现条件判断会导致无法并行。比如判断数据的类型(是string还是int),或判断某一列是否因为其他字段的过滤条件导致本行不需要被读取等场景;

    5)CPU与IO性能不匹配:每次从磁盘读取一个行数据,经过多次调用交给CPU进行处理,显然,大部分时间都是CPU等待数据就绪,导致CPU空转。

    通过上述描述,可以得出解决问题的基本方法。可以将问题分为2大类,分别用下述的向量化引擎和动态代码生成技术来解决。

    1、向量化执行引擎

    向量化执行以列存为前提,主要思想是每次从磁盘上读取一批列,这些列以数组形式组织。每次next都通过for循环处理列数组。这么做可以大幅减少next的调用次数。相应的CPU的利用率得到了提高,另外数据被组织在一起。可以进一步利用CPU硬件的特性,如SIMD,将所有数据加载到CPU的缓存当中去,提高缓存命中率,提升效率。在列存储与向量化执行引擎的双重优化下,查询执行的速度会有一个非常巨大的飞跃。

    2、动态代码生成

    向量化执行减少CPU等待时间,提高CPU Cache命中率,通过减少next调用次数来缓解虚函数调用效率问题。而动态代码生成,则是进一步解决了虚函数调用问题。

    动态代码生成技术不使用解释性的统一代码,而是直接生成对应的执行语言的代码并直接用primitive type。对于判断数据类型造成的分支判断,动态代码的效果可以消除这些类型判断,使用硬件指令来进一步提高循环处理效率。

    具体实现来说,JVM系如Spark SQL,Presto可以用反射,C++系的Impala则使用了llvm生成中间码。相对来说,C++的效率更高。

    向量化和动态代码生成技术往往是一起工作达到更好的效果。

    六、都有哪些存储空间和访问效率优化方法?

    存储和IO模块的优化方法很多,这里我们还是在Hadoop生态下来考虑,当然,很多优化方法不是Hadoop特有的,而是通用的。OLAP场景下,数据存储最基础而有效的优化是该行存储为列存储,下面讨论的优化措施均基于列存。

    1、数据压缩和编码

    数据压缩是存储领域常用的优化手段,以可控的CPU开销来大幅缩小数据在磁盘上的存储空间,一来可以节省成本,二来可以减小IO和数据在内存中跨线程和跨节点网络传输的开销。目前在用的主流压缩算法包括zlib、snappy和lz4等。压缩算法并不是压缩比越高越好,压缩率越高的算法压缩和解压缩速度往往就越慢,需要根据硬件配置和使用场景在cpu 和io之间进行权衡。

    数据编码可以理解为轻量级压缩,包括RLE和数据字典编码等。

    上图截至Presto论文,展示了RLE编码和数据字典编码的使用方式。RLE用在各列都是重复字符的情况,比如page0中6行记录的returnflag都是"F"。数据字典可高效使用在区分度较低的列上,比如列中只有几种字符串的场景。考虑到同个表的列的值相关性,数据字典可以跨page使用。

    与数据压缩相比,数据编码方式在某些聚合类查询场景下,无需对数据进行解码,直接返回所需结果。比如假设T1表的C1列为某个字符,RLE算法将16个C1列的值“aaaaaabbccccaaaa”编码为6a2b4c4a,其中6a表示有连续6个字符a。当执行 select count(*) from T1 where C1=’a’时,不需要解压6a2b4c4a,就能够知道这16行记录对应列值为a有10行。

    在列存模式下,数据压缩和编码的效率均远高于行存。

    2、数据精细化存储

    所谓数据精细化存储,是通过尽可能多得提供元数据信息来减少不必要的数据扫描和计算,常用的方法包括但不限于如下几种:

    1)数据分区:数据分区可用于将表中数据基于hash或range打散到多个存储节点上,配合多副本存储。可以提高数据容灾和迁移效率。除此之外,在查询时可以快速过滤掉不符合where条件要求的数据分区,无需逐列读取数据进行判断。

    2)行组:与数据分区类似,Hadoop中常用的parquet和orcfile还将表数据分为多个行组(row group),每个行组内的记录按列存储。这样即达到列存提高OLAP查询效率,同时能够兼顾查询多行的需求;

    3)局部索引:在数据分区或行组上创建索引,可以提高查询效率。如下图所示,orcfile在每个行组的头部维护了Index Data来,保存最大值和最小值等元数据,基于这些信息可以快速决定是否需扫描该行组。某些OLAP系统进一步丰富了元数据信息,比如建立该行组记录的倒排索引或B+树索引,进一步提高扫描和查询效率。

    4)富元数据:除了提供最大值和最小值信息外,还可进一步提供平均值、区分度、记录数、列总和,表大小分区信息,以及列的直方图等元数据信息。

    3、数据本地化访问

    数据本地化读写是常见的优化方法,在Hadoop下也提供了相应的方式。

    一般来说,读HDFS上的数据首先需要经过NameNode获取数据存放的DataNode信息,在去DataNode节点读取所需数据。

    对于Impala等OLAP系统,可以通过HDFS本地访问模式进行优化,直接读取磁盘上的HDFS文件数据。HDFS这个特性称为"Short Circuit Local Reads",其相关的配置项(在hdfs-site.xml中)如下:

    <property>

        <name>dfs.client.read.shortcircuit</name>

        <value>true</value>

      </property>

      <property>

        <name>dfs.domain.socket.path</name>

        <value>/var/lib/hadoop-hdfs/dn_socket</value>

      </property>

    其中:dfs.client.read.shortcircuit是打开这个功能的开关,dfs.domain.socket.path是Datanode和DFSClient之间沟通的Socket的本地路径。

    4、运行时数据过滤

    这是少部分OLAP系统才具有的高级功能,比如Impala的RunTime Filter(RF)运行时过滤,和SparkSQL 3.0的 Dynamic Partition Pruning动态分区裁剪,可以将驱动表的bloomfilter(BF)或过滤条件作用在被驱动表的数据扫描阶段,从而极大减少需扫描/返回的数据量。下面分别用一个图进行简述,在后续分析具体OLAP系统时再详述。

    上图直观得展示了Impala runtime filter的实现。流程如下:

    1)同时下发两个表的SCAN操作。左边是大表,右边是小表(相对而言,也有可能是同等级别的),但是左表会等待一段时间(默认是1s),因此右表的SCAN会先执行;

    2)右表的扫描的结果根据join键哈希传递扫不同的Join节点,由Join节点执行哈希表的构建和RF的构建;

    3)Join节点读取完全部的右表输入之后也完成了RF的构建,它会将RF交给Coordinator节点(如果是Broadcast Join则会直接交给左表的Scan节点);

    4)Coordinator节点将不同的RF进行merge,也就是把Bloom Filter进行merge,merge之后的Bloom Filter就是一个GLOBAL RF,它将这个RF分发给每一个左表Scan;

    5)左表会等待一段时间(默认1s)再开启数据扫描,为了是尽可能的等待RF的到达,但是无论RF什么时候到达,RF都会在到达那一刻之后被应用;

    6)左表使用RF完成扫描之后同样以Hash方式交给Join节点,由Join节点进行apply操作,以完成整个Join过程。

    sparksql图1(官方这个图有误,右边应该是Scan Date)

    sparksql图2

    上面2幅图是SparkSQL 3.0的动态分区裁剪示意图。将右表的扫描结果(hashtable of table Date after filter)广播给左表的Join节点,在进行左表扫描时即使用右表的hashtable进行条件数据过滤。

    七、除了上面这些,还有其他优化方法吗?

    还有个极为重要的技术是集群资源管理和调度。Hadoop使用YARN进行资源调度,虽然带来了很大遍历,但对性能要求较高的OLAP系统却有些不适合。

    如启动AppMaster和申请container会占用不少时间,尤其是前者,而且container的供应如果时断时续,会极大的影响时效性。

    目前的优化方法主要包括让AppMaster启动后长期驻守,container复用等方式。让资源在需要用时已经就位,查询无需等待即可马上开始。

    八、做个总结

    本系列总结了下笔者最近看的一些OLAP相关文献材料,主要是想说下自己对数仓和OLAP系统的理解,之所以采用问答形式,是因为笔者就是带着这些问题去google网上或公司内部的资料,或者直接请教在这个领域的大佬。

    由于水平有限,难免有所错误,非常欢迎大家看后能够指出,让笔者有进步的机会。这个系列可以理解为是对他人文章的一次汇总加工。部分内容直接参考了其他文章,这也是在笔者先前其他文章中极少出现的情况,这些内容均在文末“引用”小结列出。

    >>>>

    引用资料

    • https://en.wikipedia.org/wiki/

    • https://www.infoq.cn/article/NTwo*yR2ujwLMP8WCXOE

    • https://snappydata-cn.github.io/2018/04/04/SnappyData%E4%B8%8EPresto-Druid-Kylin-ES%E7%9A%84%E5%AF%B9%E6%AF%94-2/

    • http://blog.daas.ai/2018/11/26/ClickHouse_vs._Druid_Pinot/

    • https://waltyou.github.io/Spark-DAG/

    • http://hbasefly.com/

    • https://www.infoq.cn/article/an-article-mastering-sql-on-hadoop-core-technology 8. https://mp.weixin.qq.com/s/4O07cECjLbUQ4H-5K8f3gQ

    • https://www.infoq.cn/article/columnar-databases-and-vectorization

    • http://mysql.taobao.org/monthly/2017/01/06/

    • https://blog.csdn.net/yu616568

    作者丨温正湖

    来源丨https://zhuanlan.zhihu.com/p/147344996

    dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

    展开全文
  • 开源OLAP引擎

    千次阅读 2017-12-25 20:23:30
    最近几天有空,梳理一下各种OLAP的计算和存储框架。 纯计算框架(query engine) Impala C++ cloudera主导 Drill drill的主要特点是支持多种的存储引擎和存储(HDFS HBase Mongo S3 ,json parquet,csv),查询前不...

    大数据的声音虽然没有前几年热闹,但hadoop生态圈的造轮子脚步一点也没停下来。最近几天有空,梳理一下各种OLAP的计算和存储框架。

    • 纯计算框架(query engine)
      • Impala 目前在国内已经有不少商业客户在使用,估计是cloudera的国内市场推广做的不错。
        • 架构上,元数据需要单独的mysql/pgsql来存储,需要两个单独的stateserver和catalogserver来管理集群状态和元数据的变化;
        • SQL compilation支持。CBO和vectorization介绍不详细;impala的使用文档比较详细,内部技术细节的文档不多;
        • 对数据源的支持比较少,很多nosql是不支持的;
        • C++开发,cloudera主导。
      • Drill Drill是一个纯粹的SQL query engine,支持多种data source,Hadoop storage, S3-style云存储,NoSQL存储。
        • 主要特点是支持多种的data source(HDFS HBase Mongo S3 kafka openTSDB等等),查询前不需要etl工具做转换,跟BI工具集成比较好;
        • 支持SQL compilation,CBO这块用的calcite,支持data locality aware,predicate 可以下推到store层,如果store层有对应的filter。
        • 架构中比较有特点的两个地方:
          • meta data存储在底层存储引擎中,不像hive还需要一个mysql。
          • 用一个distributed in-memory k/v cache(infinispan,jboss cache的后继项目)来缓存查询查询计划分片,执行中间结果和统计信息。
        • SQL compilation,Vectorization, pipeline等技术都支持。
        • java开发,MapR公司主导。impala和drill不同的技术路线跟两个公司的定位有很大关系。
      • presto 最初是facebook主导开发,开源后传统的数仓公司TeraData提供商业支持。
        • 支持的多种数据源,mysql redis kafka cassandra等,支持的数据源比Drill要少,对Json数据的支持没有Drill好
        • 内部的架构有点像impala,一个coodinator+多个worker。
      • Hive 最初也是facebook开发。
        • 最初Hive的性能着实堪忧,目前也增加了CBO和vectorization等新特性。map reduce中间结果存盘确实是个硬伤。
      • SparkSQL 跟其他的OLAP引擎不同,sparkSQL分析的数据以RDD/DataFrame方式存放在spark集群中。
        • sparkSQL的CBO要到最新的2.2版本才支持,vectorization特性还在开发中
    • 存储框架(data store)
      • kudu kudu是一套完全独立的分布式存储引擎,很多设计概念上借鉴了HBase,但是又跟HBase不同
        • 不需要HDFS,通过raft做数据复制;sharding策略支持keyrange和hash多种;
        • 数据格式在parquet基础上做了些修改,支持二级索引,更像一个列式存储,而不是HBase schema-free的kv方式
        • kudu也是cloudera主导的项目,跟hadoop ecosystem结合比较好,尤其impala,通过impala可以支持update操作
      • Druid Druid的整体定位跟kylin比较像,适用于存储和查询eventlog。
        • 首先它没有自己的存储引擎,而是依赖于HDFS S3等; native查询接口是Http+json,SQL接口需要依赖于社区的库或者Hive;不支持Join。
        • 数据以上卷(roll-up)的方式从外部导入。简单的说对导入时,根据用户指定的统计策略,对某些列(维度)的数据做聚合统计,将聚合数据存盘以节省存储空间。导入有方式,事实和批量;导入时会根据对数据做分片,还可以指定列的索引(索引建在分片上)和压缩方式
        • java开发,使用的公司比较多,阿里,netflix,ebay等, 有个公司imply提供商业支持。
    • Hybrid compute storage
      • palo palo是百度开源的一个数仓产品,官方说法是谷歌mesa和clouderaimpala的结合
        • palo实现了SQL查询引擎和分布式存储引擎,不依赖任何hadoop组件
        • palo的meta data并不依赖于一个单点的metadata storage(例如hive的mysql),而是通过Paxos-like协议做了多点复制,这样的多个节点可以同时提供查询能力
        • sharding策略是先按照某个列做key-range(例如时间戳)切分,然后再按照hash(例如UserID)切分
        • 存储引擎方面,palo支持ORC或者parquet这种方式的列存
        • 为了支持近实时导入,存储引擎层实现了MVCC
        • 保存全量数据的同时,支持rollup 物化视图
        • 简单的多租户支持
        • C++编写,利用LLVM实现vectorization
      • clickhouse 俄罗斯yandex开源的一个数仓产品,c++编写。跟palo或者mesa定位类似,目前官方文档是俄语的,国内有一些翻译,有人在尝试

    https://en.wikipedia.org/wiki/Apache_Impala

    https://www.cloudera.com/documentation/cdh/5-0-x/Impala/Installing-and-Using-Impala/ciiu_concepts.html

    https://drill.apache.org/architecture/

    https://drill.apache.org/blog/2017/12/15/drill-1.12-released/

    https://en.wikipedia.org/wiki/Apache_Drill

    https://en.wikipedia.org/wiki/Presto_(SQL_query_engine)

    https://en.wikipedia.org/wiki/Apache_Hive

    https://cwiki.apache.org/confluence/display/Hive/Vectorized+Query+Execution

    https://hortonworks.com/blog/hive-0-14-cost-based-optimizer-cbo-technical-overview/

    https://issues.apache.org/jira/browse/SPARK-16060

    https://databricks.com/blog/2017/08/31/cost-based-optimizer-in-apache-spark-2-2.html

    http://kudu.apache.org/overview.html

    https://en.wikipedia.org/wiki/Druid_(open-source_data_store)

    http://druid.io/docs/0.11.0/design/index.html

    https://hortonworks.com/blog/apache-hive-druid-part-1-3/

    https://github.com/baidu/palo

    展开全文
  • 开源OLAP引擎:Mondrian

    万次阅读 2016-10-25 09:54:47
    OLAP Created 星期四 20 十月 2016为了满足业务管理和决策的报表系统(包括传统报表、数据仓库、OLAP等)也被创建出来,企业主管通过报表了解企业的总体运行状态。但是,随着企业间竞争的加剧和市场节奏的进一步...

    OLAP

    Created 星期四 20 十月 2016
    为了满足业务管理和决策的报表系统(包括传统报表、数据仓库、OLAP等)也被创建出来,企业主管通过报表了解企业的总体运行状态。
    但是,随着企业间竞争的加剧和市场节奏的进一步加快,企业的日常管理需要对关键业务指标的更加实时的监控和反馈。比如:制造业需要更及时的仓库调度、金融业需要更实时的风险防范、电信业需要更及时的服务指标监控。于是,越来越多的企业提出实时企业的要求,传统的ERP等信息系统和报表系统无法满足这些需求。实时业务监控解决方案旨在更好支撑客户此类需求。
    http://www.tuicool.com/articles/67ZBZv3
    当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

    OLAP技术非常多的特性,概括起来主要有如下几点特性:

    • OLAP技术是面向分析人员、管理人员的;
    • OLAP技术对数据访问通常是只读的,并且一次访问大量数据
    • OLAP技术是面向主题的多维数据分析技术。

    OLAP(On-Line Analysis Processing)在线分析处理是一种共享多维信息的快速分析技术;
    OLAP利用多维数据库技术使用户从不同角度观察数据;OLAP用于支持复杂的分析操作,侧重于对管理人员的决策支持,可以满足分析人员快速、灵活地进行大数据复量的复杂查询的要求,并且以一种直观、易懂的形式呈现查询结果,辅助决策。
    上面是OLAP的一些不同的解释,本文将从以下几个方面介绍OLAP。

    OLAP的基本概念

    http://www.huqiwen.com/2012/06/15/olap-abstruct-and-mondrian-quick-start/
    二、 OLAP的基本概念
    (1)度量、指标)
    是数据度量的指标,是数据的实际意义,即描述数据"是什么"。像上面示例中的人数。
    (2)维度
    维度是描述与业务主题相关的一组属性,单个属性或属性集合可以构成一个维。如上面示例中的学历、民族、性别等都是维度。
    (3)维的层次
    一个维往往可以具有多个层次,例如时间维度分为年、季度、月和日等层次,地区维可以是国家、地区、省、市等层次。这里的层次表示数据细化程度,对应概念分层。后面介绍的上钻操作就是由低层概念映射到高层概念。概念分层可除根据概念的全序和偏序关系确定外,还可以通过对数据进行离散化和分组实现。
    (4)维的成员
    若维是多层次的,则不同的层次的取值构成一个维成员。部分维层次同样可以构成维成员,例如"某年某季度"、"某季某月"等都可以是时间维的成员。
    (5)多维数组
    多维数组用维和度量的组合表示。一个多维数组可以表示为(维1,维2,……,维n,变量),例如(部门,职系、民族、性别,人数)组成一个多维数组。
    (6)数据单元(单元格)
    多维数组的取值。当多维数组中每个维都有确定的取值时,就唯一确定一个变量的值。数据单元可以表示为(维1成员,维2成员,……,维N成员,变量的值),例如(人事教育部,技能,回族,男,1人)表示一个数据单元,表示人事教育部职系是技能的回族男性有1人。
    (7)事实
    事实是不同维度在某一取值下的度量,例如上述人事教育部职系是技能的回族男性有1人就表示在部门、职系、民族、性别四个维度上企业人数的事实度量,并且在为人数事实中包含部门维度人事教育部这一个维度层次,如果将人数事实的所有维度考虑在内,就构成有关人数的多维分析立方体。
    三、 OLAP的特点
    电子数据表与OLAP相比,不具备OLAP的多维性、层次、维度计算以及结构与视图分离等特点。
    多维。维是OLAP的核心概念,多维性是OLAP的关键属性,这与数据仓库的多维数据组织正好相互补充。为了使用户能够从多个维度、多个数据粒度查看数据,了解数据蕴含的信息,
    系统需要提供对数据的多维分析功能,包括切片、旋转和钻取等多种操作
    四、 OLAP的操作
    OLAP比较常用的操作包括对多维数据的切片与切块、上钻(drill-up)与下钻(drill-down)以下旋转(rotate)等。此外,OLAP还能对多维数据进行深加工。
    OALP的这些操作使用户能够从多个视角观察数据,并以图形、报表等多种形式展示,从而获取隐藏在数据中的信息。
    (1)切片与切块。
    选定多维数组的一个维成员做数据分割的操作称为该维上的一个切片。通常把多维数组中选定一个二维子集的操作视为切片,假设选定的维i上的某个维成员Vi,则此多维数组子集可以定义为(维V1……,维Vi,维N,变量)。当某维只取一个维成员时,便得到一个切片,而切块则是某一维取值范围下的多个切片的叠合。通过对数据立方体的切片或切块分割,可以从不同的视角得到各种数据。
    (2)钻取
    钻取包括上钻和下钻。争取能够帮助用户获得更多的细节性数据,逐层的分析问题的所在和原因。
    上钻又称为上卷(roll-up)。上钻操作是指通过一个维的概念分层向上攀升或者通过维归约在数据立方体上进行数据汇总。例如在上面的示例中,可以按学历汇总数据,如把各种学历的都归约为所有学历,便可以得到沿学历维上钻的数据汇总。
    下钻是上钻的逆操作,通过对某一汇总数据进行维层次的细分(沿维的概念分层向下)分析数据。下钻使用用户对数据能够获得更深入的了解,更容易发现问题本质,从而做出正确的决策。
    钻取使用户不会再被海量的数据搞得晕头转向:上钻让用户站在更高层次观察数据,下钻则可以细化到用户所判决的详细数据。钻取的尝试与维度与维所划分的层次相对应,根据用户关心的数据粒度合理划分。
    (3)旋转
    旋转又称转轴,是一种视图操作,通过旋转变换一个报告或页面显示的维度方向,在表格中重新安排维的位置,例如行列转换。这种对立方体的重定位可以得到不同视角的信息。
    (4)其他OLAP操作
    除以上常用多维操作外,还有其他多维操作。
    钻过(drill-across)。钻过操作涉及多个事实表的查询并把结果合并为单个数据集,一个典型的例子就是预测数据与当前数据的结合:通常预测数据与当前数据存在于不同的表中,当用户比较预测销售与当月销售时,需要跨多个事实表查询。
    钻透(drill-through)。钻透使用关系SQL,查询数据立方体的底层,一直到后羰的关系表。
    五、 OLAP的分类
    OLAP分类
    按处理方式分类
    Server OLAP:绝大多数的OLAP系统都属于此类,Server OLAP在服务端的数据库上建立多维数据立方体,由服务端提供多维分析,并把最终结果呈现给用户
    Client OLAP:所相关立方体数据下载一本地,由本地为用户提供多维分析,从而保证在网络故障时仍然能正常工作。
    按存储方式分类
    ROLAP。ROLAP使用关系数据库或扩充关系数据库(XRDBMS)存储管理数据仓库,以关系表存储多维数据,有较强的可伸缩性。其中维数据存储在维表中,而事实数据和维ID则存储在事实表中,维表和事实表通过主外键关联。
    MOLAP。MOLAP支持数据的多维视图,采用多维数据组存储数据,它把维映射到多维数组的下标或下标的范围,而事实数据存储在数组单元中,从而实现了多维视图到数组的映射,形成了立方体的结构。大容量的数据使立方体稀疏化,此时需要稀疏矩阵压缩技术处理,由于MOLAP是从物理上实现,故又称为物理OLAP(Physical OLAP)。
    DOLAP。DOLAP是属于单层架构,它是基于桌面的客户端OLAP,主要特点是由服务器生成请求数据相关的立方体并下载到本地,由本地提供数据结构与报表格式重组,为用户提供多维分析,此时无需任何的网络连接,灵活的存储方式方便了移动用户的需求,但支持数据有限,使用范围有限。

     

    开源OLAP引擎:Mondrian

    ~/Desktop/Mondrian数据分析学习.pdf
    http://mondrian.pentaho.com/documentation/
    http://www.cnblogs.com/panfeng412/archive/2012/03/25/mondrian-aggregate-table.html

    数据立方体:cube
    在Mondrian里面的cube是以XML的形式定义的。(MDX)
    Mondrian本身是不存储数据的,通过MDX语句(一个类似于SQL的查询语言)来获取数据,Mondrian 运行的时候要连数据库,并且还要有一个数据模型配置文件(Mondrian叫schema),其实就是一个取数据的规则;由此可知Mondrian只不过是把MDX 翻译成了SQL然后从数据库中把数据拿出来给用户
    Mondrian是一个开放源代码的Rolap服务器,使用java开发的。它实现了xmla和jolap规范,而且自定义了一种使用mdx语言的客户端接口。Mondrian是olap服务器,而不是数据仓库服务器,因此Mondrian的元数据主要包括olap建模的元数据,不包括从外部数据源到数据库转换的元数据。也就是说Mondria的元数据仅仅包括了多维逻辑模型,从关系型数据库到多维逻辑模型的映射,存取权限等信息。在功能上,Mondrian支持共享维和成员计算,支持星型模型和雪花模型的功能。

    Mondrian 是一个开源项目,是开源项目Pentaho的一部分,是一个用Java写成的OLAP引擎。它实现了MDX语言、XML解析、JOLAP规范。
    它从RDBMS和其它数据源读取数据并把数据聚集在内存缓存中,然后经过Java API用多维的方式对结果进行展示,同时可以不写SQL就能分析存储于SQL 数据库的庞大数据集,可以封装JDBC数据源并把数据以多维的方式展现出来。

    整体的项目架构,四个大部分Schema manager、Session Manager、Dimension Manager、Aggregate Manager

    • l Schema Manager:与初始化紧密相关。主要是一些重要的数据结构如缓存池的构建以及多维模型的生成。
    • l Session Manager:最为重要的一个部分。接受MDX查询、解析MDX,返回结果。
    • l Aggregate Manager:实现了对聚集表的管理。主要是对OLAP缓存的管理,属于性能优化的部分。
    • l Dimension Manager:维度的管理。实现多维模型中维度和关系数据库表中列的映射,在Schema Manager也有部分功能处理这些映射。

    Mondrian通过Schema来定义一个多维数据库,它是一个逻辑概念上的模型,其中包含Cube(立方体)、Dimension(维度)、Hierarchy(层次)、Level(级别)、Measure(度量),这些被映射到数据库物理模型。Mondrian中Schema是以XML文件的形式定义的。

    • Cube(立方体)由维度构建出来的多维空间,是一系列Dimension和Measure的集合区域,它们共用一个事实表。
    • Dimension(维度)观察数据的一种角度,维度可以理解为立方体的一个轴。是一个Hierarchy的集合,维度一般有其相对应的维度表,它由Hierarchy(层次)组成,而Hierarchy(层次)又是由组成Level(级别)的。
    • Hierarchy(层次)是指定维度的层级关系的,如果没有指定,默认Hierarchy里面装的是来自立方体中的真实表。
    • Level(级别)是Hierarchy的组成部分,使用它可以构成一个结构树,Level的先后顺序决定了Level在结构树上的位置,最顶层的 Level 位于树的第一级,依次类推。
    • Measure(度量)是我们要进行度量计算的数值,支持的操作有sum、count、avg、distinct-count、max、min等。

    在多维分析中,关注的内容通常被称为度量(Measure),而把限制条件称为维度(Dimension)。
    多维分析就是对同时满足多种限制条件的所有度量值做汇总统计。包含度量值的表被称为事实表(Fact Table),描述维度具体信息的表被称为维表(Dimension Table)

    Ø 立方体:由维度构建出来的多维空间,包含了所有要分析的基础数据,所有的聚合数据操作都在立方体上进行。
    Ø 维度:就是观察数据的一种角度。在这个例子中,路线,源,时间都是维度,
    Ø 维度成员:构成维度的基本单位。对于时间维,例如它的成员分别是:第一季度、第二季度、第三季度、第四季度。
    Ø 层次:维度的层次结构,要注意的是存在两种层次:自然层次和用户自定义层次。对于时间维而言,(年、月、日)是它的一个层次,(年、季度、月)是它的另一个层次,一个维可以有多个层次,层次可以理解为单位数据聚合的一种路径。
    Ø 级别:级别组成层次。对于时间维的一个层次(年、月、日)而言,年是一个级别,月是一个级别,日是一个级别,显然这些级别是有父子关系的。
    Ø 度量值:要分析展示的数据,即指标。如图1中一个cell中包含了两个度量值:装箱数和截至时间,可以对其进行多维分析。
    Ø 事实表:存放度量值的表,同时存放了维表的外键。所有的分析用的数据最终都是来自与事实表。
    Ø 维表:一个维度对应一个或者多个维表。一个维度对应一个维表时数据的组织方式就是采用的星型模式,对应多个维表时就是采用雪花模式。雪花模式是对星型模式的规范化。简言之,维表是对维度的描述。
    l MDX查询:多维模型的查询语言MDX(MDX是微软发布的多维查询语言标准),它的语法与SQL有很多相似之处:select {[Measures].[Salary]} on columns, {[Employee].[employeeId].members} on rows from CubeTest对于这条语句,COLUMNS 和 ROWS都代表查询轴,其中COLUMNS代表列轴,ROWS代表行轴。COLUMNS又可以写成0,ROWS又可以写成1,当只有两个查询轴时,可以理解为结果的展现格式是一个平坦二维表。这条语句的含义就是查询名字为CubeTest的立方体,列显示Measures维度的salary,行显示 Employee维度employeeId级别的所有成员,那么得出的结果就是employeeId所有成员的salary,也就是所有员工的薪酬。具体语法规范和帮助文档可以参考微软的用户文档。

    百万级事实数据:按照Mondrian文档中所描述的内容可以看出,只基于操作系统环境和数据库环境的优化,Mondrian Server在百万行级别数据量的事实表(关系数据库)仍能够运行良好。当然这需要我们自己来评测和证实。
    千万级事实数据:当事实表数据立方体的数据量达到千万行以上时,Mondrian建议采用"汇总表"或者是由数据库支持的类似Oracle数据库的"物化视图"功能来优化OLAP查询的性能。
    Mondrian缓存设置:由于Mondrian会将查询过的数据缓存起来,所以Mondrian建议缓存的大小根据具体项目的实际情况判断,当然是缓存越大越好

    Mondrian缓存控制

    为了提高海量数据下的查询响应速度,Mondrian自动将首次查询的结果缓存到内存中,之后的查询如果命中缓存内容,则不再访问数据库。这种实现方式有点自不必说,
    但是在实现实时OLAP时会存在问题,实时OLAP中数据变化频繁导致缓存中的数据不是最新的。
    缓存控制接口:为了做到不重启OLAP Server也能更新缓存,Mondrian提供了一系列的刷新缓存的接口,支持指定清除指定schema的元数据缓存、查询结果缓存;清除动作可以是全部清除 也可以是 部分清除(可以指定清除某个维度下某级别成员的相关内容)。
    数据变化监听: Mondrian提供了缓存控制接口(被动响应),但对于实现我们的目标"实时OLAP"来说我们就需要自己实现一个数据变更监听的模块,来监听数据变化,一旦数据有变化就发起变更事件,更新Mondrian引擎的缓存。目前初步考虑实现方案为ETL工具在数据处理结束后通知OLAP引擎。引擎收到数据变更通知后做清理缓存的动作。

    Jpivot:简单说是一个展示工具,有人说是个标签库,类似于struts。只是用来显示mondrian传来的xml数据,将其渲染成我们熟悉的html。对于层次性很强的报表,XML渲染的确有他的魅力,免去了繁杂的js痛苦。总之mondrian是用来研究和提取数据,jpivot是用来显示数据。至于jpivit是如何显示数据,主要是通过xls+xml。 Jpivot本身的界面是很难看的。
    Pentaho、Saiku、Jpivot都用到了Mondrian做为其多维数据处理的服务器,网上的很多关于Mondrian的文章也都是以Jpivot来进行分析的,
    不过Jpivot已经被抛弃了作者也不再更新了,并且Jpivot只能支持到Mondrian3.5 所以对于新版本的Mondrian一定是不能用Jpivot了(不过Jpivot有一个替代品Pivot4j这个还在持续维护),
    这里还是推荐大家用Saiku或者Pivot4j
    如果我们不想用Saiku、pivot4j 这样现成的东西(毕竟有很多东西我们用不到)那么可以把Mondrian 集成到我们自己的应用中去

    模型配置文件编写

    http://mondrian.pentaho.com/documentation/schema.php
    personDemo.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <Schema name="Mondrian"> <!--模型定义-->
    <Cube name="Person"> <!--立方体 ,一个立方体有多个维度-->

    <Table name="PERSON" /> <!--立方体对应的表 -->
    <Dimension name="部门" foreignKey="USERID" > <!--定义维度 -->

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有部门" > <!--定义维度下面的层次,层次包含很多层 -->
    <Table name="PERSON" alias="a"/> <!--定义维度获取数据的来源-表 -->
    <Level name="部门" column="DEPARTMENT" uniqueMembers="true" /> <!--定义层次的层,每个层对应数据库中对应的字段 -->
    <Level name="姓名" column="USERNAME" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="性别" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有性别">

    <Table name="PERSON" alias="b" />

    <Level name="性别" column="SEX" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="专业技术资格类别" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有专业技术资格类别">

    <Table name="PERSON" alias="c" />

    <Level name="资格类别" column="ZYJSLB" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="专业技术资格等级" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有专业技术资格等级">

    <Table name="PERSON" alias="d" />

    <Level name="资格等级" column="ZYJSDJ" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="职系" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有职系">

    <Table name="PERSON" alias="e" />

    <Level name="职系" column="ZHIXI" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="民族" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有民族">

    <Table name="PERSON" alias="f" />

    <Level name="民族" column="NATIONALITY" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Dimension name="学历" foreignKey="USERID" >

    <Hierarchy hasAll="true" primaryKey="USERID" allMemberName="所有学历">

    <Table name="PERSON" alias="g" />

    <Level name="学历" column="XUELI" uniqueMembers="true" />
    </Hierarchy>

    </Dimension>
    <Measure name="人数" column="USERID" aggregator="distinct count" /> <!--指标/度量,采用distinct count聚合 -->
    </Cube>

    </Schema>
    对应表:
    CREATE TABLE `person` (
    `userid` varchar(100) ,
    `department` varchar(100) ,
    `username` varchar(100),
    `sex` varchar(100) ,
    `nationality` varchar(100),
    `post` varchar(100),
    `zyjslb` varchar(100),
    `zyjsdj` varchar(100) ,
    `zhixi` varchar(100),
    `xueli` varchar(100) ,
    `age` int(10) ,
    PRIMARY KEY (`userid`)
    )

    MDX查询语句:select NON EMPTY {[Measures].[人数]} on columns, NON EMPTY {([部门].[所有部门], [职系].[所有职系], [专业技术资格类别].[所有专业技术资格类别], [专业技术资格等级].[所有专业技术资格等级], [学历].[所有学历], [民族].[所有民族], [性别].[所有性别])} ON rows from Person

    模型配置文件XML元素分析

    http://www.biaodianfu.com/olap-mondrian.html
    Schema
    Schema 定义了一个多维数据库。包含了一个逻辑模型,而这个逻辑模型的目的是为了书写 MDX 语言的查询语句。这个逻辑模型实际上提供了这几个概念:

    • Cubes: 立方体
    • Dimensions: 维度
    • Hierarchies: 层次
    • Levels: 级别
    • Members: 成员

    而一个schema 文件就是编辑这个 schema 的一个xml 文件。在这个文件中形成逻辑模型和数据库物理模型的对应。

    Cube
    一个 Cube 是一系列维度 (Dimension) 和度量 (Measure) 的集合区域。在 Cube 中, Dimension 和 Measure 的共同地方就是共用一个事实表。 Cube 中的有以下几个属性:

    • name: Cube 的名字。
    • caption: 标题 , 在表示层显示的。
    • cache: 是否对 Cube 对应的实表用 mondrian 进行存储 , 默认为 true。
    • enabled: 是布尔型的 , 如果是被激活 ,Cubes 就执行 , 否则就不予理睬,默认为 true。
    • Cube 里面有一个全局的标签定义了所用的事实表的表名。

    Dimension
    他是一个层次( Hierarchies )的集合 , 维度一般有其相对应的维度表 . 他的组成是由层次(Hierarchies)而层次(Hierarchies)又是有级别(Level)组成 . 其属性如下:

    • name: Dimension 的名称。
    • type: 类型,有两个可选的类型: StandarDimension 和 TimeDimension ,默认为StandardDimension。
    • caption: 标题 , 在表示层显示的UsagePrefix加前缀 , 消除歧义。
    • foreignKey: 外键,对应事实表中的一个列,它通过 <Hierarchy> 元素中的主键属性连接起来。

    Hierarchy
    你一定要指定其中的各种关系,如果没有指定,就默认 Hierarchy 里面装的是来自立方体中的真实表 . 属性如下:

    • name: Hierarchy 的名称,该值可以为空,为空时表示 Hirearchy 的名字和 Dimension 的名字相同。当一个 Dimension 有多个 Hierarchy时,注意 name 值要唯一。
    • hasAll: 布尔型的 , 决定是否包含全部的成员 member。
    • allMemberName: 所有成员的名字 , 也就是总的标题 , 例如: allMemberName= "全部产品"。
    • allLevelName: 所有级别的名字,它会覆盖其下所有的 Member 的 name 和所有的 Level 的 name 属性的值。
    • allMemberCaption: 例如 : allMemberCaption= "全部产品"这个是在表示层显示的内容。
    • PrimaryKey: 通过主键来确定成员,该主键指的是成员表中的主键,该主键同时要与 Dimension 里设置的 foreignKey 属性对应的字段形成外键对应关系。
    • primaryKeyTable: 如果成员表不只一个,而是多个表通过 join 关系形成的,那么就要通过这个属性来指明 join 的这些表中,哪一个与Dimension 里设置的foreignKey 属性形成外键关系。通过该属性来指明主表。
    • caption: 标题 , 在表示层显示的。
    • defaultMember
    • memberReaderClass 设定一个成员读取器,默认情况下 Hierarchy 都是从关系型数据库里读取的,如果你的数据不在 RDBMS 里面的话,你可以通过自定义一个member reader 来表现一个 Hierarchy 。

    Level
    级别 , 他是组成 Hierarchy 的部分。属性很多,并且是 schema 编写的关键,使用它可以构成一个结构树, Level 的先后顺序决定了 Level在这棵树上的的位置,最顶层的 Level 位于树的第一级,依次类推。 Level 的属性如下:

    • name: 名称
    • table: 该 Level 要使用的表名
    • column: 用上面指定的表中某一列作为该 Level 的关键字
    • nameColumn: 用来显示的时候使用,如果不定义,那么就采用上面的 column 的值来进行显示。
    • oridinalColumn: 定义该 Level 上的成员的显示顺序,如果不指定,那么采用 column 的值。
    • parentColumn: 在一个有父 – 子关系的 Hierarchy 当中,当前 Level 引用的是其父成员的列名。好比是一张部门表,在一张表里表现部门的上下级关系,一个是主键,肯定还有一个字段为连接到该主键的外键的列名,这里的 parentColumn 指的就是这个列名。
    • nullParentValue: 如果当前的 Level 是有上下级关系(设置了 parentColumn 属性),如果该 Level 又处于顶级,我们需要将顶级的数据取出来,这里指的是位于顶级的父成员的值,有些数据库不支持 null, 那么也可以使用0或-1 等,这就表示顶级的成员的父 ID 为0 或为-1 。
    • type: 数据类型,默认值为 string 。当然还可以是 Numeric 、 Integer 、 Boolean 、 Date 等。
    • uniqueMembers: 该属性用于优化产生的 SQL ,如果你知道这个级别和其父级别交叉后的值或者是维度表中给定的级别所有的值是唯一的,那么就可以设置该值为 true ,否则为 false 。
    • levelType: 该 Level 的类型,默认为 regular (正常的),如果你在其 Dimension 属性 type 里选择了 TimeDimension 那么这里就可以选择 TimeYears 、 TimeQuarters 、 TimeMonth 、 TimeWeeds 、 TimeDays 。
    • hideMemberIf: 在什么时候不隐藏该成员,可选的值有三个: Never 、 IfBlankName 、 IfParentName
    • approxRowCount: 该属性可以用来提高性能,可以通过指定一个数值以减少判断级别、层次、维度基数的时间,该属性在通过使用 XMLA 连接Mondrian 很有用处。
    • caption: 标题 , 在表示层显示的。
    • captionColumn: 用来显示标题的列。
    • formatter: 该属性定义了 Member.getCaption() 方法返回的动作值,这里需要是一个实现了 mondrian.olap.MemberFormatter 接口的类,用来对Caption地值进行格式化。

    Join
    对于一个 Hierarchy 来说,有两种方式为其指定:一种是直接通过一个 Table 标签指定;一种是通过 Join 将若干张表连接起来指定。一旦采用 Join 的话,那么就要在 Hierarchy 里的 primaryKeyTable 属性指定主表。

    Measure

    • Measure 就是我们要计算的数值,操作的核心。它的属性如下:
    • name: 名称。
    • aggregator: 要采用的计算函数。
    • column: 要计算的列名。
    • formatString: 计算结果的显示格式。
    • visible: 是否可见。
    • datatype: 数据类型,默认为 Numeric
    • formatter: 采用类来对该 Measure 的值进行格式,具体参考 Level 的 formatter 属性。
    • caption: 标题,用来显示时使用。

    概括总结一下:在多维分析中,关注的内容通常被称为度量(Measure),而把限制条件称为维度(Dimension)。多维分析就是对同时满足多种限制条件的所有度量值做汇总统计。包含度量值的表被称为事实表(Fact Table),描述维度具体信息的表被称为维表(Dimension Table),同时有一点需要注意:并不是所有的维度都要有维表,对于取值简单的维度,可以直接使用事实表中的一列作为维度展示。

    什么是聚合表(Aggregate Table)

    下描述了一个数据库的结构。该数据库中共有五张表,分别是Sales表,Customer表,Time表,Product表和Mfr表。这个数据库的作用是存储每一笔交易:包括这笔交易发生在什么时间,交易的产品类型,进行交易的客户信息,交易方式,交易了多少件产品以及成交金额是多少。
    模型中有一张事实表(Sales),两个度量列(units和dollars),四个维度表(Product, Mfr, Customer, Time)。在这个星型模型的最顶层,我们创建了以下多维模型

    • [Sales]立方体包含[Unit sales]和[Dollar sales]两个度量值;
    • [Product]维度包含[All Products],[Manufacturer],[Brand],[Prodid]四个级别;
    • [Time]维度包含[All Time],[Year],[Quarter],[Month],[Day]五个级别;
    • [Customer]维度包含[All Customers],[State],[City],[Custid]四个级别;
    • [Payment Method]维度包含[All Payment Methods],[Payment Method]两个级别。

    假设现在我们要对交易做一些统计,例如,某一件特定产品在某一个时间段内以某种特定方式总共卖出多少件或多少钱,这时成交产品数和成交金额是我们最终关注的内容,其他的因素例如时间、产品、方式等都只是对我们最终关注内容进行统计的限制条件。
    在上面的例子中,限制条件有时间、产品类型、用户类型和交易方式
    有时我们并不需要同时使用所有的限制条件,例如,当我们只想知道指定产品的成交总金额时,那么除了产品类型之外其他三个限制条件都是多余的,而在查询时,需要在整个事实表中执行查询,找出产品类型为指定类型的所有产品然后再做统计,为了提高查询效率,我们可以新建一张表,这张表按照产品类型把事实表中的行合并到一起,合并的方式是抛弃其他维,把度量值按特定的方式(max,min,sum,count或avg)整合到一起。这种表被叫做聚合表(Aggregate Table)。

    聚合表的应用场景
    事实表中的行构成了一个集合,每一维(或若干维)按照其取值的不同可以将事实表这个全集划分成若干个不相交的子集。聚合表所做的工作实际上就是把划分出的子集归为数据库表中的一行,这样做一方面可以减少数据库表的行数,另一方面也省去了查询时所需要做的一些统计工作,从而提高查询时的效率。

    1. 使用Mondrian做大数据量(如>100W行)的OLAP分析时,考虑是否可以使用聚合表进行优化。
    2. 然而Mondrian的优化方式又不限于聚合表这一种,是否要进行聚合表优化,要根据实际情况来决定。
    3. Mondrian目前并不提供对聚合表的数据同步机制,如果要做实时OLAP,需要自己实现聚合表和事实表中的数据同步。

    聚合表的定义见:http://www.cnblogs.com/panfeng412/archive/2012/03/25/mondrian-aggregate-table.html

    Schema-workspace图形化配置模型文件

    http://sourceforge.net/projects/mondrian/files/schema%20workbench/
    http://blog.csdn.net/athenaer/article/details/7947193

    其他参考:http://blog.csdn.net/zhangzhongzhong/article/details/50685654
    http://blog.csdn.net/xiaolang85/article/details/45248289
    http://wushexu.iteye.com/blog/1960252

     

    展开全文
  • OLAP引擎,就得先说说OLTP引擎。 什么是OLTP引擎 20世纪70年代,关系型数据库随着一篇影响世界发展进程的论文发表而出现。 20世纪80年代,人们太喜欢关系型数据库了,恨不得把所有的数据都存进去,许多企业利用...

    说OLAP引擎,就得先说说OLTP引擎。

    什么是OLTP引擎

    20世纪70年代,关系型数据库随着一篇影响世界发展进程的论文发表而出现。
    20世纪80年代,人们太喜欢关系型数据库了,恨不得把所有的数据都存进去,许多企业利用关系型数据库来存储和管理业务数据,并建立相应的应用系统来支持日常的业务运作。
    这种应用以支持业务处理为主要目的,被称为联机事务处理(On line Transaction Processing,OLTP)应用,它所存储的数据被称为操作数据或者业务数据。

    一言以蔽之:OLTP引擎用来管理操作性系统数据。

    什么是OLAP引擎

    同样是20世纪70年代,4P’s理念的出现打破了企业主动提供服务的僵局,企业的决策者们需要根据客户提供个性化的服务,提高客户的粘度。
    随着数据的积累,OLTP引擎力有未逮,企业家们需要一个新的技术来快速从积累的数据中获得最新最准确的信息。
    最后在20世纪90年代,那个发表划时代论文的人–关系型数据库教父埃德加·弗兰克·科德(E.F.Codd 提出了多维数据库和多维分析的概念,即联机分析处理(Online Analytical Processing,OLAP)应用。
    OLAP委员会对联机分析处理的定义为:使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取,从而获得对数据更深入了解的一类软件技术。

    一言以蔽之:OLAP引擎用来管理分析性数据。

    不管是之后的数据仓库时代,大数据时代,亦或者未来的数据中台时代,云时代,OLAP引擎都会因为其特性与历史遗留性留存下来。

    OLAP引擎准则

    E.F.Codd对OLAP引擎定下了12条准则:

    • 准则1 OLAP模型必须提供多维概念视图

    • 准则2 透明性准则

    • 准则3 存取能力准则

    • 准则4 稳定的报表能力

    • 准则5 客户/服务器体系结构

    • 准则6 维的等同性准则

    • 准则7 动态的稀疏矩阵处理准则

    • 准则8 多用户支持能力准则

    • 准则9 非受限的跨维操作

    • 准则10 直观的数据操纵

    • 准则11 灵活的报表生成

    • 准则12 不受限的维与聚集层次

    OLTP引擎与OLAP引擎比较

    与OLAP 不同的是,OLTP系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作,强调事务性。

    OLAP系统则强调数据分析,强调SQL执行时长,强调磁盘I/O,强调分区。

    在这里插入图片描述

    现在的OLAP引擎有HAWQ、Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum等,可以说目前没有一个引擎能在数据量,灵活程度和性能上做到完美,用户需要根据自己的需求进行选型。
    在这里插入图片描述

    什么是MOLAP引擎

    MOLAP(Multi-dimensional OLAP ),多维OLAP引擎也可以叫做传统OLAP引擎。

    特点:

    • 传统的 OLAP 分析方式
    • 数据存储在多维数据集中

    代表:

    • Kylin
    • Druid

    优点:

    • 卓越的性能
    • 支持复杂的计算

    缺点:

    • 需要预先定义维度
    • 不支持明细数据查询
    • 成本高

    场景:适合性能要求高,成本相对宽松的场景。

    什么是ROLAP引擎

    RLOAP(Relational OLAP ),关系型OLAP引擎。

    特点:

    • 以关系数据库为核心,以关系型结构进行多维数据的表示
    • 通过 SQL 的 where 条件以呈现传统 OLAP 的切片、切块功能

    代表:

    • Presto
    • Impala

    优点:

    • 不需要预处理
    • 可扩展性好
    • 可高效处理大量数据

    缺点:

    • 性能不足
    • 需要更过的计算资源

    场景:适合性能要求相对低,查询灵活度要求高的即席查询场景。

    什么是HOLAP引擎

    HLOAP(Hybrid OLAP),混合OLAP引擎。

    特点:

    • 兼顾MOLAP和ROLAP的优点,兼顾查询性能与灵活度。
    • 当查询聚合性数据的时候,使用 MOLAP 技术;当查询明细数据时,使用 ROLAP 技术。在给定使用场景的前提下,以达到查询性能的最优化。

    总结

    目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
    从体系架构上说,采用MOLAP使得OLAP应用和数据仓库分离开,降低了耦合度,这种架构是比较理想的,可以让不同部件专门干自己的事,付出的代价主要是ETL的复杂度。
    如果使用ROLAP引擎,引擎的性能很大一部分还是依赖数据仓库的设计和数据的治理,对数据仓库工程师的要求就要高一点。

    图片转载自易观。
    在这里插入图片描述

    展开全文
  • 开源OLAP引擎对比

    千次阅读 2019-07-28 15:59:50
    文章目录开源OLAP引擎对比OLAP简介分布式OLAP引擎分类及对比基于MPP架构的ROLAP引擎预计算引擎架构的MOLAP搜索引擎架构纯列存OLAP基于内存的SnappyData对比 开源OLAP引擎对比 OLAP简介 OLAP(On-Line Analytical ...
  • 开源OLAP系统对比

    千次阅读 2019-07-06 16:06:49
    常见OLAP对比 数据库 响应时间 并发能力 社区 处理能力 分析能力 理解 Impala 慢 低 适中 支持的数据规模大 兼容HQL以及多表join和窗口函数 目前通用的解决方案是impala+kudu,mpp架构 Kylin 快 高 活跃 支持的数据...
  • 摘要:本文主要介绍了主流开源OLAP引擎:Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等,逐一介绍了每一款开源 OLAP 引擎,包含架构、优缺点、使用场景等,希望可以给大家有所启发。 PS: 文章较长...
  • prestoPresto是Facebook开发的分布式大数据SQL查询引擎,专门进行快速数据分析。特点:可以将多个数据源的数据进行合并,可以跨越整个组织进行分析。直接从HDFS读取数据,在使用前不需要大量的ETL操作。查询原理:...
  • 开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum) 易观CTO 郭炜 序 现在大数据组件非常多,众说不一,在每个企业不同的使用场景里究竟应该使用哪个引擎呢?这是易观Spark实战营出品的...
  • 开源OLAP引擎测评报告

    千次阅读 2019-01-23 14:25:50
    开源OLAP引擎测评报告 原创: 易观CTO 郭炜 Analysys易观    导读 现在大数据组件非常多,众说不一,在每个企业不同的使用场景里究竟应该使用哪个引擎呢?这是易观Spark实战营出品的开源Olap引擎测评报告,...
  • 大家都知道开源大数据组件种类众多,其中开源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等。当前企业对大数据的研究与应用日趋理性,那么,如何根据业务特点,选择一个适合自身场景的...
  • Mondrian开源OLAP引擎详解

    千次阅读 2018-05-14 16:09:35
    Mondrian是一个基于Java语言的开源OLAP引擎,它通过MDX语句执行查询,从关系型数据库RDBMS中读取数据,然后经过Java API以多维度的形式展示查询结果。Mondrian是一个OpenSource的基于关系数据库的分析服务器,遵循...
  • 关键词:caravel、olap、kylin、数据可视化 Caravel(曾用名Panoramix),是由知名在线房屋短租公司Airbnb开源的一款数据探索与可视化工具,该工具在可视化、易用性和交互性上非常有特色,用户可以轻松对数据进行可视...
  • 开源OLAP引擎Mondrian

    2014-03-07 10:34:13
    关于OLAP开源引擎Mondrian讲解不错: http://www.blogjava.net/pdw2009/archive/2008/04/17/193728.html Mondrian提供了MDX查询的API,类似于Java中的JDBC Mondrian:MDX多维分析语言 JDBC:传统的SQL     ...
  • OLAP开源引擎

    2020-04-13 15:25:31
    目前市面上主流的开源OLAP引擎包含不限于:Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等,可以说目前没有一个引擎能在数据量,灵活程度和性能上做到完美,用户需要根据自己的需求...
  • 主流OLAP系统对比总结

    2020-04-01 11:32:40
    机分析处理OLAP是一种软件技术,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速...
  • 这是易观Spark实战营出品的开源Olap引擎测评报告,团队选取了Hive、Sparksql、Presto、Impala、Hawq、Clickhouse、Greenplum大数据查询引擎,在原生推荐配置情况下,在不同场景下做一次横向对比,供大家参考。...
  • SparkSQL是Hadoop中另一个著名的SQL引擎,它以Spark作为底层计算框架,Spark使用RDD作为分布式程序的工作集合,它提供一种分布式共享内存的受限形式。在分布式共享内存系统中,应用可以向全局地址空间的任意位置进行...
  • 常用开源OLAP性能比较

    2019-09-23 21:21:42
    一、易观测试结果 1 多表关联查询 [外链图片转存失败(img-GxHAAZIh-1569244897010)...thumbnail)] 2 单表查询 二、自己测试结果(单表查询) 2.1 数据情况: ...数据名:student.txt ...数据属性:id(string) ,nam...
  • 开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum) 易观CTO 郭炜 序 现在大数据组件非常多,众说不一,在每个企业不同的使用场景里究竟应该使用哪个引擎呢?这是易观Spark实战营出品的...
  • Doris是百度2017年开源OLAP系统,能够支撑10P级的数据规模,每天几百亿条写入量,秒级百亿条查询,在数据查询、报表BI、用户行为分析系统,甚至交互式分析中广泛应用。 官方文档:http://doris.apache.org/ ...

空空如也

1 2 3 4 5 ... 20
收藏数 11,914
精华内容 4,765
热门标签
关键字:

开源olap