Rango_lhl的博客

Flink分区器

FlinkSQL 级联窗口计算并Sink2Hbase

一、背景说明所谓CDC：全称是 Change Data Capture ，在广义的概念上，只要能捕获数据变更的技术，我们都可以称为 CDC 。通常我们说的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。目前实时链路对于数据的处理是大多数使用的方案是通过工具，对业务数据日志的监控（如canal/maxwell），并连接到kafka，实现对业务数据的实时获取，在实时数仓架构上，ods层一般也会设计在kafka（数据入湖另外说），参考下面图1。而通过FlinkCDC则可以在确保数据一

窗口（Windows）时间语义，要配合窗口操作才能发挥作用。最主要的用途，当然就是开窗口、根据时间段做计算了。下面我们就来看看Table API和SQL中，怎么利用时间字段做窗口操作。在Table API和SQL中，主要有两种窗口：Group Windows和Over Windows分组窗口（Group Windows）Group Windows 是使用 window（w:GroupWindow）子句定义的，并且必须由as子句指定一个别名。为了按窗口对表进行分组，窗口的别名必须在 grou

一、背景说明需求为从Kafka消费对应主题数据，通过TableApi对数据进行WordCount后，基于DDL写法将数据写入ES。二、代码部分说明：代码中关于Kafka及ES的连接部分可以抽象到单独的工具类使用，这里只是一个演示的小demo，后续操作均可自行扩展，如Kakfa一般处理为json格式数据，引入fastjson等工具使用富函数进行格式处理即可。package com.flinksql.test;import org.apache.flink.api.common.functions

一、背景说明Flink的API做了4层的封装，上两层TableAPI、SQL语法相对简单便于编写，面对小需求可以快速上手解决，本文参考官网及部分线上教程编写source端、sink端代码，分别读取socket、kafka及文本作为source，并将流数据输出写入Kafka、ES及MySQL，方便后续查看使用。二、代码部分说明：这里使用connect及DDL两种写法，connect满足Flink1.10及以前版本使用，目前官方文档均是以DDL写法作为介绍，建议1.10以后的版本使用DDL写法操作，通

一、背景说明在Flink中可以使用Window join或者Interval Join实现双流join，不过使用join只能实现内连接，如果要实现左右连接或者外连接，则可以通过connect算子来实现。现有订单数据及支付数据如下方说明，基于数据时间实现订单及支付数据的关联，超时或者缺失则由侧输出流输出//OrderLog.csv 订单数据，首列为订单id，付款成功则类型为pay（第二列），且生成支付id（第三列），最后列为时间34729,create,,155843084234730,create,

一、背景说明：在上篇文章实现了TopN计算，但是碰到迟到数据则会无法在当前窗口计算，需要对其中的键控状态优化Flink使用二次聚合实现TopN计算本次需求是对数据进行统计，要求每隔5秒，输出最近10分钟内访问量最多的前N个URL，数据流预览如下（每次一条从端口传入）：208.115.111.72 - - 17/05/2015:10:25:49 +0000 GET /?N=A&page=21 //15:50-25:50窗口数据208.115.111.72 - - 17/05/2015:1

一、背景说明：有需求需要对数据进行统计，要求每隔5分钟输出最近1小时内点击量最多的前N个商品，数据格式预览如下：543462,1715,1464116,pv,1511658000662867,2244074,1575622,pv,1511658000561558,3611281,965809,pv,1511658000894923,3076029,1879194,pv,1511658000834377,4541270,3738615,pv,1511658000315321,942195,433

一、背景说明在Flink中对流数据进行去重计算是常有操作，如流量域对独立访客之类的统计，去重思路一般有三个：基于Hashset来实现去重数据存在内存，容量小，服务重启会丢失。使用状态编程ValueState/MapState实现去重常用方式，可以使用内存/文件系统/RocksDB作为状态后端存储。结合Redis使用布隆过滤器实现去重适用对上亿数据量进行去重实现，占用资源少效率高，有小概率误判。这里以自定义布隆过滤器的方式，实现Flink窗口计算中独立访客的统计，数据集样例如下： 二、

一、键控状态说明参考官网说明，几个键控状态介绍如下：ValueState: 保存一个可以更新和检索的值（如上所述，每个值都对应到当前的输入数据的 key，因此算子接收到的每个 key 都可能对应一个值）。 这个值可以通过 update(T) 进行更新，通过 T value() 进行检索。ListState: 保存一个元素的列表。可以往这个列表中追加数据，并在当前的列表上进行检索。可以通过 add(T) 或者 addAll(List) 进行添加元素，通过 Iterable get() 获得整个列表。还

通过一个小需求的开发来简明Flink定时器的应用。一、需求说明：对水库的数据进行实时监测，如果10秒内水位线没有下降，则做预警输出。数据使用socket进行模拟，数据包含 传感器编号/时间戳/水位 三个字段。实现逻辑说明如下图：数据1实时进来，第一条数据水位线为1米，建立定时器，第四条数据在10秒内进来，并且水位降低，则删除定时器，随即后续无任何再操作。数据2实时进来，第一条数据水位线为1米，建立定时器，第四条数据在第10秒进来，10秒内水位无下降，出发定时器的规则，在侧输出流输出预警提.

一、关于Flink的Watermark1.12版本之后默认时间语义为Event time（事件时间），并且实际使用也是以事件时间为主，故这边背景均以基于时间事件的来说明。支持event time的流式处理框架需要一种能够测量event time 进度的方式；比如, 一个窗口算子创建了一个长度为1小时的窗口，那么这个算子需要知道事件时间已经到达了这个窗口的关闭时间, 从而在程序中去关闭这个窗口。事件时间可以不依赖处理时间来表示时间的进度.例如,在程序中,即使处理时间和事件时间有相同的速度, 事件时间

