Apache Flink

大数据生态体系蓬勃发展，分布式技术组件越来越丰富，Hadoop，Spark，Flink等快速涌现，让海量数据的解决方案越来越完善，这些分布式技术组件都是架构在大批量廉价商用服务器之上提供高性能，高可用，可扩展的服务的分布式集群。 那么他们如何设计，底层是如何实现的呢？ 我们在遇见类似的需求时， 是否也能研制一套海量数据处理技术 呢？ 当然能！这套 hadoop 课程视频， 对Hadoop底层源码剖析，三天带你手写一个hadoop框架，原价 1998 元，现在 限时免费送 ！ 资料目录 1. 手写RPC实现 （1）海量数据的存储及计算方案探索分析 （2）单线程的通用存储和计算方案设计和实现 （3）多线程的通用存储和计算方案设计和实现 （4）多进程的通用存储和计算方案设计 （5）手写RPC实现 2. 手写HDFS框架 （1）手写分布式文件系统功能实现： 整体架构实现 （2）手写分布式文件系统功能实现： 上传文件实现 （3）手写分布式文件系统功能实现： 下载文件实现 （4）手写分布式文件系统功能实现： 元数据管理实现 3. 手写MapReduce （1）手写分布式计算框架功能实现： 整体架构实现Job设计 （2）手写分布式计算框架功能实现： 通用数据读取组件InputFormat和Mapper组件实现 （3）手写分布式计算框架功能实现：

Apache DolphinScheduler 是一个分布式去中心化，易扩展的可视化 DAG 工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。 近日，伯毅同学给社区贡献了工作流核心表结构的剖析文章，非常细致，喜欢的伙伴请转走 1. 工作流总体存储结构 在 dolphinscheduler 库中创建的所有工作流定义(模板)都保存在 t_ds_process_definition 表中. 该数据库表结构如下表所示: 序号 字段 类型 描述 1 id int(11) 主键 2 name varchar(255) 流程定义名称 3 version int(11) 流程定义版本 4 release_state tinyint(4) 流程定义的发布状态：0 未上线 , 1已上线 5 project_id int(11) 项目id 6 user_id int(11) 流程定义所属用户id 7 process_definition_json longtext 流程定义JSON 8 description text 流程定义描述 9 global_params text 全局参数 10 flag tinyint(4) 流程是否可用：0 不可用，1 可用 11 locations text 节点坐标信息 12 connects text 节点连线信息

