快乐成长



每天进步一点点

携程基于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