第一章 为什么要用flink?

一、背景

阿里巴巴以9000万欧元的价格收购了位于柏林的Data Artisans这家最牛逼的开源流引擎Flink背后的创业公司。
在Hadoop生态圈,Flink是一个比Spark更新的引擎。Spark你肯定知道了,就是那个取代了MapReduce成为新一代数据处理引擎霸主的。
但是你可能不知道,阿里巴巴内部已经全面用Flink取代了Spark。
所以如果你只学Hadoop和Spark,却不学Flink,马上就会在大数据的浪潮里掉队伍。
阿里用Flink服务了上亿的用户

1、Flink为什么敢成为新一代流计算?

2、Flink带来了什么高级抽象?

3、Flink的状态为什么是VIP?

4、Flink是大数据的未来吗?

5、Flink源码深入讲解
通过这套教程,结合项目实践代码,你会得到哪些收获?
1.大数据主流框架深入讲解,不仅讲应用,更会深入讲框架底层源码;建立起整个大数据的知识框架
2.如何深入理解大数据的架构底层平台、大数据的应用开发和平台之间的关系;
3.以及如何更好的把相应的平台知识和应用开发结合起来的方法。

二、flink特点

  • 支持高吞吐、低延迟、高性能的流处理
  • 支持高度灵活的窗口(Window)操作
  • 支持有状态计算的Exactly-once语义
  • 提供DataStream API和DataSet API

三、应用场景

那这些场景对应着什么业务需求呢?我们来总结下,大概如下:

flink 配置不依赖hadoop启动 flink为何要依赖hadoop_数据

初看这些需求,是不是感觉很难?那么我们接下来来分析一下该怎么去实现?
从这些需求来看,最根本的业务都是需要实时查看数据信息,那么首先我们得想想如何去采集这些实时数据,然后将采集的实时数据进行实时的计算,最后将计算后的结果下发到第三方。

1、数据实时采集

就上面这些需求,我们需要采集些什么数据呢?

  1. 买家搜索记录信息
  2. 买家浏览的商品信息
  3. 买家下单订单信息
  4. 网站的所有浏览记录
  5. 机器 CPU/MEM/IO 信息
  6. 应用日志信息

2、数据实时计算

  1. 采集后的数据实时上报后,需要做实时的计算,那我们怎么实现计算呢?
  2. 计算所有商品的总销售额
  3. 统计单个商品的销量,最后求 Top5
  4. 关联用户信息和浏览信息、下单信息
  5. 统计网站所有的请求 IP 并统计每个 IP 的请求数量
  6. 计算一分钟内机器 CPU/MEM/IO 的平均值、75 分位数值
  7. 过滤出 Error 级别的日志信息

3、数据实时下发

实时计算后的数据,需要及时地下发到下游,这里说的下游代表可能是以下几项

  1. 告警方式(邮件、短信、钉钉、微信)
    在计算层会将计算结果与阈值进行比较,超过阈值触发告警,让运维提前收到通知,及时做好应对措施,减少故障的损失大小。
  2. 存储(消息队列、DB、文件系统等)
    数据存储后,监控大盘(Dashboard)从存储(ElasticSearch、HBase 等)里面查询对应指标的数据就可以查看实时的监控信息,做到对促销活动的商品销量、销售额,机器 CPU、MEM 等有实时监控,运营、运维、开发、领导都可以实时查看并作出对应的措施。
  • 让运营知道哪些商品是爆款,哪些店铺成交额最多,哪些商品成交额最高,哪些商品浏览量最多:
  • 让运维可以时刻了解机器的运行状况,出现宕机或者其他不稳定情况可以及时处理:
  • 让开发知道自己项目运行的情况,从 Error 日志知道出现了哪些 Bug:
  • 让领导知道这次促销赚了多少 money:
    从数据采集到数据计算再到数据下发,整个流程在上面的场景对实时性要求还是很高的,任何一个地方出现问题都将影响最后的效果!

4、实时计算场景

前面说了这么多场景,这里我们总结一下实时计算常用的场景有哪些呢?

  1. 交通信号灯数据
  2. 道路上车流量统计(拥堵状况)
  3. 公安视频监控
  4. 服务器运行状态监控
  5. 金融证券公司实时跟踪股市波动,计算风险价值
  6. 数据实时 ETL
  7. 银行或者支付公司涉及金融盗窃的预警
    ……
    另外自己还做过调研,实时计算框架的使用场景有如下这些:
    业务数据处理,聚合业务数据,统计之类
  • 流量日志A
  • ETL
  • 安防这块, 公安视频结构化数据, 用F link做图片搜索
  • 风控,主要处理结构化数据
  • 用F link做业务告警
  • 动态数据监控
    大屏实时展示
  • 实时数据分析
  • 实时预警
  • 实时指标统计
  • 实时报表统计
  • 实时决策(F link CEP)
  • 广告业务, 多流join
  • 工业大数据,需要有状态的实时计算框架
  • 毕业论文/日志处理
    总结一下大概有下面这四类:
