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