1. 业务需求 接收实时数据流数据，实时更新状态，并且每隔一定的时间，将所有状态数据输出。 实时数据类型：("张", 1) 状态更新：第一个元素为key，将第二个元素全部缓存起来，放到list中，最后将key和其对应的list全部输出。 2. 实现方案 使用processFunction算子，在processElement函数中仅注册一次定时器，然后在onTimer函数中处理定时器任务，并且重新注册定时器。 3. 实现代码 3.1 source /** * 每隔1秒发送一个tuple2类型的数据，第一个字段值为随机的一个姓氏，第二个字段为自增的数字 **/ class MySourceTuple2 extends SourceFunction[(String, Long)] { var isRunning: Boolean = true val names: List[String] = List("张", "王", "李", "赵") private val random = new Random() var number: Long = 1 override def run(ctx: SourceFunction.SourceContext[(String, Long)]): Unit = { while (true) { val index: Int = random

作者： 阿里巴巴菜鸟物流团队 （弃疾，孝江，姜继忠） 一、业务背景 菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台，日均处理包裹事件几十亿，承载了菜鸟物流数据的大部分处理任务。 智能物流分析引擎将基于运配网络的各类应用场景集中到了统一的一个技术架构，以此提供强大的吞吐和计算能力。基于原架构的数据处理流程为：Datahub实时采集数据源，包含仓、配、运和订单等数据，实时计算Flink基于流批一体的模式对数据预处理，形成一个以订单为单位，包含订单跟踪事件的宽表，写入存储引擎HBase中，再供外部查询。 在数据处理部分，随着数据量的增加，原有的存储系统HBase在维表全量导入中所需要的时间越来越长，这就需要耗费大量的资源，另外其单机吞吐的表现不是很好，单位成本高。在数据量较小时，成本不是需要考虑的关键因素，但当数据量规模变大时，成本的重要性就体现出来了。菜鸟智能物流每天需要处理大批量的数据，这也就意味着每天将会浪费大量的资源。 同时，在我们的场景中，有些表是作为Flink维表基于PK进行PointQuery，有些表需要进行OLAP分析，而HBase并不能两种场景都满足。为了OLAP分析，需要将数据同步到批处理系统中，为了KV查询，需要将数据同步到KVStore。不同的查询需求就需要借助多个系统，数据在不同系统之间的导入导出不仅会加深数据同步的负担，也会带来冗余存储

如果要问最近几年，IT行业哪个技术方向最火？一定属于ABC，即AI + Big Data + Cloud，也就是人工智能、大数据和云计算。 这几年，随着互联网大潮走向低谷，同时传统企业纷纷进行数字化转型，基本各个公司都在考虑如何进一步挖掘数据价值，提高企业的运营效率。在这种趋势下，大数据技术越来越重要。所以，AI时代，还不了解大数据就真的OUT了！ 相比较AI和云计算，大数据的技术门槛更低一些，而且跟业务的相关性更大。我个人感觉再过几年，大数据技术将会像当前的分布式技术一样，变成一项基本的技能要求。 前几天，我在团队内进行了一次大数据的技术分享，重点是对大数据知识做一次扫盲，同时提供一份学习指南。这篇文章，我基于分享的内容再做一次系统性整理，希望对大数据方向感兴趣的同学有所帮助，内容分成以下5个部分： 1、大数据的发展历史 2、大数据的核心概念 3、大数据平台的通用架构和技术体系 4、大数据的通用处理流程 5、大数据下的数仓体系架构 01 大数据的发展历史 在解释「大数据」这个概念之前，先带大家了解下大数据将近30年的发展历史，共经历了5个阶段。那在每个阶段中，大数据的历史定位是怎样的？又遇到了哪些痛点呢？ 1.1 启蒙阶段：数据仓库的出现 20世纪90年代，商业智能（也就是我们熟悉的BI系统）诞生，它将企业已有的业务数据转化成为知识，帮助老板们进行经营决策。比如零售场景中

点击上方 蓝色字体 ，选择“ 设为星标 ” 回复”资源“获取更多资源 大数据技术与架构 点击右侧关注，大数据开发领域最强公众号！ 暴走大数据 点击右侧关注，暴走大数据！ 1 概念 （1）定义 复合事件处理（Complex Event Processing，CEP）是一种基于动态环境中事件流的分析技术，事件在这里通常是有意义的状态变化，通过分析事件间的关系，利用过滤、关联、聚合等技术，根据事件间的时序关系和聚合关系制定检测规则，持续地从事件流中查询出符合要求的事件序列，最终分析得到更复杂的复合事件。 （2）特征 CEP的特征如下： 目标：从有序的简单事件流中发现一些高阶特征； 输入：一个或多个简单事件构成的事件流； 处理：识别简单事件之间的内在联系，多个符合一定规则的简单事件构成复杂事件； 输出：满足规则的复杂事件。 （3）功能 CEP用于分析低延迟、频繁产生的不同来源的事件流。CEP可以帮助在复杂的、不相关的时间流中找出有意义的模式和复杂的关系，以接近实时或准实时的获得通知或组织一些行为。 CEP支持在流上进行模式匹配，根据模式的条件不同，分为连续的条件或不连续的条件；模式的条件允许有时间的限制，当条件范围内没有达到满足的条件时，会导致模式匹配超时。 看起来很简单，但是它有很多不同的功能： ① 输入的流数据，尽快产生结果； ② 在2个事件流上，基于时间进行聚合类的计算； ③

[源码解析] GroupReduce，GroupCombine和Flink SQL group by 目录 [源码解析] GroupReduce，GroupCombine和Flink SQL group by 0x00 摘要 0x01 缘由 0x02 概念 2.1 GroupReduce 2.2 GroupCombine 2.3 例子 0x03 代码 0x04 Flink SQL内部翻译 0x05 JobGraph 0x06 Runtime 6.1 ChainedFlatMapDriver 6.2 GroupReduceCombineDriver 6.3 GroupReduceDriver & ChainedFlatMapDriver 0x07 总结 0x08 参考 0x00 摘要 本文从源码和实例入手，为大家解析 Flink 中 GroupReduce 和 GroupCombine 的用途。也涉及到了 Flink SQL group by 的内部实现。 0x01 缘由 在前文 [源码解析] Flink的Groupby和reduce究竟做了什么 中，我们剖析了Group和reduce都做了些什么，也对combine有了一些了解。但是总感觉意犹未尽，因为在Flink还提出了若干新算子，比如GroupReduce和GroupCombine。这几个算子不搞定，总觉得如鲠在喉

基础环境 准备3台虚拟机 配置无密码登录 配置方法: https://ipooli.com/2020/04/linux_host/ 并且做好主机映射。 下载Flink https://www.apache.org/dyn/closer.lua/flink/flink-1.10.1/flink-1.10.1-bin-scala_2.11.tgz 并解压缩 部署 Standalone Cluster 单机模式 启动 进入flink-1.10.1 文件夹内 直接执行: ./bin/start-cluster.sh 集群模式 修改配置文件 进入flink-1.10.1 文件夹内 修改 ./conf/flink-conf.yaml 修改如下几个参数: jobmanager.rpc.address: bigdata1 jobmanager.rpc.port: 6123 jobmanager.heap.size: 1024m taskmanager.memory.process.size: 1568m taskmanager.numberOfTaskSlots: 3 parallelism.default: 3 修改 ./conf/masters 配置master节点 修改为: bigdata1:8081 修改 ./conf/slaves 配置slaves节点 修改为: bigdata1

在使用eventTime的时候如何处理乱序数据？我们知道，流处理从事件产生，到流经source，再到operator，中间是有一个过程和时间的。虽然大部分情况下，流到operator的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络延迟等原因，导致乱序的产生，特别是使用kafka的话，多个分区的数据无法保证有序。所以在进行window计算的时候，我们又不能无限期的等下去，必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了。这个特别的机制，就是watermark。Watermark是用于处理乱序事件的，用于衡量Event Time进展的机制。watermark可以翻译为水位线。 一、Watermark的核心原理 Watermark的核心本质可以理解成一个延迟触发机制。 在 Flink 的窗口处理过程中，如果确定全部数据到达，就可以对 Window 的所有数据做 窗口计算操作（如汇总、分组等），如果数据没有全部到达，则继续等待该窗口中的数据全 部到达才开始处理。这种情况下就需要用到水位线（WaterMarks）机制，它能够衡量数据处 理进度（表达数据到达的完整性），保证事件数据（全部）到达 Flink 系统，或者在乱序及 延迟到达时，也能够像预期一样计算出正确并且连续的结果。当任何 Event 进入到 Flink 系统时，会根据当前最大事件时间产生

用户画像标签体系 ​ 用户画像的核心在于给用户“打标签”，每一个标签通常是人为规定的特征标识，用高度精炼的特征描述一类人，例如年龄、性别、兴趣偏好等，不同的标签通过结构化的数据体系整合，就可与组合出不同的用户画像。 ​ 梳理标签体系是实现用户画像过程中最基础、也是最核心的工作，后续的建模、数据仓库搭建都会依赖于标签体系。 ​ 为什么需要梳理标签体系，因为不同的企业做用户画像有不同的战略目的，广告公司做用户画像是为精准广告服务，电商做用户画像是为用户购买更多商品，内容平台做用户画像是推荐用户更感兴趣的内容提升流量再变现，金融行业做用户画像是为了寻找到目标客户的同时做好风险的控制。 ​ 所以第一步，我们要结合所在的行业，业务去分析我们用户画像的目的。这其实就是战略，我们要通过战略去指引我们最终的方向。 对于电商企业来说，可能最重要的两个问题就是： 现有用户- 我的现存用户是谁？为什么买我的产品？他们有什么偏好？哪些用户价值最高？ 潜在客户- 我的潜在用户在哪儿？他们喜欢什么？哪些渠道能找到他们？获客成本是多少？ 而对于金融企业，还要加上一条： 用户风险—用户的收入能力怎么样？他们是否有过贷款或者信用卡的逾期？他们的征信有问题吗？ 我们做用户画像的目的也就是根据我们指定的战略方向最终去解决这些问题。 在梳理标签的过程还要紧密的结合我们的数据，不能脱离了数据去空想