apache calcite

原文作者：王长春，来自平安银行零售大数据团队 概述 Apache Calcite是一个基础的软件框架，它提供了查询处理、查询优化以及查询语言支持的能力。很多流行的开源数据处理系统例如Apache Hive,Apache Storm,ApacheFlink,Druid等都采用了它。 下图是采用Apache Calcite的开源数据处理系统，以及Calcite能连接到的数据源。 大多数数据处理系统是使用Calcite来做SQL解析和查询优化。还有部分使用Avatica(Calcite的子项目)来构建自己的JDBC driver。还有部分使用Calcite来重写查询请求以使用物化视图。 最近十几年来，出现了很多专门的数据处理引擎。例如列式存储、流处理引擎、文档搜索引擎等等。这些引擎宣称他们在特殊方面能提供更高“性价比”的性能，并且宣称“one size fits all”范式的时代已经终结了。Spark、Storm、Flink、Elasticsearch、Druid等多种引擎的流行确实说明了这一点。 这些数据处理引擎都面临着一些共同但是难以解决的问题。 一是数据处理引擎都要做查询优化以及提供sql查询语言或者其他DSL查询语言。 二是使用者可能使用了多个专门的数据引擎，例如使用了ES、Spark、Druid.那么使用者很可能会有在异构数据源上支持查询以及查询优化的需求。 Apache

1. 背景 calcite作为一款开源的动态数据管理框架（ https://calcite.apache.org/ ），它具备很多典型数据库管理系统的功能，比如SQL解析、SQL校验、SQL查询优化、SQL生成以及数据连接查询等，但是又省略了一些关键的功能，比如Calcite并不存储相关的元数据和基本数据，不完全包含相关处理数据的算法等。 也正是因为Calcite本身与数据存储和处理的逻辑无关，所以这让它成为与多个数据存储位置（数据源）和多种数据处理引擎之间进行调解的绝佳选择。 Calcite所做的工作就是将各种SQL语句解析成抽象语法树（AST Abstract Syntax Tree），并根据一定的规则或成本对AST的算法与关系进行优化，最后推给各个数据处理引擎进行执行。 Calcite整体架构如下图所示： Hive，Flink，Storm都使用Calcite作为其SQL解析优化引擎。 2. Calcite适配器 这里需要提到一个重要的概念：Schema adapters（ https://calcite.apache.org/docs/adapter.html ） A schema adapter allows Calcite to read particular kind of data, presenting the data as tables within a

前言 不知不觉，2020年已经过去一半了，最近突然反应过来自己也看了不少文献资料了，就想着把看过的文献和觉得比较好的书籍做一个总结，基本都是大数据分布式领域的，回顾自己学识的同时，也给想从事或这个领域的小伙伴一些参考 😃。最后顺便把接下来要看的东西列个列表，也会将自己学习的心得和经验分享出来，有需要的童鞋可以参考参考。 另外有些文献看完我会进行整理和输出，这部分链接我一并附在文献的介绍后面，后面看的书或是文献也会保持这种习惯，如果觉得有兴趣欢迎各位大佬交流，顺便也可以点波关注~~ 论文总结 MapReduce 《MapReduce Simplified Data Processing on Large Clusters》 从现在的眼光来看，Mapreduce可以说可圈可点。但在那个年代，这个思想可以说是相当先进的。不得不说Google一直引领技术潮流，包括近几年流行的k8s也是Google主导。 这篇文章主要介绍了Mapreduce的流程还有一些细节方面的介绍，如果已经有使用过Mapreduce编程的小伙伴应该看一遍就能懂。另外，看完如果想加以巩固的话，推荐做MIT6.824的Lab1，用go实现一个Mapreduce。至于什么是Mit6.824，百度一下就知道喔。我以前也有写过一篇介绍MR，有兴趣的童鞋不妨看看： 从分治算法到 Hadoop MapReduce 。 地址：

我们在第 02 课时中使用 Flink Table & SQL 的 API 实现了最简单的 WordCount 程序。在这一课时中，将分别从 Flink Table & SQL 的背景和编程模型、常见的 API、算子和内置函数等对 Flink Table & SQL 做一个详细的讲解和概括，最后模拟了一个实际业务场景使用 Flink Table & SQL 开发。 Flink Table & SQL 概述 背景 我们在前面的课时中讲过 Flink 的分层模型，Flink 自身提供了不同级别的抽象来支持我们开发流式或者批量处理程序，下图描述了 Flink 支持的 4 种不同级别的抽象。 Table API 和 SQL 处于最顶端，是 Flink 提供的高级 API 操作。Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL 语义的开发语言。 我们在第 04 课时中提到过，Flink 在编程模型上提供了 DataStream 和 DataSet 两套 API，并没有做到事实上的批流统一，因为用户和开发者还是开发了两套代码。正是因为 Flink Table & SQL 的加入，可以说 Flink 在某种程度上做到了事实上的批流一体。 原理 你之前可能都了解过 Hive，在离线计算场景下 Hive 几乎扛起了离线数据处理的半壁江山

