Apache Flink

本文整理自 2019 年 4 月 13 日在深圳举行的 Flink Meetup 会议，分享嘉宾张俊，目前担任 OPPO 大数据平台研发负责人，也是 Apache Flink contributor。 本文主要内容如下： OPPO 实时数仓的演进思路； 基于 Flink SQL 的扩展工作； 构建实时数仓的应用案例； 未来工作的思考和展望。 一.OPPO 实时数仓的演进思路 1.1.OPPO 业务与数据规模 大家都知道 OPPO 是做智能手机的，但并不知道 OPPO 与互联网以及大数据有什么关系，下图概要介绍了 OPPO 的业务与数据情况： OPPO 作为手机厂商，基于 Android 定制了自己的 ColorOS 系统，当前日活跃用户超过 2 亿。围绕 ColorOS，OPPO 构建了很多互联网应用，比如应用商店、浏览器、信息流等。在运营这些互联网应用的过程中，OPPO 积累了大量的数据，上图右边是整体数据规模的演进：从 2012 年开始每年都是 2~3 倍的增长速度，截至目前总数据量已经超过 100PB，日增数据量超过 200TB。 要支撑这么大的一个数据量，OPPO 研发出一整套的数据系统与服务，并逐渐形成了自己的数据中台体系。 1.2.OPPO 数据中台 今年大家都在谈数据中台，OPPO 是如何理解数据中台的呢？我们把它分成了 4 个层次： 最下层是统一工具体系，涵盖了 "

Flink有7种数据类型分别是： Java Tuples and Scala Case Classes Java POJOs Primitive Types Regular Classes Values Hadoop Writables Special Types Tuple Tuple是一个组合数据类型，包含了固定数量的不同类别的字段。范围可以从Tuple0到Tuple25，表示包含的字段数量个数。 POJO java和scala中定义POJO作用是一样的，POJO的类要满足以下条件： 必须用public修饰 必须要有一个public无参构造函数 所有字段要么是public的，要么必须要有setter和getter方法 类型必须是Flink支持的 Values 需要手动序列化和反序列化 Hadoop Writeables 必须是实现了org.apache.hadoop.Writable的类型。 来源： oschina 链接： https://my.oschina.net/u/946962/blog/3099462

