实时计算Flink

最新推荐文章于 2024-02-22 20:00:45 发布
最新推荐文章于 2024-02-22 20:00:45 发布
阅读量942 收藏 4
点赞数 3
分类专栏： 大数据分布式平台 flink
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/code__online/article/details/116355224
版权

实时计算Flink

三种实时计算框架storm、spark streaming和flink的对比
  • storm延迟低但吞吐量小
  • spark streaming吞吐量大，但延迟高
  • flink是一种兼具低延迟和高吞吐量特点的流计算技术，还是一套框架中能同时支持批处理和流处理的
    一个计算平台

Flink流处理特性

  1. 高吞吐、低延迟、高性能
  2. 支持带有事件时间的窗口（Window）操作
  3. 支持有状态计算的Exactly-once语义
  4. 支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作
  5. 支持具有Backpressure功能的持续流模型
  6. 支持基于轻量级分布式快照（Snapshot）实现的容错
  7. 同时支持batch on Streaming处理和Streaming处理
  8. Flink在JVM内部实现了自己的内存管理
  9. 支持迭代计算
  10. 支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存

Flink技术栈图

image

  • 和spark类似，Flink也有Flink Core（runtime层）来统一支持流处理和批处理
  • Flink Core（runtime层）：一个分布式的流处理引擎，提供了支持Flink计算的全部核心实现
    • 支持分布式流处理
    • JobGraph到ExecutorGraph的映射、调度，为上层API提供基础服务
  • Flink API：实现了面向Stream的流处理和batch的批处理API
  • 特定应用领域库
    • Flink ML：提供机器学习库，通过Pipeline API来调用多种机器学习算法
    • 图计算库GElly：提供了图计算相关API和多种图计算算法实现

Flink基本概念

DataSet：对静态数据进行批处理操作、将静态数据抽象为分布式数据集，使用Flink各种操符处理数据集，支持Java、Scala、Python
DataStream：对数据流进行流处理操作，将流式的数据抽象为分布式数据流，用Flink各种操作符处理数据流，支持Java、Scala
Table API：对结构化数据进行查询操作，将结构化数据抽象为关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java、Scala

数据集：

  • 无界数据集：持续不断，不停地流入数据
  • 有界数据集：批次的数据

数据处理模型：

  • 流处理：实时任务，任务一直运行，处理无界数据
  • 批处理任务，处理有界数据，任务完成释放资源

Flink：将有界数据集当做无界数据集的一种特例
Spark Streaming：把无界数据集切割成有界，通过微批的方式进行流计算

Spark和Flink的区别
  • spark可以处理批量数据和流式数据，底层实现原理相同，都是转化为底层RDD，按照RDD DAG的逻辑进行操作
  • Flink虽然也可以同时进行批处理和流处理操作，但是，这两种操作是有所差异的，调用的方法也会不一样，属于两种不同的策略方案

API图解

image

  • runtime层以JobGraph形式接收程序。JobGraph即为一个一般化的并行数据流图（dataflow），它拥有任意数量的Task来接收和产生data stream。
  • DataStream API和DataSet API都会使用单独编译的处理方式生成JobGraph。DataSet API使用optimizer来决定针对程序的优化方法，而DataStream API则使用stream builder来完成该任务。
  • 在执行JobGraph时，Flink提供了多种候选部署方案（如local，remote，YARN等）。
  • Flink附随了一些产生DataSet或DataStream API程序的的类库和API：处理逻辑表查询的Table，机器学习的FlinkML，图像处理的Gelly，复杂事件处理的CEP。

Flink基本组件

image

Flink的三个基本组件：Source、Transformation（核心处理逻辑）和Sink

用户实现的Flink程序是由Stream和Transformation这两个基本构建块组成，其中Stream是一个中间结果数据，而Transformation是一个操作，它对一个或多个输入Stream进行计算处理，输出一个或多个结果Stream。当一个Flink程序被执行的时候，它会被映射为Streaming Dataflow。一个Streaming Dataflow是由一组Stream和Transformation Operator组成，它类似于一个DAG图，在启动的时候从一个或多个Source Operator开始，结束于一个或多个Sink Operator。 下面是一个由Flink程序映射为Streaming Dataflow的示意图，如下所示：

