Apache Kylin一Kylin介绍

作者: ZacksTang
  1. 传统大数据分析的问题

在基于Hadoop 生态的传统大数据分析中,主要使用的技术是MPP(Massively Parallel Processing)大规模并行处理和列式存储。MPP使用线性增加计算资源换取计算时间的线性下降,列式存储可以提高读取数据的速率。两者结合可以使得基于 Hadoop 的SQL 查询速度从小时级降为分钟级。不过分钟级别的查询响应仍未达到交互式分析级别,主要问题在于:MPP以及列式存储,并未改变查询问题的根本问题,也就是"查询时间与数据量存在线性增长关系"的这一事实。

  1. Kylin

    Kylin是基于Hadoop 大数据平台的一个在线分析处理(OLAP)引擎,再用多维立方体与计算技术,将大数据的SQL查询速度从之前的数分钟乃至几小时提升至亚秒级别。这种极大的速度提升,使得超大型数据集的交互式分析成为可能。其中关键的就是打破查询时间随数据量呈线性增长的事实。

对于 OLAP,可以注意到两点事实:

  1. 大数据查询的一般是统计结果,是多条记录聚合之后的统计值,并不是原始的记录(或是说原始记录访问的频率非常低)
  2. 聚合是按维度进行的,而维度的聚合可能性是有限的,一般不会随着数据的增长而线性增长

基于这两点,Kylin中使用了"预计算”:尽量使用预先计算得到的"聚合结果”,在查询时也尽量使用预计算的结果,得到最终查询结果。从而避免直接扫描规模非常大的原始数据。

举个例子,使用下面的SQL语句查询10月1日那天销量最高的商品: SELECT item, SUM(sell_amount) FROM sell_details WHERE sell_date='2016-10-01' GROUP BY item ORDER BY SUM(sell_amount) DESC

传统方法需要扫描所有记录,找到 2016-10-01 的销售记录,然后按item ,对sell_amount 进行 SUM 聚合,然后降序排列返回。假如10月1日当天有1亿条交易记录,那么查询必须读取的数据量至少1亿条,并按交易记录数线性增长,查询时间也会线性增长。

而若是使用预计算,则会事先按维度 [sell_date, item] 计算 SUM(sell_amount) 并将其存储下来。在查询时,找到10月1日的销售商品,就可以直接排序返回了。读取的记录数最大不会超过维度[sell_date, item] 的组合数。

假设们的sell_date 为2016年的每日,则sell_date 一共有365 种);假设商品一共有 10 万条,则[sell_date, item] 的组合数为 3650 万种。此时无论有多少条交易记录,读取的记录数最多都不会超过 3650万条。假设10月1日的交易包含了 5 万条商品(某天的交易可能并不会覆盖到所有商品),那么在预计算后就仅有 5 万条记录了。无论是10月1号有多少条交易记录,甚至是几亿条,只要是涉及的商品只有5万条,则预计算后的结果也仅有 5 万条。而且此预计算的结果是已经按商品聚合后的结果,省去了运行时的聚合计算。

预计算就是kylin在PPM已经列式存储之外,提供给大数据分析的第三个关键技术。

  1. Kylin 工作原理

    Kylin 的工作原理本质上是MOLAP(Multidimensional Online Analytical Processing)Cube,也就是多维立方体分析。这是数据分析中非常经典的理论,在RMDB时代就已广泛使用。 3.1. 维度和度量

维度(Dimension)就是观察数据的角度,比如商品的销售数据,可以从时间的维度来观察(如下左图所示),也可以进一步细化从时间与地区的维度来观察(如下右图所示):

维度一般是一组离散的值,比如时间维度上的每个独立日期,或者商品维度上的每一件独立的商品。所以在统计时可以把"维度值相同"的记录聚合起来,应用聚合运算(例如累加SUM,平均AVG,去重DISTINCT等)。

而度量就是被聚合的统计值,也是聚合运算的结果,一般是连续值,如上图中的销售额。通过比较和测算度量,分析师可以对数据进行评估,比如今年销售额是否较去年有增长、增速是否达预期、不同商品种类的销售增长是否合理等。 3.2 Cube 和 Cuboid

在有了维度和度量的概念后,就可以对数据表或数据模型上的所有字段进行分类了,它们要么是维度,要么是度量(可以被聚合)。之后就有了根据维度、度量做预计算的Cube理论。

给定一个数据模型,们可以对其上所有维度进行组合。对于N个维度来说,所有组合可能性有2N种。对每一种维度的组合,做度量的聚合运算,运算的结果保存为一个物化视图,称为Cuboid。将所有维度组合成的Cuboid作为一个整体,称为Cude。所以简单地说,一个Cube就是许多按维度聚合的物化视图的集合。

举个例子,假设有一个电商的销售数据集,其中维度有时间(Time),商品(Item)、地点(Location)和供应商(Supplier),度量有销售额(GMV)。那么所有维度的组合就有24=16种。比如一维(1D)的组合有[Time], [Item], [Location], [Supplier] 四种;二维(2D)的组合有[Time, Item], [Time, Location], [Time, Supplier], [Item, Location], [Item, Supplier], [Location, Supplier] 六种;三维(3D)的组合也有4种;最后零维度(0D)和四维度(4D)组合各一种,共计16种组合。

计算Cuboid,就是按维度来聚合销售额(GMV),如果用SQL表达式来计算Cuboid[Time, Location],那就是: SELECT Time, Location, SUM(GMV) as GMV FROM Sales GROUP BY Time, Location

