Apache Flink

随着5G时代的到来，未来都将会是万物互联，各种各样的设备都会与网络连接起来。未来有无人驾驶、很多的设备都能接入到5G，会有大量的数据产生。 以后这些数据都将需要做实时分析，有人把Flink归类为第三代大数据引擎。第一代：Hadoop、第二代：Spark 。 1.什么是 Flink Flink官网：https://flink.apache.org/ Apache Flink 是一个分布式大数据处理引擎，可对1.有限数据流和2.无线数据流进行有状态计算。可部署在各种集群环境，对各种大小的数据规模进行快速计算。 名词解释： 有限数据流：即数据已经产生，数据大小已经确定。数据有限，可以做离线计算； 无限数据流：即数据流一旦产生，不知道什么时候结束。比如：数据实时写入到Kafka。数据无限，可以做实时计算。 1.1.Flink设计初衷 Flink 设计之初，就是为实时计算而设计的。但是因为其计算引擎过于强大，所以也可以做离线计算。它可以部署在各种各样的集群中，比如 Flink自己的 standalone 集群，flink on yarn部署，Flink 还可以跑在K8S上，Flink 还可以跑在各种各样的集群上。Flink为了开发测试比较方便，还可以使用单机模式。可以对各种大小规模的数据进行快速计算。特点就是：快。 1.2.Flink历史介绍 早在 2008年，Flink

题记 这是星球-静夜思模块里面一篇文章，有感于星球微信群的一次交流，连夜边思考边记录了下来。 静夜思模块完全是深夜里由感而发，大多包含但不限于：认知的梳理 、方法论的探讨、各种问题的暗时间思考…… 微信群机缘巧合，认识了很多领域的先行者、持续技术跟进者，统称或者俗称大佬。 比如：硅谷、腾讯云、阿里云、蚂蚁金服、小米、华为、Oracle一线大厂ES大佬。 比如：HBASE大佬 比如：SPring大佬 比如：Flink大佬 面对大佬，我们的表情通常是这样的？ 一方面：对大佬，我们要敬重，肯定某些领域比我们经验丰富，值得我们去学习！ 另一方面：我们要学习和反思。 大佬到底是如何炼成的？我认为这更重要。 相比大佬近况，我更喜欢看大佬的成长历程，如何一步步成长的！ 结合我的近十年的从业经历和大量观察，总结出以下十点认知。 第一：没有人一下就是大佬 著名骨灰级程序员左耳朵耗子 当年也是从小城市辗转反侧到上海、北京，从事业单位、私企、小外企、亚马逊、阿里、创业。 也经历过面试C语言基础一问三不知的情况。他的20几年的心路历程，能看得出一步步点滴积累的重要性。 早期的collshell文章深度没有那么深，甚至再早期05年之前都是在CSDN发文的，但是的的确确是有非常详尽、经历思考的干货总结。 第二：爷爷都是从孙子做起的 话糙理不糙。知名自媒体，财务自由的90后帅张。最早机房打杂，干过测试、开发

Flink包含8中分区策略，这8中分区策略(分区器)分别如下面所示，本文将从源码的角度一一解读每个分区器的实现方式。 GlobalPartitioner ShufflePartitioner RebalancePartitioner RescalePartitioner BroadcastPartitioner ForwardPartitioner KeyGroupStreamPartitioner CustomPartitionerWrapper 继承关系图 接口 名称 ChannelSelector 实现 public interface ChannelSelector<T extends IOReadableWritable> { /** * 初始化channels数量，channel可以理解为下游Operator的某个实例(并行算子的某个subtask). */ void setup(int numberOfChannels); /** *根据当前的record以及Channel总数， *决定应将record发送到下游哪个Channel。 *不同的分区策略会实现不同的该方法。 */ int selectChannel(T record); /** *是否以广播的形式发送到下游所有的算子实例 */ boolean isBroadcast(); } 抽象类 名称

Flink 系列博客 Flink QuickStart Flink双流操作 Flink on Yarn Kerberos的配置 Flink on Yarn部署和任务提交操作 Flink配置Prometheus监控 Flink in docker 部署 Flink HA 部署 Flink 常见调优参数总结 Flink 源码之任务提交流程分析 Flink 源码之基本算子 Flink 源码之Trigger Flink 源码之Evictor 简介 Flink 双数据流转换为单数据流操作的运算有 cogroup , join 和 coflatmap 。下面为大家对比介绍下这3个运算的功能和用法。 Join ：只输出条件匹配的元素对。 CoGroup : 除了输出匹配的元素对以外，未能匹配的元素也会输出。 CoFlatMap ：没有匹配条件，不进行匹配，分别处理两个流的元素。在此基础上完全可以实现join和cogroup的功能，比他们使用上更加自由。 对于join和cogroup来说，代码结构大致如下： val stream1 = ... val stream2 = ... stream1.join(stream2) .where(_._1).equalTo(_._1) //join的条件stream1中的某个字段和stream2中的字段值相等 .window(...) // 指定window

