本文将介绍为什么需要在Kylin创建Cube过程中使用Hive视图；而如果使用Hive视图，能够带来什么好处，解决什么样的问题；以及需要学会如何使用视图，使用视图有什么限制等等。 1.为什么需要使用视图 Kylin创建Cube的过程中使用Hive的表数据作为输入源。但是有些情况下，Hive中的表定义和数据并不能满足分析的需求，例如有些列的值需要进行处理，有些列的类型不满足需求，甚至有时候我们在创建Hive表时为了方便快捷，会将Hive表的所有列的字段类型都定义为string，因此很多情况下在使用Kylin之前需要对Hive上的数据格式等问题进行适当的处理。 但是如果在Hive中通过修改原表来解决上面的问题，比如使用alter table的方式修改原始表的Schema信息未免会对其它依赖Hive的组件有所影响（例如可能导致通过Sqoop等方式导入数据失败），而且也有可能导致之前的作业无法正常运行。于是我们需要考虑在不改变原表的情况下解决这个问题，因此我们想到的方案是使用Hive的视图。 当然，除了Hive数据源本身Schema等限制之外，Kylin对于Hive的使用还有一定的限制，这也间接的导致我们需要使用视图： A. 同一个项目下使用相同表（可能根据不同的filter条件过滤，或者设置了不同的维度等）创建了不同的Cube，会导致查询的时候定位到错误的Cube等异常问题。 B. 只支持星型模型 我们的来源表可能包含多张事实表和多张维表，那么就需要将多张事实表整合成一张大的宽表。 2. 如何使用视图 Hive目前只支持逻辑视图，而我们需要的仅仅是对Hive原始的Schema信息的修改，而并非希望通过物化视图优化查询速度，因此目前Hive对视图的支持可以满足Kylin的需要。 下面根据不同的场景分别介绍一下如何创建视图作为Kylin的输入源： A. 分表的情况 两个表具有相同的结构，但是保存不同的数据，例如一个表保存Android端的访问数据，一个访问iOS端的数据，那么就可以通过Hive的view解决。 例如有一个用户有两张表product_android和product_ios，这两个表具有相同的表结构，用户需要将平台（Android或者IOS）作为一个维度进行分析，因此我们为其创建了这样的view：
这样可以将palearn_cube作为事实表来创建Cube，其中而platform作为其中的一个维度 B.自定义函数 Kylin中使用Apache Calcite作为SQL的查询引擎，但是Kylin支持的自定义函数代价比较大，因此如果需要使用自定义函数，那么可以在Hive中创建视图来对字段进行处理。 C.雪花模型的支持 目前Kylin仅支持星型模型，而通过在Hive中创建视图，我们可以很容易地把雪花模型转换为星型模型，甚至生成一个大的宽表。 D.频繁修改表字段名 Kylin直接使用Hive中的字段名作为元数据，如果频繁修改事实表或者维度表的字段名会导致元数据错误（https://issues.apache.org/jira/browse/KYLIN-1173），因此通过视图增加一层映射是比较好的方法，这样可以使得原生的Hive表的字段名对Kylin的Cube透明，此后再需要修改字段名的时候不会对Cube有所影响，只需要修改view的定义。 E.UHC维度 当一个维度的cardinality比较大时可能会出现的问题比较多，首先可能导致Extract Fact Table Distinct Columns这一步时导致reducer出现OOM；其次在创建维度字典树可能会导致维度字典树太大占据大量的内存；另外会导致cube的构建速度缓慢，占用大量的存储空间。此时就需要思考一下这样的UHC维度是否是必须的，是否可以提取出部分信息减小维度，例如timestamp维度，是否可以精确到5分钟，详细地址的维度，是否可以精确到县、镇，这样可以大大减小维度数，而且更详细的信息并没有太大的统计意义。例如url类型的维度，是否可以把参数去掉只保留访问路径。 F.Hive中表字段类型变化 比如我们之前有一个需求计算一个指标的Count Distinct值，虽然这个字段存放的内容为整数值，但是Hive表字段类型为string，Kylin中Count Distinct聚合函数不支持字符类型，因此我们在Hive中创建视图解决这个问题，即将string类型转换为整数类型。 G.复合数据类型处理 由于Hive中可以定义复杂的数据类型，例如map、struct，而Kylin中无法处理这种类型，所以需要使用视图将复杂类型字段进行拆分出维度和度量。 在我们目前的实践中，有一部分Cube依赖的事实表都是通过view创建的，这样增加了一层映射，可以减小cube对原始表的依赖，提高灵活性。
3.使用视图限制 由于Hive的限制，Hive不能对view使用HCatalog获取数据 （https://issues.apache.org/jira/browse/HIVE-10851），因此当你在Kylin中load一个view的时候，Kylin计算表的cardinality的job无法获取到cardinality的值，这时就要求用户知道每一列的cardinality大致的情况，如果实在不确定可以到Hive里面查询一下。 4.使用视图实战 这里我给朋友们简单演示一下视图的使用，其实视图在我们项目中还是会经常遇到的。 不知道朋友们还记不记得之前我们创建过三张表（请查看“Apache Kylin进阶部分之多维分析的Cube创建实战”章节）：
如果您根据本书实战的话，当前Hive的kylin_flat_db数据库下面应该有这三张表。我们现在将在Hive中对这三张表创建视图，根据视图来构建Cube，大概步骤如下： 步骤一：创建视图 在Hive Cli中执行如下SQL：
这里对cookieid字段（字符串类型）使用hash函数处理，结果处理为整数类型，我们这样做的目的是为了使用Count Distinct（目前只支持整数类型）精确去重。 注：hash算法的特点是可重复和不可逆的，即针对不同的字符串进行hash处理，结果可能会重复的，所以上面的方法存在一定的问题。在实际项目中我们使用Hive自定义函数对需要使用Count Distinct精确的字段（整数类型就不必处理了）处理成整数类型。 步骤二：创建项目 创建“view_project”工程，当然也可以使用任何已经存在的工程。 步骤三：导入数据源 导入kylin_flat_db数据库下刚才创建的视图v_pvuv。 步骤四：创建Model 这里我们作为演示，只选了一张视图作为事实表，没有维表。其中： 维度字段：v_date，regionname，cityname 度量字段：cookieid，pv 分区字段：v_date 步骤五：创建Cube 因为朋友们对于如何创建Cube都很熟悉了，这里我们简要罗列几步。 创建Cube所选的维度如下： 创建Cube所选的度量如下：
其中我们使用精确的COUNT_DISTINCT函数来计算cookieid字段中值，所以返回类型为bitmap。 步骤六：构建Cube 设置构建的结束时间，然后构建Cube。 步骤七：查询Cube 查询如下SQL： 结果为：
在我们使用Kylin的过程中，对于上面提到的问题很多都可以通过Hive的视图进行解决。如果朋友们在Kylin使用过程中遇到一些Kylin自身无法解决的时候，可以尝试一下Hive的视图，也许会给您带来惊喜。
相关书籍推荐：
扫描二维码购买本书
本文转载于微信公众号: 程序人生(coder_life)，更多微信文章请扫描关注公众号: |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
