kylin实战总结

Apache Kylin****项目实践

目前基于kylin的数据分析平台已经在业务中开始测试以及使用，并且在用户管理和权限操作方面做了的二次开发改造，以实现project和cube的安全管理。 下图是cube的查询响应图表，cube 大小为157GB，包括一个事实表，14个维度和4个度量：

在项目实践过程中也遇到问题： Hadoop任务内存资源不够，cube计算失败。

调整MapReduce分配资源参数：在cube计算过程中，会出现mr任务失败，根据日志排查，主要因mr的内存分配不足导致，于是，我们根据任务实际情况整体调整了yarn.nodemanager.resource.memory-mb、mapreduce.map.memory.mb、 mapreduce.map.java.opts、mapreduce.reduce.memory.mb、apreduce.reduce.java.opts 等参数。 JVMGC相关参数调优：可以通过GC调优获得更好的GC性能，减少单次GC的时间和FULL GC频率。

使用Apache Kylin的实践总结

1、大的事实表采用天分区增量构建，为了不影响查询性能，可以定期做合并(Merge)，周期可以根据实际情况确定。 2、对于维表比较大的情况，或者查询Select部分存在复杂的逻辑判断，存在Apache Kylin不支持的函数或语句时，可以将事实表和维表的关联处理创建为Hive视图，之后根据视图创建Cube模型。 3、每次查询必然带有的条件建议在字典设置步骤将其设置为Mandatory。这样会最终 Build出来Cube的大小会减少一半。 4、Cube的维度如果超过10个，建议将常用的聚合字段做分组。 5、Cube定义中RowKey顺序：Mandatory维度，Where过滤条件中出现频率较多的维度，高基数维度，低基数维度。 6、当Segment中某一个Cuboid的大小超过一定的阈值时，修改数据分片大小以实现数据读取的并行化，从而优化Cube的查询速度。 7、设计合适的维度编码能减少维度对空间的占用，比如对于高基数的维度如果使用Dict字典编码方式占用大量空间，容易造成构建引擎或查询引擎的内存溢出。 8、对维度进行分片，如果Cuboid中某两个行的Shard by Dimension的值相同，那么无论这个Cuboid最终会被划分多少个分片，这两行数据必然会被分配到同一个分片中，方便查询和索引。 9、部署层面，可以通过Nginx在前端做负载均衡，后端启动多个Query Server接收查询请求处理。

基于Kylin的前景规划

经过项目的摸索和实践，Apache Kylin能很好的解决开篇所说的大数据计算分析的3大痛点问题，提升业务的查询效率。 首先，在接下来我们也将会持续关注Kylin的发展变化，包括数据字典的分布式构建以及基于Kafka定义Streaming Table，从而完成准实时Cube的构建的特性。 其次，规划设计符合需求的拖拽前台界面，支持探索性数据查询。采用拖拽式方便用户使用；规定化前台界面，屏蔽后台技术细节，避免低效的查询出现。 在目前的工作基础上规划构建基于Apache Kylin的大数据OLAP分析平台， 如下图所示：

最后还将继续调研和分析新的存储引擎和构建引擎来满足更多的业务需求。

作者：葡萄喃喃呓语 链接：https://www.jianshu.com/p/c8b2a2c6af78 來源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。