kylin原理第一篇 整体架构

• 整体架构
• 优点
• 缺点
• 使用场景

kylin整体架构：

优点：

• 模块规整、思路清晰。api模块就是api服务的，在这个逻辑，如果是查询就跳转到queryService模块，该模块内部又有sql解析模块、然后到物理执行计划产出，最后到hbase的执行产出，数据返回，服务端整合数据返回。
• 可插拔的组件方式，对于现在大数据技术迭代很频繁的年代，而且大数据技术一般组件化的方式比较多，可插拔的方式有很大的拓展性。
• 预聚合的方式就是快。只要查询的语句能够命中cuboid，查询就是极其快速的。
• 精确去重。
• 支持join查询。

缺点：

• 缓存比较鸡肋。sql级别的缓存有时候穿透率很高。至少在我们的使用场景里，查询穿透率几乎80%以上。如果缓存能够在数据seg级别，那缓存使用率就高很多。在2.6版本之后，已经有了这方面的改进，不过是缓存在hbase端，靠协处理器改进，这对于hbase服务提出了更高的要求。
• 数据build时间很长。跟druid或者别的预聚合引擎相比，kylin的build时间是几倍的大小。
• 数据膨胀率比较高。对hbase的压力会比较大。
• 存储端，目前用的是hbase，严重依赖协处理器。高并发的时候，有服务hang住的状况发生，而且没有索引的使用，在高并发的时候，IO暴增。
• 服务端有OOM的风险，主要是在高基数列的情况下，加载字典就爆了。
• 如果遇到维度变化，重新构建整体cube的成本就比较高。
• 单个cube最高63个维度。

使用场景：

• 维度变化不频繁。
• 维度基数可控，不能太高。
• update数据变化比较多的。

kylin系列整理：

• 1、kylin的整体架构
• 2、kylin的任务生成（源码解析）
• 3、kylin的job任务运行（源码解析）
• 4、kylin的build原理（源码解析）
• 5、kylin的query原理（源码解析）
• 6、kylin的cuboId计算原理（源码解析）
• 7、kylin的精确去重原理（源码解析）
• 8、kylin的协处理器原理（源码解析）