Apache Kylin

Apache Kylin是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。 伪分布式环境搭建 hadoop-2.7.7安装 http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCluster.html hive2.1.1 https://my.oschina.net/peakfang/blog/2236971 hbase1.2.6 http://hbase.apache.org/book.html#_introduction kylin-2.2.0 http://kylin.apache.org/docs/install/index.html 如果所用的spark为（hive on spark）源码编译不带hive jar包，或者1.6.3版本时，因SPARK_HOME目录下无jars目录，启动kylin时会报如下错误 find: ‘/usr/local/spark-1.6.3/jars’: No such file or directory [root@node222 local]# vi kylin-2.5.0/bin

去重计数在企业日常分析中应用广泛，如用户留存、销售统计、广告营销等。海量数据下的去重计数十分消耗资源，动辄几分钟，甚至几小时，Apache Kylin 如何做到秒级的低延迟精确去重呢？ 什么是去重计数 去重计数是数据分析中的常用分析函数，指查询某列中不同值的个数，在 SQL 中的函数是 count(distinct col)。它与 count(col) 函数的区别在于有一个 distinct 描述符，意思是去掉重复值，因此称为去重计数。 去重计数使用广泛，例如：在网站/app 使用统计中，PV/UV 是最常用的指标，其中 UV（unique visitor，独立访问用户）就是去重后的数字，即同一个用户的所有访问记录只计入一次。对于网站/app 所有者，PV (page view）代表的使用量的高低，UV 代表用户的多少，两个数字都很重要；只有结合两个数字一起，才能更加准确地了解网站/app的用户、用量增长情况。 图 1：PV/UV 统计 大数据上去重运算的难点与挑战 去重运算因为涉及到数值的比较，因此它的计算要比单纯的 PV 计数要略复杂。当数据量不大的时候，单机运行的性能或许还能忍受。但是当数据量渐长的时候，所花的时间越来越长，依靠单节点处理难以满足，此时就需要依靠分布式框架如 MapReduce 或 Spark 等并行处理，把大数据分而治之。 学习过 MapReduce 的朋友

在上一章节中，我们讲到实时数仓的建设，互联网大数据技术发展到今天，各个领域基本已经成熟，有各式各样的解决方案可以供我们选择。 在实时数仓建设中，解决方案成熟，消息队列Kafka、Redis、Hbase鲜有敌手，几乎已成垄断之势。而OLAP的选择则制约整个实时数仓的能力。开源盛世的今天，可以供我们选择和使用的OLAP数据库令人眼花缭乱，这章我们选取了几个最常用的OLAP开源数据引擎进行分析，希望能给正在做技术选型和未来架构升级的你提供一些帮助。 本文给出了常用的开源OLAP引擎的性能测评： https://blog.csdn.net/oDaiLiDong/article/details/86570211 OLAP百家争鸣 OLAP简介 OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。与此相对的是OLTP（on-line transaction processing）联机事务处理系统。 联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。 Codd认为联机事务处理（OLTP）已不能满足终端用户对数据库查询分析的要求

工业互联网和 5G 时代正逐步到来，万物智能网联、智能互联已成为一种趋势。目前物联网应用在很多场景下，如智慧制造、智慧城市、智慧农业等。本文以智慧城市为背景，介绍西安中服软件有限公司是如何利用大数据分析神兽 Apache Kylin，让物联网的传感器信息，通过云化的大数据物联网云平台，对感知的数据进行分析处理，进而满足智慧城市的建设需求。 业务背景 作为智慧城市的重要组成部分，智慧楼宇也以惊人的速度发展着，挖掘和处理楼宇数据，并以此来精准控制并降低楼宇能耗成为一个重要问题。以 IoT 设备完成能源网络搭建，并进行数据采集，然后推送到流处理工具，楼宇管理者可以通过常规的数据分析，根据不同的用能区域、能耗类型，对建筑能耗进行分时段计量和分项计量，分别计算指定时间范围内电、水、气等能源的使用量，并且对未来能耗使用进行一定程度的预测。管理者可通过梳理不同能源的使用情况，实现对能源的高效管理。 做一个单点的能源管理系统并不存在技术难点，但是在设备上云后，要将其做成一个 Saas 产品，我们就需要考虑很多问题，如性能问题等。 传统的做法，不同的租户将物联网设备在云端绑定后，系统自动为他们生成对应的数据库表，以此来做到资源隔离。这些物联设备的事实数据和维度数据都存放于 Oracle 中，但是使用关系型数据库存在一些问题： 无法支撑大数据量，当数据量达到一定程度时，需要进行倒库。

“随着维度数目的增加，Cuboid 的数量会爆炸式地增长。为了缓解 Cube 的构建压力，Apache Kylin 引入了一系列的高级设置，帮助用户筛选出真正需要的 Cuboid。这些高级设置包括聚合组（Aggregation Group）、联合维度（Joint Dimension）、层级维度（Hierachy Dimension）和必要维度（Mandatory Dimension）等。” 正如上述官方文档提到的，在维度过多时，合理地使用聚合组能解决 Cube 膨胀率过大的问题。听起来那么美好，但是，不合理的聚合组设置将对性能产生灾难性影响。 剪枝原理 Apache Kylin 的主要工作就是为源数据构建 N 个维度的 Cube，实现聚合的预计算。从理论上说，构建 N 个维度的 Cube 就会生成 2^N 个 Cuboid。 所以，只要降低最终 Cuboid 的数量，就可以减小膨胀率，达到对 Cube 剪枝的效果。 构建一个 4 个维度（A，B，C, D）的 Cube，就需要生成 16 个Cuboid。 那么问题来了，如果这 4 个维度（A，B，C, D），能够根据某业务逻辑找出一个隐藏的规律，即：当进行聚合时，用户仅仅关注维度 AB 组合和维度 CD 组合（即只会通过维度 A 和 B 或者 C 和 D 进行聚合，而不会通过 A 和 C、B 和 C、A 和 D、B 和 D 进行聚合

##引言 前文回顾：《数据智能时代来临：本质及技术体系要求》作为本系列的第一篇文章，概括性地阐述了对于数据智能的理解以及推出了对应的核心技术体系要求： 数据智能就是以数据作为生产资料，通过结合大规模数据处理、数据挖掘、机器学习、人机交互、可视化等多种技术，从大量的数据中提炼、发掘、获取知识，为人们在基于数据制定决策时提供有效的智能支持，减少或者消除不确定性。 从对数据智能的定义来看，数据智能的技术体系至少需要包含几个方面，见下图所示： ▲数据智能技术体系构成 其中数据资产治理、数据质量保证、数据智能下的安全计算体系会在后续的系列文章中重点阐述。 然而最近在实际工作中，发现大家对于如何处理多维数据进行分析以解决实际业务问题方面存在一些实实在在的困扰，特别是对于选择什么样的底层系统无所适从，毕竟有资源给大家进行试验的公司并不是太多。 故此我和团队一起研究，同时也借鉴了外部的一些资料，针对这个议题撰写了本系列的第二篇文章，主要围绕“多维度分析系统的选型方法”的主题，供大家参考，希望能缩短大家的决策时间。 ##正文内容 ###分析系统的考量要素 CAP 理论大家都已经比较熟悉， C.A.P 之间无法兼得，只能有所取舍。在分析系统中同样需要在三个要素间进行取舍和平衡，三要素分别是数据量、灵活性以及性能。 ▲分析系统考量三要素 有的系统在数据量达到一定数量，譬如超过P级别后，在资源不变情况下

前言 Kylin 用户在使用 Spark的过程中，经常会遇到任务提交缓慢、构建节点不稳定的问题。为了更方便地向 Spark 提交、管理和监控任务，有些用户会使用 Livy 作为 Spark 的交互接口。在最新的 Apache Kylin 3.0 版本中，Kylin 加入了通过 Apache Livy 递交 Spark 任务的新功能[KYLIN-3795]，特此感谢滴滴靳国卫同学对此功能的贡献。 Livy 介绍 Apache Livy 是一个基于 Spark 的开源 REST 服务，是 Apache 基金会的一个孵化项目，它能够通过 REST 的方式将代码片段或是序列化的二进制代码提交到 Spark 集群中去执行。它提供了如下基本功能： 提交 Scala、Python 或是 R 代码片段到远端的 Spark 集群上执行。 提交 Java、Scala、Python 所编写的 Spark 作业到远端的 Spark 集群上执行。 Apache Livy 架构 为什么使用 Livy 1. 当前 Spark 存在的问题 Spark 当前支持两种交互方式： 交互式处理用户使用 spark-shell 或 pyspark 脚本启动 Spark 应用程序，伴随应用程序启动的同时，Spark 会在当前终端启动 REPL(Read–Eval–Print Loop) 来接收用户的代码输入，并将其编译成

UDF（User Defined Function 用户自定义函数）是 SQL 环境中很关键的特性。通过写 UDF，开发者可以方便地插入常用的处理代码并在查询中使用。Apache Kylin 支持持久化的 UDF。来自华安保险的赵兴成特别带来了 Kylin 中 UDF 的分享，快跟着兴成一探究竟吧～ 背景 Apache Kylin 作为 OLAP 神器，在海量数据的多维分析方面优势明显，给我们的工作提供了很大帮助，也一直是华安保险 OLAP 系统的后台的主要支撑。在我们的系统中，把指标分成基础指标和衍生指标两大类，基础指标即不可再分解，由业务直接生成的指标，衍生指标则是由基础指标通过混合计算得出。 一直以来，为了节省空间，增加构建速度，Kylin 的 Cube 中我们只保留了基础指标，而衍生指标基本是通过应用层的 SQL 来计算解决，这样带来两个问题： SQL 复杂，可读性差，比如需要加入 case when 和类似 (commamt+devamt+servamt)/grossprm as ** 的语法； 易出错，如果有开发人员对指标定义不熟悉或者理解有偏差，极易造成计算结果错误。 如何解决？ 用过 Hive 的人都清楚，Hive 中有个 UDF（User Defined Function）功能，非常好用。那么 Kylin 中是否有这样的功能呢？有的，只有三个：三个类都位于 org

现如今，大数据、数据科学和机器学习不仅是技术圈的热门话题，也是当今社会的重要组成。数据就在每个人身边，同时每天正以惊人的速度快速增长，据 福布斯 报道： 到 2025 年，每年将产生大约 175 个 Zettabytes 的数据量。 目前我们所熟知的行业都越来越依赖于对大数据的高级处理和分析，如金融、医疗保健、农业、能源、媒体、教育等所有重要的社会发展行业，然而这些庞大的数据集让数据分析、数据挖掘、机器学习和数据科学面临了巨大的挑战。 数据科学家和分析师在尝试对于海量数据的分析时会面临数据处理流程复杂、报表查询缓慢等问题，但在实践中发现可通过 Apache Kylin 与 Python 的集成解决这一大难题，从而帮助分析师和数据科学家最终获得对大规模（TB 级和 PB 级）数据集的自由访问。 机器学习和数据科学面临的挑战 机器学习（ML）工程师和数据科学家在对大数据运行计算时遇到的主要挑战之一是处理更大容量的数据时带来的更大的计算复杂度 。 因此，随着数据集的扩大，即使是微不足道的操作也会变得昂贵。此外，随着数据量的增加，算法性能越来越依赖于用于存储和移动数据的技术架构，同时数据量越大，并行数据结构，数据分区和存储以及数据复用变得更加重要。 Apache Kylin 如何解决这些挑战？ Apache Kylin 是一个开源的分布式大数据分析引擎，旨在为 Hadoop上的多维分析

前言 Kylin 用户在使用 Spark的过程中，经常会遇到任务提交缓慢、构建节点不稳定的问题。为了更方便地向 Spark 提交、管理和监控任务，有些用户会使用 Livy 作为 Spark 的交互接口。在最新的 Apache Kylin 3.0 版本中，Kylin 加入了通过 Apache Livy 递交 Spark 任务的新功能[KYLIN-3795]，特此感谢滴滴靳国卫同学对此功能的贡献。 Livy 介绍 Apache Livy 是一个基于 Spark 的开源 REST 服务，是 Apache 基金会的一个孵化项目，它能够通过 REST 的方式将代码片段或是序列化的二进制代码提交到 Spark 集群中去执行。它提供了如下基本功能： 提交 Scala、Python 或是 R 代码片段到远端的 Spark 集群上执行。 提交 Java、Scala、Python 所编写的 Spark 作业到远端的 Spark 集群上执行。 Apache Livy 架构 为什么使用 Livy 1. 当前 Spark 存在的问题 Spark 当前支持两种交互方式： 交互式处理用户使用 spark-shell 或 pyspark 脚本启动 Spark 应用程序，伴随应用程序启动的同时，Spark 会在当前终端启动 REPL(Read–Eval–Print Loop) 来接收用户的代码输入，并将其编译成