​  ​ 在《[什么的是用户画像]( https://mp.weixin.qq.com/s/169tCtjgUiDNeHIKLtGO9w )》一文中，我们已经知道用户画像对于企业的巨大意义，当然也有着非常大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？ # 挑战 - ## 大数据 随着互联网的崛起和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能获取的每一个用户的数据量是非常巨大的，而用户量本身更是巨大的，我们面临的是TB级，PB级的数据，所以我们必须要一套可以支撑大数据量的高可用性，高扩展性的系统架构来支撑用户画像分析的实现。毫无疑问，大数据时代的到来让这一切都成为可能，近年来，以Hadoop为代表的大数据技术如雨后春笋般迅速发展，每隔一段时间都会有一项新的技术诞生，不断驱动的业务向前，这让我们对于用户画像的简单统计，复杂分析，机器学习都成为可能。所以整体用户画像体系必须建立在大数据架构之上。 ![]( https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200525090411478

摘要： 脏数据对数据计算的正确性带来了很严重的影响。因此，我们需要探索一种方法，能够实现Spark写入Elasticsearch数据的可靠性与正确性。 概述 Spark与Elasticsearch（es）的结合，是近年来大数据解决方案很火热的一个话题。一个是出色的分布式计算引擎，另一个是出色的搜索引擎。近年来，越来越多的成熟方案落地到行业产品中，包括我们耳熟能详的Spark+ES+HBase日志分析平台。 目前，华为云数据湖探索（DLI）服务已全面支持Spark/Flink跨源访问Elasticsearch。而之前在实现过程中也遇到过很多场景化问题，本文将挑选其中比较经典的分布式一致性问题进行探讨。 分布式一致性问题 问题描述 数据容错是大数据计算引擎面临的主要问题之一。目前，主流的开源大数据比如Apache Spark和Apache Flink已经完全实现了Exactly Once语义，保证了内部数据处理的正确性。但是在将计算结果写入到外部数据源时，因为外部数据源架构与访问方式的多样性，始终没能找到一个统一的解决方案来保证一致性（我们称为Sink算子一致性问题）。再加上es本身没有事务处理的能力，因此如何保证写入es数据一致性成为了热点话题。 我们举一个简单的例子来说明一下，图1在SparkRDD中（这里假设是一个task），每一条蓝色的线代表100万条数据

1. 本地模式 建议环境: Linux: CentOS 6.x版本 (笔者用的是macOS Catalina) JDK: 8以上版本(需要配置好JAVA_HOME) (笔者用的是JDK14) 1-1) 从官网下载Flink安装包 笔者使用的是flink-1.10.1-bin-scala_2.12.tgz 解压安装包，拷贝到/usr/local目录下 1-2) 配置bash脚本 编辑bash配置文件: (Mac) vi ~/.bash_profile (CentOS) vi /etc/profile 添加FLINK_HOME # flink export FLINK_HOME=/usr/local/flink-1.10.1 export PATH=$PATH:$FLINK_HOME/bin 保存 （Mac) source ~/.bash_profile (CentOS) source /etc/profile 1-3) 启动Flink start-cluster.sh 运行结果: Starting cluster. Starting standalonesession daemon on host KGdeMacBook-Pro.local. Starting taskexecutor daemon on host KGdeMacBook-Pro.local. 访问http:/

​ 数据接入 数据的接入可以通过将数据实时写入Kafka进行接入，不管是直接的写入还是通过oracle和mysql的实时接入方式，比如oracle的ogg，mysql的binlog ogg Golden Gate（简称OGG）提供异构环境下交易数据的实时捕捉、变换、投递。 通过OGG可以实时的将oracle中的数据写入Kafka中。 对生产系统影响小：实时读取交易日志，以低资源占用实现大交易量数据实时复制 以交易为单位复制，保证交易一致性：只同步已提交的数据 高性能 智能的交易重组和操作合并 使用数据库本地接口访问 并行处理体系 binlog MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等）， 以事件形式记录 ，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是 复制和恢复 。 通过这些手段，可以将数据同步到kafka也就是我们的实时系统中来。 Flink接入Kafka数据 Apache Kafka Connector可以方便对kafka数据的接入。 依赖 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka_2.11

DataStream API（一） 在了解DataStream API之前我们先来了解一下Flink API的构成。Flink API是分层的。由最底层的Stateful Stream Process到最顶层的SQL分为四层。如下图： DataStream API 顾名思义，就是DataStream类的API，DataStream表示Flink程序中的流式数据集合。它是一个包含重复项的 不可变 数据集合，这些数据可以是有界的也可以是无界的，处理他们的API是相同的。 DataStream是不可变的，这意味着一旦它们被创建，就不能添加或删除元素。也不能简单地检查内部的元素，而只能使用DataStream API（Transform）来处理它们。 Flink程序基本部分组成： 获得执行环境(Environment)， 加载/创建初始数据(Source)， 指定此数据的转换(Transform)， 指定计算结果的存放位置(Sink)， 触发程序执行(Execut) 下面我们一起来了解一下Flink DataStream的执行环境。 Environment Flink的执行环境包括两种，分别是StreamExecutionEnvironment和ExecutionEnvironment，他们分别对应StreamData和DataSet。StreamData是流式数据集

Apache Kylin v3.1.0 已于上周正式发布，其中包含了许多值得一试的新功能，本文选择了 Presto 查询下压引擎、Flink 构建引擎、Kylin on Kubernetes 解决方案、新版 Hive 全局字典、增强的 Cube 迁移服务这五项重点功能进行介绍。 Presto 查询下压引擎 之前版本的 Kylin 提供了查询下压功能，该功能对于 Hive 数据源的下压有比较好的支持，但是对 Hive 以外的具有不兼容语法的数据源，用户就容易遇到因为种种方言不兼容而导致查询下压失败的问题。 为了解决这个问题，Kyligence 贡献了基于 Data Source SDK 开发的 Presto 查询下压引擎，该功能通过 Calicte 完成了Kylin 和 Presto 方言翻译，大大提升了查询下压的成功率。 Presto 下压引擎的使用文档请参考 : http://kylin.apache.org/docs/tutorial/query_pushdown.html 崭新的 Flink 构建引擎 Flink Engine 由腾讯贡献到 Kylin 社区（KYLIN – 3758）。在过去版本中，Kylin 只支持 MapReduce 和 Spark 两种构建引擎，为了扩大 Kylin 生态，进一步提升构建速度，Kylin v3.1.0引入了 Flink 作为构建引擎