携程基于Flink的实时特征平台

  categories:资料  tags:  author:

本文来自于flink-china,本文主要介绍原实时特征作业的开发痛点、特征平台系统架构以及选择Flink的原因等。

本文主要内容如下:

在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状

选择Flink作为平台计算引擎的原因

Flink的实践:有代表性的使用示例、为兼容Aerospike(平台的存储介质)的开发以及碰到的坑

当前效果&未来规划

一、在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状

1、原实时特征作业的开发运维

1.1、选择实时计算平台:依据项目的性能指标要求(latency,throughput等),在已有的实时计算平台:Storm Spark flink进行选择

1.2主要的开发运维过程:

80%以上的作业需要用到消息队列数据源,但是消息队列为非结构化数据且没有统一的数据字典。所以需要通过消费对应的topic,解析消息并确定所需的内容

基于需求中的场景,设计开发计算逻辑

在实时数据不能完全满足数据需求的情况,另外开发单独的离线作业以及融合逻辑;

例如:在需要30天数据的场景下,但消息队列中只有七天内的数据时(kafka中消息的默认保留时间),剩下23天就需要用离线数据来补充。

设计开发数据的校验和纠错逻辑 消息的传输需要依赖网络,消息丢失和超时难以完全避免,所以需要有一个校验和纠错的逻辑。

测试上线

监控和预警

2、原实时特征作业的开发痛点

消息队列数据源结构没有统一的数据字典

特征计算逻辑高度定制化,开发测试周期长

实时数据不能满足需求时,需要定制离线作业和融合逻辑

校验和纠错方案没有形成最佳实践,实际效果比较依赖个人能力

监控和预警方案需要基于业务逻辑定制

3、基于整理的痛点,确定下来的平台目标

实时数据字典:提供统一的数据源注册、管理功能,支持单一结构消息的topic和包含多种不同结构消息的topic

逻辑抽象:抽象为SQL,减少工作量&降低使用门槛

特征融合:提供融合特征的功能,解决实时特征不能完全满足数据需求的情况

数据校验和纠错:提供利用离线数据校验和纠错实时特征的功能

实时计算延迟:ms级

实时计算容错:端到端 exactly-once

统一的监控预警和HA方案

4、特征平台系统架构

现在的架构是标准lamda架构,离线部分由spark sql + dataX组成。现在使用的是KV存储系统Aerospike,跟redis的主要区别是使用SSD作为主存,我们压测下来大部分场景读写性能跟redis在同一个数据量级。… 阅读全文

实时计算 Flink SQL 核心功能解密

  categories:资料  tags:  author:

实时计算 Flink SQL 核心功能解密

Flink SQL 是于2017年7月开始面向集团开放流计算服务的。虽然是一个非常年轻的产品,但是到双11期间已经支撑了数千个作业,在双11期间,Blink 作业的处理峰值达到了5+亿每秒,而其中仅 Flink SQL 作业的处理总峰值就达到了3亿/秒。Flink SQL 在这么短的时间内支撑了如此多的业务,与其稳定的内核、完善的功能、强大的生态是分不开的。

本文会带着大家一起来揭开 Flink SQL 核心功能的面纱(API上我们将尽可能的和Flink社区保持一致,这样才能够更好的融入开源的生态,所以我们将API叫做Flink SQL,而不是Blink SQL。事实上flink社区的SQL绝大部分是我们阿里的工程师贡献的:3个 Flink Committer,10+ Contributor,贡献 80% 的SQL 功能,近200个 commit,近十万行的代码)。

为什么是 SQL?

Blink 将 SQL 定位为其最核心的 API。为什么是 SQL 而不是 DataStream API 呢?因为 SQL 具有以下几个优点:

阅读全文

Flink原理与实现架构和拓扑概览

  categories:资料  tags:  author:

架构

要了解一个系统,一般都是从架构开始。我们关心的问题是:系统部署成功后各个节点都启动了哪些服务,各个服务之间又是怎么交互和协调的。下方是Flink集群启动后架构图。

当Flink集群启动后,首先会启动一个JobManger和一个或多个的TaskManager。由客户端提交任务给JobManager,JobManager再调度任务到各个TaskManager去执行,然后TaskManager将心跳和统计信息汇报给JobManager.TaskManager之间以流的形式进行数据的传输。上述三者均为独立的JVM进程。

  • 客户为提交作业的客户端,可以是运行在任何机器上(与JobManager环境连通即可)。提交作业后,客户可以结束进程(流的任务),也可以不结束并等待结果返回。
  • JobManager主要负责调度工作并协调任务做检查点,职责上很像Storm的Nimbus。从客户处接收到工作和JAR包等资源后,会生成优化后的执行计划,并以任务的单元调度到各个TaskManager去执行。
  • TaskManager在启动的时候就设置好了槽位数(Slot),每个插槽能启动一个任务,任务为线程。从JobManager处理接收需要部署的任务,部署启动后,与自己的上游建立Netty连接,接收数据并处理。

