使用maven插件优化项目

记录可以用于优化项目的maven插件。

蓄水池采样算法

蓄水池采样算法是一种随机抽样算法，它能够在一个很大的集合中，抽取一部分样本，并保证每个样本的选取概率都是相等并随机的。

• 特点：
  • 选取集合可以非常大，甚至不知道边界。
  • 每个样本的选取随机且概率相等。
  • 时间复杂度较低，O(n)，节省内存。
• 适用场景：
  • 在一些非常大的集合，或者未知大小的集合，不知道边界的集合，不知道文件总行数的情况下，随机抽取k个元素。
  • 保证每个元素抽取都是均匀随机的并且概率相等。
  • 尽量高效，节省内存地抽取

Trino源码学习-内存管理

Trino中的内存管理分为两块:

• LocalMemoryManager: 在ServerMainModule中声明，用于管理当前节点的内存使用
• ClusterMemoryManager: 在CoordinatorModule中声明，用于管理集群的内存使用

Trino源码学习-TASK执行

上篇我们介绍了查询是如何调度的。本篇将介绍Task的执行。

HikariCP: Failed to validate connection

最近在日志中常常看到HikariCP的warnning.

1

Failed to validate connection com.mysql.jdbc.JDBC4Connection@xxxxx (...)Possibly consider using a shorter maxLifetime value.

相关配置

HikariCP相关配置

• minimumIdle: 池的最小连接数
• maximumPoolSize: 池的最大连接数
• idleTimeout: 允许连接在池中闲置的最长时间。仅在minimumIdle小于maximumPoolSize时使用。池中连接小于minimumIdle时，空闲连接将不会被取消。
• maxLifetime: 池中连接的最长生命周期。0 表示没有最大生命周期约束。
• keepaliveTime: HikariCP 连接保活的时间间隔。该值必须小于maxLifetime
• connectionTimeout: 控制客户端等待池中连接的最长毫秒数，如果在没有连接可用的情况下超过此时间，则抛出SQLException。

mysql相关配置

• wait_timeout: mysql 为了防止空闲连接浪费，占用资源，在超过wait_timeout 时间后，会主动关闭该连接，清理资源。通过show variables like 'wait_timeout%'可以查询该配置值。

通过对上面配置的了解，结合日志告警，应该是maxLifeTime设置的过长了。导致池中存在已经被close的连接。所以maxLifeTime要小于空闲连接的回收时长(例如 mysql的wait_timeout )。

注意, 应用和数据库中间可能存在HA和DB proxy，maxLifeTime也需要考虑中间链接的空闲超时。

Trino源码学习-查询调度

上篇分析了SQL逻辑执行计划的生成，本篇将继续分析逻辑计划是如何在进行调度的。

The Snowflake Elastic Data Warehouse

摘要

我们生活在分布式计算的黄金时代。公有云平台几乎能够按需提供无限的计算和存储资源。同时，SaaS模型(Software-as-a-Service)将企业级系统带给了无法负担成本和相关系统复杂性的用户。传统的数仓系统正在努力的适应新的环境，但是首先，它是为固定资源而设计，从而没办法利用云的弹性能力。另外，传统的数仓依赖复杂的ETL流水线和物理调优，这个是和云的半结构数据和快速解决工作问题的新形式所需要的弹性和快速不一致的。

我们决定进行根本性的重新设计。我们的任务是去建立云上的企业级数据仓库的解决方案。就是Snowflake弹性数据仓库，简称Snowflake。Snowflake是一种多租户、事务性、安全、高度可扩展的弹性系统，具备完整的SQL支持和半结构化和schema-less数据模式支持。Snowflake在亚马逊云上提供现付即用的服务。用户只需将数据导入云上，就可以立即利用他们熟悉的工具和界面进行管理和查询。从2012年底，Snowflake开始计划实施，到2015年6月，Snowflake已经可以大体可用。现在，Snowflake被越来越多的大大小小的组织用于生产。这个系统每天运行几百万次查询在几PB的数据上。

