资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

Posted DBAplus社群

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)相关的知识,希望对你有一定的参考价值。


本文根据dbaplus社群第166期线上分享整理而成,文末还有好书送哦~


讲师介绍
资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

王新春

唯品会高级经理


  • 在唯品会负责实时平台相关内容,主要包括实时计算框架、提供实时基础数据及机器学习平台的工作。

  • 曾在美团点评同样负责大数据平台工作,在大数据实时处理方向积累了丰富经验。


本文主要内容包括以下几个方面:


  • 唯品会实时平台现状;

  • Flink在唯品会的实践;

  • Flink On K8S;

  • 最新项目进展。

一、唯品会实时平台现状


目前在唯品会,实时平台并不是一个统一的计算框架,而是包括Storm、Spark、Flink在内的三个主要计算框架。由于历史原因,当前在Storm平台上的job数量是最多的,但是从去年开始,业务重心逐渐切换到Flink上面,所以今年在Flink上面的应用数量有了大幅增加。


实时平台的核心业务包含八大部分:


  • RTRS(实时推荐引擎):实时推荐作为电商的重点业务,包含多个实时特征;

  • Dataeye大促看板):包含各种维度的统计指标(例如:各种维度的订单、UV、转化率、漏斗等),供领导层、运营、产品决策使用;

  • 实时数据清洗:从用户埋点收集来数据,进行实时清洗和关联,为下游的各个业务提供更好的数据;

  • 互联网金融;

  • 安全风控;

  • 与友商比价;

  • Logview、Mercury、Titan作为内部服务的监控系统;

  • VDRC实时数据同步系统等。


共计有1400台机器和600+应用。


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图1 实时核心业务


实时平台的职责主要包括实时计算平台和实时基础数据:


  • 实时计算平台在Storm、Spark、Flink等计算框架的基础上,为监控、稳定性提供了保障,为业务开发提供了数据的输入与输出;

  • 实时基础数据包含对上游埋点的定义和规范化,对用户行为数据、mysql的Binlog日志等数据进行清洗、打宽等处理,为下游提供质量保证的数据。


在架构设计上,包括两大数据源:


  • 一种是在App、微信、H5等应用上的埋点数据,原始数据收集后发送到Kafka中;

  • 另一种是线上实时数据的MySQL Binlog日志。数据在计算框架里面做清洗关联,把原始的数据通过实时ETL为下游的业务应用(包括离线宽表等)提供更易于使用的数据。


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图2 实时平台整体架构


二、Flink在唯品会的实践


场景一:Dataeye实时看板


Dataeye实时看板,支持需要对所有的埋点数据、订单数据等进行实时计算。具有数据量大的特点。并且需要统计的维度有很多,例如全站、二级平台、部类、档期、人群、活动、时间维度等,提高了计算的复杂程度,统计的数据输出指标每秒钟可以达到几十万。


以UV计算为例,首先对Kafka内的埋点数据进行清洗,然后与Redis数据进行关联,关联好的数据写入Kafka中;后续Flink计算任务消费Kafka的关联数据。


通常任务计算结果的量也很大(由于计算维度和指标特别多,可以达到上千万),数据输出也是通过Kafka作为缓冲,最终使用同步任务同步到HBase中,作为实时数据展示。


同步任务会对写入HBase的数据限流和同类型的指标合并,保护HBase。与此同时,还有另一路计算方案作为容灾。



资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图3 Dataeye计算任务架构


在以Storm为计算引擎中的进行指标计算时,需要使用Redis作为中间状态的存储。而切换到Flink后,Flink自身具备状态存储,节省了存储空间。由于不需要访问Redis,也提升了性能,整体资源消耗降低到了原来的1/3。


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图4 Storm VS Flink计算架构


在将计算任务从Storm逐步迁移到Flink的过程中,对两路方案先后进行迁移,同时将计算任务和同步任务分离,缓解了数据写入HBase的压力。


切换到Flink后也需要对一些问题进行追踪和改进。对于FlinkKafkaConsumer,由于业务原因,对Kafka中的Aotu Commit进行修改及对Offset的设定需要自己实现支持Kafka集群切换的功能。对不带Window的state数据需要手动清理。还有计算框架的通病——数据倾斜问题需要处理。同时对于同步任务追数问题,Storm可以从Redis中取值,Flink只能等待。


场景二:Kafka数据落地HDFS


之前都是通过Spark Streaming的方式去实现,现在正在逐步切换到Flink上面,通过OrcBucketingTableSink将埋点数据落地到HDFS上的Hive表中。


在Flink处理中,单Task Write可达到3.5K/s左右,使用Flink后资源消耗降低了90%,同时将延迟30s降低到了3s以内。目前还在做Flink对Spark Bucket Table的支持。


场景三:实时的ETL


对于ETL处理工作而言,存在的一个痛点就是字典表存储在HDFS中,并且是不断变化的,而实时的数据流需要与字典表进行join。


字典表的变化是由离线批处理任务引起的,目前的做法是使用ContinuousFile MonitoringFunction和ContinuousFileRea derOperator定时监听HDFS数据变化,不断地将新数据刷入,使用最新的数据去做join实时数据。