1. 实时数据存储

实时数据存储的时候做一些微聚合、过滤某些字段、数据脱敏,组建数据仓库,实时 ETL。

2. 实时数据分析

实时数据接入机器学习框架(TensorFlow)或者一些算法进行数据建模、分析,然后动态的给出商品推荐、广告推荐

3. 实时监控告警

金融相关涉及交易、实时风控、车流量预警、服务器监控告警、应用日志告警

4. 实时数据报表

活动营销时销售额/销售量大屏,TopN 商品

说到实时计算,这里不得不讲一下和传统的离线计算的区别。

5、离线计算 vs 实时计算

再讲这两个区别之前,我们先来看看流处理和批处理的区别:

流处理与批处理

flink 配置不依赖hadoop启动 flink为何要依赖hadoop_flink_02

看完流处理与批处理这两者的区别之后,我们来抽象一下前面文章的场景需求(实时计算):

flink 配置不依赖hadoop启动 flink为何要依赖hadoop_flink 配置不依赖hadoop启动_03

实时计算需要不断的从 MQ 中读取采集的数据,然后处理计算后往 DB 里存储,在计算这层你无法感知到会有多少数据量过来、要做一些简单的操作(过滤、聚合等)、及时将数据下发。

相比传统的离线计算,它却是这样的:

flink 配置不依赖hadoop启动 flink为何要依赖hadoop_apache_04

在计算这层,它从 DB(不限 MySQL,还有其他的存储介质)里面读取数据,该数据一般就是固定的(前一天、前一星期、前一个月),然后再做一些复杂的计算或者统计分析,最后生成可供直观查看的报表(dashboard)。

离线计算的特点
  • 数据量大且时间周期长(一天、一星期、一个月、半年、一年)
  • 在大量数据上进行复杂的批量运算
  • 数据在计算之前已经固定,不再会发生变化
  • 能够方便的查询批量计算的结果
实时计算的特点

在大数据中与离线计算对应的则是实时计算,那么实时计算有什么特点呢?由于应用场景的各不相同,所以这两种计算引擎接收数据的方式也不太一样:离线计算的数据是固定的(不再会发生变化),通常离线计算的任务都是定时的,如:每天晚上 0 点的时候定时计算前一天的数据,生成报表;然而实时计算的数据源却是流式的。

这里我不得不讲讲什么是流式数据呢?我的理解是比如你在淘宝上下单了某个商品或者点击浏览了某件商品,你就会发现你的页面立马就会给你推荐这种商品的广告和类似商品的店铺,这种就是属于实时数据处理然后作出相关推荐,这类数据需要不断的从你在网页上的点击动作中获取数据,之后进行实时分析然后给出推荐。

流式数据的特点
  • 数据实时到达
  • 数据到达次序独立,不受应用系统所控制
  • 数据规模大且无法预知容量
  • 原始数据一经处理,除非特意保存,否则不能被再次取出处理,或者再次提取数据代价昂贵

**实时计算一时爽,一直实时计算一直爽,**对于持续生成最新数据的场景,采用流数据处理是非常有利的。例如,再监控服务器的一些运行指标的时候,能根据采集上来的实时数据进行判断,当超出一定阈值的时候发出警报,进行提醒作用。再如通过处理流数据生成简单的报告,如五分钟的窗口聚合数据平均值。复杂的事情还有在流数据中进行数据多维度关联、聚合、筛选,从而找到复杂事件中的根因。更为复杂的是做一些复杂的数据分析操作,如应用机器学习算法,然后根据算法处理后的数据结果提取出有效的信息,作出、给出不一样的推荐内容,让不同的人可以看见不同的网页(千人千面)。
实时计算面临的挑战

  • 数据处理唯一性(如何保证数据只处理一次?至少一次?最多一次?)
  • 数据处理的及时性(采集的实时数据量太大的话可能会导致短时间内处理不过来,如何保证数据能够及时的处理,不出现数据堆积?)
  • 数据处理层和存储层的可扩展性(如何根据采集的实时数据量的大小提供动态扩缩容?)

总结:主流大数据处理框架的未来——flink
Flink资源:681vip资料分享网