Hello World

项目中需要调研使用mondrian，自己从网上下了一个的demo，但是运行过程中遇到了一些问题，随着对问题的分析和解决也加深了对mondrian的使用。

概述最近一直在倒腾Impala，公司内部也属于刚刚部署使用，初次体验感觉性能还是比较好的（可能是使用Hive过多的原因），并且Impala还可以支持Kudu引擎，这个目前看上去是实时离线统一的较好解决方案，因此考虑在公司内部推广使用，但是一旦给多个产品部署、使用就需要考虑如下的几个问题：部署方式：它决定了以后的扩展性和运维复杂度等。权限隔离：如何做到用户的数据不被他授权的用户查询。资源隔离：用

概述出于对可扩展性和性能的考虑，UDF已变成大数据生态圈查询引擎的必备功能之一，无论是Calcite、Hive、Impala都对其进行支持，但是UDF的支持有利也有弊，好处在于它提供了对某些用户独有需求的支持，例如某些产品需要将表中的某字段使用自定义的方式解析成可读字段，例如需要实现特殊的聚合函数；它的弊端在于它对用户开发，这样对于恶意的用户可能执行非正常的逻辑.

Impala性能的调优是一个不断调整的过程，这里介绍了一些基本你的准则，当然对于具体的性能问题还是要借住实际的工具分析。

背景随着大数据时代的到来，Hadoop在过去几年以接近统治性的方式包揽的ETL和数据分析查询的工作，大家也无意间的想往大数据方向靠拢，即使每天数据也就几十、几百M也要放到Hadoop上作分析，只会适得其反，但是当面对真正的Big Data的时候，Hadoop就会暴露出它对于数据分析查询支持的弱点。甚至出现《MapReduce: 一个巨大的倒退》此类极端的吐槽，这也怪不得Hadoop，毕竟它的设计就是

由来之前根据Impala官方的文档尝试使用haproxy实现impalad节点的负载均衡，但是这种方案存在一些弊端，例如haproxy本身也是单点的，虽然可以通过keeplived实现haproxy的高可用，但是这样的配置难免有点太重了，实现impala负载均衡的同时还需要多部署两个组件，增大了系统运维的复杂度。在大数据生态圈中zookeeper是一个必不可少的自身具有高可用保证的组件，本文探讨如何

hiveserver2的代理访问可以使得平台端代理任意用户执行SQL操作就像该用户自己执行的操作一样（就像一个普通用户直接使用hive CLI执行操作），本文主要探索hiveserver2是如何使用代理的方式实现支持不同用户完成SQL操作，为修改impala支持对应的操作做铺垫。

众所周知，Impala包含三个模块，分别是impalad、catalogd和statestored，其中statestored模块的作用是实现一个业务无关的订阅(Subscribe)发布(Publish)系统,catalod和impalad中的部分消息传递需要通过statestored传递，为什么要使用这样一个业务无关的服务来传递消息呢？下面我们来揭开它神秘的面纱。

个人觉得该文章对于诸如Impala这样的MPP架构的SQL引擎和Runtime Framework架构的Hive/Spark SQL进行对比，感觉总结的特别好，并且和本人最近的公司相近，学习转载之。

前言Impala采用了比较奇葩的多个impalad同时提供服务的方式，并且它会由catalogd缓存全部元数据，再通过statestored完成每一次的元数据的更新到impalad节点上，Impala集群会缓存全部的元数据，这种缓存机制就导致通过其他手段更新元数据或者数据对于Impala是无感知的，例如通过hive建表，直接拷贝新的数据到HDFS上等，Impala提供了两种机制来实现元数据的更新，分

聚合操作（Aggregation）是OLAP分析查询中最常见的操作之一，可以说它是数据分析查询的基石，它对应这SQL中的GROUP BY子句，OLAP中的上卷下钻操作无非就是对于GROUP BY和WHERE条件的改变，如何能够高效的实现聚合是决定OLAP分析性能的最重要因素之一（另外几个因素包括如何减少SCAN记录数、如何高效实现JOIN等）。

Impala的定位是一种新型的MPP查询引擎，但是它又不是典型的MPP类型的SQL引擎，提到MPP数据库首先想到的可能是GreenPlum，它的每一个节点完全独立，节点直接不共享数据，节点之间的信息传递全都通过网络实现。而Impala可以说是一个MPP计算引擎，它需要处理的数据存储在HDFS、Hbase或者Kudu之上，这些存储引擎都是独立于Impala的，可以称之为第三方存储引擎，Impala使用

Impala是一个高性能的OLAP引擎，Impala本身只是一个OLAP-SQL引擎，它访问的数据存储在第三方引擎中，第三方引擎包括HDFS、Hbase、kudu。对于HDFS上的数据，Impala支持多种文件格式，目前可以访问Parquet、TEXT、avro、sequence file等。对于HDFS文件格式，Impala不支持更新操作，这主要限制于HDFS对于更新操作的支持比较弱。本文主要介绍