可以看到Flink的任务调度是多线程模型,并且不同Job / Task混合在一个TaskManager进程中。虽然这种方式可以有效提高CPU利用率,但是个人不太喜欢这种设计,因为不仅缺少资源隔离机制,同时也不方便调试。类似Storm的进程模型,一个JVM中只跑该Jobs Tasks实际应用中更为合理。

工作例子

本文所示例子为flink-1.0.x版本

我们使用Flink自带的例子包中的SocketTextStreamWordCount,这是一个从socket流中统计单词出现次数的例子。

首先,使用netcat的启动本地服务器:

$ nc -l 9000

然后提交Flink程序

$ bin / flink运行示例/ streaming / SocketTextStreamWordCount.jar \
  --hostname 10.218.130.9 \
  -  9000

在netcat端输入单词并监控taskmanager的输出可以看到单词统计的结果。

SocketTextStreamWordCount 的具体代码如下:

阅读全文

Flink 零基础实战教程:如何计算实时热门商品

  categories:资料  tags:  author:

在上一篇入门教程中,我们已经能够快速构建一个基础的 Flink 程序了。本文会一步步地带领你实现一个更复杂的 Flink 应用程序:实时热门商品。在开始本文前我们建议你先实践一遍上篇文章,因为本文会沿用上文的my-flink-project项目框架。

通过本文你将学到:

  1. 如何基于 EventTime 处理,如何指定 Watermark
  2. 如何使用 Flink 灵活的 Window API
  3. 何时需要用到 State,以及如何使用
  4. 如何使用 ProcessFunction 实现 TopN 功能

 

实战案例介绍

本案例将实现一个“实时热门商品”的需求,我们可以将“实时热门商品”翻译成程序员更好理解的需求:每隔5分钟输出最近一小时内点击量最多的前 N 个商品。将这个需求进行分解我们大概要做这么几件事情:

  • 抽取出业务时间戳,告诉 Flink 框架基于业务时间做窗口
  • 过滤出点击行为数据
  • 按一小时的窗口大小,每5分钟统计一次,做滑动窗口聚合(Sliding Window)
  • 按每个窗口聚合,输出每个窗口中点击量前N名的商品

数据准备

这里我们准备了一份淘宝用户行为数据集(来自阿里云天池公开数据集,特别感谢)。本数据集包含了淘宝上某一天随机一百万用户的所有行为(包括点击、购买、加购、收藏)。数据集的组织形式和MovieLens-20M类似,即数据集的每一行表示一条用户行为,由用户ID、商品ID、商品类目ID、行为类型和时间戳组成,并以逗号分隔。关于数据集中每一列的详细描述如下:

列名称 说明
阅读全文

Flink 原理与实现:Table & SQL API

  categories:资料  tags:  author:

Flink 已经拥有了强大的 DataStream/DataSet API,可以基本满足流计算和批计算中的所有需求。为什么还需要 Table & SQL API 呢?

首先 Table API 是一种关系型API,类 SQL 的API,用户可以像操作表一样地操作数据,非常的直观和方便。用户只需要说需要什么东西,系统就会自动地帮你决定如何最高效地计算它,而不需要像 DataStream 一样写一大堆 Function,优化还得纯靠手工调优。另外,SQL 作为一个“人所皆知”的语言,如果一个引擎提供 SQL,它将很容易被人们接受。这已经是业界很常见的现象了。值得学习的是,Flink 的 Table API 与 SQL API 的实现,有 80% 的代码是共用的。所以当我们讨论 Table API 时,常常是指 Table & SQL API。

Table & SQL API

阅读全文

新一代大数据处理引擎Flink

  categories:资料  tags:  author:

大数据计算引擎的发展

这几年大数据的飞速发展,出现了很多热门的开源社区,其中著名的有 Hadoop、Storm,以及后来的 Spark,他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河,也以内存为赌注,赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink,也就在这个时候默默的发展着。

在国外一些社区,有很多人将大数据的计算引擎分成了 4 代,当然,也有很多人不会认同。我们先姑且这么认为和讨论。

首先第一代的计算引擎,无疑就是 Hadoop 承载的 MapReduce。这里大家应该都不会对 MapReduce 陌生,它将计算分为两个阶段,分别为 Map 和 Reduce。对于上层应用来说,就不得不想方设法去拆分算法,甚至于不得不在上层应用实现多个 Job 的串联,以完成一个完整的算法,例如迭代计算。

由于这样的弊端,催生了支持 DAG 框架的产生。因此,支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别,不过对于当时的 Tez 和 Oozie 来说,大多还是批处理的任务。

接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 … 阅读全文

Flink定制输入输出源

  categories:资料  tags:  author:

本地输入输出

代码

package com.abeffect.blink;

import org.apache.flink.api.java.DataSet;
import org.apache.flink.api.java.ExecutionEnvironment;
import org.apache.flink.api.common.functions.FlatMapFunction;
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.util.Collector;

public class WordCount {

public static void main(String[] args) throws Exception {

// set up the execution environment
final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();

// get input … 阅读全文



快乐成长 每天进步一点点      京ICP备18032580号-1