背景及现状
汽车之家是一家力求为消费者提供最新汽车报价,汽车图片,汽车价格大全,最精彩的汽车新闻、行情、评测、导购内容,是提供信息最快最全的中国汽车网站。
在公司发展过程中，之家运用了各种各样的数据管理系统来存储与管理各种各样的数据：关系型数据库、NoSQL 数据库、文档数据库、Key-value 数据库，对象存储系统等等。形态多样的数据管理系统为之家在管理数据上带来便利的同时，随之而来的是管理与充分利用这些数据系统存储的数据的难题。
无论是关系型数据库中的MySQL，抑或是 Hadoop 体系下的 Hive，这些目前业界通用的数据管理系统都有自成体系的一套 SQL 方言，在之家的业务系统中，也运用到了这些数据关系系。
所以在之家，需求方想要分析某一种数据管理系统的数据，就得熟练掌握某一种 SQL 方言；为了对不同数据源进行联合查询，就得在应用程序逻辑中使用不同的客户端去连接不同的数据源，由之而来带来的问题是：整个分析过程架构复杂，编程入口多，系统集成困难，这对于涉及海量数据的数据分析工作变得十分痛苦。
解决方案
针对上述问题，之家调研了多种方案和技术可行性，最终选择openLooKeng。
首先，在之家用到了RDBMS、NoSQL、Hive、MPPDB等多种类型数据仓库，openLooKeng可以实现这些数据仓库的联合查询。其次，利用openLooKeng的跨源异构查询能力，之家需求方可以快速分析海量数据，从而揭示出数据背后的真相，为上层提供决策的依据，指导业务发展。最后，openLookeng为开源项目，社区活跃度高，出现问题可以和社区共同快速解决。
关键特性
让我们先来看看 openLooKeng 的一些关键特性，以便更深入的理解为什么open LooKeng 和之家的业务场景相符合，甚至您也可以基于 openLooKeng 的这些能力进一步探索更多的业务场景。
1. ANSI SQL2003 语法的支持
在之家的多种业务场景中，使用的是 ANSI SQL2003 语法，由于openLooKeng支持此语法，所以之家用户使用 openLooKeng 语法进行查询时，一方面无需改变之前查询习惯，无差异运用。另一方面无论底层数据源是 RDBMS 还是 NoSQL 或者其他数据管理系统，借助 openLooKeng的Connector 框架，数据可以依然存放在原始的数据源中，从而实现数据平滑迁移的查询。
最后，通过 openLooKeng 的统一 SQL 入口，可实现对底层各种数据源 SQL 方言的屏蔽，之家用户无需再关心底层数据源的 SQL 方言便可获取到该数据源的数据，方便用户消费数据。
2. 多种多样的数据源 Connector
在之家运用了多种数据管理系统，openLooKeng 针对这些数据管理系统都有对应的数据源 Connector，包括 RDBMS（Oracle Connector），NoSQL（Hive Connector、HBase Connector 等），全文检索数据库（ElasticSearch Connector 等）。openLoo Keng 可以通过这些多样的 Connector 方便的获取到数据源数据，从而进一步进行基于内存的高性能联合计算。
3. 高性能的查询优化技术
openLooKeng 在内存计算框架的基础上，还利用许多查询优化技术来满足高性能的交互式查询的需要。
3.1 索引
openLooKeng 提供基于 Bitmap Index、Bloom Filter 以及 Min-max Index 等索引。通过在现有数据上创建索引，并且把索引结果存储在数据源外部，在查询计划编排时便利用索引信息过滤掉不匹配的文件，减少需要读取的数据规模，从而加速查询过程。
3.2 Cache
openLooKeng 提供丰富多样的 Cache，包括元数据 cache、执行计划 cache、ORC 行数据 cache 等。通过这些多样的 cache，可加速用户多次对同一 SQL 或者同一类型 SQL 的查询时延响应。
3.3 动态过滤
所谓的动态过滤是指是在运行时（run time）将 join 一侧表的过滤信息的结果应用到另一侧表的过滤器的优化方法，openLooKeng 不仅提供了多种数据源的动态过滤优化特性，还将这一优化特性应用到了 DataCenter Connector，从而加速不同场景关联查询的性能。
3.4 算子下推
openLooKeng 通过 Connector 框架连接到 RDBMS 等数据源时，由于 RDBMS 具有较强的计算能力，一般情况下将算子下推到数据源进行计算可以获取到更好的性能。openLooKeng 目前支持多种数据源的算子下推，包括 Oracle、HANA 等，特别地，针对 DC Connector 也实现了算子下推，从而实现了更快的查询时延响应。
商业数据分析应用实践
在之家的商业化广告、线索等多个业务线，每个业务线根据不同的业务场景，分别使用不用的数据源，这些数据存储系统往往相互隔离，形成相互独立的数据孤岛。当针对不同业务线的不同数据源或者同业务线的不同数据源进行联合数据分析的时候，openLookeng起到了至关重要的作用。针对数据开发和分析师应用场景如下：
针对开发而言。针对上述业务场景，按照一般解决思路，把数据都统一入统一数据源，然后在统一数据源中查询分析，导致数据链路长，数据完整性和时效性不能保证，数据校验时，产生额外的数据验证时间，并且验证逻辑复杂化。引入openLooKeng后，可以直接在自带页面或者通过JDBC驱动的方式从JAVA访问openLookeng,配置中增加业务数据所存储的各种数据源，直接就可以用统一查询SQL进行夸源查询，提升开发效率。
站在分析师角度。面对海量数据，如果不知道数据用在哪里、怎么用，就无法基于海量数据构建新的业务模型。分析师对个业务线数据进行商业分析时，需要从业务数据所存储的多个数据源中获取数 据，如RDBMS(如MYSQL,ORACLE等)或者NOSQL(如HIVE,HBASE等)。
查询不同的数据源，需要不同的连接方式或客户端，运行不同的SQL方言。这些差异导致额外的学习成本和复杂的应用开发逻辑，另外，每种数据源自带的函数，比如字符串函数、窗口函数、计算函数等，对应的函数名称或者参数也不相同，所以使用时，需要分别区分处理，加大了工作量，数据错误率也会上升。
引入openLookeng后，提供统一SQL接口，自动屏蔽各个数据源语法差异，减去学习的时间，分析师商业化分析效率大大提高。
升级Apache Kylin连接器
之家商业化业务强度依赖的Kylin并没有被openLooKeng覆盖，openLooKeng 对Kylin数据源的支持不完善，达不到使用要求，所以我们决定升级Kylin连接器并贡献给社区。
首先介绍下Kylin。Kylin是一个开源OLAP分析引擎，提供HADOOP之上的SQL查询接口以及多维分析能力以支持超大规模数据。作为一款OLAP分析工具，在之家有着相当广泛的应用，所以Kylin和其他数据源的跨源查询需求随之而来。
其次解释下openLooKeng连接器(connector,以下连接器用connector代替)。connector是用于在 openLooKeng 中进行查询的所有数据的源。即使您的数据源没有可以支持它的基础表，只要将您的数据源与 openLooKeng 期望使用的 API 相适配，您也可以针对这些数据编写查询。
最后详细介绍对Kylin connector升级的关键点：
1. 元数据
Kylin元数据和其他RDBMS如MYSQL不同，它包括HIVE表的元数据和Kylin的元数据，Kylin的元数据包括Project，Model，Cube，Segment多种元数据信息，所以针对Kylin元数据的操作和RDBMS相比有区别。比如获取查询SQL的列信息，Kylin是基于Apache Calcite来实现SQL解析和优化，包括生成执行计划，所以对于Kylin SQL的列信息获取基于Calcite来实现。如下图：
2. SQL关键字
当在Kylin中查询使用SQL关键字时，要加上双引号，并且里面的内容要大写，这点与其他的RDBMS也不相同，需要单独处理。如下图：
在KylinSqlStatementWriter类中重写select方法，对sql中的关键字进行特殊处理。其中处理具体规则如下：
如果Kylin中的查询SQL语句中，对列的重命名名称为sum、count、min、max、rank关键字，则将关键字加上双引号，并且大写处理。
3. SQL优化器
在正常使用过程中，发现openLooKeng的优化规则SingleDistinctAggregationGroupBy对Kylin connector不适用,因为对于Kylin而言，只有当查询的模式和cube定义相匹配的时候，Kylin才能用对应的cube数据来完成查询，但是对于SingleDistinctAggregationGroupBy这个规则优化查询之后，输出和原有的SQL差异比较大的时候，造成匹配不上原有cube，则导致查询不到数据。所以需要升级SQL优化器。
3.1 介绍
下图为openLooKeng执行SQL的各个环节，查询语句经过解析之后形成抽象语法树，然后经过Analyze生成逻辑计划，逻辑计划再经过一系列的优化规则来生成更高效的逻辑计划，进而转成物理计划。在逻辑计划优化阶段，openLooKeng提供了几类查询优化器(比如基于成本的优化，基于rule的优化，支持table下推优化器规则)，每类优化器提供几十种优化规则。
其次补充说明：SingleDistinctAggregationToGroupBy优化规则对Kylin不适用的原因，由于SingleDistinctAggregationToGroupBy规则是对指标进行distinct的SQL优化，优化逻辑为将SQL转换成group by ,然后再count计算，其实就是采用“分治”的思想来提升查询效率，对于如下SQL：
当经过此规则优化之后，输出如下：
但是优化之后的SQL匹配不到对应cube，所以当Kylin的sql进行查询优化的时候，需要过滤此规则。
3.2 自定义规则方案
首先,根据上述优化规则是针对逻辑计划的。LogicalPlanner类就是对解析出来的抽象语法树（AST）生成逻辑计划，我们可以从下图看出，planOptimizers包含了几类优化规则，而SingleDistinctAggregationToGroupBy是属于IterativeOptimizer这类规则。
针对Kylin connector自定义过滤规则，有两种方案，如下：
方案一：基于openLooKeng的下推框架，将执行计划树传递给connector，再将PlanOpt
imizerst提供给执行优化引擎，这样可以让connector引入针对自己的任意优化规则。基于此方案，是否可以将SingleDistiAggregation ToGroupBy优化规则在Kylin
connector中实现过滤。但是此框架只能增加自定义优化规则，不能修改原有系统规则，如下图，所以此方案不可行。
方案二：利用OptimizerUtils工具类提供的两个方法，来判断上文中系统自带的优化规则是否适用于此逻辑计划，所以对规则的过滤是在OptimizerUtils类中实现。目前采用的是这种方案。
3.3 自定义规则初始化
接下来为了实现代码的可扩展性和可维护性，将自定义的过滤规则配置在文件中，由于connector的连接信息已经有独立的配置文件，所以直接在此文件中增加配置项“blacklist”。如下图：
下面介绍如何将新增配置项初始化到系统中。在主程序启动类PrestoServer的start方法中调用StaticCatalogStore.loadCatalogs的方法来进配置和连接信息初始化。如下图：
过滤规则初始化到OptimizerUtils类的planOptimizerBlacklist静态变量中，如下图；
3.4 自定义规则过滤
首先，在OptimizerUtils类的isEnabledLegacy方法中实现规则过滤。首先通过逻辑执行计划解析出SQL中的catalog列表，然后遍历优化器中的优化规则，如果优化规则在数据源catalog配置列表中，则此规则不起作用。
其次，获取catalog列表时，由于上文提到的几十种规则都是对于同一逻辑计划进行优化，所以用threadlocal维护一个解析后的线程本地变量，在同一请求中，只解析一次执行计划，避免重复解析，提升效率。
最后，讲解如何解析逻辑计划，由于逻辑计划为一个计划树，树上有通过解析SQL得到的节点，比如TableScanNode，ProjectNod，JoinNode，FilterNode等，比如如下SQL：
对应的逻辑计划树为：
由于需要获取表对应的数据源catalog，所以我们只关心TableScanNode节点，递归计划树，获取到所有表的数据源catalog。如下图：
总结与规划
引入openLooKeng后，之家具备了跨源异构的数据查询能力，覆盖了同业务线的或不用业务线的不同数据源的分析业务场景，提高了之家用户数据分析效率。另外，根据之家自身业务需要，升级Kylin connector并贡献给社区，使openLooKeng的connector更加丰富，同时覆盖了之家更多的应用。
后续我们持续关注openLooKeng社区发展，并且接入之家更多的业务和分析场景，不断完善和持续更新迭代openLooKeng，和社区共同成长。