在这里插入图片描述

并行数据流

在Flink中，程序是并行和分布式的。一个Stream可以被分成多个Stream分区（Stream Partitions），一个Operator可以被分成多个Operator Subtask，每一个Operator Subtask是在不同的线程中独立执行的。一个Operator的并行度，等于Operator Subtask的个数，一个Stream的并行度总是等于生成它的Operator的并行度。

在这里插入图片描述

两个operator之间stream的两种模式：

One-to-one模式

比如从Source[1]到map()[1]，它保持了Source的分区特性（Partitioning）和分区内元素处理的有序性，也就是说map()[1]的Subtask看到数据流中记录的顺序，与Source[1]中看到的记录顺序是一致的。

Redistribution模式

这种模式改变了输入数据流的分区，比如从map()[1]、map()[2]到keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的Subtask向下游的多个不同的Subtask发送数据，改变了数据流的分区，这与实际应用所选择的Operator有关系。

在这里插入图片描述

任务、operator链

在Flink分布式执行环境中，Operator Chain将多个Operator Subtask串起来组成tasks，实际上就是一个执行链，它减少了线程到线程切换和缓存的开销，降低延迟的同时提高了整体吞吐量。每个执行链会在TaskManager上一个独立的线程中执行。

时间操作

  1. 事件时间（Event Time）：表示事件创建时间
  2. 采集时间（Ingestion Time）：表示事件进入到Flink Dataflow的时间
  3. 处理时间（Processing Time）：表示某个Operator对事件进行处理的本地系统时间

image

Event Time时间窗口的实现

Flink借鉴了Google的MillWheel项目，通过WaterMark来支持基于Event Time的时间窗口。

  • 当操作符通过基于Event Time的时间窗口来处理数据时，它必须在确定所有属于该时间窗口的消息全部流入此操作符后才能开始数据处理。但是由于消息可能是乱序的，所以操作符无法直接确认何时所有属于该时间窗口的消息全部流入此操作符。WaterMark包含一个时间戳，Flink使用WaterMark标记所有小于该时间戳的消息都已流入，Flink的数据源在确认所有小于某个时间戳的消息都已输出到Flink流处理系统后，会生成一个包含该时间戳的WaterMark，插入到消息流中输出到Flink流处理系统中，Flink操作符按照时间窗口缓存所有流入的消息，当操作符处理到WaterMark时，它对所有小于该WaterMark时间戳的时间窗口数据进行处理并发送到下一个操作符节点，然后也将WaterMark发送到下一个操作符节点。
  • 为了保证能够处理所有属于某个时间窗口的消息，操作符必须等到大于这个时间窗口的WaterMark之后才能开始对该时间窗口的消息进行处理，相对于基于Operator Time的时间窗口，Flink需要占用更多内存，且会直接影响消息处理的延迟时间。对此，一个可能的优化措施是，对于聚合类的操作符，可以提前对部分消息进行聚合操作，当有属于该时间窗口的新消息流入时，基于之前的部分聚合结果继续计算，这样的话，只需缓存中间计算结果即可，无需缓存该时间窗口的所有消息。

Flink使用WaterMark衡量事件时间，WaterMark携带时间戳t，并被插入到stream中。

  1. WaterMark的含义是所有时间t’< t的事件都已经发生。
  2. 针对乱序的的流，WaterMark至关重要，这样可以允许一些事件到达延迟，而不至于过于影响window窗口的计算。
  3. 并行数据流中，当Operator有多个输入流时，Operator的event time以最小流event time为准。
    在这里插入图片描述

窗口操作

  • 时间窗口：time window
    • 翻滚窗口：不重叠 [12:01-12:05]->[12:06-12:10]
    • 滑动窗口：有重叠 [12:01-12:05]->[12:02-12:06]->[12:03-12:07]
  • 事件窗口：每100条数据一个窗口（事件数量）
  • 会话窗口：不活动时间间隔来划分
    在这里插入图片描述

Flink API（略）

Flink 容错