自 Google Dataflow 模型被提出以来，流批一体就成为分布式计算引擎最为主流的发展趋势。流批一体意味着计算引擎同时具备流计算的低延迟和批计算的高吞吐高稳定性，提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的。对用户来说流批一体很大程度上减少了开发维护的成本，但同时这对计算引擎来说是一个很大的挑战。 作为 Dataflow 模型的最早采用者之一，Apache Flink 在流批一体特性的完成度上在开源项目中是十分领先的。本文将基于社区资料和笔者的经验，介绍 Flink 目前（1.10）流批一体的现状以及未来的发展规划。 概况 相信不少读者都知道，Flink 遵循 Dataflow 模型的理念: 批处理是流处理的特例。不过出于批处理场景的执行效率、资源需求和复杂度各方面的考虑，在 Flink 设计之初流处理应用和批处理应用尽管底层都是流处理，但在编程 API 上是分开的。这允许 Flink 在执行层面仍沿用批处理的优化技术，并简化掉架构移除掉不需要的 watermark、checkpoint 等特性。 图1. Flink 经典架构 在 Flink 架构上，负责物理执行环境的 Runtime 层是统一的流处理，上面分别有独立的 DataStream 和 DataSet 两个 API，两者基于不同的任务类型（Stream Task/Batch Task）和

从"UDF不应有状态" 切入来剖析Flink SQL代码生成 目录 从"UDF不应有状态" 切入来剖析Flink SQL代码生成 0x00 摘要 0x01 概述结论 1. 问题结论 2. 问题流程 0x02 实例代码 1. UDF函数 2. 测试代码 3. 输出结果 0x03 Flink SQL UDF转换流程 1. LogicalFilter 2. FilterToCalcRule 3. LogicalCalc 4. DataSetCalc 5. generateFunction (问题点所在) 6. FlatMapRunner 0x04 UDF生成的代码 1. 缩减版 2. 完整版 0x05 总结 0x00 摘要 "Flink SQL UDF不应有状态" 这个技术细节可能有些朋友已经知道了。但是为什么不应该有状态呢？这个恐怕大家就不甚清楚了。本文就带你一起从这个问题点入手，看看Flink SQL究竟是怎么处理UDF，怎么生成对应的SQL代码。 0x01 概述结论 先说结论，后续一步步给大家详述问题过程。 1. 问题结论 结论 是：Flink内部针对UDF生成了java代码，但是这些java代码针对SQL做了优化，导致在某种情况下， 可能 会对 " 在SQL中本应只调用一次 " 的UDF 重复调用 。 我们在写SQL时候，经常会在SQL中只写一次UDF

[源码分析] 带你梳理 Flink SQL / Table API内部执行流程 目录 [源码分析] 带你梳理 Flink SQL / Table API内部执行流程 0x00 摘要 0x01 Apache Calcite 1. Calcite 概念 2. Calcite 处理流程 0x02 Flink SQL综述 1. Flink关系型API执行原理 2. Flink Sql 执行流程 3. Flink Table Api 执行流程 4. Flink Table/SQL 执行流程的异同 0x03 Flink SQL 相关对象 1. TableEnvironment对象 2. Catalog 3. StreamPlanner 4. FlinkPlannerImpl 5. Table 和 TableImpl 0x04 Flink SQL 具体流程 1. SQL 解析阶段（SQL–>SqlNode） 2. SqlNode 验证（SqlNode–>SqlNode） 3. 语义分析（SqlNode–>RelNode/RexNode） 4. 优化阶段（RelNode–>RelNode） 优化器的作用 基于成本优化（CBO） VolcanoPlanner相关概念 VolcanoPlanner执行步骤 优化规则 StreamExecUnionRule StreamExecJoinRule 5.

从flink的官方文档，我们知道flink的编程模型分为四层，sql层是最高层的api，Table api是中间层，DataStream/DataSet Api 是核心，stateful Streaming process层是底层实现。 其中， flink dataset api使用及原理 介绍了DataSet Api flink DataStream API使用及原理 介绍了DataStream Api flink中的时间戳如何使用？---Watermark使用及原理 介绍了底层实现的基础Watermark flink window实例分析 介绍了window的概念及使用原理 Flink中的状态与容错 介绍了State的概念及checkpoint，savepoint的容错机制 上上篇< 使用flink Table &Sql api来构建批量和流式应用(1)Table的基本概念 >介绍了Table的基本概念及使用方法 上篇< 使用flink Table &Sql api来构建批量和流式应用(2)Table API概述 > 本篇主要看看Flink Sql 有哪些功能及背后的原理 1. sql功能 体现在org.apache.flink.table.api.TableEnvironment，目前flink仅支持select和insert操作 (1) select /** *