kylin_kylin v10系统 - CSDN
精华内容
参与话题
  • kylin详细介绍

    千次阅读 2018-05-10 11:36:49
    由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
     

    展开全文
  • 基于Apache Kylin 构建大数据分析平台(完整目录版),目录非常详细精准,十分方便查阅,比其他的下载版本都详细,童叟无欺
  • OLAP引擎——Kylin介绍

    万次阅读 多人点赞 2016-03-15 16:04:37
    最近一直在学习和使用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的,以及执行查询的流程。


    展开全文
  • 这几个框架都是OLAP大数据分析比较常见的框架,各自特点如下: presto:facebook开源的一个java写的分布式数据查询框架,原生集成了Hive、Hbase和关系型数据库,Presto背后所使用的执行模式与Hive有根本的不同,它...

    这几个框架都是OLAP大数据分析比较常见的框架,各自特点如下: 
    presto:facebook开源的一个java写的分布式数据查询框架,原生集成了Hive、Hbase和关系型数据库,Presto背后所使用的执行模式与Hive有根本的不同,它没有使用MapReduce,大部分场景下比hive快一个数量级,其中的关键是所有的处理都在内存中完成。 
    Druid:是一个实时处理时序数据的Olap数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。 
    spark SQL:基于spark平台上的一个olap框架,本质上也是基于DAG的MPP, 基本思路是增加机器来并行计算,从而提高查询速度。 
    kylin:核心是Cube,cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。

    这几种框架各有优缺点,存在就是合理,如何选型个人看法如下:

    从成熟度来讲:kylin>spark sql>Druid>presto

    从超大数据的查询效率来看:Druid>kylin>presto>spark sql

    从支持的数据源种类来讲:presto>spark sql>kylin>Druid

    大数据查询目前来讲可以大体分为三类:

    1.基于hbase预聚合的,比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标,在数据接入的时候根据指定的指标进行聚合运算,适合相对固定的业务报表类需求,只需要统计少量维度即可满足业务报表需求

    2.基于Parquet列式存储的,比如Presto, Drill,Impala等,基本是完全基于内存的并行计算,Parquet系能降低存储空间,提高IO效率,以离线处理为主,很难提高数据写的实时性,超大表的join支持可能不够好。spark sql也算类似,但它在内存不足时可以spill disk来支持超大数据查询和join

    3.基于lucene外部索引的,比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储,但对于日志、行为类时序数据,所有的搜索请求都也必须搜索所有的分片,另外,对于聚合分析场景的支持也是软肋

     

    展开全文
  • Druid 大数据分析

    万次阅读 2019-02-28 10:38:14
    0. 前言OLTP 与 OLAPOLTP:OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。通俗的讲,就是对数据的增删改查等操作。OLAP:OLAP是数据仓库系统的主要应用,支持复杂的分析操作,...
  • Kylin&Druid浅析

    千次阅读 2019-11-23 18:38:38
    一、kylin 核心思想 Apache Kylin的核心思想是利用空间换时间,它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中(目前还仅支持hbase), 同时由于Apache Kylin在查询方面制定了多种灵活的策略,...
  • 关键词:caravel、olap、kylin、数据可视化 Caravel(曾用名Panoramix),是由知名在线房屋短租公司Airbnb开源的一款数据探索与可视化工具,该工具在可视化、易用性和交互性上非常有特色,用户可以轻松对数据进行可视...
  • Kylin大数据分析

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

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

    2020-01-07 17:51:00
    Kylin 第1章 概述 1.1 Kylin定义 Apache Kylin是一个开源的分布式分析引擎,提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay开发并贡献至开源社区。它能在亚秒内查询巨大的...
  • kylin

    2020-09-13 10:00:19
    kylin 1、概念 Apache Kylin是一个开源的分布式分析引擎,提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表 Kylin...
  • 由于笔者所在环境没有人用过kylin,笔者也是自学官网,阅读书籍 将kylin用于实际项目,期间遇到了很多很多关于kylin使用的问题。为了让后面的人在使用kylin实践的时候能够少走弯路,在此生成kylin的调优,错误总结,...
  • Kafka+kylin——kylin2.5.0流式构建

    千次阅读 2019-03-07 22:05:05
    《一份详细的Kylin执行样例——基于kylin2.5.0》一文中,小厨介绍了如何使用kylin,今天开辟一个新路线,个人感觉随着时代的发展,数据实时分析会成为主力军,因为今天介绍一下Kafka+kylin,流式构建cube。kylin是从...
  • kylin 官方案例learn_kylin手动创建测试

    千次阅读 2017-12-01 17:54:45
    在上一篇文章中介绍了kylin相关的基本知识,这篇文章的主要目的是针对kylin初学者,进行一次详细的kylin案例介绍,这里,我们还是以官方给定的数据为例。说明,我用的是kylin2.1.0. 与kylin1.x 可能有不一样的地方。...
  • Apache Kylin

    2019-06-24 15:09:02
    Kylin思维导图 前言 随着移动互联网、物联网等技术的发展,近些年人类所积累的数据正在呈爆炸式的增长,大数据时代已经来临。但是海量数据的收集只是大数据技术的第一步,如何让数据产生价值才是大数据领域的终极...
  • Apache Kylin集成superset

    千次阅读 2018-06-28 13:18:55
    目前Kylin已经可以与superset进行集成,详细的说明可参考kylin官方文档: [ superset ]。但是superset原生并不支持kylin,因此我们需要安装Kyligence公司提供的kylinpy工具。这是一个python的kylin客户端工具,可以...
  • kylin介绍

    2017-05-23 16:33:47
    Kylin是ebay开发的一套OLAP系统,与Mondrian不同的是,它是一个MOLAP系统,主要用于支持大数据生态圈的数据分析业务,它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中(目前还仅支持hbase),这段时间...
  • KylinKylin中的cube构建

    万次阅读 热门讨论 2015-12-26 18:06:17
    kylin如何构建cube的,从原始数据(hive)到目标数据(hbase)的过程。
  • 在《Kylin2.5.0安装部署及样例sample.sh》一文中,我们搭建了kylin2.5.0版本的运行环境,并且简单演示了一下官方的Sample Cube的示例,这样从宏观上对kylin的运行流程有了一个整体的认识。那么,这篇文章我们将继续...
1 2 3 4 5 ... 20
收藏数 19,292
精华内容 7,716
关键字:

kylin