Flink容错的核心：barrier（组标记栏）
以河水举例：
storm是一滴一滴处理数据
spark streaming像水坝，一批一批放水，上一批的水处完才放下一批水
Flink在水中定期插入barrier，水不停地流，只是加了些barrier。
注意：如果源头是多个数据流，那么都同步的增加同样的barrier，同时在job处理过程中，为了保证job失败时可以从错误中恢复，Flink对barrier进行对齐（align）操作

  • barrier被定期插入数据流中，作为数据流的一部分和数据一起向下流：一部分进入当前快照，另一部分进入下一个快照。
  • 每一个barrier都带有快照ID，barrier之前的数据都会进入此快照
  • 当一个中间（intermediate）operator接收到所有input stream的barrier n后，会发送Barrier n到属于该barrier的Snapshot n的数据流中。当一个Sink Operator接收到所有input stream的barrier n后会向Checkpoint Coordinator确认Snapshot n，直到所有的sink确认Snapshot n，才算最终完成快照（标志snapshot n快照结束）。

image

对齐

当Operator接收到多个输入的数据流时，需要在Snapshot Barrier中对数据流进行排列对齐：

  • Operator从一个incoming Stream接收到Snapshot Barrier n，然后暂停处理，直到其它的incoming Stream的Barrier n（否则属于2个Snapshot的记录就混在一起了）到达该Operator
  • 接收到Barrier n的Stream被临时搁置，来自这些Stream的记录不会被处理，而是被放在一个Buffer中。
  • 一旦最后一个Stream接收到Barrier n，Operator会emit所有暂存在Buffer中的记录，然后向Checkpoint Coordinator发送Snapshot n。
  • 继续处理来自多个Stream的记录

image

基于Stream Aligning操作能够实现Exactly Once语义，但是也会给流处理应用带来延迟，因为为了排列对齐Barrier，会暂时缓存一部分Stream的记录到Buffer中，尤其是在数据流并行度很高的场景下可能更加明显，通常以最迟对齐Barrier的一个Stream为处理Buffer中缓存记录的时刻点。在Flink中，提供了一个开关，选择是否使用Stream Aligning，如果关掉则Exactly Once会变成At least once。

Checkpoint机制

Flink的容错核心是保持分布式数据流和operator状态的snapshot一致性。Checkpoint并不仅仅是对数据流做了一个状态的snapshot，它也包含了一个Operator内部所持有的状态，这样才能够在保证在流处理系统失败时能够正确地恢复数据流处理。状态包含两种：

  • 系统状态：一个Operator进行计算处理的时候需要对数据进行缓冲，所以数据缓冲区的状态是与Operator相关联的。以窗口操作的缓冲区为例，Flink系统会收集或聚合记录数据并放到缓冲区中，直到该缓冲区中的数据被处理完成。
  • 一种是用户自定义状态（状态可以通过转换函数进行创建和修改），它可以是函数中的Java对象这样的简单变量，也可以是与函数相关的Key/Value状态。

当operator在接收到所有输入流barrier n的快照和提交barrier n到输出流之前，
对operator的状态做快照。在下一个barrier出现之前，operator的状态快照更新到state，一旦这个barrier被应用之后，不能对其做任何更新操作。该operator的状态被存储到state之后，operator向checkpoint发出确认信号，然后提交快照barrier到输出流。

快照结果包含两种：

  • 当快照启动时，每一个并行的数据流的offset/position
  • 对于每一个operator，有一个pointer指向存储在state后端的snapshot

image

任务调度

在JobManager端，会接收到Client提交的JobGraph形式的Flink Job，JobManager会将一个JobGraph转换映射为一个ExecutionGraph，ExecutionGraph是JobGraph的并行表示，也就是实际JobManager调度一个Job在TaskManager上运行的逻辑视图。

image

物理上进行调度，基于资源的分配与使用的一个例子：

image

  1. 左上子图：有2个TaskManager，每个TaskManager有3个Task Slot
  2. 左下子图：一个Flink Job，逻辑上包含了1个data source、1个MapFunction、1个ReduceFunction，对应一个JobGraph
  3. 左下子图：用户提交的Flink Job对各个Operator进行的配置——data source的并行度设置为4，MapFunction的并行度也为4，ReduceFunction的并行度为3，在JobManager端对应于ExecutionGraph
  4. 右上子图：TaskManager 1上，有2个并行的ExecutionVertex组成的DAG图，它们各占用一个Task Slot
  5. 右下子图：TaskManager 2上，也有2个并行的ExecutionVertex组成的DAG图，它们也各占用一个Task Slot
  6. 在2个TaskManager上运行的4个Execution是并行执行的