一、背景说明本文基于IK分词器，自定义一个UDTF（Table Functions），实现类似Hive的explode行转列的效果，以此来简明开发过程。如下图Flink三层API接口中，Table API的接口位于最顶层也是最易用的一层，可以套用SQL语法进行代码编写，对于有SQL基础的能很快上手，但是不足之处在于灵活度有限，自有函数不能满足使用的时候，需要通过自定义函数实现，类似Hive的UDF/UDTF/UDAF自定义函数，在Flink也可以称之为Scalar Functions/Table Fun

一、背景说明：在目前实时数仓中，由于维表具有主键唯一性的特点，Hbase/Redis通常作为维表存放选择Hbase：数据存于磁盘具有持久性但是查询效率慢。Redis：数据存于内存查询效率高，但维表多数据量大时候占用资源多。基于旁路缓存思想，对维表存储的优化的思路为：维表数据存储在Hbase，使用Redis作为缓存，但查询维表时有限查询Redis，如果没有该维表则去Hbase查询后并将维表数据放入Redis，并按一定时间保存，超过时间Redis自动清理（可使不常用维表无需常驻内存，缺点是首次查询较

一、需求说明：对页面日志数据进行ETL，对跳出用户进行标记后输出到Kafka。跳出用户定义：条件1：不是从其他页面跳转过来的页面，是一个首次访问页面。日志数据表现为不存在last_page_id字段。条件2：距离首次访问结束后10秒内，没有对其他的页面再进行访问。ps：该需求一般为实时项目中对kafka日志数据进行消费后处理，后续输出到kafka计算页面跳出率用于运营分析使用，该文重点在于代码部分的处理，因此测试数据简化输入及输出。测试数据说明：//mid对应设备，page_id对应当

尽管MR由于计算效率问题，已经不适用于大多数业务场景，Hive3开始计算引擎改为TEZ，但MR的经典思路在Hadoop生态各组件都有体现，重温后对各组件原理的理解还有使用都有帮助，如Spark的RDD分区里面的源码就能看到MR分片思想的影子。这里仅拿输入Map前分片（Split）这个动作的源码做窥探，深入挖掘下分片（split）的思想。一、简单总结进行MR前，对要计算的各文件按分片逻辑切分，多少个分片则对应产生多少个Map计算。分片逻辑以某个值（splitSize）为基准，超过其1.1倍时，则再做分片

一、名称节点（NameNode）1.什么是名称节点在HDFS中，名称节点负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构-FsImage和EditLog。FsImage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。EditLog：中记录所有针对文件创建、删除、重命名等操作的日志文件。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。2.名称节点工作过程名

一、HDFS相关类说明FileSystem：通用文件系统的抽象基类，可以被分布式文件系统继承，所有可能使用Hadoop文件系统的代码都要使用到这个类。DistributedFileSystem：Hadoop为FileSystem这个抽象类提供了多种具体的实现，DistributedFileSystem就是FileSystem在HDFS文件系统中的实现。FSDataInputStream：FileSystem的open()方法返回的是一个输入流FSDataInputStream对象，在HDSF文件系统中

一、Spark中水印作用Spark内部引擎的实现是保留内部状态的，以便让基于事件时间的窗口聚合可以更新旧的数据，但是如果一个查询持续运行多天，那么系统绑定中间状态累积的数量也会随之增加，为了释放资源，用户可以通过自定义水印来告知系统可以丢弃哪些在内存中旧状态的数据。自定义水印可以使用withWatermark()方法。二、延迟数据处理实例（基于pyspark）通过一个实例说明，Spark如何处理迟到数据以及水印在迟到数据处理的作用。该实例中，首先建立一个基于CSV文件的输入源，模拟实时写入CSV文件

一、hive.groupby.skewindataset hive.groupby.skewindata=true;数据倾斜时负载均衡，当选项设定为true，生成的查询计划会有两个MRJob。第一个MRJob 中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中（这个过程可

Hive中的Join可分为Common Join（Reduce阶段完成join）和Map Join（Map阶段完成join）一、Map Join作用及原理作用简单来说，在Map阶段进行join，而不是Common Join那样在Reduce阶段按照join列进行分发后在每个Reduce节点上进行join，一来省去Shuffle这个代价昂贵的阶段，二来不需要分发也就没有倾斜的问题。ps：关于Shuffle的过程可读上篇文章：https://blog.youkuaiyun.com/rango_lhl/article

一、区别①本质上相同，都是把Map端数据分类处理后交由Reduce的过程。②数据流有所区别，MR按map, spill, merge, shuffle, sort, reduce等各阶段逐一实现。Spark基于DAG数据流，可实现更复杂数据流操作（根据宽/窄依赖实现）③实现功能上有所区别，MR在map中做了排序操作，而Spark假定大多数应用场景Shuffle数据的排序操作不是必须的，而是采用Aggregator机制（Hashmap每个元素<K,V>形式）实现。（下面有较详细说明）p

把Flume Source（netcat类型），从终端上不断给FlumeSource发送消息，Flume把消息汇集到Sink（avro类型），由Sink把消息推送给Spark Streaming并处理后输出版本信息：spark2.4.0 Flume 1.7.0（基于pyspark）一、Flume安装①、文件导入# 将apache-flume-1.7.0-bin.tar.gz解压到/usr/local目录下sudo tar -zxvf apache-flume-1.7.0-bin.tar.g.