将计算的结果保存为物化视图,所有Cuboid 物化视图的总称就是Cube了。 3.3 Kylin 工作原理 Apache Kylin 的工作原理就是对数据模型做Cube 预计算,并利用计算的结果加速查询。过程如下:

  1. 指定数据类型,定义维度和度量
  2. 预计算Cube,计算所有Cuboid 并将其保存为物化视图
  3. 执行查询时,读取Cuboid,进行加工运算产生查询结果

由于Kylin 查询过程中不会扫描原始记录,而是通过预计算预先完成表的关联、聚合等复杂运算,并利用预计算结果来执行查询,因此其速度比非预计算的查询技术一般要快一到两个数量级。特别是在超大数据集上的优势更加明显,当数据集达到千亿乃至万亿级别时,Kylin的速度甚至可以超越其他非预计算技术1000倍以上。

  1. 事实表(Fact Table)与维度表(Dimension Table)

事实表(Fact Table)是指存储事实记录的表,如电商的销售日志,并且是维度模型中的主表,代表着键和度量的集合。事实表的记录会不断地增长,所以它的体积远大于其他表,通常事实表占据数据仓库中90%或更多的空间。

维度表(Dimension Table),也称为维表或查找表(Lookup Table),是与事实表相对应的一种表。维度表的目的是将业务含义和上下文添加到数据仓库中的事实表和度量中。维度表是事实表的入口点,它实现了数据仓库的业务接口。它们基本上是事实表中的键引用的查找表。它保存了维度的属性值,可以与事实表做关联,相当于将事实表上经常出现的属性抽取、规范出来用一张表进行管理,常见的维度表如:日期表(存储日期对应的周、月、季度等属性)、地点表(包含国家、省/州、城市等属性)等。使用维度表的好处有:

  • 减小了事实表的大小;
  • 便于维度的管理和维护,增加、删除和修改维度的属性时,不必对事实表的大量记录进行改动;
  • 维度表可以为多个事实表同时使用,减少重复工作。

在 Kylin 中构建 Cube 时,会使用到事实表与维度表,届时通过例子可以更清晰地了解这两个表的区别。

以上便是 Kylin 的基本介绍,下章们会介绍如何在 AWS EMR 上搭建 Kylin。



原文创作:ZacksTang

原文链接:https://www.cnblogs.com/zackstang/p/12728677.html

文章列表

更多推荐

更多
  • Pulsar消息队列-一套高可用实时消息系统实现 实时消息【即时通信】系统,有群聊和单聊两种方式,其形态异于消息队列:1 大量的 group 信息变动,群聊形式的即时通信系统在正常服务形态下,瞬时可能有大量用户登入登出。2 ...
  • Pulsar消息队列-Pulsar对比Kafka笔记 很多人查看 Pulsar 之前可能对 Kafka 很熟悉,参照上图可见二者内部结构的区别,Pulsar 和 Kafka 都是以 Topic 描述一个基本的数据集合,Topic 数据又分为若干 Partition,即对数据进行逻辑上的 ...
  • Pulsar消息队列-对 2017 年一套 IM 系统的反思 信系统的开发,前前后后参与或者主导了六七个 IM 系统的研发。上一次开发的 IM 系统的时间点还是 2018 年,关于该系统的详细描述见 [一套高可用实时消息系统实现][1] ...
  • Apache APISIX文档-快速入门指南-如何构建 Apache APISIX 如何构建 Apache APISIX,步骤1:安装 Apache APISIX,步骤2:安装 etcd,步骤3:管理 Apache APISIX 服务,步骤4:运行测试案例,步骤5:修改 Admin API key,步骤6:为 Apac
  • Apache APISIX文档-快速入门指南-快速入门指南 快速入门指南,概述,前提条件,第一步:安装 Apache APISIX,第二步:创建路由,第三步:验证,进阶操作,工作原理,创建上游服务Upstream,绑定路由与上游服务,添加身份验证,为路由添加前缀,APISIX Dashboard
  • Apache APISIX文档-架构设计-APISIX APISIX,软件架构,插件加载流程,插件内部结构,配置 APISIX,插件加载流程,比如指定 APISIX 默认监听端口为 8000,并且设置 etcd 地址为 http://foo:2379, 其他配置保持默认。在 ...
  • Apache APISIX文档-架构设计-Service Service 是某类 API 的抽象(也可以理解为一组 Route 的抽象)。它通常与上游服务抽象是一一对应的,Route 与 Service 之间,通常是 N:1 的关系,参看下图。不同 Route 规则同时绑定到一个 Service ...
  • Apache APISIX文档-架构设计-Plugin Config 如果你想要复用一组通用的插件配置,你可以把它们提取成一个 Plugin config,并绑定到对应的路由上。举个例子,你可以这么做:创建 Plugin config,如果这个路由已经配置了 plugins,那么 Plugin config ...
  • Apache APISIX文档-架构设计-Debug Mode 注意:在 APISIX 2.10 之前,开启基本调试模式曾经是设置 conf/config.yaml 中的 apisix.enable_debug 为 true。设置 conf/debug.yaml 中的选项,开启高级调试模式。由于 ...
  • Apache APISIX文档-架构设计-Consumer 如上图所示,作为 API 网关,需要知道 API Consumer(消费方)具体是谁,这样就可以对不同 API Consumer 配置不同规则。授权认证:比如有 [key-auth] 等。获取 consumer_...
  • 近期文章

    更多
    文章目录

      推荐作者

      更多