我们计划用更加通用的方式去支持Hive表和Stream的join,实现Hive表数据变化后数据自动推送的效果。


三、Flink On K8S


在唯品会内部有一些不同的计算框架:有实时计算的,有机器学习的,还有离线计算的,所以需要一个统一的底层框架来进行管理,因此将Flink迁移到了K8S上。


在K8S上使用了思科的网络组件,每个Docker容器都有独立的IP,对外也是可见的。实时平台的融合器整体架构如下图所示:


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图5 Flink On K8S架构


唯品会在K8S上的实现方案与Flink社区提供的方案差异还是很大的。唯品会使用K8S StatefulSet模式部署,内部实现了cluster相关的一些接口。一个job对应一个mini cluster,并且支持HA。


对于Flink来说,使用StatefulSet的最大的原因是pod的hostname是有序的;这样潜在的好处有:


  • hostname为-0和-1的pod可以直接指定为jobmanager;可以使用一个statefulset启动一个cluster,而deployment必须2个;Jobmanager和TaskManager分别独立的deployment;

  • pod由于各种原因fail后,由于StatefulSet重新拉起的pod的hostname不变,集群recover的速度理论上可以比deployment更快(deployment每次主机名随机)。


镜像的docker entrypoint脚本里面需要设置的环境变量设置说明:


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)


对应Flink集群所依赖的HDFS等其他配置,则通过创建configmap来管理和维护。


kubectl create configmap hdfs-conf --from-file=hdfs-site.xml --from-file=core-site.xml


四、最新项目进展


当前实时系统、机器学习平台要处理的数据分布在各种数据存储组件中,如Kafka、Redis、Tair和HDFS等,想要方便高效地访问、处理、共享这些数据是一个很大的挑战,对于当前的数据访问和解析常常需要耗费很多的精力,主要的痛点包括:


  • 对于Kafka、Redis、Tair中的Binary(PB/Avro等格式)数据,使用者无法快速直接地了解数据的schema及数据内容,采集数据内容及与写入者的沟通成本很高;

  • 由于缺少独立的统一数据系统服务,对Kafka、Redis、Tair等中的Binary数据访问需要依赖写入者提供的信息,如proto生成类、数据格式wiki定义等,维护成本高,容易出错;

  • 缺乏relational schema使得使用者无法直接基于更高效易用的SQL或LINQ层API开发业务;

  • 无法通过一个独立的服务方便地发布和共享数据;

  • 实时数据无法直接提供给Batch SQL引擎使用;

  • 此外,对于当前大部分的数据源的访问也缺少审计、权限管理、访问监控、跟踪等特性。


UDM(统一数据管理系统)包括Location Manager、Schema Metastore以及Client Proxy等模块,主要的功能包括:


  • 用户可以通过Web GUI界面方便地查看数据Schema,探查数据内容;

  • 提供支持审计、监控、溯源等附加功能的Client API Proxy;

  • 在Spark/Flink/Storm等框架中,以最适合使用的形式提供这些数据源的封装。


UDM的整体架构如下图所示:


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图6 UDM架构


UDM的使用者包括实时、机器学习以及离线平台中数据的生产者和使用者。在使用SQL API或Table API的时候,首先完成Schema的注册,之后使用SQL进行开发,降低了开发代码量。


以Spark访问Kafka PB数据的时序图来说明UDM的内部流程:


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

图7 UDM使用时序图


在Flink中,使用UDMExternalCatalog来打通Flink计算框架和UDM之间的桥梁,通过实现ExternalCatalog的各个接口及实现各自数据源的TableSourceFactory,完成Schema和接入管控等各项功能。


Q & A


Q:能详细描述一下“实现Hive表数据变化之后,数据自动推送的效果是指什么吗?


A:就是Hive表的数据更新后,可以在Flink里面缓存的数据也可以更新掉。这样jion的时候,就可以关联最新的数据了。目前来说,还是需要一些自己开发工作的,官方框架不支持。


直播回放


https://m.qlchat.com/topic/details?topicId=2000002260839321&tracePage=liveCenter

彩蛋来了

在本文微信订阅号(dbaplus)评论区留下足以引起共鸣的真知灼见,小编将在本文发布后的隔天中午12点根据留言精彩程度选出2位幸运读者,送出以下好书一本~

注:同一月份里,已获赠者将不可重复拿书。


资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)

特别鸣谢图灵社区为活动提供图书赞助。

一次对AIOps落地元年的初次总结

一场携BAT等名企大佬共同探索的盛宴

Gdevops广州收官之战

用前瞻思维与视角邀你前往!


扫描下图二维码了解更多详情↓↓

以上是关于资源消耗降低2/3,Flink在唯品会实时平台的应用(有彩蛋)的主要内容,如果未能解决你的问题,请参考以下文章

Flink 在唯品会的实践

Clickhouse 在唯品会数据产品的实践

唯品会在 Flink 容器化与平台化上的建设实践

唯品会:在 Flink 容器化与平台化上的建设实践

在唯品会上的未支付订单最后是怎么处理的

Leo|20页PPT剖析唯品会API网关设计与实践