序 本文主要研究一下flink DataStream的split操作 实例 SplitStream<Integer> split = someDataStream.split(new OutputSelector<Integer>() { @Override public Iterable<String> select(Integer value) { List<String> output = new ArrayList<String>(); if (value % 2 == 0) { output.add("even"); } else { output.add("odd"); } return output; } }); 本实例将dataStream split为两个dataStream，一个outputName为even，另一个outputName为odd DataStream.split flink-streaming-java_2.11-1.7.0-sources.jar!/org/apache/flink/streaming/api/datastream/DataStream.java @Public public class DataStream<T> { //...... public SplitStream<T> split(OutputSelector<T>

序 本文主要研究一下flink jdbc的ParameterValuesProvider ParameterValuesProvider flink-jdbc_2.11-1.8.0-sources.jar!/org/apache/flink/api/java/io/jdbc/split/ParameterValuesProvider.java /** * This interface is used by the {@link JDBCInputFormat} to compute the list of parallel query to run (i.e. splits). * Each query will be parameterized using a row of the matrix provided by each {@link ParameterValuesProvider} * implementation. */ public interface ParameterValuesProvider { /** Returns the necessary parameters array to use for query in parallel a table. */ Serializable[][] getParameterValues(); }

作者：品鉴 数据中台门在阿里巴巴集团干什么的，由哪个部门掌管？数据中台在阿里巴巴的主要作用是什么呢？外面吹嘘这么神秘的数据中台在阿里实践的如何呢？今天小编正好要采访数据技术及产品部门里面一个老大，带大家来一探究竟。 刚一开头，老大就陷入沉思，沉重的说：“数据技术及产品部门在阿里巴巴集团其实已走过16个年头，掌管着全集团的数据资产，那么多年的积累，帮助阿里建立起了一套完整的数据体系，对业务有全面的支撑。”整个数据中台从基础设施，基础数据技术起步，到数据资产管理；从内部的数据挖掘到体系规范、标准、流程和体系制定；外部产出从数据可视化技术到数据应用，使得内部的小二从方方面面都感受到数据中台的真实存在。 数据技术及产品部门历史 说到数据中台不能不说阿里的底层基础架构的扎实程度，数据中台基于阿里云的基础设施，使用了Maxcompute大数据平台、Analysis database、HBase、ECS等基础组件，基于这些基础组件之上，数据技术及产品部门的智慧工程师们开发了数据资产，它管理着全域大数据，统一的数据建设、管理、服务，服务阿里外部千万用户和内部业务给全集团小二们方便使用全集团的数据，当然这些都有严格的安全和权限管理哦，只有有需要的小二才可以看到和使用哦！ 数据技术及产品部门汇集了各种数据，因此数据官们开发了各种各样的数据技术帮助业务部门实现快速而准确的数据

序 本文主要研究一下flink taskmanager的jvm-exit-on-oom配置 taskmanager.jvm-exit-on-oom flink-1.7.2/flink-core/src/main/java/org/apache/flink/configuration/TaskManagerOptions.java @PublicEvolving public class TaskManagerOptions { //...... /** * Whether to kill the TaskManager when the task thread throws an OutOfMemoryError. */ public static final ConfigOption<Boolean> KILL_ON_OUT_OF_MEMORY = key("taskmanager.jvm-exit-on-oom") .defaultValue(false) .withDescription("Whether to kill the TaskManager when the task thread throws an OutOfMemoryError."); //...... } taskmanager.jvm-exit-on-oom配置默认为false

本文从编程模型、任务调度、时间机制、Kafka 动态分区的感知、容错及处理语义、背压等几个方面对比 Spark Stream 与 Flink，希望对有实时处理需求业务的企业端用户在框架选型有所启发。本文篇幅较长，建议先收藏～ / 编程模型对比 / 运行角色 Spark Streaming 运行时的角色(standalone 模式)主要有： Master :主要负责整体集群资源的管理和应用程序调度； Worker :负责单个节点的资源管理，driver 和 executor 的启动等； Driver :用户入口程序执行的地方，即 SparkContext 执行的地方，主要是 DGA 生成、stage 划分、task 生成及调度； Executor :负责执行 task，反馈执行状态和执行结果。 Flink 运行时的角色(standalone 模式)主要有: Jobmanager : 协调分布式执行，他们调度任务、协调 checkpoints、协调故障恢复等。至少有一个 JobManager。高可用情况下可以启动多个 JobManager，其中一个选举为 leader，其余为 standby； Taskmanager : 负责执行具体的 tasks、缓存、交换数据流，至少有一个 TaskManager； Slot : 每个 task slot 代表 TaskManager

引言 近些年，企业对数据服务实时化服务的需求日益增多。本文整理了常见实时数据组件的性能特点和适用场景，介绍了美团如何通过 Flink 引擎构建实时数据仓库，从而提供高效、稳健的实时数据服务。此前我们美团技术博客发布过一篇文章《 流计算框架 Flink 与 Storm 的性能对比 》，对 Flink 和 Storm 俩个引擎的计算性能进行了比较。本文主要阐述使用 Flink 在实际数据生产上的经验。 实时平台初期架构 在实时数据系统建设初期，由于对实时数据的需求较少，形成不了完整的数据体系。我们采用的是“一路到底”的开发模式：通过在实时计算平台上部署 Storm 作业处理实时数据队列来提取数据指标，直接推送到实时应用服务中。 图1 初期实时数据架构 但是，随着产品和业务人员对实时数据需求的不断增多，新的挑战也随之发生。 数据指标越来越多，“烟囱式”的开发导致代码耦合问题严重。 需求越来越多，有的需要明细数据，有的需要 OLAP 分析。单一的开发模式难以应付多种需求。 缺少完善的监控系统，无法在对业务产生影响之前发现并修复问题。 实时数据仓库的构建 为解决以上问题，我们根据生产离线数据的经验，选择使用分层设计方案来建设实时数据仓库，其分层架构如下图所示： 图2 实时数仓数据分层架构 该方案由以下四层构成： ODS 层：Binlog 和流量日志以及各业务实时队列。 数据明细层

Operators transform one or more DataStreams into a new DataStream. Operators操作转换一个或多个DataStream到一个新的DataStream 。 filter function Scala object DataStreamTransformationApp { def main(args: Array[String]): Unit = { val env = StreamExecutionEnvironment.getExecutionEnvironment filterFunction(env) env.execute("DataStreamTransformationApp") } def filterFunction(env: StreamExecutionEnvironment): Unit = { val data=env.addSource(new CustomNonParallelSourceFunction) data.map(x=>{ println("received:" + x) x }).filter(_%2 == 0).print().setParallelism(1) } } 数据源选择之前的任意一个数据源即可。 这里的map中没有做任何实质性的操作

Checkpoint 与 state 的关系 Checkpoint 是从 source 触发到下游所有节点完成的一次全局操作。下图可以有一个对 Checkpoint 的直观感受，红框里面可以看到一共触发了 569K 次 Checkpoint，然后全部都成功完成，没有 fail 的。 state 其实就是 Checkpoint 所做的主要持久化备份的主要数据 ，看下图的具体数据统计，其 state 也就 9kb 大小 。 什么是 state 我们接下来看什么是 state。先看一个非常经典的 word count 代码，这段代码会去监控本地的 9000 端口的数据并对网络端口输入进行词频统计，我们本地行动 netcat，然后在终端输入 hello world，执行程序会输出什么？ 答案很明显，(hello, 1) 和 (word,1) 那么问题来了，如果再次在终端输入 hello world，程序会输入什么？ 答案其实也很明显，(hello, 2) 和 (world, 2)。为什么 Flink 知道之前已经处理过一次 hello world，这就是 state 发挥作用了，这里是被称为 keyed state 存储了之前需要统计的数据，所以帮助 Flink 知道 hello 和 world 分别出现过一次。 回顾一下刚才这段 word count 代码。keyby 接口的调用会创建