精华内容
参与话题
问答
  • kylin详细介绍

    千次阅读 2018-05-10 11:35:14
    由eBay开源的一个大数据OLAP框架,2014年11月加入了Apache,项目名字也改成了“Apache Kylin”,Apache Kylin是唯一来自中国的Apache顶级开源项目,定位于在Hadoop平台之上实现传统数据仓库,商业智能的能力,提供...

    OLAP(on-Line AnalysisProcessing)的实现方式

    • ROLAP:
    基于关系数据库的OLAP实现(Relational OLAP)。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。特点是将细节数据保留在关系型数据库的事实表中,聚合后的数据也保存在关系型的数据库中。这种方式查询效率最低,不推荐使用。
    • MOLAP:

    多维数据组织的OLAP实现(Multidimensional OLAP。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块(Cube)"的结构,在MOLAP中对"立方块"的"旋转"、"切块"、"切片"是产生多维数据报表的主要技术。特点是将细节数据和聚合后的数据均保存在cube中,所以以空间换效率,查询时效率高,但生成cube时需要大量的时间和空间。

    • HOLAP:

    基于混合数据组织的OLAP实现(Hybrid OLAP)。如低层是关系型的,高层是多维矩阵型的。这种方式具有更好的灵活性。特点是将细节数据保留在关系型数据库的事实表中,但是聚合后的数据保存在cube中,聚合时需要比ROLAP更多的时间,查询效率比ROLAP高,但低于MOLAP。 kylin的cube数据是作为key-value结构存储在hbase中的,key是每一个维度成员的组合值,不同的cuboid下面的key的结构是不一样的,例如cuboid={brand,product,year}下面的一个key可能是brand='Nike',product='shoe',year=2015,那么这个key就可以写成Nike:shoe:2015,但是如果使用这种方式的话会出现很多重复,所以一般情况下我们会把一个维度下的所有成员取出来,然后保存在一个数组里面,使用数组的下标组合成为一个key,这样可以大大节省key的存储空间,kylin也使用了相同的方法,只不过使用了字典树(Trie树),每一个维度的字典树作为cube的元数据以二进制的方式存储在hbase中,内存中也会一直保持一份。


    由eBay开源的一个大数据OLAP框架,2014年11月加入了Apache,项目名字也改成了“Apache Kylin”,Apache Kylin是唯一来自中国的Apache顶级开源项目,定位于在Hadoop平台之上实现传统数据仓库,商业智能的能力,提供交互式的,多维分析能力,并提供在传统数据仓库技术所不能做到的超大规模数据集的快速查询,并使用普通的PC硬件,而无需采购专用的,私有的一体机或者高端存储等

         kylin是一个MOLAP系统,通过预计算的方式缓存了所有 需要查询的的数据结果,需要大量的存储空间(原数据量的10+倍)。一般我们要分析的数据可能存储在关系数据库、HDFS上数据、文本文件、excel 等。kylin主要是对hive中的数据进行预计算,利用hadoop的mapreduce框架实现

        当前已经有超过100多家国内国外的公司正式使用Kylin作为其大数据分析平台的核心。包括eBay、Glispa、微软、Expedia、百度、美团、网易、京东、唯品会、中国移动、中国电信、国泰君安、华泰证券、联想、〇PP〇、魅族、去哪儿等等。Apache Kylin被用到了诸多如数据仓库,用户行为分析,流量(日志)分析,自助分析平台,电商分析,广告效果分析,实时分析,数据服务平台等各种场景

    目录

    系统架构


    • kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求,系统架构如下:
    • 上图黑线勾勒出Cube Build Engine是如何以离线处理方式将关系型数据转化成键-值型数据,黄线部分表现出在线分析数据的处理流程。
    •  数据请求可以利用基于SQL的工具由SQL提交而产生,或者利用第三方应用程序通过Kylin的RESTful服务来实现。
    • RESTful服务会调用Query Engine,后者则检测对应的目标数据集是否真实存在。如果确实存在,该引擎会直接访问目标数据并以次秒级延迟返回结果。
    • 如果目标数据集并不存在,该引擎则会根据设计将无匹配数据集的查询路由至Hadoop上的SQL处、即交由Hive等Hadoop集群负责处理

    组件介绍


    • 核心组件:Kylin的OLAP引擎框架包括元数据引擎、查询引擎、作业引擎、存储引擎以及用来处理客户端请求的REST服务器
    • 元数据管理工具(Metadata Manager): Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件,用于对保存在Kylin当中的所有元数据进行管理,其中包括最为重要的cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础,包括cube的定义,星状模型的定义、job的信息、job的输出信息、维度的directory信 息等等,元数据和cube都存储在hbase中,存储的格式是json字符串,除此之外,还可以选择将元数据存储在本地文件系统
    • 任务引擎(Job Engine): 这套引擎的设计目的在于处理所有离线任务,其中包括shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调,从而确保每一项任务都能得到切实执行并解决其间出现的故障
    • 存储引擎(Storage Engine): 这套引擎负责管理底层存储——特别是cuboid,其以键-值对的形式进行保存。存储引擎使用的是HBase——这是目前Hadoop生态系统当中最理想的键-值系统使用方案。Kylin还能够通过扩展实现对其它键-值系统的支持,例如Redis
    • REST Server:  REST Server是一套面向应用程序开发的入口点,旨在实现针对Kylin平台的应用开发工作。 此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及获取用户权限等等。
    • ODBC驱动程序:为了支持第三方工具与应用程序——例如Tableau——我们构建起了一套ODBC驱动程序并对其进行了开源。我们的目标是让用户能够更为顺畅地采用这套Kylin平台
    • jdbc驱动程序:kylin提供了jdbc的驱动,驱动的classname为org.apache.kylin.jdbc.Driver,使用 的url的前缀jdbc:kylin:,使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。这类接口也使得kylin很 好的兼容tebleau甚至mondrian。
    • 查询引擎(Query Engine):当cube准备就绪后,查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互,从而向用户返回对应的结果,kylin使用一个开源的Calcite框架实现SQL的解析,相当于SQL引擎层
    •  Routing:该模块负责将解析SQL生成的执行计划转换成cube缓存的查询,cube是通过预计算缓存在hbase中,这部分查询是可以再秒级甚至 毫秒级完成,而还有一些操作使用过查询原始数据(存储在hadoop上通过hive上查询),这部分查询的延迟比较高。
    • Cube构建引擎:这个模块是所有模块的基础,它负责预计算创建cube,创建的过程是通过hive读取原始数据然后通过一些mapreduce计算生成Htable然后load到hbase中

     部署结构


    • 单节点部署架构图
    • 单节点优点是:部署简单;缺点也很明显: Kylin是单点,并发请求上来的时候它会成为瓶颈
    • 集群部署架构图
    • 为了将负载分布到Kylin cluster, 需要建立一个Load Balancer. 在LB这里可以启用SSL加密,申请域名,还可以安装防火墙,对外只暴露LB的地址和端口,确保Hadoop和Kylin在网络上对外是隔离的
    • 部署到Cluster非常简单,只需要增加Kylin的节点数,因为Kylin的metadata也是存储在HBase,只需要让它们用同一张metadata表就可以组成cluster,通常在这个时候会用LDAP来管理用户权限
    • 读写分离集群部署架构图
    • Kylin非常适合于做读写分离,原因是Kylin的工作负载有两种:
      1. 前者是Cube的计算,它是批量的、延时很长的计算,有密集的CPU和IO
      2. 后者是在线的计算,是只读的,因为面向用户,它要求低延迟。Cube计算的过程会对集群带来很大的负载,从而产生噪音;所以我们有充足的理由进行读写分析
    • Kylin很容易做到这一点,你可以把HBase单独部署成一个集群,在部署Kylin的节点上,hadoop 配置指向运算的集群,Hbase的配置指向HBase集群。通过这样的部署,可以确保Hbase的查询可以在很短时间完成,而计算集群可以跟公司其它部门分享

    KMS架构


    • KMS = Kylin + Mondrian + Saiku 是一个简单的三层架构,Git上已经有一个整合Kylin,Mondrian以及Saiku的项目。照着这个项目的指引,可以很轻松的搭建这么一个三层的系统。在此,致谢开源项目作者mustangore
    • Kylin: kylin是apache软件基金会的顶级项目,一个开源的分布式多维分析工具。通过预计算所有合理的维度组合下各个指标的值并把计算结果存储到HBASE中的方式,大大提高分布式多维分析的查询效率。Kylin接收sql查询语句作为输入,以查询结果作为输出。通过预计算的方式,将在hive中可能需要几分钟的查询响应时间下降到毫秒级
    • Mondrian:Mondrian是一个OLAP分析的引擎,主要工作是根据事先配置好的schema,将输入的多维分析语句MDX(Multidimensional Expressions )翻译成目标数据库/数据引擎的执行语言(比如SQL)
    • Saiku: Saiku提供了一个多维分析的用户操作界面,可以通过简单拖拉拽的方式迅速生成报表。Saiku的主要工作是根据事先配置好的schema,将用户的操作转化成MDX语句提供给Mondrian引擎执行
    • 架构图如下:

    新资讯


    • Apache Kylin在 1.5.0 推出了从流数据进行准实时(Near Real Time)处理功能,可以直接从Apache Kafka的主题(Topic)中消费数据来构建Cube
    • Apache Kylin 1.5.0的流处理是一次实验性的探索,它打破了以往只能从Apache Hive表构建Cube的局限, 但它在实现上存在一些局限
      1. 不可扩展︰ 由于是利用单个 Java 进程(而不是利用某种计算框架)对数据做处理,当遇到流数据高峰时,可能由于资源不足而导致构建失败
      2. 可能会丢失数据︰ 由于使用一个起始时间+结束时间在Kafka队列中使用二分查找近似地寻找消息的偏移量(offset),过早或过晚到达的消息将会被遗漏,从而使得查询结果有误差
      3. 难以监控︰ 用于构建的任务是单独通过shell脚本执行的,而不是像其它Cube那样由任务引擎统一调度和执行,所以这些任务是在Web界面和REST API上都无法查询到的,使得用户无法方便地使用工具进行监控和管理
      4. 其它︰ 必须持续执行,如果有系统宕机将会造成某些时间窗口的任务没有被执行,从而必须依靠管理员手动恢复;如果宕机时间较长,管理员不得不将长时间窗口切成多个小时间窗口依次来恢复,非常繁琐
    • 新版流式构建是在Kylin v1.5的"可插拔 "架构下的一个完美实现︰ 将Kafka主题视为一种数据源,实现相应的适配器,将数据先抽取、转换和保存到 HDFS,接下来使用各种Kylin的构建引擎(MR/Spark等)对数据进行并行计算 ,下图是高层次的架构图


      Kylin是ebay开发的一套OLAP系统,与Mondrian不同的是,它是一个MOLAP系统,主要用于支持大数据生态圈的数据分析业务,它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中(目前还仅支持hbase),这段时间对mondrian和kylin都进行了使用,发现这两个系统是时间和空间的一个权衡吧,mondrian是一个ROLAP系统,所有的查询可以通过实时的数据库查询完成,而不会有任何的预计算,大大节约了存储空间的要求(但是会有查询结果的缓存,目前是缓存在程序内存中,很容易导致OOM),而kylin是一个MOLAP系统,通过预计算的方式缓存了所有需要查询的的数据结果,需要大量的存储空间(原数据量的10+倍)。一般我们要分析的数据可能存储在关系数据库(mysql、oracle,一般是程序内部写入的一些业务数据,可能存在分表甚至分库的需求)、HDFS上数据(结构化数据,一般是业务的日志信息,通过hive查询)、文本文件、excel等。kylin主要是对hive中的数据进行预计算,利用hadoop的mapreduce框架实现。而mondrian理论上可以支持任意的提供SQL接口数据,由于关系数据库一般会存在索引,所以即使使用mondrian去查询性能还是可以接受的,当前我们使用的oracle数据库,千万条级别的记录,查询可以在分钟级别完成,但是对于hive、
    这样的数据源查询就太慢了,慢得不可以接受。
     
    系统架构
         于是,我们开始尝试使用kylin,kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求,而对于关系数据库中的数据分析进行预计算可能有点不合适了(关系数据库一般存在索引使得即使数据量很大查询也不会慢的离谱,除非SQL写的很烂)。在使用kylin的过程中,也逐渐对kylin有了一定的认识,首先看一下kylin的系统架构:
    Kylin系统架构
         kylin由以下几部分组成:
      · REST Server:提供一些restful接口,例如创建cube、构建cube、刷新cube、合并cube等cube的操作,project、table、cube等元数据管理、用户访问权限、系统配置动态修改等。除此之外还可以通过该接口实现SQL的查询,这些接口一方面可以通过第三方程序的调用,另一方也被kylin的web界面使用。
      · jdbc/odbc接口:kylin提供了jdbc的驱动,驱动的classname为org.apache.kylin.jdbc.Driver,使用的url的前缀jdbc:kylin:,使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。这类接口也使得kylin很好的兼容tebleau甚至mondrian。
      · Query引擎:kylin使用一个开源的Calcite框架实现SQL的解析,相当于SQL引擎层。
      · Routing:该模块负责将解析SQL生成的执行计划转换成cube缓存的查询,cube是通过预计算缓存在hbase中,这部分查询是可以再秒级甚至毫秒级完成,而还有一些操作使用过查询原始数据(存储在hadoop上通过hive上查询),这部分查询的延迟比较高。
      · Metadata:kylin中有大量的元数据信息,包括cube的定义,星状模型的定义、job的信息、job的输出信息、维度的directory信息等等,元数据和cube都存储在hbase中,存储的格式是json字符串,除此之外,还可以选择将元数据存储在本地文件系统。
      · Cube构建引擎:这个模块是所有模块的基础,它负责预计算创建cube,创建的过程是通过hive读取原始数据然后通过一些mapreduce计算生成Htable然后load到hbase中。
     
    关键流程
         在kylin中,最关键的两个流程是cube的预计算过程和SQL查询转换成cube的过程,cube的构造可以分成cube的构建和cube的合并,首先需要创建一个cube的定义,包括设置cube名、cube的星状模型结构,dimension信息、measure信息、设置where条件、根据hive中事实表定义的partition设置增量cube,设置rowkey等信息,这些设置在mondrian中也是可以看到的,一个cube包含一些dimension和measure,where条件决定了源数据的大小,在mondrian中可以通过view实现。另外,kylin还提供了增量计算的功能,虽然达不到实时计算的需求,但是基本上可以满足数据分析的需求。
         查询解析过程主要是使用Calcite框架将用户输入的SQL解析并转换成对hbase的key-value查询操作以获取结果,但是经过使用发现它对SQL的支持是比较差的,所有的SQL不能使用from A,B where xxx之类的join方式,必须使用inner(left、right) join on的方式,否则解析就会出错,这就会导致mondrian生成的SQL压根不能使用kylin查询(因为mondrian生成的SQL是前面一种方式的),另外还有一个局限性就是发现只能对cube相关的表和列进行查询,例如根据维度进行group by查询定义的度量信息,而其他的查询也统统的返回错误,这点倒也不算是很大的问题,毕竟cube的模型已经定义,我们不太可能查询这个模型以外的东西。还有一点有点不能接受的是kylin对于子查询的支持很弱,测试发现查询的结果经常返回空(没有一行),而相同的查询在hive中是有结果的,这对于一些产品方需求支持不是很好,例如产品方可能需要查询年销售额大于xx的地区的每个月的销售总额。我们一般情况下会写出这样的sql:select month, sum(sales) from fact where location in (select location from fact group by year having sum(sales) > 1000) group by month;前一段时间测试发现这种SQL对于关系数据库简直是灾难,因为in语句会导致后面的子查询没有缓存结果,而写成select month, sum(sales) from fact  as A inner join (select location from fact group by year having sum(sales) > 1000) as B on A.location = B.location group by month;可以提高性能,但是测试发现kylin返回的结果为空,而kylin对于in语句的查询时非常高效的(毕竟全部走缓存),那么我们就不得不首先执行子查询得到location集合,然后再写一个SQL使用where location in xxx(kylin对于使用in子句的查询支持还是相当棒的)的方式获得结果,这个应该是需要改进的地方吧。
     
    cube模型
         前面介绍了cube在创建过程中需要的设置,这里看一些每一个设置的具体含义吧,首先我们会设置cube名和notification列表,前者需要保证是全局唯一的,后者是一些Email用于通知cube的一些事件的发生。接着我们需要定义一个星状模型,和一般的数据仓库模型一样,需要指定一个事实表和任意多个维度表,如果存在维度表还需要指定事实表和维度表的关联关系,也就是join方式。接下来是定义dimension,在定义dimension的时候可以选择dimension的类型,分为Normal、Hierachy以及Derived,这个后面再进行介绍,dimension的定义决定着cube的大小,也需要用户对原始的表非常了解。
         接下来是定义measure,kylin会为每一个cube创建一个聚合函数为count(1)的度量,它不需要关联任何列,用户自定义的度量可以选择SUM、COUNT、DISTINCT COUNT、MIN、MAX,而每一个度量定义时还可以选择这些聚合函数的参数,可以选择常量或者事实表的某一列,一般情况下我们当然选择某一列。这里我们发现kylin并不提供AVG等相对较复杂的聚合函数(方差、平均差更没有了),主要是因为它需要基于缓存的cube做增量计算并且合并成新的cube,而这些复杂的聚合函数并不能简单的对两个值计算之后得到新的值,例如需要增量合并的两个cube中某一个key对应的sum值分别为A和B,那么合并之后的则为A+B,而如果此时的聚合函数是AVG,那么我们必须知道这个key的count和sum之后才能做聚合。这就要求使用者必须自己想办法自己计算了。
         定义完measure之后需要设置where条件,这一步是对原始数据进行过滤,例如我们设定销售额小于XXX的地区不在于本次分析范围之内,那么就可以在where条件里设定location in xxx(子查询),那么生成的cube会过滤掉这些location,这一步其实相当于对无效数据的清洗,但是在kylin中这个是会固化的,不容易改变,例如我今天希望将销售额小于XX的地区清洗掉,明天可能有想将年消费小于xxx的用户去除,这就需要每次都创建一个相同的cube,区别仅仅在于where条件,他们之间会有很多的重复缓存数据,也会导致存储空间的浪费,但这也是MOLAP系统不可避免的,因此当过滤条件变化比较多的时候,更好的方案则是创建一个完整的cube(不设置任何where条件),使用子查询的方式过滤掉不希望要的一些维度成员。
         接下来的一步是设置增量cube信息,首先需要选择事实表中的某一个时间类型的分区列(貌似只能是按照天进行分区),然后再指定本次构建的cube的时间范围(起始时间点和结束时间点),这一步的结果会作为原始数据查询的where条件,保证本次构建的cube只包含这个闭区间时间内的数据,如果事实表没有时间类型的分区别或者没有选择任何分区则表示数据不会动态更新,也就不可以增量的创建cube了。
         最后一步设置rowkey,这一步的建议是看看就可以了,不要进行修改,除非对kylin内部实现有比较深的理解才能知道怎么去修改。当然这里有一个可以修改的是mandatory dimension,如果一个维度需要在每次查询的时候都出现,那么可以设置这个dimension为mandatory,可以省去很多存储空间,另外还可以对所有维度进行划分group,不会组合查询的dimension可以划分在不同的group中,这样也会降低存储空间。
     
    Dimension介绍
         在一个多维数据集合中,维度的个数决定着维度之间可能的组合数,而每一个维度中成员集合的大小决定着每一个可能的组合的个数,例如有三个普通的维度A、B、C,他们的不同成员数分别为10/100/1000,那么一个维度的组合有2的3次方个,分别是{空、A、B、C、AB、BC、AC、ABC},每一个成员我们称为cuboid(维度的组合),而这些集合的成员组合个数分别为1、10、100、1000、10*100、100*1000、10*1000和10*100*1000。我们称每一个dimension中不同成员个数为cardinatily,我们要尽量避免存储cardinatily比较高的维度的组合,在上面的例子中我们可以不缓存BC和C这两个cuboid,可以通过计算的方式通过ABC中成员的值计算出BC或者C中某个成员组合的值,这相当于是时间和空间的一个权衡吧。
         在kylin中存在的四种维度是为了减少cuboid的个数,而不是每一个维度是否缓存的,当前kylin是对所有的cuboid中的所有组合都进行计算和存储的,对于普通的dimension,从上面的例子中可以看出N个维度的cuboid个数为2的N次方,而kylin中设置了一些维度可以减少cuboid个数,当然,这需要使用者对自己需要的维度十分了解,知道自己可能根据什么进行group by。
         好了,我们先来看一下kylin中的三种特殊的dimension以及它们的作用,这里参考:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin
    1、Mandatory维度
         这种维度意味着每次查询的group by中都会携带的,将某一个dimension设置为mandatory可以将cuboid的个数减少一半,如下图:
    mandatory dimension
    这是因为我们确定每一次group by都会携带A,那么就可以省去所有不包含A这个维度的cuboid了。
    2、hierarchy维度
         这种维度是最常见的,尤其是在mondrian中,我们对于多维数据的操作经常会有上卷下钻之类的操作,这也就需要要求维度之间有层级关系,例如国家、省、城市,年、季度、月等。有层级关系的维度也可以大大减少cuboid的个数。如下图:
    hierarchy dimension
    这里仅仅局限于A/B/C是一个层级,例如A是年份,B是季度、C是月份,那么查询的时候可能的组合只有年、xx年的季度、xx年xx季度的xx月,这就意味着我们不能再单独的对季度和月份进行聚合了,例如我们查询的时候不能使用group by month,而必须使用group by year,quart,month。如果需要单独的对month进行聚合,那么还需要再使用month列定义一个单独的普通维度。
    3、derived维度
         这类维度的意思是可推导的维度,需要该维度对应的一个或者多个列可以和维度表的主键是一对一的,这种维度可以大大减少cuboid个数,如下图:
    derived dimension
    例如timeid是时间这个维度表的主键,也就是事实表的外检,时间只精确到天,那么year、month、day三列可以唯一对应着一个time_id,而time_id是事实表的外键,那么我们可以指定year、month、day为一个derived维度,实际存储的时候可以只根据timeid的取值决定维度的组合,但这就要求我们在查询的时候使用的group by必须指定derived维度集合中的所有列。
         最后,简单介绍一下如何计算cuboid个数的,假设我们存在两个普通维度brand、product,存在一个hierarchy,包含四个维度分别为year、quart、month和day,一个derived维度,指定location信息,包含country、province和city列,这相当于一共9个维度,但是根据上面的分析我们并不需要512分cuboid。
    第0层的cuboid(不包含任何维度,不包含group by),cuboid的个数为1,这个cuboid的成员个数也为1;
    第1层的cuboid包含一个维度,一共有4种组合(分别为brand、product、year、location,因为quart是hierarchy的第二个层级,不能单独group by,而location的三列可以视为一个整体),成员个数则有每一个维度的cardinality;
    第2层的cuboid有7种,分别为{brand、product}、{brand、year}、{brand、location}、{product、year}、{product、location}、{year、location}和{year、quart};
    第3层的cuboid有8种,分别为{brand、product、year}、{brand、product、location}、{product、year、location}、{brand、year、location}、{brand、year、quart}、{product、year、quart}、{location、year、quart}、{year、quart、month};
    第4层的cuboid有8种,分别为{brand、product、year、location}、{brand、product、year、quart}、{brand、location、year、quart}、{product、location、year、quart}、{brand、year、quart、month}、{product、year、quart、month}、{location、year、quart、month}、{year、quart、month、day}
    第5层的cuboid有7种,分别为{brand、product、year、quart、location}、{brand、product、year、quart、momth}、{brand、location、year、quart、month}、{product、location、year、quart、month}、{brand、year、quart、month、day}、{product、year、quart、month、day}、{location、year、quart、month、day}
    第6层的cuboid有5种,分别为{brand、product、year、quart、month、location}、{brand、product、year、quart、momth、day}、{brand、location、year、quart、month、day}、{product、location、year、quart、month、day}
    第7层的cuboid有1中,为{brand、product、year、quart、month、day、location}
    所以一共40个cuboid(kylin计算的是39个,应该没有把第0层的计算在内)。
     
    增量cube
         由于kylin的核心在于预计算缓存数据,那么对于实时的数据查询的支持就不如mondrian好了,但是一般情况下我们数据分析并没有完全实时的要求,数据延迟几个小时甚至一天是可以接受的,kylin提供了增量cube的接口,kylin的实现是一个cube(这里是指逻辑上的cube)中可以包含多个segment,每一个segment对应着一个物理cube,在实际存储上对应着一个hbase的一个表,用户定义根据某一个字段进行增量(目前仅支持时间,并且这个字段必须是hive的一个分区字段),在使用的时候首先需要定义好cube的定义,可以指定一个时间的partition字段作为增量cube的依赖字段,其实这个选择是作为原始数据选择的条件,例如选择起始时间A到B的数据那么创建的cube则会只包含这个时间段的数据聚合值,创建完一个cube之后可以再次基于以前的cube进行build,每次build会生成一个新的segment,只不过原始数据不一样了(根据每次build指定的时间区间),每次查询的时候会查询所有的segment聚合之后的值进行返回,有点类似于tablet的存储方式,但是当segment存在过多的时候查询效率就会下降,因此需要在存在多个segment的时候将它们进行合并,合并的时候其实是指定了一个时间区间,内部会选择这个时间区间内的所有segment进行合并,合并完成之后使用新的segment替换被合并的多个segment,合并的执行时非常迅速的,数据不需要再从HDFS中获取,直接将两个hbase表中相同key的数据进行聚合就可以了。但是有一点需要注意的是当合并完成之后,被合并的几个segment所对应的hbase表并没有被删除。实际的使用过程中对于增量的cube可以写个定时任务每天凌晨进行build,当达到一个数目之后进行merge(其实每次build完成之后都进行merge也应该是可以的)。
     
    cube的词典树
         kylin的cube数据是作为key-value结构存储在hbase中的,key是每一个维度成员的组合值,不同的cuboid下面的key的结构是不一样的,例如cuboid={brand,product,year}下面的一个key可能是brand='Nike',product='shoe',year=2015,那么这个key就可以写成Nike:shoe:2015,但是如果使用这种方式的话会出现很多重复,所以一般情况下我们会把一个维度下的所有成员取出来,然后保存在一个数组里面,使用数组的下标组合成为一个key,这样可以大大节省key的存储空间,kylin也使用了相同的方法,只不过使用了字典树(Trie树),每一个维度的字典树作为cube的元数据以二进制的方式存储在hbase中,内存中也会一直保持一份。
     
    总结
         以上介绍了kylin的整体框架以及部分的模块的流程,由于之前主要是关注cube的一些操作,例如创建、构建、合并等,对于查询这一块了解的较少,当然,这一块是kylin的核心之一。接下来会从源代码的角度去看kylin是如何构建和mergecube的,以及执行查询的流程。
    展开全文
  • Kylin - 框架介绍

    万次阅读 2019-04-05 13:07:54
    1. Apache Kylin 是什么? Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的...

    1. Apache Kylin 是什么?

    Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表

    2. Apache Kylin框架介绍

    Apache kylin 能提供低延迟(sub-second latency)的秘诀就是预计算即针对一个星型拓扑结构的数据立方体,预计算多个维度组合的度量,然后将结果保存在hbase中,对外暴露JDBC、ODBC、Rest API的查询接口,即可实现实时查询

     

    Kylin 框架

    如上图所示,Kylin从Hadoop Hive中获取数据,然后经过Cube Build Engine,将Hive中的数据Build成一个OLAP Cube保存在HBase中。用户执行SQL查询时,通过Query引擎,将SQL语句解析成OLAP Cube查询,然后将结果返回给用户。

    3. Apache Kylin核心概念

    1.表(table):This is definition of hive tables as source of cubes,在build cube 之前,必须同步在 kylin中。
    2.模型(model):模型描述了一个星型模式的数据结构,它定义了一个事实表(Fact Table)和多个查找表(Lookup Table)的连接和过滤关系。
    3. Cube 描述:描述一个Cube实例的定义和配置选项,包括使用了哪个数据模型、包含哪些维度和度量、如何将数据进行分区、如何处理自动合并等等。
    4.Cube实例:通过Cube描述Build得到,包含一个或者多个Cube Segment。
    5.分区(Partition):用户可以在Cube描述中使用一个DATA/STRING的列作为分区的列,从而将一个Cube按照日期分割成多个segment。
    6.立方体段(cube segment):它是立方体构建(build)后的数据载体,一个 segment 映射hbase中的一张表,立方体实例构建(build)后,会产生一个新的segment,一旦某个已经构建的立方体的原始数据发生变化,只需刷新(fresh)变化的时间段所关联的segment即可。
    7.聚合组:每一个聚合组是一个维度的子集,在内部通过组合构建cuboid。
    8.作业(job):对立方体实例发出构建(build)请求后,会产生一个作业。该作业记录了立方体实例build时的每一步任务信息。作业的状态信息反映构建立方体实例的结果信息。如作业执行的状态信息为RUNNING 时,表明立方体实例正在被构建;若作业状态信息为FINISHED ,表明立方体实例构建成功;若作业状态信息为ERROR ,表明立方体实例构建失败!

    3.1 DIMENSION & MEASURE的种类

    • Mandotary:强制维度,所有cuboid必须包含的维度。
    • Hierarchy:层次关系维度,维度之间具有层次关系性,只需要保留一定层次关系的cuboid即可。
    • Derived:衍生维度,在lookup 表中,有一些维度可以通过它的主键衍生得到,所以这些维度将不参加cuboid的构建。
    • Count Distinct(HyperLogLog) :直接进行count distinct是很难去计算的,一个近似的算法HyperLogLog可以保持错误率在一个很低的范围内。
    • Count Distinct(Precise):将基于RoaringBitMap进行计算,目前只支持int和BigInt。

    3.2 Cube Action种类

    • BUILD:给定一个分区列指定的时间间隔,对Cube进行Build,创建一个新的cube Segment。
    • REFRESH:这个操作,将在一些分期周期内对cube Segment进行重新build。
    • MERGE:这个操作将合并多个cube segments。这个操作可以在构建cube时,设置为自动完成。
    • PURGE:清理一个Cube实例下的segment,但是不会删除HBase表中的Tables。

    3.3 Job状态

    *NEW:表示一个job已经被创建。
    *PENDING:表示一个job已经被job Scheduler提交,等待执行资源。
    *RUNNING:表示一个job正在运行。
    *FINISHED:表示一个job成功完成。
    *ERROR:表示一个job因为错误退出。
    *DISCARDED:表示一个job被用户取消。

    3.4 Job执行

    *RESUME:这个操作将从失败的Job的最后一个成功点继续执行该Job。
    *DISCARD:无论工作的状态,用户可以结束它和释放资源。

    4. Apache Kylin Cube 的构建过程

    4.1 Cube的物理模型

    Cube物理模型

     

    如上图所示,一个常用的3维立方体,包含:时间、地点、产品。假如data cell 中存放的是产量,则我们可以根据时间、地点、产品来确定产量,同时也可以根据时间、地点来确定所有产品的总产量等。
    Apache Kylin就将所有(时间、地点、产品)的各种组合实现算出来,data cell 中存放度量,其中每一种组合都称为cuboid。估n维的数据最多有2^n个cuboid,不过Kylin通过设定维度的种类,可以减少cuboid的数目。

    4.2 Cube构建算法介绍

    4.2.1 逐层算法(Layer Cubing)

    我们知道,一个N维的Cube,是由1个N维子立方体、N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体、......、N个1维子立方体和1个0维子立方体构成,总共有2^N个子立方体组成,在逐层算法中,按维度数逐层减少来计算,每个层级的计算(除了第一层,它是从原始数据聚合而来),是基于它上一层级的结果来计算的。
    比如,[Group by A, B]的结果,可以基于[Group by A, B, C]的结果,通过去掉C后聚合得来的;这样可以减少重复计算;当 0维度Cuboid计算出来的时候,整个Cube的计算也就完成了。

    逐层算法

    如上图所示,展示了一个4维的Cube构建过程。
    此算法的Mapper和Reducer都比较简单。Mapper以上一层Cuboid的结果(Key-Value对)作为输入。由于Key是由各维度值拼接在一起,从其中找出要聚合的维度,去掉它的值成新的Key,并对Value进行操作,然后把新Key和Value输出,进而Hadoop MapReduce对所有新Key进行排序、洗牌(shuffle)、再送到Reducer处;Reducer的输入会是一组有相同Key的Value集合,对这些Value做聚合计算,再结合Key输出就完成了一轮计算。
    每一轮的计算都是一个MapReduce任务,且串行执行; 一个N维的Cube,至少需要N次MapReduce Job。

    算法优点

    • 此算法充分利用了MapReduce的能力,处理了中间复杂的排序和洗牌工作,故而算法代码清晰简单,易于维护;
    • 受益于Hadoop的日趋成熟,此算法对集群要求低,运行稳定;在内部维护Kylin的过程中,很少遇到在这几步出错的情况;即便是在Hadoop集群比较繁忙的时候,任务也能完成。

    算法缺点

    • 当Cube有比较多维度的时候,所需要的MapReduce任务也相应增加;由于Hadoop的任务调度需要耗费额外资源,特别是集群较庞大的时候,反复递交任务造成的额外开销会相当可观;
    • 由于Mapper不做预聚合,此算法会对Hadoop MapReduce输出较多数据; 虽然已经使用了Combiner来减少从Mapper端到Reducer端的数据传输,所有数据依然需要通过Hadoop MapReduce来排序和组合才能被聚合,无形之中增加了集群的压力;
    • 对HDFS的读写操作较多:由于每一层计算的输出会用做下一层计算的输入,这些Key-Value需要写到HDFS上;当所有计算都完成后,Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式,以导入到HBase中去;
    • 总体而言,该算法的效率较低,尤其是当Cube维度数较大的时候;时常有用户问,是否能改进Cube算法,缩短时间。

    4.2.2 快速Cube算法(Fast Cubing)

    快速Cube算法(Fast Cubing)是麒麟团队对新算法的一个统称,它还被称作“逐段”(By Segment) 或“逐块”(By Split) 算法。

    该算法的主要思想是,对Mapper所分配的数据块,将它计算成一个完整的小Cube 段(包含所有Cuboid);每个Mapper将计算完的Cube段输出给Reducer做合并,生成大Cube,也就是最终结果;图2解释了此流程。

    快速Cube算法


    与旧算法相比,快速算法主要有两点不同

    • Mapper会利用内存做预聚合,算出所有组合;Mapper输出的每个Key都是不同的,这样会减少输出到Hadoop MapReduce的数据量,Combiner也不再需要;
    • 一轮MapReduce便会完成所有层次的计算,减少Hadoop任务的调配。

    子立方体生成树的遍历
    值得一提的还有一个改动,就是子立方体生成树(Cuboid Spanning Tree)的遍历次序;在旧算法中,Kylin按照层级,也就是广度优先遍历(Broad First Search)的次序计算出各个Cuboid;在快速Cube算法中,Mapper会按深度优先遍历(Depth First Search)来计算各个Cuboid。深度优先遍历是一个递归方法,将父Cuboid压栈以计算子Cuboid,直到没有子Cuboid需要计算时才出栈并输出给Hadoop;最多需要暂存N个Cuboid,N是Cube维度数。
    采用DFS,是为了兼顾CPU和内存:

    • 从父Cuboid计算子Cuboid,避免重复计算;
    • 只压栈当前计算的Cuboid的父Cuboid,减少内存占用。

       

      立方体生成数的遍历过程

    上图是一个四维Cube的完整生成树;按照DFS的次序,在0维Cuboid 输出前的计算次序是 ABCD -> BCD -> CD -> D -> , ABCD, BCD, CD和D需要被暂存;在被输出后,D可被输出,内存得到释放;在C被计算并输出后,CD就可以被输出; ABCD最后被输出。

    4.3 Cube构建流程

    Cube构建流程

    主要步骤如下:

    1. 构建一个中间平表(Hive Table):将Model中的fact表和look up表构建成一个大的Flat Hive Table。
    2. 重新分配Flat Hive Tables。
    3. 从事实表中抽取维度的Distinct值。
    4. 对所有维度表进行压缩编码,生成维度字典。
    5. 计算和统计所有的维度组合,并保存,其中,每一种维度组合,称为一个Cuboid。
    6. 创建HTable。
    7. 构建最基础的Cuboid数据。
    8. 利用算法构建N维到0维的Cuboid数据。
    9. 构建Cube。
    10. 将Cuboid数据转换成HFile。
    11. 将HFile直接加载到HBase Table中。
    12. 更新Cube信息。
    13. 清理Hive。

    5. Apache Kylin Cube 的存储

    简单的说Cuboid的维度会映射为HBase的Rowkey,Cuboid的指标会映射为HBase的Value。

    Cube映射成HBase存储

    如上图原始表所示:Hive表有两个维度列year和city,有一个指标列price。如上图预聚合表所示:我们具体要计算的是year和city这两个维度所有维度组合(即4个cuboid)下的sum(priece)指标,这个指标的具体计算过程就是由MapReduce完成的。
    如上图字典编码所示:为了节省存储资源,Kylin对维度值进行了字典编码。图中将beijing和shanghai依次编码为0和1。

    如上图HBase KV存储所示:在计算cuboid过程中,会将Hive表的数据转化为HBase的KV形式。Rowkey的具体格式是cuboid id + 具体的维度值(最新的Rowkey中为了并发查询还加入了ShardKey),以预聚合表内容的第2行为例,其维度组合是(year,city),所以cuboid id就是00000011,cuboid是8位,具体维度值是1994和shanghai,所以编码后的维度值对应上图的字典编码也是11,所以HBase的Rowkey就是0000001111,对应的HBase Value就是sum(priece)的具体值

    6. Apache Kylin 如何将SQL转换成HBase Scan查询

    还是以上面的例子进行解释,假
    设查询SQL如下:

    SQL 转换成 SCAN

    这个SQL涉及维度year和city,所以其对应的cuboid是00000011,又因为city的值是确定的beijing,所以在Scan HBase时就会Scan Rowkey以00000011开头且city的值是beijing的行,取到对应指标sum(price)的值,返回给用户。


    链接:https://www.jianshu.com/p/6eadb77d091c
     

    展开全文
  • OLAP引擎——Kylin介绍

    万次阅读 多人点赞 2015-08-30 12:01:41
    最近一直在学习和使用kylin,分享一下学习的收获以及对kylin的理解~
         Kylin是ebay开发的一套OLAP系统,与Mondrian不同的是,它是一个MOLAP系统,主要用于支持大数据生态圈的数据分析业务,它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中(目前还仅支持hbase),这段时间对mondrian和kylin都进行了使用,发现这两个系统是时间和空间的一个权衡吧,mondrian是一个ROLAP系统,所有的查询可以通过实时的数据库查询完成,而不会有任何的预计算,大大节约了存储空间的要求(但是会有查询结果的缓存,目前是缓存在程序内存中,很容易导致OOM),而kylin是一个MOLAP系统,通过预计算的方式缓存了所有需要查询的的数据结果,需要大量的存储空间(原数据量的10+倍)。一般我们要分析的数据可能存储在关系数据库(mysql、oracle,一般是程序内部写入的一些业务数据,可能存在分表甚至分库的需求)、HDFS上数据(结构化数据,一般是业务的日志信息,通过hive查询)、文本文件、excel等。kylin主要是对hive中的数据进行预计算,利用hadoop的mapreduce框架实现。而mondrian理论上可以支持任意的提供SQL接口数据,由于关系数据库一般会存在索引,所以即使使用mondrian去查询性能还是可以接受的,当前我们使用的oracle数据库,千万条级别的记录,查询可以在分钟级别完成,但是对于hive、
    这样的数据源查询就太慢了,慢得不可以接受。

    系统架构
         于是,我们开始尝试使用kylin,kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求,而对于关系数据库中的数据分析进行预计算可能有点不合适了(关系数据库一般存在索引使得即使数据量很大查询也不会慢的离谱,除非SQL写的很烂)。在使用kylin的过程中,也逐渐对kylin有了一定的认识,首先看一下kylin的系统架构:

    kylin系统架构
         kylin由以下几部分组成:
    · REST Server:提供一些restful接口,例如创建cube、构建cube、刷新cube、合并cube等cube的操作,project、table、cube等元数据管理、用户访问权限、系统配置动态修改等。除此之外还可以通过该接口实现SQL的查询,这些接口一方面可以通过第三方程序的调用,另一方也被kylin的web界面使用。
    · jdbc/odbc接口:kylin提供了jdbc的驱动,驱动的classname为org.apache.kylin.jdbc.Driver,使用的url的前缀jdbc:kylin:,使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。这类接口也使得kylin很好的兼容tebleau甚至mondrian。
    · Query引擎:kylin使用一个开源的Calcite框架实现SQL的解析,相当于SQL引擎层。
    · Routing:该模块负责将解析SQL生成的执行计划转换成cube缓存的查询,cube是通过预计算缓存在hbase中,这部分查询是可以再秒级甚至毫秒级完成,而还有一些操作使用过查询原始数据(存储在hadoop上通过hive上查询),这部分查询的延迟比较高。
    · Metadata:kylin中有大量的元数据信息,包括cube的定义,星状模型的定义、job的信息、job的输出信息、维度的directory信息等等,元数据和cube都存储在hbase中,存储的格式是json字符串,除此之外,还可以选择将元数据存储在本地文件系统。
    · Cube构建引擎:这个模块是所有模块的基础,它负责预计算创建cube,创建的过程是通过hive读取原始数据然后通过一些mapreduce计算生成Htable然后load到hbase中。

    关键流程
         在kylin中,最关键的两个流程是cube的预计算过程和SQL查询转换成cube的过程,cube的构造可以分成cube的构建和cube的合并,首先需要创建一个cube的定义,包括设置cube名、cube的星状模型结构,dimension信息、measure信息、设置where条件、根据hive中事实表定义的partition设置增量cube,设置rowkey等信息,这些设置在mondrian中也是可以看到的,一个cube包含一些dimension和measure,where条件决定了源数据的大小,在mondrian中可以通过view实现。另外,kylin还提供了增量计算的功能,虽然达不到实时计算的需求,但是基本上可以满足数据分析的需求。
         查询解析过程主要是使用Calcite框架将用户输入的SQL解析并转换成对hbase的key-value查询操作以获取结果,但是经过使用发现它对SQL的支持是比较差的,所有的SQL不能使用from A,B where xxx之类的join方式,必须使用inner(left、right) join on的方式,否则解析就会出错,这就会导致mondrian生成的SQL压根不能使用kylin查询(因为mondrian生成的SQL是前面一种方式的),另外还有一个局限性就是发现只能对cube相关的表和列进行查询,例如根据维度进行group by查询定义的度量信息,而其他的查询也统统的返回错误,这点倒也不算是很大的问题,毕竟cube的模型已经定义,我们不太可能查询这个模型以外的东西。还有一点有点不能接受的是kylin对于子查询的支持很弱,测试发现查询的结果经常返回空(没有一行),而相同的查询在hive中是有结果的,这对于一些产品方需求支持不是很好,例如产品方可能需要查询年销售额大于xx的地区的每个月的销售总额。我们一般情况下会写出这样的sql:select month, sum(sales) from fact where location in (select location from fact group by year having sum(sales) > 1000) group by month;前一段时间测试发现这种SQL对于关系数据库简直是灾难,因为in语句会导致后面的子查询没有缓存结果,而写成select month, sum(sales) from fact  as A inner join (select location from fact group by year having sum(sales) > 1000) as B on A.location = B.location group by month;可以提高性能,但是测试发现kylin返回的结果为空,而kylin对于in语句的查询时非常高效的(毕竟全部走缓存),那么我们就不得不首先执行子查询得到location集合,然后再写一个SQL使用where location in xxx(kylin对于使用in子句的查询支持还是相当棒的)的方式获得结果,这个应该是需要改进的地方吧。

    cube模型
         前面介绍了cube在创建过程中需要的设置,这里看一些每一个设置的具体含义吧,首先我们会设置cube名和notification列表,前者需要保证是全局唯一的,后者是一些Email用于通知cube的一些事件的发生。接着我们需要定义一个星状模型,和一般的数据仓库模型一样,需要指定一个事实表和任意多个维度表,如果存在维度表还需要指定事实表和维度表的关联关系,也就是join方式。接下来是定义dimension,在定义dimension的时候可以选择dimension的类型,分为Normal、Hierachy以及Derived,这个后面再进行介绍,dimension的定义决定着cube的大小,也需要用户对原始的表非常了解。
         接下来是定义measure,kylin会为每一个cube创建一个聚合函数为count(1)的度量,它不需要关联任何列,用户自定义的度量可以选择SUM、COUNT、DISTINCT COUNT、MIN、MAX,而每一个度量定义时还可以选择这些聚合函数的参数,可以选择常量或者事实表的某一列,一般情况下我们当然选择某一列。这里我们发现kylin并不提供AVG等相对较复杂的聚合函数(方差、平均差更没有了),主要是因为它需要基于缓存的cube做增量计算并且合并成新的cube,而这些复杂的聚合函数并不能简单的对两个值计算之后得到新的值,例如需要增量合并的两个cube中某一个key对应的sum值分别为A和B,那么合并之后的则为A+B,而如果此时的聚合函数是AVG,那么我们必须知道这个key的count和sum之后才能做聚合。这就要求使用者必须自己想办法自己计算了。
         定义完measure之后需要设置where条件,这一步是对原始数据进行过滤,例如我们设定销售额小于XXX的地区不在于本次分析范围之内,那么就可以在where条件里设定location in xxx(子查询),那么生成的cube会过滤掉这些location,这一步其实相当于对无效数据的清洗,但是在kylin中这个是会固化的,不容易改变,例如我今天希望将销售额小于XX的地区清洗掉,明天可能有想将年消费小于xxx的用户去除,这就需要每次都创建一个相同的cube,区别仅仅在于where条件,他们之间会有很多的重复缓存数据,也会导致存储空间的浪费,但这也是MOLAP系统不可避免的,因此当过滤条件变化比较多的时候,更好的方案则是创建一个完整的cube(不设置任何where条件),使用子查询的方式过滤掉不希望要的一些维度成员。
         接下来的一步是设置增量cube信息,首先需要选择事实表中的某一个时间类型的分区列(貌似只能是按照天进行分区),然后再指定本次构建的cube的时间范围(起始时间点和结束时间点),这一步的结果会作为原始数据查询的where条件,保证本次构建的cube只包含这个闭区间时间内的数据,如果事实表没有时间类型的分区别或者没有选择任何分区则表示数据不会动态更新,也就不可以增量的创建cube了。
         最后一步设置rowkey,这一步的建议是看看就可以了,不要进行修改,除非对kylin内部实现有比较深的理解才能知道怎么去修改。当然这里有一个可以修改的是mandatory dimension,如果一个维度需要在每次查询的时候都出现,那么可以设置这个dimension为mandatory,可以省去很多存储空间,另外还可以对所有维度进行划分group,不会组合查询的dimension可以划分在不同的group中,这样也会降低存储空间。


    Dimension介绍
         在一个多维数据集合中,维度的个数决定着维度之间可能的组合数,而每一个维度中成员集合的大小决定着每一个可能的组合的个数,例如有三个普通的维度A、B、C,他们的不同成员数分别为10/100/1000,那么一个维度的组合有2的3次方个,分别是{空、A、B、C、AB、BC、AC、ABC},每一个成员我们称为cuboid(维度的组合),而这些集合的成员组合个数分别为1、10、100、1000、10*100、100*1000、10*1000和10*100*1000。我们称每一个dimension中不同成员个数为cardinatily,我们要尽量避免存储cardinatily比较高的维度的组合,在上面的例子中我们可以不缓存BC和C这两个cuboid,可以通过计算的方式通过ABC中成员的值计算出BC或者C中某个成员组合的值,这相当于是时间和空间的一个权衡吧。
         在kylin中存在的四种维度是为了减少cuboid的个数,而不是每一个维度是否缓存的,当前kylin是对所有的cuboid中的所有组合都进行计算和存储的,对于普通的dimension,从上面的例子中可以看出N个维度的cuboid个数为2的N次方,而kylin中设置了一些维度可以减少cuboid个数,当然,这需要使用者对自己需要的维度十分了解,知道自己可能根据什么进行group by。
         好了,我们先来看一下kylin中的三种特殊的dimension以及它们的作用,这里参考:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin
    1、Mandatory维度
         这种维度意味着每次查询的group by中都会携带的,将某一个dimension设置为mandatory可以将cuboid的个数减少一半,如下图:
    mandatory dimension
    这是因为我们确定每一次group by都会携带A,那么就可以省去所有不包含A这个维度的cuboid了。
    2、hierarchy维度
         这种维度是最常见的,尤其是在mondrian中,我们对于多维数据的操作经常会有上卷下钻之类的操作,这也就需要要求维度之间有层级关系,例如国家、省、城市,年、季度、月等。有层级关系的维度也可以大大减少cuboid的个数。如下图:
    hierarchy dimension
    这里仅仅局限于A/B/C是一个层级,例如A是年份,B是季度、C是月份,那么查询的时候可能的组合只有年、xx年的季度、xx年xx季度的xx月,这就意味着我们不能再单独的对季度和月份进行聚合了,例如我们查询的时候不能使用group by month,而必须使用group by year,quart,month。如果需要单独的对month进行聚合,那么还需要再使用month列定义一个单独的普通维度。
    3、derived维度
         这类维度的意思是可推导的维度,需要该维度对应的一个或者多个列可以和维度表的主键是一对一的,这种维度可以大大减少cuboid个数,如下图:
    derived dimension
    例如timeid是时间这个维度表的主键,也就是事实表的外检,时间只精确到天,那么year、month、day三列可以唯一对应着一个time_id,而time_id是事实表的外键,那么我们可以指定year、month、day为一个derived维度,实际存储的时候可以只根据timeid的取值决定维度的组合,但这就要求我们在查询的时候使用的group by必须指定derived维度集合中的所有列。
         最后,简单介绍一下如何计算cuboid个数的,假设我们存在两个普通维度brand、product,存在一个hierarchy,包含四个维度分别为year、quart、month和day,一个derived维度,指定location信息,包含country、province和city列,这相当于一共9个维度,但是根据上面的分析我们并不需要512分cuboid。
    第0层的cuboid(不包含任何维度,不包含group by),cuboid的个数为1,这个cuboid的成员个数也为1;
    第1层的cuboid包含一个维度,一共有4种组合(分别为brand、product、year、location,因为quart是hierarchy的第二个层级,不能单独group by,而location的三列可以视为一个整体),成员个数则有每一个维度的cardinality;
    第2层的cuboid有7种,分别为{brand、product}、{brand、year}、{brand、location}、{product、year}、{product、location}、{year、location}和{year、quart};
    第3层的cuboid有8种,分别为{brand、product、year}、{brand、product、location}、{product、year、location}、{brand、year、location}、{brand、year、quart}、{product、year、quart}、{location、year、quart}、{year、quart、month};
    第4层的cuboid有8种,分别为{brand、product、year、location}、{brand、product、year、quart}、{brand、location、year、quart}、{product、location、year、quart}、{brand、year、quart、month}、{product、year、quart、month}、{location、year、quart、month}、{year、quart、month、day}
    第5层的cuboid有7种,分别为{brand、product、year、quart、location}、{brand、product、year、quart、momth}、{brand、location、year、quart、month}、{product、location、year、quart、month}、{brand、year、quart、month、day}、{product、year、quart、month、day}、{location、year、quart、month、day}
    第6层的cuboid有5种,分别为{brand、product、year、quart、month、location}、{brand、product、year、quart、momth、day}、{brand、location、year、quart、month、day}、{product、location、year、quart、month、day}
    第7层的cuboid有1中,为{brand、product、year、quart、month、day、location}
    所以一共40个cuboid(kylin计算的是39个,应该没有把第0层的计算在内)。

    增量cube
         由于kylin的核心在于预计算缓存数据,那么对于实时的数据查询的支持就不如mondrian好了,但是一般情况下我们数据分析并没有完全实时的要求,数据延迟几个小时甚至一天是可以接受的,kylin提供了增量cube的接口,kylin的实现是一个cube(这里是指逻辑上的cube)中可以包含多个segment,每一个segment对应着一个物理cube,在实际存储上对应着一个hbase的一个表,用户定义根据某一个字段进行增量(目前仅支持时间,并且这个字段必须是hive的一个分区字段),在使用的时候首先需要定义好cube的定义,可以指定一个时间的partition字段作为增量cube的依赖字段,其实这个选择是作为原始数据选择的条件,例如选择起始时间A到B的数据那么创建的cube则会只包含这个时间段的数据聚合值,创建完一个cube之后可以再次基于以前的cube进行build,每次build会生成一个新的segment,只不过原始数据不一样了(根据每次build指定的时间区间),每次查询的时候会查询所有的segment聚合之后的值进行返回,有点类似于tablet的存储方式,但是当segment存在过多的时候查询效率就会下降,因此需要在存在多个segment的时候将它们进行合并,合并的时候其实是指定了一个时间区间,内部会选择这个时间区间内的所有segment进行合并,合并完成之后使用新的segment替换被合并的多个segment,合并的执行时非常迅速的,数据不需要再从HDFS中获取,直接将两个hbase表中相同key的数据进行聚合就可以了。但是有一点需要注意的是当合并完成之后,被合并的几个segment所对应的hbase表并没有被删除。实际的使用过程中对于增量的cube可以写个定时任务每天凌晨进行build,当达到一个数目之后进行merge(其实每次build完成之后都进行merge也应该是可以的)。

    cube的词典树
         kylin的cube数据是作为key-value结构存储在hbase中的,key是每一个维度成员的组合值,不同的cuboid下面的key的结构是不一样的,例如cuboid={brand,product,year}下面的一个key可能是brand='Nike',product='shoe',year=2015,那么这个key就可以写成Nike:shoe:2015,但是如果使用这种方式的话会出现很多重复,所以一般情况下我们会把一个维度下的所有成员取出来,然后保存在一个数组里面,使用数组的下标组合成为一个key,这样可以大大节省key的存储空间,kylin也使用了相同的方法,只不过使用了字典树(Trie树),每一个维度的字典树作为cube的元数据以二进制的方式存储在hbase中,内存中也会一直保持一份。

    总结
         以上介绍了kylin的整体框架以及部分的模块的流程,由于之前主要是关注cube的一些操作,例如创建、构建、合并等,对于查询这一块了解的较少,当然,这一块是kylin的核心之一。接下来会从源代码的角度去看kylin是如何构建和mergecube的,以及执行查询的流程。


    展开全文
  • Kylin系列(一)—— 入门

    千次阅读 2018-09-06 17:11:49
    Kylin 入门到进阶 Kylin kylin构造算法 kylin构造过程 kylin维度优化 Kylin 入门到进阶 前言 核心概念 数据仓库 传统数仓和大数据数仓的区别 OLAP和OLTP 维度和度量 维度的基数 事实表和维度表 星型模型 ...

    总目录

    Kylin系列(一)—— 入门
    Kylin系列(二)—— Cube 构造算法


    因为平常只会使用kylin而不知其原理,故写下此篇文章。文章不是自己原创,是看过很多资料,查过很多博客,有自己的理解,觉得精华的部分的一个集合。算是自己对Kylin学习完的一个总结和概括吧。文章最后有链接,需要请自取。

    前言

    企业中的查询大致可分为即席查询和定制查询两种。很多的OLAP引擎包括Hive、Presto、SparkSQL,虽然很大成都上能降低数据分析的难度,但是他们都只适用于即席查询的场景。但是随着数据量和计算复杂度的增长,响应时间是无法保证的,这其实和业务需要是相违背的,数据分析师以及业务部门人员需要的对数据实时的反馈,才能更好对业务产生指导。

    Kylin的产生就是为了解决如何对海量数据进行OLAP查询

    Kylin是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力,也可以说Kylin就是基于Hadoop平台。

    Kylin构建在Hadoop等分布式计算平台之上,充分利用了MapReduce的并行处理能力和可扩展基础设施,高效处理超大数据规模(其实kylin的中的cuboid都是基于MapReduce任务的),可根据数据的规模实现架构的可伸缩。

    过程:
    - 数据源(Hive、Kafla)
    - 计算:构建多维立方体用MapRedue
    - 存储:Hbase
    - SQL查询解析: kylin SQL解析器

    Kylin采用预计算的模式,用户只需提前定义好查询维度,Kylin将会帮助我们进行计算,并将结果存储到HBase中,为海量数据的查询和分析提供亚秒级返回,是空间换时间的解决方案。

    其实就是用穷举的办法把所有可能涉及到的维度的组合数都算一遍。利用sql解析,利用Hbase的性能,从算好的结果中提取数据。

    提一下,Apache Kylin是第一个由中国人主导的Apache顶级项目。

    核心概念

    数据仓库

    Data Warehouse 简称DW,即数据仓库,是BI中的核心部分。主要是将不同数据源的数据整合到一起,通过多维分析等方式为企业提供决策支持和报表生成。

    数据仓库和传统型数据仓库的用途是不同的。传统型数据仓库面向事务,而DW面向分析。传统型数据库更多的是对业务作出实时反应,涉及增删改查,所以需要遵循三大范式,需要ACID。而数据仓库中的数据多为历史数据,主要目的是为企业决策提供支持,所以可能存在大量数据冗余,但利于多个维度查询,为决策者提供更多观察角度。

    传统BI中,数据仓库的数据会存储在Mysql、Sql Sever等数据库,而大数据领域常用的是Hive。Hive也是Kylin的默认数据源。

    传统数仓和大数据数仓的区别

    那么这里顺带提一句传统型数据仓库和大数据数据仓库之间的区别。为什么一定要是使用大数据数据仓库。

    这里有几点理由:
    1.数据源多样化
    原来的数据源可能更多来自于交易数据,但是可能有:行为数据、财务数据等。
    2.数据量暴涨
    原来的数据源可能较单一,但是数据源多样化后,数据量暴涨,单机的运算无法满足。比如处理行为日志数据的需求,是没办法处理的。使用Hive后,可利用分布式和分区特效加快效率。
    3.数据类型
    传统数仓只能解决结构化的数据的问题,而无法解决非结构化数据。而大数据数仓可以通过Hbase接受非结构化数据,利用hive外部表来读取数据。
    4.服务对象
    传统数仓可能更多针对于高管、运营、财务人员,大数据数仓不仅用于上述人群,而且可以为各个系统提供接口数据,例如推荐系统、内部风控系统等等。
    5.处理速度快
    大数据数仓采用分布式架构,利用分布式计算效率远高于传统数仓,且可按需进行动态扩展,无需担心性能问题。

    OLAP和OLTP

    OLAP(online analytical process)联机事物处理,是以多维度分析,提供决策支持,多应用于数仓。OLTP(online transcation process),联机事物处理,多用于传统数据库,如mysql\Oracle\sql Sever等,专注于对业务系统的反馈进行对单行数据的增删改查。

    维度和度量

    维度指的是观察数据的角度,如对于一张订单表来说,维度有订单生成时间、地区、产品类别、产品等等。

    维度一般是一个离散的值,比如时间维度上的每一个独立日期,地区上每一个地点,因此统计时可以将相同维度的记录聚合在一起,进行聚合计算。

    度量就是被聚合的统计值,也就是运算的结果,如对于一张订单,他的销售量和销售金额是两种度量,是需要统计聚合的值。

    维度的基数

    指的是该维度在数据集中出现的不同值的个数。

    例如一个国家是一个维度,如果有200个不同的值,那么此维度的基数是200。

    通常一个维度的基数会从几十到几万个不等,个别维度如“用户ID”的基数会超过百万甚至千万。

    基数超过1百万的维度通常被称为超高基数维度。

    Cube中所有维度的基数决定了Cube的复杂度,如果有好几个超高基数的维度,那么Cube膨胀的概率就会很高。

    事实表和维度表

    事实表(factTable)指的是存储有事实记录的表,包含了每个时间的具体要素,以及具体发生的事情如系统记录、销售记录以及库存记录等等。

    事实表的体积是远大于其他表的。

    维度表(DimensionTable)是对事实表中事件要素的描述信息。

    它保存了维度属性值,可以跟事实表关联:相当于把事实表上经常重复出现的属性抽取、规范出来用作一张表。

    常见的维度表:日期表(日期对应的周月季度等属性)、地点表(包含国家、省州、城市)。

    维度表的好处:
    - 缩小了事实表的大小
    - 便于维度的管理和维护,对维度表的修改不必对事实表进行大量的改动。
    - 维度表可以为多个事实表重用。

    提一句,再Kylin种采用的是星型模型,即维度表全部和事实表直接关联。

    星型模型

    星型模型是数据挖掘种常用的几种多维度数据模型之一。他的特点是只有一张事实表,以及零到多个维度表,事实表和维度表通过主表外键相关联,维度表之间没有关联。

    (注意在kylin中,维度表的主键是唯一的,并且事实表中,除了join的关联字段,不允许和维度表中的字段相同,并且维度表和维表之间字段也不能相同。并且事实表和维度表join关联的字段类型必须相同。这在构建cube的时候是经常会遇到错误。)

    Kylin中维度表的设计

    Kylin对于维度表来说是有一定要求的。

    要具有数据一致性,主键值必须是唯一的。即与维度表相关联的列在维度表中一定是唯一的,否则会报错。这在后续的kylin报错解析会有所提及。

    维度表越小越好,因为Kylin会将维度表加载到内存中供以查询;默认阈值为300MB.

    改变频率低,Kylin在每次构建中试图重用维度表的快照,若经常改变,重用会失效,这就导致会经常性的对维度表创建快找。

    维度表不要是hive视图,因为视图其实是一个逻辑结构,并不实际存在,每次使用都需要进行一个物化,从而导致额外时间的开销。

    Cube和Cuboid

    了解维度和度量,就可以将数据模型上的所有字段进行分类:他们要么是维度,要么是度量,没有第三种字段。根据定义的维度和度量就可以构建cube了。

    对于一个给定的数据模型,我们可以对其上所有的维度进行组合,对于N个维度来说,组合的可能性共有2的N次方种。即一个N维的cube,是由1个N维子立方体,N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体… N个1维子立方体和1个0维子立方体构成。其实就是排列组合。

    对于每一种维度的组合,将度量做聚合运算,然后将运算的结果保存为一个物化视图,称为cuboid。所有维度组合的cuboid作为一个整体,被称为Cube.

    举个例子,假设有维度A、B、C,那么2的2的3次方,即8种。

    0维度0D:一种
    一维度1D:[A][B][C]
    二维度2D:[AB][AC][BC]
    三维度3D:[ABC]

    SQL表达计算Cuboid[A,B]

    select A,B,Sum(amount) from table1
    group by A,B

    将计算结果保存为物化视图,所有cuboid物化视图的总称就是Cube.

    Kylin的技术架构

    Apache Kylin系统主要可以分为在线查询和离线构建两部分,具体架构图如下:
    此处输入图片的描述

    首先来看离线构建部分。从图中可以看出,左侧位数据源,目前kylin默认的数据源是Hive,保存着待分析的用户数据。根据元数据的定义,构建引擎从数据源抽取数据,并构建Cube.数据以关系表的形式输入,并且符合星形模型。构建技术主要为MapReduce。构建后的Cube保存在右侧存储引擎中,目前Kylin默认的存储引擎是HBase。

    完成离线构建后,用户可以从上方的查询系统发送SQL进行查询分析。Kylin提供了RESTful API、JDBC/ODBC接口供用户调用。无论从哪个接口进入,SQL最终都会来到REST服务层,再转交给查询引擎进行处理。查询引擎解析SQL,生成基于关系表的逻辑执行计划,然后将其转译为基于Cube的物理执行计划,最后查询预计算生成的Cube并产生结果。整个过程不会访问原始数据源。如果用户提交的查询语句未在Kylin中预先定义,Kylin会返回一个错误。

    值得一提的是,Kylin对数据源、执行引擎和Cube存储三个核心模块提取出了抽象层,这意味着这三个模块可以被任意地扩展和替换。

    Kylin的核心模块

    REST Server

    REST Server是一套面向应用程序开发的入口点。此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及用户权限等等。另外可以通过Restful借口实现SQL查询。

    查询引擎(Query Engine)

    当cube准备就绪后,查询引擎能够获取并解析用户查询。他随后会与系统中的其他组件进行交互,从而向用户返回对应的结果。

    Routing

    负责将解析SQL生成的执行计划转换成cube缓存查询,cube是通过预计算缓存在hbase中。

    元数据管理工具

    Kylin是一款元数据驱动型应用程序。元数据管理工具十一大关键性组件,用于对保存在Kylin当中的所有元数据进行管理,其中包括最为重要的cube元数据。其他全部组件的正常运作都需以元数据管理工具为基础。Kylin的元数据存储在Hbase中。

    任务引擎(Cube Build Engine)

    这套引擎的设计目的在于处理所有离线任务,其中包括shell脚本、Java API以及MapReduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调,从而确保每一项任务都能得到切实执行并解决其间出现的故障。

    Kylin Cube三种构造

    我们来谈谈Cube构建。Kylin的Cube构建分为三种:全量构建、增量构建、流式构建。最简单的是全量构建,就是每次构建都Hive表进行全表构建。但是全量构建在实际环境中并不常用,因为大多数业务场景虾,事实数据都在不断地增长中,所以最常用的构建方式其实是增量构建。

    这里提出一个全量构建的例子。比如链家的相关数据必须使用全量构建,如成交业绩相关,因为一单成交时间有2个月之久,可能存在中间关于某单的修改,那么业绩也随之修改。故只能采用全量构建,dm表为全量整年的业绩。但是维度控制在较少范围,故压力不大。总体来说,这是通过控制DM表来控制实现的,且在kylin中只保留一个最新的segment。

    增量构建可以使Cube每次只构建Hive表中新增部分的数据,而不是全部数据,因此大大降低了构建成本。Kylin将Cube分为多个Segment,每个Segment用起始时间和结束时间来标识。

    增量构建与全量构建的不同之处:

    1. 创建model时需要指定Partition Date Column,用日期字段来对Cube进行分割。

    增量构建
    2. 创建Cube时需要指定Partition Start Date,即Cube默认的第一个Segment的起始时间。
    可看文章
    Kylin Cube Creation
    Kylin Cube Build and Job Monitoring

    增量构建的方式解决了业务数据动态增长的问题。但是却不能满足分钟级近实时返回结果的需求,因为增量构建他们使用的时Hive作为数据源,Hive中的数据由ETL定时导入(如每天一次)。数据的时效性对于数据价值的重要性不言而喻。Kylin给出了流式构建方案。

    流式构建使用Kafka作为数据源,构建引擎定时从Kafka中拉去数据进行构建。这一个设计与Spark Streaming的微批次思想非常像。需要注意流式构建在1.6版本后存在。

    Kylin提供:
    - Cube构建可以在Web UI界面和RESTful API
    - 数据查询可以在Web UI界面和RESTful API和JDBC/ODBC接口

    用户可以根据自身情况选择合适的构建和查询方式。

    博客参考

    kylin的基本介绍
    http://cxy7.com/articles/2018/06/09/1528544157772.html
    https://www.jianshu.com/p/abd5e90ab051
    http://www.liuhaihua.cn/archives/451581.html

    传统数仓和大数据平台的区别

    https://blog.csdn.net/Gospelanswer/article/details/78208761
    https://support.huaweicloud.com/dws_faq/dws_03_0005.html

    Inmon Kimball 数据仓库架构之争
    https://blog.csdn.net/paicMis/article/details/53236869
    https://blog.csdn.net/yanshu2012/article/details/55254300

    OLTP与OLAP的介绍
    https://www.cnblogs.com/hhandbibi/p/7118740.html

    展开全文
  • kylin介绍

    2018-12-21 19:14:27
    最近在公司实习的时候,由于在数据处理的时候有用到kylin,第一次接触,没有多少感觉,主要是不知道它具体能做什么,用到的时候就去对照别人构建好的model和cube构建自己的model和cube,导致自己的使用的过程中,爬...
  • Kylin作用是什么?

    2020-03-23 22:27:18
    题记:想了解Kylin、首先需要了解一下什么是OLAP、OLTP 一、OLAP:( OnLine Analytical Processing ) 一般查询延迟在秒级或者毫秒级,可以实现交互式查询、OLAP的查询一般需要Scan大量数据,大多时候只访问部分列...
  •  这里的kylin是 OLAP的范畴,是ebay上海研发团队研发的一个多维存储的产品,目的是为了  解决hbase紧依靠rowkey来快速查询的局限, 其核心是 空间换时间, 不是国产linux的kylin操作系统   1 说明:   1 ...
  • Kylin大数据分析

    千次阅读 2019-04-20 20:16:40
    Apache Kylin(Extreme OLAP Engine for Big Data)是一个开源的分布式分析引擎,为Hadoop等大型分布式数据平台之上的超大规模数据集通过标准SQL查询及多维分析(OLAP)功能,提供亚秒级的交互式分析能力。...
  • 第一个“国产“Apache顶级项目——Kylin,了解一下!

    万次阅读 多人点赞 2020-05-13 22:47:05
    写在前面: 博主是一名大数据初学者,昵称来源于《爱丽丝梦游仙境》中的Alice和自己的昵称。作为一名互联网小白,写博客一方面是为了记录自己的学习历程,一方面是希望能够帮助到很多和自己一样处于起步阶段的萌新。...
  • Kylin 大数据时代的OLAP利器

    千次阅读 2018-11-19 10:24:32
    Olap简介 OLAP的历史与基本概念 Olap全称为在线联机分析应用,是一种对于多维数据分析查询的解决方案。 典型的Olap应用场景包括销售、市场、管理等商务报表,预算决算,经济报表等等。 最早的Olap查询工具是发布...
  • kylin大数据多维分析

    2018-06-04 01:16:47
    Apache Kylin,中文名麒(shen)麟(shou) 是Hadoop动物园的重要成员。 Apache Kylin是一个开源的分布式分析引擎,最初由eBay开发贡献至开源社区。 简而言之,Kylin的核心思想是计算在多维分析中可能使用的测量值的...
  • Kylin大数据实战学习教程 大数据高级架构师,多年大数据项目架构及研发经验...
  • 如今的小米不仅是一家手机公司,更是一家大数据与人工智能公司。随着小米公司各项业务的快速发展,数据中的商业价值也愈发突显。而与此同时,各业务团队在数据查询、分析等方面的压力...
  • 作者 | 小米大数据   如今的小米不仅是一家手机公司,更是一家大数据与人工智能公司。随着小米公司各项业务的快速发展,数据中的商业价值也愈发突显。而与此同时,各业务团队在数据查询、分析等方面的压力同样...
  • Apache Kylin大数据OLAP利器.pdf;Apache Kylin大数据OLAP利器.pdf
  • 基于kylin大数据多维分析功能整合

    千次阅读 2016-12-21 13:51:17
    大数据OLAP目前主要有ROLAP和MOLAP。目前我们已采用的ROLAP方式组建数据平台,提供了更大的操作灵活性,同时在海量数据的情况下分析计算缓慢。MOLAP 能降低分析和数据库的耦合性,提高处理效率和改善分工,但降低...
  • kylin基本的安装和使用
  • kylin大数据实战学习教程。cube构建,安装文档,资料,还有视频,基础篇,进阶篇,高级篇,实战详解。
  • 第十三,十四章目录 第十三章 Azkaban 一个批量工作流任务调度器 13.1 Oozie和Azkaban的区别 工作流配置上:azkaban使用properties或yml,oozie使用xml工作流传参上:azkaban直接传参,oozie还额外支持EL表达式...
  • 内容简介: ApacheKylin是一个 开源的分布式分析引擎,...本书分为21章,详细讲解APpache Kylin概念安装、配置、部署,让读者对Apache Kylin 构建大数据分析平台有一一个感性认识。同时,本书从应用角度,结合Dome和...
  • 本文从架构原理篇开始揭开Apache Kylin 分析引擎的神秘面纱,后续将对任务调度、构建引擎、存储引擎、查询引擎、性能调优、运维管理做深入的分析。
  • 大数据OLAP Kylin

    2018-09-05 15:32:55
    在传统的关系型数据库中通过预计算预缓存来实现OLAP分析查询并不新鲜, 微软的SSAS就是典型的...现在大数据炙手可热, 通过预计算预缓存的手段来提高大数据的OLAP能力变得自然而然. 于是Kylin应运而生. Kylin的默...
  • 各种大数据框架近几年发展得如火如荼,比如Hadoop, MapReduce,Hive, Hbase, Storm, Spark, Flink, Kylin 等,各个框架的角色是怎么样的?如何配合起来使用?本文将从时间顺序上逐个说明。 首先要介绍一下Hadoop,...
  • 第1章 大数据Kylin之概述

    千次阅读 2020-01-30 12:39:37
    Kylin概述 1.1、 Kylin定义 Apache Kylin是一个开源的分布式分析引擎,提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP) 能力以支持超大规模数据,最初由eBay开发并贡献至开源社区。它能在亚秒内查询巨大的Hive...
  • 大数据技术是以数据流为核心的多个技术组成的技术栈,Mars将和大家一起持续学习,持续交流,持续更新~
  • 感谢关注天善智能,走好数据之路↑↑↑欢迎关注天善智能,我们是专注于商业智能BI,大数据,数据分析领域的垂直社区,学习,问答、求职一站式搞定!天善智能社区地址:https://www.hellobi.com/课程地址:...
  • 本文作者:李栋,来自Kyligence公司,也是Apache Kylin ...在现在的大数据时代,越来越多的企业开始使用Hadoop管理数据,但是现有的业务分析工具(如Tableau,Microstrategy等)往往存在很大的局限,如难以水平
  • Apache Kylin 大数据时代的OLAP利器

    千次阅读 2016-03-27 11:06:50
    1. OLAP简介   OLAP的历史与基本概念 ...OLAP全称为在线联机分析应用,是一种对于多维数据分析查询的解决方案。典型的OLAP应用场景包括销售、市场、管理等商务报表,预算决算,经济报表等等。...
  • 大数据 对多维数据进行分析 聚类分析 OLAP 多种软件odbc 链接
  • 2018年7月在 Apache Kylin meetup@上海活动上,甜橙金融架构师介绍了在数据量爆炸场景下,如何使用 Apache Kylin 解决分析慢分析难的问题。 ![]...

空空如也

1 2 3 4 5 ... 20
收藏数 653,191
精华内容 261,276
关键字:

kylin