2020-11-30 sparkSql 当前时间 前N小时select from_unixtime(unix_timestamp(current_timestamp) - 1* 60 * 60 *N,‘yyyy-MM-dd HH:mm:ss’) as sub
2020-11-30 hvie 窗口函数目录1 窗口函数 Windowing functions2 OVER详解 The OVER clause2.1 标准聚合函数2.2 分析函数 Analytics functions2.3 OVER子句也支持聚合函数2.4 window clause 的另一种写法1 窗口函数 Windowing functionsFIRST_VALUE(col, bool DEFAULT)返回分组窗口内第一行col的值，DEFAULT默认为false，如果指定为true
Mac 下 ssh 开启服务 在Mac通过ssh localhost 拒绝访问的问题，可能是由于sshd服务未开启1、开启sshd服务sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist2、查看ssh的服务是否开启sudo launchctl list |grep ssh3、sudo ssh localhost连接本地localhost成功...
Mac下SSH免密登录localhost step1ssh-keygen -t rsa Press enter for each line 提示输入直接按回车就好 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod og-wx ~/.ssh/authorized_keys chmod 750 $HOME 第四步才是最重要的一步，这一步不做的话每次ssh localhost都会让你输密码，恶心死了。 大家可以copy上面的指令依次执行即可。还不行的话参考stack
hive中内部表及外部表特性差异 关键点：ARCHIVE/UNARCHIVE/TRUNCATE/MERGE/CONCATENATE命令只能在内部表上进行使用;DROP操作将会删除内部表的元数据及数据信息,而对于外部表则仅仅删除元数据信息;ACID的事务特性仅仅适用于内部表; 查询结果缓存只适用于内部表;外部表的表约束只支持RELY操作;一些物化视图的特性只适用于内部表;hive中表的两种基本类型1)、内部表(managed)--默认2)、外部表(external)简介本文将介绍内部表及..
Flink 源码分析之 Flink startupMode 是如何起作用的 之前一直有个疑问，如果consumer.setStartFromLatest()以及kafkaProperties.put("auto.offset.reset", "earliest")同时存在，究竟哪一个会起作用，答案肯定是consumer.setStartFromLatest()，为什么呢？我们一起来看一下@Overridepublic void open(Configuration configuration) throws Exception {// determine th.
Flink 源码分析之 Flink 是如何 kafka 读取数据的 首先来看一下 FlinkKafkaConsumerBase.run方法，相当于是Flink 从kafka中拉取数据的入口方法://入口方法 start a sourcepublic void run(SourceContext<T> sourceContext) throws Exception {......// from this point forward:// - 'snapshotState' will draw offsets from the f.
Flink 源码分析之 FlinkConsumer 是如何保证一个 partition 对应一个 thread 的 我们都知道flink 连接kafka时，默认是一个partition对应一个thread，它究竟是怎么实现的呢？以及到我们自己定义 RichParallelSourceFunction 的时候如何借鉴这部分代码呢？我们一起来看一下(基于flink-1.8)看过flink kafka连接器源码的同学对 FlinkKafkaConsumerBase 应该不陌生(没有看过的也无所谓，我们一起来看就好)一起来看一下 FlinkKafkaConsumerBase 的 open 方法中关键的部分.
Flink 源码分析之 Flink 自定义 source、sink 是如何起作用的 自从学会自定义source之后，一直都比较好奇，为什么我实现一个 *SourceFunction，我自己定义的代码就可以跟 Flink很好的整合在一起？下面以 RichParallelSourceFunction 为例，来具体看一下究竟是自定义 source 是如何执行的首先看一下 Flink中的抽象类 AbstractUdfStreamOperator，专门负责Rich*Function的 open 和close方法......// flink 提供的 Rich*Funct.
Flink 源码分析之一文搞懂 Flink 消息全流程 我们以下面代码为例：FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("canal_monitor_order_astable", new SimpleStringSchema(), properties);consumer.setStartFromEarliest();env.addSource(consumer).flatMap(...).print()当 Flink.
Flink 源码分析之写给大忙人看的 Flink Window 原理 Window 可以说是 Flink 中必不可少的 operator 之一，在很多场合都有很非凡的表现。今天呢，我们就一起来看一下 window 是如何实现的。window 分类Tumbling WindowSliding WindowSession WindowGlobal Windowwindow operatorevictorevictor 主要用于做一些数据的自定义操作，可以在执行用户代码之前，也可以在执行用户代码之后，更详细的描
Flink 源码分析之 - 如何保存 offset Flink对Offset的管理，有两种方式：1.Checkpointing disabled 完全依赖于kafka自身的API2.Checkpointing enabled 当checkpoint做完的时候，会将offset提交给kafka or zk本文只针对于第二种，Checkpointing enabledFlinkKafkaConsumerBase中的 notifyCheckpointComplete@Override//当checkpoint完成的时候，此方.
Spark SQL之External DataSource外部数据源（二）源码分析 上周Spark1.2刚发布，周末在家没事，把这个特性给了解一下，顺便分析下源码，看一看这个特性是如何设计及实现的。 /**Spark SQL源码分析系列文章*/（Ps: External DataSource使用篇地址：Spark SQL之External DataSource外部数据源（一）示例http://blog.csdn.net/oopsoom/article/details/42061077）一、Sources包核心 Spark SQL在Spark1.2中提供了...
Spark SQL 源码分析之 In-Memory Columnar Storage 之 in-memory query 前面讲到了Spark SQL In-Memory Columnar Storage的存储结构是基于列存储的。 那么基于以上存储结构，我们查询cache在jvm内的数据又是如何查询的，本文将揭示查询In-Memory Data的方式。一、引子本例使用hive console里查询cache后的src表。select value from src当我们将src表cache到了内存后，再次查询src，可以通过analyzed执行计划来观察内部调用。即parse后，会形成InMemor..
Spark SQL 源码分析之 In-Memory Columnar Storage 之 cache table Spark SQL 可以将数据缓存到内存中，我们可以见到的通过调用cache table tableName即可将一张表缓存到内存中，来极大的提高查询效率。 这就涉及到内存中的数据的存储形式，我们知道基于关系型的数据可以存储为基于行存储结构 或 者基于列存储结构，或者基于行和列的混合存储，即Row Based Storage、Column Based Storage、 PAX Storage。 Spark SQL 的内存数据是如何组织的？ Spark SQL 将数据加载到内存是...
Spark SQL Catalyst源码分析之UDF 在SQL的世界里，除了官方提供的常用的处理函数之外，一般都会提供可扩展的对外自定义函数接口，这已经成为一种事实的标准。 在前面Spark SQL源码分析之核心流程一文中，已经介绍了Spark SQL Catalyst Analyzer的作用，其中包含了ResolveFunctions这个解析函数的功能。但是随着Spark1.1版本的发布，Spark SQL的代码有很多新完善和新功能了，和我先前基于1.0的源码分析多少有些不同，比如支持UDF：spark1.0及以前的实现：...
Spark SQL 源码分析之Physical Plan 到 RDD的具体实现 接上一篇文章Spark SQL Catalyst源码分析之Physical Plan，本文将介绍Physical Plan的toRDD的具体实现细节： 我们都知道一段sql，真正的执行是当你调用它的collect()方法才会执行Spark Job，最后计算得到RDD。 lazy val toRdd: RDD[Row] = executedPlan.execute() Spark Plan基本包含4种操作类型，即BasicOperator基本类型，还有就是Join、Aggregate和S...
Spark SQL Catalyst源码分析之Physical Plan 前面几篇文章主要介绍的是spark sql包里的的spark sql执行流程，以及Catalyst包内的SqlParser，Analyzer和Optimizer，最后要介绍一下Catalyst里最后的一个Plan了，即Physical Plan。物理计划是Spark SQL执行Spark job的前置，也是最后一道计划。 如图：一、SparkPlanner话接上回，Optimizer接受输入的Analyzed Logical Plan后，会有SparkPlanner来对Opti...
Spark SQL Catalyst源码分析之Optimizer /**Spark SQL源码分析系列文章*/ 前几篇文章介绍了Spark SQL的Catalyst的核心运行流程、SqlParser，和Analyzer以及核心类库TreeNode，本文将详细讲解Spark SQL的Optimizer的优化思想以及Optimizer在Catalyst里的表现方式，并加上自己的实践，对Optimizer有一个直观的认识。 Optimizer的主要职责是将Analyzer给Resolved的Logical Plan根据不同的优化策略Batch，来对语法树进行优...
Spark SQL Catalyst源码分析之TreeNode Library /**Spark SQL源码分析系列文章*/ 前几篇文章介绍了Spark SQL的Catalyst的核心运行流程、SqlParser，和Analyzer，本来打算直接写Optimizer的，但是发现忘记介绍TreeNode这个Catalyst的核心概念，介绍这个可以更好的理解Optimizer是如何对Analyzed Logical Plan进行优化的生成Optimized Logical Plan，本文就将TreeNode基本架构进行解释。 一、TreeNode类型 ...
关注
