scala

本文会主要讲三种udf： ScalarFunction TableFunction AggregateFunction 用户自定义函数是非常重要的一个特征，因为他极大地扩展了查询的表达能力。本文除了介绍这三种udf之外，最后会介绍一个redis作为交互数据源的udf案例。 注册用户自定义函数 在大多数场景下，用户自定义函数在使用之前是必须要注册的。对于Scala的Table API，udf是不需要注册的。 调用TableEnvironment的registerFunction()方法来实现注册。Udf注册成功之后，会被插入TableEnvironment的function catalog，这样table API和sql就能解析他了。 1.Scalar Functions 标量函数 标量函数，是指返回一个值的函数。标量函数是实现将0，1，或者多个标量值转化为一个新值。 实现一个标量函数需要继承ScalarFunction，并且实现一个或者多个evaluation方法。标量函数的行为就是通过evaluation方法来实现的。evaluation方法必须定义为public，命名为eval。evaluation方法的输入参数类型和返回值类型决定着标量函数的输入参数类型和返回值类型。evaluation方法也可以被重载实现多个eval。同时evaluation方法支持变参数，例如：eval

一、Flink SQL 背景 Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL 语义的开发语言。 自 2015 年开始，阿里巴巴开始调研开源流计算引擎，最终决定基于 Flink 打造新一代计算引擎，针对 Flink 存在的不足进行优化和改进，并且在 2019 年初将最终代码开源，也就是我们熟知的 Blink。Blink 在原来的 Flink 基础上最显著的一个贡献就是 Flink SQL 的实现。 Flink SQL 是面向用户的 API 层，在我们传统的流式计算领域，比如 Storm、Spark Streaming 都会提供一些 Function 或者 Datastream API，用户通过 Java 或 Scala 写业务逻辑，这种方式虽然灵活，但有一些不足，比如具备一定门槛且调优较难，随着版本的不断更新，API 也出现了很多不兼容的地方。 在这个背景下，毫无疑问，SQL 就成了我们最佳选择，之所以选择将 SQL 作为核心 API，是因为其具有几个非常重要的特点： SQL 属于设定式语言，用户只要表达清楚需求即可，不需要了解具体做法； SQL 可优化，内置多种查询优化器，这些查询优化器可为 SQL 翻译出最优执行计划； SQL 易于理解，不同行业和领域的人都懂，学习成本较低； SQL 非常稳定，在数据库 30

目标： Flink从txt文件中读取数据，写入到mysql中 环境准备： 如果没有mysql，可以按照下面命令安装一下 wget https://repo.mysql.com//mysql80-community-release-el7-3.noarch.rpm yum -y install mysql80-community-release-el7-3.noarch.rpm yum install mysql-community-server -y systemctl restart mariadb 查看mysql默认密码 [root@localhost ~]# grep 'temporary password' /var/log/mysqld.log 2020-11-04T02:05:26.432219Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: qCk4b_3iEE;V 修改mysql默认密码 mysql -uroot -p'qCk4b_3iEE;V' mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'Mafei@20201104'; Query OK, 0 rows affected (0.03

在高并发业务场景下，消息队列在流量削峰、解耦上有不可替代的作用。当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。 消息队列这么多，到底该选择哪款消息队列呢？ 选择消息队列的基本标准 虽然这些消息队列在功能和特性方面各有优劣，但我们在选择的时候要有一个基本标准。 首先，必须是开源的产品。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统的问题，而不是等待开发者发布的下一个版本来解决。 其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。流行的好处是，只要使用场景不太冷门，遇到 Bug 的概率会非常低，因为大部分遇到的 Bug，其他人早就遇到并且修复了。在使用过程中遇到的一些问题，也比较容易在网上搜索到类似的问题，然后很快的找到解决方案。还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。 最后，作为一款及格的消息队列，必须具备的几个特性包括： 消息的可靠传递：确保不丢消息； Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息； 性能：具备足够好的性能，能满足绝大多数场景的性能要求。 接下来看一下有哪些符合上面这些条件，可供选择的开源消息队列。 RabbitMQ

scala Future object MyFuture { def doWork(i: Int): Int = { Thread.sleep(3 * 1000) i } def main(args: Array[String]): Unit = 1 to 5 foreach { i => val future = Future { blocking { doWork(i) } } future onComplete { case Success(value) => println(value) case Failure(exception) => println(exception) } // 通过视界转换，让 Int 拥有更丰富的方法 // 由于继承了 AnyVal，表明这是一个 value class /* implicit final class DurationInt(private val n: Int) extends AnyVal with DurationConversions { override protected def durationIn(unit: TimeUnit): FiniteDuration = Duration(n.toLong, unit) } */ Await.result(future, 7 seconds) } } 来源：