Kyligence是一家专注于大数据分析领域创新的数据科技公司，提供基于Apache Kylin的企业级智能分析平台及产品，以及可靠、专业、源码级的商业化支持；并推出Apache Kylin开发者培训，颁发全球唯一的Apache Kylin开发者认证证书。
说到Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。每一层的计算都是一个单独的Map Reduce任务。如下图所示。
MapReduce的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在column family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有良好的快速响应和高并发。
有了这些预计算的结果，当收到用户的SQL请求，Kylin会对SQL做查询计划，并把本该进行的Join、Sum、Count Distinct等操作改写成Cube的查询操作。
Kylin提供了一个原生的Web界面，在这里，用户可以方便的创建和设置Cube、管控Cube构建进度，并提供SQL查询和基本的结果可视化。
北京移动也在meetup上展示了Kylin在电信运营商的应用案例，从数据上看，Kylin能够在比Hive/SparkSQL在更弱的硬件配置下获得更好的查询性能。
目前，有越来越多的国内外公司将Kylin作为大数据生产环境中的重要组件，如ebay、银联、百度、中国移动等。大家如果想了解更多社区的案例和动态，可以登录Apache Kylin官网或Kyligence博客进行查看。
开发者和用户可以通过定制开发，将Kylin接入除Hadoop/HBase/Hive以外的大数据系统，比如用Kafka代替Hive作数据源，用Spark代替MapReduce做计算引擎，用Cassandra代替HBase做存储，都将变得更为简单。这也保证了Kylin可以随平台技术一起演进，紧跟技术潮流。
在Kylin 1.5.x中还对HBase存储结构进行了调整，将大的Cuboid分片存储，将线性扫描改良为并行扫描。基于上万查询进行了测试对比结果显示，分片的存储结构能够极大提速原本较慢的查询5-10倍，但对原本较快的查询提速不明显，综合起来平均提速为2倍左右。
除此之外，1.5.x还引入了Fast cubing算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。对500多个Cube任务的实验显示，引入Fast cubing后，总体的Cube构建任务提速1.5倍。
另一个重要的功能是Diagnosis。用户经常会遇到一些棘手的问题，例如Cube构建任务失败、SQL查询失败，或Cube构建时间过长、SQL查询时间过长等。但由于运维人员对Kylin系统了解不深，很难快速定位到root cause所在地。我们在mailing list里也经常看到很多用户求助，由于不能提供足够充分的信息，社区也很难给出一针见血的建议。
当一个cube构建任务执行失败或时间过长，用户可以单击Job下的Diagnosis按钮。同样的，系统会抓取和下载Job相关信息成一个zip包。
我突然冒出的一个想法：为什么是DBToCode？
看过了几个代码自动生成器，基本上是从数据库开始，自动生成代码，首先对他们的工作表示肯定，觉得他们做的比较好，有很多地方值得学习。 但是，仔细的想一下，为什么要从数据库开始呢，数据库是最原始的么？我想，最原始的应该是数据类型，能不能从数据类型开始，编写一个代码自动生成的工具软件呢？即：只要先定义需要的数据类型，然后根据这些数据类型自动建立数据库以及表，再到存储过程、数据的访问等等…… 这条路是不是可行的呢？ 突然之间冒出了这个想法，再也睡不着了，于是爬起来，开始构思，加上刚刚研究了NASA的WorldWind（一个类似于GoogleEarth的3D地图软件），NASA的WW里边展示的元素（地图、图标、边界线以及地名）都是用Xml表示的，而且有一个LayerSet的Xml架构文件，里边定义了所有WW可以展示的元素的数据类型。如果先用Xml架构文件定义Xml数据类型，然后根据Xml架构文件建立自动数据库，生成访问数据库的存储过程，然后再根据Xml架构文件生成数据访问的代码，如果可以的话，将会大量减轻开发人员的工作量。 因此，我决定编写这样的一个工具，从Xml架构文件开始，自动生成数据库和代码...