本文主要介绍Snowflake的设计、多集群共享数据的结构和Snowflake的关键特性：极致的弹性和可用性、半结构化和schema-less的数据支持、时间旅行、端到端的安全性，最后是一些经验总结和对未来工作的展望。

Trino源码学习-SQL语法树解析

Trino在查询提交时，会将SQL文本解析成语法树。Trino将这一动作分为2个部分:

flowchart LR
    s1(SQL)-->|Parser base Antlr|s2(ANTLR AST)
    s2-->|AST builder base Antlr Visitor|s3(Presto AST)

Antlr Parser

Antlr的使用在Trino中就不多做介绍了，简单来说，Antlr基于类似巴斯卡范式(BNF)的语法规则和词法规则文件，动态生成Parser和Lexer。在Trino项目中，该文件位于core/trino-parser/src/main/antlr4/io/trino/sql/parser/SqlBase.g4。通过使用Antlr的mave插件，在generate source阶段，会动态生成core/trino-parser/target/generated-sources/antlr4/io/trino/sql/parser/目录下的SqlBaseLexer和SqlBaseParser。

io.trino.sql.parser.SqlParser

trino在实际使用过程中并没有直接使用Antlr的Parser，而是统一使用门面类SqlParser用于执行语法解析。SqlParser的解析方法内部都是通过调用invokeParser来实现的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

private Node invokeParser(String name, String sql, Function<SqlBaseParser, ParserRuleContext> parseFunction, ParsingOptions parsingOptions)
    {
        try {
            //CaseInsensitiveStream 忽略大小写
            SqlBaseLexer lexer = new SqlBaseLexer(new CaseInsensitiveStream(CharStreams.fromString(sql)));
            CommonTokenStream tokenStream = new CommonTokenStream(lexer);
            SqlBaseParser parser = new SqlBaseParser(tokenStream);
            // 此处优化是由于antlr的内存泄漏
            // https://github.com/antlr/antlr4/issues/499
            initializer.accept(lexer, parser); 
           


            // Override the default error strategy to not attempt inserting or deleting a token.
            // Otherwise, it messes up error reporting
            parser.setErrorHandler(new DefaultErrorStrategy()
            {
                @Override
                public Token recoverInline(Parser recognizer)
                        throws RecognitionException
                {
                    if (nextTokensContext == null) {
                        throw new InputMismatchException(recognizer);
                    }
                    throw new InputMismatchException(recognizer, nextTokensState, nextTokensContext);
                }
            });
            // 流式遍历方式的listenner。进行后置处理
            parser.addParseListener(new PostProcessor(Arrays.asList(parser.getRuleNames()), parser));

            lexer.removeErrorListeners();
            lexer.addErrorListener(LEXER_ERROR_LISTENER);

            parser.removeErrorListeners();
            parser.addErrorListener(PARSER_ERROR_HANDLER);

            ParserRuleContext tree;
            try {
                // first, try parsing with potentially faster SLL mode
                parser.getInterpreter().setPredictionMode(PredictionMode.SLL);
                tree = parseFunction.apply(parser); // 此时解析为Antlr树
            }
            catch (ParseCancellationException ex) {
                // if we fail, parse with LL mode
                tokenStream.seek(0); // rewind input stream
                parser.reset();
                // SLL不行的话，使用降级模式LL
                parser.getInterpreter().setPredictionMode(PredictionMode.LL);
                tree = parseFunction.apply(parser);
            }

            return new AstBuilder(parsingOptions).visit(tree); // 访问者模式，生成Presto自定义的语法树
        }
        catch (StackOverflowError e) {
            throw new ParsingException(name + " is too large (stack overflow while parsing)");
        }
    }

Presto 自定义的语法节点类存放在core/trino-parser/src/main/java/io/trino/sql/tree包下。

antlr内存泄漏问题，详细内容可见 AntlrV4 的内存泄漏问题

Trino源码学习-执行计划生成

上篇分析了trino提交查询部分的源码，本篇来分析下，构建执行计划部分的源码。

Trino源码学习-Page数据结构

本篇来看下在查询执行的过程中，底层的数据结构是什么样的。