Back Pressure监控

概念：通常是由于某段时间内源头数据量的暴涨，导致流任务处理数据的速度远远小于源头数据的流入速度
导致问题：这种情况会导致流任务的内存越积越大，可能导致资源耗尽甚至系统崩溃
不同流计算引擎的处理方式不同：

  • Storm：通过监控process bolt中接收队列负载情况来处理反压，既当超过高水位值时，就会将反压信息写到Zookeeper，由于zookeeper的watch通知worker进入反压状态，最后spout停止发送tuple。
  • Spark Streaming：设置属性“Spark.Streaming.backpressure.enabled”进行自动反压，即动态控制数据接收速率来适配集群数据处理能力
  • Flink：不需要设置，自动处理反压，即每一个组件都有对应的分布式阻塞队列，只有队列不满的情况下，上游才发数据，较慢的接收者会自动降低发送速率，如果队列满了（有界队列），发送者会阻塞。Flink Web界面上提供了对运行Job的Backpressure行为的监控，它通过使用Sampling线程对正在运行的Task进行堆栈跟踪采样来实现。

image

默认情况下，JobManager会每间隔50ms触发对一个Job的每个Task依次进行100次堆栈跟踪调用，过计算得到一个比值，例如，radio=0.01，表示100次中仅有1次方法调用阻塞。Flink目前定义了如下Backpressure状态：
OK: 0 <= Ratio <= 0.10
LOW: 0.10 < Ratio <= 0.5
HIGH: 0.5 < Ratio <= 1

