大家都知道，企业中的查询一般分为即席查询和定制查询两种。对于即时查询需求我们用presto和Impala做为引擎(为什么会用到两个?这个问题跟我们的需求演化和公司系统架构有关系，presto从支持标准的sql上看，可以减轻业务侧对现有的功能sql改造，简单来说就是为了兼容现状。部署的环境依赖也比较简单，方便部署；而Impala主要是用在大数据需求新功能上，又方便检索冷热数据的聚合)。而定制查询，它的场景多数是对用户的操作或是对下线的业务数据做出实时分析，如果用Hive或SparkSQL作为查询引擎，估计要花上数分钟甚至数十分钟的时间才能响应，显然是不能满足需求的。在很长一段时间里，企业只能对数据仓库中的数据进行提前计算，再将算好后的结果存储在APP层或DW层上，再提供给用户进行查询。但是上面我们也说了，当业务复杂度和数据量逐渐升高后，使用这套方案的开发成本和维护成本都显著上升。因此，对于已经固化下来的查询进行亚秒级返回的解决办法。我们使用了Apache Kylin，我们只需要提前定义好查询维度，Kylin就能帮助我们进行计算，并将结果存储到结果表中。这样不仅很好地解决了海量数据快速查询的问题，也减少了手动开发和维护提前计算程序的成本。
但是Kylin默认将计算结果放入到Hbase中，从上图看，没有看到Hbase，而是Kudu。因为我们自己实现了Kylin与Kudu的整合。
Kylin使用Kudu存储引擎
存储引擎，我们引入自研的storage-kudu模块替代默认的storage-hbase。Kylin依赖的三大模块：数据源、构建引擎、存储引擎。数据源我们还是使用Hive, 至于在kudu中的数据，因为上面已经解决了Hive支持kudu的方案，所以Kylin通过Hive也可以加载到Kudu中的数据。构建引擎我们使用了Kylin支持的spark计算引擎。而spark同时也是支持与Kudu整合的。从源码上看，Kylin架构要求扩展存储引擎需要实现IStorage接口，这接口有两个函数一个是指定构建Cube引擎接口adaptToBuildEngine和能够查询Cube的createQuery接口，剩下的数据在Kudu的存取细节基本都直接使用spark支持Kudu的api。
实时离线开发统一访问数据入口部分分析数据，比如用户的满意度调查、水电费使用统计等，在即时查询系统中已经存在，不就需要再同步一份数据到hdfs当中。为了减少存储空间成本，避免数据多份存储，那么就至少需要解决在Kudu中的数据能让hive能访问到。但是我们使用的hive版本中，hive并不支持Kudu表的操作，预告最新的hive4.0版本中，也未开发完成。
需要解决的问题：
即时系统中存在Kudu表数据，需要通过Hive能访问，这点仿照Impala，创建外部表 ，将kudu的表映射到Hive上
Hive能像Impala一样，能创建表、查询、更新、删除操作
Kylin能使用Kudu表
保证数据结构和元数据信息的一致性
Hive、Kudu元数据整合：
从Hive官网公布信息和源码分析来看，核心类KuduStorageHandler、KuduSerDe、KuduInputFormat、KuduOutputFormat已经实现一分部功能，KuduMetaHook还没有，保证 meta 的一致性需要必须实现HiveMetaHook。从源码上看KuduStorageHandler已经继承了DefaultStorageHandler和实现了HiveStoragePredicateHandler，再实现与HMS的交互就可以对 Kudu meta 的相关操作和可以发现Kudu的表并进行操作了(与《CDH6.3.2升级Hive到4.0.0》文章中使用同个版本)。
其中即时系统实时同步到Kudu的表数据，也需要创建Hive外部表，把kudu表映射到Hive来，也是在KuduStorageHandler中实现，包括数据的查询、修改、删除。通过在数据集成服务的《同步管理》模块中，每次创建数据同步任务时，都会去连接Hive并创建Kudu的外部映射表。
如此一来，不管上层使用的SparkSQL、Kylin还是HQL访问hdfs或kudu的表，对开发者或对数据使用者来说都是统一的入口。
透明的数据分层存储