博客园  :: 首页  :: 联系 :: 管理

kylin(一): 原理架构

Posted on 2016-12-06 20:31  天戈朱  阅读(21601)  评论(0编辑  收藏  举报

      由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等)对数据进行并行计算 ,下图是高层次的架构图