架构

  • 当Flink系统启动时，首先启动JobManager和一至多个TaskManager。JobManager负责协调Flink系统，TaskManager则是执行并行程序的worker。当系统以本地形式启动时，一个JobManager和一个TaskManager会启动在同一个JVM中。
  • 当一个程序被提交后，系统会创建一个Client来进行预处理，将程序转变成一个并行数据流的形式，交给JobManager和TaskManager执行。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nexxmjr2-1619947545387)(https://ci.apache.org/projects/flink/flink-docs-release-1.7/fig/processes.svg)]

Task的Slots和资源

  • 每一个worker（Taskmanager）是一个JVM进程，task slot可以理解为进程对内存资源的封装，里面运行一个或多个线程，每一个worker能接收多少task，由task slot来控制
  • 一个TaskManager进程中有多个subtask线程，意味着task将共享TCP连接（基于多路复用）和心跳消息，共享数据集和数据结构，减少每个task的负担
  • 这里的slot只对内存隔离管理，CPU不进行隔离

在这里插入图片描述

默认情况下，只要运行同一个Flink job，Flink允许subtasks共享slots即使它们是不同tasks的subtasks。这样的结果是一个solt能保存一个job的完整pipeline。slot共享由以下两个好处：

  • Flink集群task slots的数量和一个Flink job的并行度保持一致
  • 最大化利用slot资源 当没有slot共享时，source/map()这一非密集subtask和一个密集subtask所占用的资源一样多，不利于资源的有效利用。当slot共享时，一个Flink job均匀的分布在TaskManagers，并行度从2增加到6以达到最大化利用slots资源

在这里插入图片描述

状态后端

key/values形式的数据结构被存储的位置取决于所选择的状态后端

  • 一个是内存中的hash map
  • 另一个是RocksDB

除了定义保存state的数据结构，state backends实现了基于时间点对key/values做快照机制，并将快照作为checkpoint的一部分来存储。

在这里插入图片描述

Flink On Yarn

Flink在YARN集群上运行时：Flink job所需要的jar包和配置文件等先上传到HDFS中，Flink YARN Client负责与YARN RM通信协商资源请求，Flink JobManager和Flink TaskManager分别申请到Container去运行各自的进程。

YARN AM与Flink JobManager在同一个Container中，这样AM可以知道Flink JobManager的地址，从而AM可以申请Container去启动Flink TaskManager。待Flink成功运行在YARN集群上，Flink YARN Client就可以提交Flink Job到Flink JobManager，并进行后续的映射、调度和计算处理。

在这里插入图片描述

Flink环境安装

1.集群环境
hostnameIP
master192.168.63.20
slave1192.168.63.21
slave2192.168.63.22
2.官方下载：
[root@master src]# wget https://archive.apache.org/dist/flink/flink-1.4.0/flink-1.4.0-bin-hadoop26-scala_2.11.tgz
3.解压
[root@master flink-1.4.0]# tar -zxvf /usr/local/src/flink-1.4.0-bin-hadoop26-scala_2.11.tgz -C /usr/local/
4.修改配置文件

（1）修改conf/flink-conf.yaml

将jobmanager.rpc.address修改为集群jobmanager的hostname/IP

image

（2）修改masters文件

master：8081

（3）修改slaves文件

slave1
slave2

（4） 将flink目录拷贝到slave1和slave2中

[root@master flink-1.4.0]# scp -r /usr/local/flink-1.4.0 root@slave1:/usr/local/
[root@master flink-1.4.0]# scp -r /usr/local/flink-1.4.0 root@slave2:/usr/local/
5.启动集群

master

[root@master flink-1.4.0]# ./bin/start-cluster.sh

添加一个jobmanager

[root@master flink-1.4.0]# ./bin/jobmanager.sh start cluster|stop|stop-all

添加一个taskmanager

[root@master flink-1.4.0]# ./bin/taskmanager.sh start|stop|stop-all
6.监控页面

http://master:8081

image

7.任务进程

master

image

slave

image

Flink实践操作

本地idea实践

//导入flink scala 包
import org.apache.flink.streaming.api.scala._
import org.apache.flink.streaming.api.windowing.time.Time

object FlinkTest {
  def main(args: Array[String]): Unit = {
//    batch操作
//    val benv = ExecutionEnvironment.getExecutionEnvironment
//    val path = "/home/cqupt/Documents/data"
//    val dataSet = benv.readTextFile(s"$path/test.txt")
//    dataSet.map(_.split(",")(0)).map((_,1L)).groupBy(0).sum(1).print()

//    stream操作
//    构造一个stream的env
    val senv = StreamExecutionEnvironment.getExecutionEnvironment
    val dataStream = senv.socketTextStream("master",9999)
//    对数据流进行逻辑处理
    val wordcount = dataStream.map(x=>WordCount(x,1))
      .keyBy("word")
//    输出5s时间窗口里所有元素的第一个元素，并将所有元素数量统计出来
      .timeWindowAll(Time.seconds(5),Time.seconds(1))
//      .max("count")
//    事件窗口里所有元素数量上限为5，元素输出步长为2，输出为窗口第一个到达的元素
//      .countWindowAll(5,2)
//    时间窗口：窗口长度为5s，窗口每隔1s滑动一次
//      .timeWindow(Time.seconds(5),Time.seconds(1))
//    事件窗口：窗口某一个元素数量上限为10，每一个元素出现2次才进行输出，某个元素数量达到10后，再输入这个元素输出依旧为10
//      .countWindow(10,2)
      .sum("count")

    wordcount.print()

    senv.execute("stream")

  }
 //    定义一个class
  case class WordCount(word:String,count:Long)
}

输出结果

image

standalone集群

1. 启动集群
[root@master flink-1.4.0]# cd /usr/local/flink-1.4.0/
[root@master flink-1.4.0]# ./bin/start-cluster.sh
2. 提交任务到集群

slave2提前开启监听端口号9999

[root@slave2 ~]# nc -lp 9999

将jar包提交到集群

[root@master flink-1.4.0]# ./bin/flink run examples/streaming/SocketWindowWordCount.jar --port 9999

查看监控页面 master：8081

image

输出结果如下

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/local/flink-1.4.0/lib/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/local/hadoop-2.6.1/share/hadoop/common/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
fa : 3
fsa : 1
af : 1
a : 6
as : 1
f : 7
 : 3
3. 关闭standalone模式

关闭监听端口9999即可

Flink on Yarn模式

1. 建立yarn-session
[root@master flink-1.4.0]# ./bin/yarn-session.sh -n 2 -s 1 -jm 1024 -tm 1024
2. 开启监听端口
[root@slave1 ~]# nc -lp 9999
3. 提交任务到集群
[root@master flink-1.4.0]# ./bin/flink run examples/streaming/SocketWindowWordCount.jar --port 9999
4. yarn集群监控页面 master：8088

image

5. 进入ApplicationMaster

查看输出结果

image

code__online
关注
  • 3
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 9
    评论
专栏目录
助力“新基建” | 基于StreamWorks构建实时大数据处理平台
袋鼠云的博客
04-14 1479
2020年春节期间，一场突如其来的疫情在全国蔓延开来，打破了大家原有的工作生活节奏。疫情期间，大家宅在家就能随时看到实时的大数据疫情地图，可以随时刷到自己当前感兴趣的抖音视频，这一切背后依赖的最重要的技术，就是实时大数据处理技术。 现在疫情即将过去，国家提出要加快大数据中心等新型基础设施建设，实时大数据处理平台建设成为企业数智化转型过程中越来越重要的部分。 |什么是实时计算 在大数据处理领...
flink-ml:Apache Flink的机器学习库
03-31
Flink ML是一个提供机器学习（ML）API和库的库，可简化机器学习管道的构建。 它为MLlib开发人员提供了一套标准的ML API，以实现ML算法，并提供了ML算法库，这些库可用于为训练和推理工作构建ML管道。 Flink ML是在的保护下开发的。 建设项目 运行mvn clean package命令。 然后，您将找到一个包含应用程序的JAR文件，以及可能作为依赖项添加到该应用程序的任何库： target/<artifact>-<version>.jar 。 贡献 您可以在了解有关如何进行贡献的更多信息。 对于代码贡献，请仔细阅读“部分，以了解正在进行的社区工作。 执照 该存储库中的代码已获得。
浅谈实时计算
阿甘兄
09-07 3001
浅谈实时计算，概念、Flink技术以及常见的解决方案参考。
Flink ML 的新特性解析与应用
最新发布
Ververica的博客
02-22 1240
本文整理自阿里巴巴算法专家赵伟波，在 Flink Forward Asia 2023 AI 特征工程专场的分享。
实时计算知识，最详细的整理
麦地与诗人
02-23 3563
随着云计算、大数据等名词的流行，涌现出一大批相关的技术，其中Hadoop是较早出现的一种分布式架构，得到了大量的应用。本章先说明大数据和Hadoop的基本概念，之后介绍HDFS、MapReduce、YARN三个基本的Hadoop组件。除了基本组成部分，Hadoop生态圈中还有很多其他的工具组件，它们可以提供创建数据仓库所需的大部分功能。
一文读懂大数据实时计算
yuan_more的博客
07-11 2243
本文分为四个章节介绍实时计算，第一节介绍实时计算出现的原因及概念；第二节介绍实时计算的应用场景；第三节介绍实时计算常见的架构；第四节是实时数仓解决方案。 一、实时计算 实时计算一般都是针对海量数据进行的，并且要求为秒级。由于大数据兴起之初，Hadoop并没有给出实时计算解决方案，随后Storm，SparkStreaming，Flink等实时计算框架应运而生，而Kafka，ES的兴起使得实时计算领域的技术越来越完善，而随着物联网，机器学习等技术的推广，实时流式计算将在这些领域得到充分的应用。 实时计.
阿里云实时计算Flink版
03-06
阿里云实时计算Flink版
大数据实时计算FlinkSQL解密
03-03
阿里巴巴自2015年开始调研开源流计算引擎，最终决定基于Flink打造新一代计算引擎，针对Flink存在的不足进行优化和改进，并将最终代码贡献给开源社区。目前为止，我们已经向社区贡献了数百个Commiter。阿里巴巴将该...
大数据实时计算Flink SQL解密
06-26
2018年第九届中国数据库技术大会，阿里巴巴集团的伍翀分享
5小时玩转阿里云实时计算Flink实时湖仓-原始业务数据脚本.zip
08-25
5小时玩转阿里云实时计算Flink实时湖仓 5小时玩转阿里云实时计算Flink实时湖仓 5小时玩转阿里云实时计算Flink实时湖仓 5小时玩转阿里云实时计算Flink实时湖仓 5小时玩转阿里云实时计算Flink实时湖仓 5小时玩转阿里云...
大数据实时计算Flink SQL架构介绍.pptx
10-14
大数据实时计算Flink SQL架构介绍.pptx
大数据实时流计算详解
fegus的博客
07-13 2717
我曾任职于华为 2012 实验室高斯部门，负责实时分析型内存数据库 RTANA、华为公有云 RDS 服务的研发工作。目前，我专注于移动反欺诈解决方案的研发。针对公司业务需求，我开发了一个实时流计算系统，并在此基础上完成了风控系统的研发。最终，这个系统被一个独角兽收购。最近这两年，越来越多的业务和数据分析对实时性提出更高的要求，与之对应解决实时计算问题的流计算框架，也开始流行起来。因为工作原因，常有人问我有关实时流计算系统的问题。整体观察下来我发现：很多时候，他们并非不知道这些框架 ，也并非不熟悉这些框架的
你了解实时计算吗？
浩然之气,兼容并蓄 http://blog.csdn.net/gsky1986
07-27 2990
实时计算是什么？
什么是流式(实时)计算?
m0_58873085的博客
06-26 2642
什么是流式计算，流式计算与离线计算的区别，流式计算有哪些概念？流式计算有哪些框架，这些框架多方面性能如何？
Storm实时计算：Storm的实时计算原理和使用方法
禅与计算机程序设计艺术
07-03 5605
作者：禅与计算机程序设计艺术 Storm 实时计算：Storm 的实时计算原理和使用方法 在大数据处理领域，实时计算是一个重要的话题。在 Hadoop 生态系统中，Storm 是一个实时计算框架，它可以在实时数据流的基础上进行实时计算。本文将介绍 St
实时计算 Flink 与你相约阿里云
阿里云技术
01-05 540
摘要： 如何使用实时计算 Flink 搞定实时数据处理难题？本文由阿里巴巴高级技术专家邓小勇老师分享，从实时计算的历史回顾着手，详细介绍了阿里云实时计算 Flink 的核心优势与应用场景，文章内容主要分为以下四部分： 历史回眸 选择理由 产品介绍 未来可期 众所周知，阿里云的 Slogan 是“计算是为了无法计算的价值”。计算的实体是数据，但是随着时间的推移，数据的价值其实是逐渐递减的。如何从数据产生开始，尽早地发掘它的最大价值，成为实时计算不懈追求的目标。 随着技术的发展， Flink 已经成为
开源Flink迁移至实时计算Flink
song_quan_的博客
10-11 1421
Flink各类任务迁移。数据准确性校验。业务稳定性验证。Flink集群容量评估。
基于Kafka+Flink+Redis的电商大屏实时计算案例
微信搜：import_bigdata，大数据领域硬核原创作者
11-07 2888
前言一年一度的双11又要到了，阿里的双11销量大屏可以说是一道特殊的风景线。实时大屏（real-time dashboard）正在被越来越多的企业采用，用来及时呈现关键的...
基于实时计算Flink版的场景解决方案demo
阿里云开发者
09-03 1137
简介：通过两个demo分享技术实时计算flink版的解决方案本文整理自阿里云智能行业解决方案专家GIN的直播分享直播链接：https://developer.aliyun.com/learning/course/839本文主要分享两个基于 Flink 制作的实时大数据的应用。为了更好的体现应用的价值以及它所代表的典型的场景，这次的分享定制了两个接近现实生活中的应用案例。第一个是如何去做实时的 API 应用服务日志的分析，第二个是采用模拟的 IoT 遥测数据去分析车辆的引擎，并且做实时的异常侦测，以达到做预测
每日实时uv计算flink
09-25
每日实时UV计算是一项利用Flink来实现的任务。首先，我们需要明确UV（Unique Visitors）的含义，它代表网站或应用程序中的独立访客数量。通过实时UV计算，我们可以了解每天有多少独立访客访问我们的网站或应用程序。...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 9
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值