Flink带头大哥2019/02/15         
近期,阿里将Blink开源的事儿在大数据圈引起了不小的骚动。本次开源的 Blink 代码在 Flink1.5.1 版本之上,加入了大量的新功能,以及在性能和稳定性上的各种优化。主要贡献包括:阿里巴巴在流计算上积累的一些新功能和性能的优化,一套完整的(能够跑通全部 TPC-H/TPC-DS,能够读取 Hive meta 和 data)高性能 Batch SQL,以及一些以提升易用性为主的功能(包括支持更高效的 interactive programming,与 zeppelin 更紧密的结合,以及体验和性能更佳的 Flink web)。
众所周知,阿里非常重视Flink,相信很多大数据爱好者和我一样,非常好奇阿里都用Flink干些啥。好吧,今天头哥儿就来盘它。
Flink四大应用场景
阿里在Flink的应用主要包含四个模块:实时监控、实时报表、流数据分析和实时仓库。
实时监控:
1. 用户行为预警、app crash 预警、服务器攻击预警
2. 对用户行为或者相关事件进行实时监测和分析,基于风控规则进行预警
实时报表:
1. 双11、双12等活动直播大屏
2. 对外数据产品:生意参谋等
3. 数据化运营
流数据分析:
1. 实时计算相关指标反馈及时调整决策
2. 内容投放、无线智能推送、实时个性化推荐等
实时仓库:
1. 数据实时清洗、归并、结构化
2. 数仓的补充和优化
头哥儿分析了很多公司的应用案例发现,其实Flink主要用在如下三大场景:
上图包含两块:Traditional transaction Application(传统事务应用)和Event-driven Applications(事件驱动应用)。
Traditional transaction Application执行流程:比如点击流Events可以通过Application写入Transaction DB(数据库),同时也可以通过Application从Transaction DB将数据读出,并进行处理,当处理结果达到一个预警值就会触发一个Action动作,这种方式一般为事后诸葛亮。
Event-driven Applications执行流程:比如采集的数据Events可以不断的放入消息队列,Flink应用会不断ingest(消费)消息队列中的数据,Flink 应用内部维护着一段时间的数据(state),隔一段时间会将数据持久化存储(Persistent sstorage),防止Flink应用死掉。Flink应用每接受一条数据,就会处理一条数据,处理之后就会触发(trigger)一个动作(Action),同时也可以将处理结果写入外部消息队列中,其他Flink应用再消费。
典型的事件驱动类应用:
1.欺诈检测(Fraud detection)
2.异常检测(Anomaly detection)
3.基于规则的告警(Rule-based alerting)
4.业务流程监控(Business process monitoring)
5.Web应用程序(社交网络)
Data Analytics Applications包含Batch analytics(批处理分析)和Streaming analytics(流处理分析)。
Batch analytics可以理解为周期性查询:比如Flink应用凌晨从Recorded Events中读取昨天的数据,然后做周期查询运算,最后将数据写入Database或者HDFS,或者直接将数据生成报表供公司上层领导决策使用。
Streaming analytics可以理解为连续性查询:比如实时展示双十一天猫销售GMV,用户下单数据需要实时写入消息队列,Flink 应用源源不断读取数据做实时计算,然后不断的将数据更新至Database或者K-VStore,最后做大屏实时展示。
Data Pipeline Applications包含Periodic (周期性)ETL和Data Pipeline(管道)
Periodic ETL:比如每天凌晨周期性的启动一个Flink ETL Job,读取传统数据库中的数据,然后做ETL,最后写入数据库和文件系统。
Data Pipeline:比如启动一个Flink 实时应用,数据源(比如数据库、Kafka)中的数据不断的通过Flink Data Pipeline流入或者追加到数据仓库(数据库或者文件系统),或者Kafka消息队列。
一个思考题:假设你是一个电商公司,经常搞运营活动,但收效甚微,经过细致排查,发现原来是羊毛党在薅平台的羊毛,把补给用户的补贴都薅走了,钱花了不少,效果却没达到。你怎么办?能用Flink解决吗?