前言书接上文，如果说HDFS的数据访问层各个BigData SQL Engine做的都大同小异的话，那么Runtime Filter（下文简称RF）则是Impala比较独特的”黑科技”了,在深入学习Impala之前对于这个名词比较陌生，但它绝对是Impala性能提升的一大法宝，我们将试图围绕着如下几个问题展开以详细介绍Runtime Filter的细节。什么是Runtime FilterRunt

在Impala中，权限管理的作用主要是确定某个用户是否有权限访问某些资源，用户对于这些资源具有哪种访问权限等，这里涉及到三个概念：用户，资源和权限。对于Impala 1.1之后的版本，可以直接集成Apache Sentry服务来实现Impala的权限管理，由于Impala可以和hive共享元数据库，包括权限机制。用户在不开启权限认证的impala集群中，没有用户的概念存在了，所有访问Impala

概述Impala分为是三个组件，statestored/catalogd和impalad，其中statestored和catalogd是单点的，没有高可用的需求，因为这两个实例是无状态的，本身不存储任何数据，例如catalogd的数据存储在第三方数据库(例如mysql中)，statestore的数据全都存储在内存中，可以通过简单的主备的方式来实现高可用，本文最后会提到。正常情况下只有master提供

本文主要介绍了开源的OALP引擎mondrian测试数据的导入过程以及对OLAP中cube以及相关定义的介绍，最后讲述了本人在OLAP开发中主要遇到的问题

配置hiveserver2，基于kerberos认证，使用0.14.0版本，记录中间遇到的问题和访问方式

对OLAP引擎（主要是mondrian）的一些理解

mondrian创建连接的过程，不包括如何加载schema内容。

kylin可能执行一些构建cube等任务，因此需要一个比较合理的任务调度机制，本文介绍了kylin如何设置任务调度模块的，以及对链式任务执行逻辑进行分析。

学习使用Calcite

在使用Kylin过程中有一些需求是hive原始表结构完成不了了的，这时候使用hive的视图可以增加灵活性并且满足各种需求，看我们是如何使用的吧

Cube模型和Kylin创建Cube时的高级设置，Rowkey、维度组、维度字典等。

kylin如何构建cube的，从原始数据（hive）到目标数据（hbase）的过程。

缘由    近期由于发现线上cube的构建时间太慢（一个项目的cube构建前一天的数据一般需要170分钟左右），目前我们接入的应用才三个，如果后期接入更多的cube之后会导致更慢的cube构建速度，于是深入了解了一下cuboid是如何确定的，看了代码之后发现和我们预想的不一样，于是经过咨询社区之后也觉得之前的算法是存在一定的问题（2.x版本已经对此做了修改），因此就准备对cuboid的计算进行修改

本文主要使用Hive引擎对比测试了两种业界较为认可的列式存储格式——ORC和Parquet，并使用Text存储格式做对比，设置了星状模型、扁平式宽表，嵌套式宽表等多种场景进行测试，以供感兴趣的同学参考。

背景随着大数据时代的到来，越来越多的数据流向了Hadoop生态圈，同时对于能够快速的从TB甚至PB级别的数据中获取有价值的数据对于一个产品和公司来说更加重要，在Hadoop生态圈的快速发展过程中，涌现了一批开源的数据分析引擎，例如Hive、Spark SQL、Impala、Presto等，同时也产生了多个高性能的列式存储格式，例如RCFile、ORC、Parquet等，本文主要从实现的角度上对比分析

由来Apache Kylin定位是大数据量的秒级SQL查询引擎，原理是通过预计算所有可能的维度组合存储在Hbase中，查询时解析SQL获取维度和度量信息，然后再从hbase中扫描获取数据返回，个人认为Kylin最强大的地方在于实现了SQL引擎，如果使用自定义的格式化查询语言也可以完成相应的数据访问操作，无非是指定查询的维度、度量、聚合函数、过滤条件，排序列等等。但是这种描述较之于SQL太弱了，SQL

背景最近开始使用了新版本的Kylin，在此之前对于新版本的了解只是代码实现和一些简单的新功能测试，但是并没有导入实际场景的数据做分析和查询，线上Hadoop稳定之后，逐渐得将一些老需求往新的环境迁移，基于以前的调研，新版本（V2，版本为1.5.2）的Kylin提供了几个比较显著的功能和优化：新的度量类型，包括TOPN、基于bitmap的精确distinct count和RAW。自定义度量框架，用

一种解决Impala自定义属性查询的方案背景在使用Impala做自助分析的过程中，我们经常发现自定义属性的需求，通常情况下用户会将这种不确定key的字段全部塞到一个MAP字段中，然后通过Impala的复杂结构查询语法进行查询，目前Impala只支持Parquet格式表的schema中使用复杂数据类型（包括STRUCT、ARRAY和MAP），查询语法可以参考 Impala复杂类型语法，但是它存在两个弊