广州市建设厅网站首页,铜川网站建设电话,平台网站开发可行性分析,wordpress怎么修改右上角的内容本文由趣头条实时平台负责人席建刚分享趣头条实时平台的建设#xff0c;整理者叶里君。文章将从平台的架构、Flink 现状#xff0c;Flink 应用以及未来计划四部分分享。
一#xff0e;平台架构
1.Flink 应用时间线 首先是平台的架构#xff0c;2018 年 3 月之前基本都是基…本文由趣头条实时平台负责人席建刚分享趣头条实时平台的建设整理者叶里君。文章将从平台的架构、Flink 现状Flink 应用以及未来计划四部分分享。
一平台架构
1.Flink 应用时间线 首先是平台的架构2018 年 3 月之前基本都是基于 Storm 和 Spark Streaming 来做的。目前基本已经把 Spark Streaming 和 Storm 淘汰了主要都是 Flink SQL 来做的。起初还比较传统一般是接需求然后开发类似于 Flink SQL 的任务基本是手工作坊操作模式。
后来 Flink SQL 的任务逐渐多了起来就开始考虑往平台化方向发展。大概在 2018 年 10 月份我们开始搭建实时平台。当时设计实时平台时就直接抛弃了 Spark Streaming 和 Storm基础理念设计的时候主要以 Flink 场景来设计平台。趣头条实时平台上线将近两个月后当时任务量并不多由于趣头条基本都是 PHP 和 Golang 开发语言而Flink更偏向于 Java 包括它 API 的提供所以经常会接到用户需求如 Golang 能不能开发 PHP 能不能开发
这个问题听起来比较奇怪但是对于不会用并且确实也想用的用户就需要想办法解决这个问题。后来我们做了一版类似于 Flink SQL 配置化开发可以让用户不用写Flink 代码初衷是考虑到操作门槛如果相对高那么 Flink 在趣头条的应用推进就不会这么顺畅。这也是 1.0 的配置开发诞生的背景。
在以上三件事情完成后这个平台基本就能提供给有开发能力的同学开发一些 Flink 任务同时类似于分析师、优秀的产品等没有开发能力的的同学也知道 Flink他们更关心每天曲线的变化可以根据数据对一些产品做相应的策略调整能够自己配比较简单的 SQL 化任务。
在此之后平台任务逐渐增多就开始做实时平台的分布式包括多集群。单集群因为部分部门的任务要求较高至少要达到三个九的标准所以当时设计的时候就考虑到要支持 Flink 多集群后期比如说 A 集群故障了可以让用户立马切到B集群发布两集群保持互通底层 Checkpoint 是可以实时同步的。
到了 19 年 6 月份1.0 配置化开发的方案不是更抽象的或者说不是 Flink 工程化的结构后来也参考 Flink 的开源分支 Blink 并参考 Blink 自己实现了一版类似于 Blink 的方案之后基本在配置化开发这一块可以推广给代码开发的同学因为他们可能对 Source 的源跟 Sink 源包括一些数据中间环节的处理流程比产品和分析师稍微了解的相对较多。
2.集群及任务量 这个是目前集群的规模CPC 集群差不多是 30 个节点采用了 Flink on Yarn 的这种模式这个是独立的计费集群会有一些广告商的点击计费统计。当时这个定的时候会是由两个集群去跑两个任务类似于 HA它可以在应用层面去做降级。比如说集群挂了它还可以在另外公共集群也会有任务。这样的话就是说如果出问题至少不会两个集群同时出问题这种概率应该是比较小。
公共集群现在是 200 多个节点到今年 10 月左右节点数可能会增至 400 到 500 个左右。目前 Kafka 也是有多副本集群的后续 Kafka 的数据流的转换也是通过 Flink 去实现可配置化的方式数据导流比如 Kafka 是公司数据流的核心的链路之一如果出问题的话会导致整个影响所有的依赖于上下游这种数据消费。目前 Kafka 那边会有多副本集群这种概念那 Flink 在中间扮演的就是我可以把这个数据流实时的同步到不同的集群去做类似于做容灾的方案。
3.数据流架构
公共集群 Flink 的任务目前是 200 多然后 CPC 是十多个任务下面为数据流结构数据源基本来自于手机端 H5 还有服务端。然后中间会有一层 Log Server 这个是公司自己开发的全部打到了 Log Server 之后Log Server 会打到 KafkaKafka 也是多链路有主副本集群这种概念中间环节在之前是有 storm 和 spark目前 100% 都是 Flink。 接下来就是 Sink 出来以后的数据目前用的种类还是挺多的包括 MySQL ClickhouseCassandra Elasticsearch 包括也会落部分 Hadoop 到 HDFS 还有 Prometheus。再往后主要是基于后续落的数据做了一些类似于企业级的应用最上面 Dashboard 是大屏一般是用来显示数据流的大屏。第二个是基础部门的性能指标。
最下面是数据入库下面是机器学习使用目前 TensorFlow 基本是通过 Flink 拼接样本清洗一些数据然后落一些 TensorFlow 的数据结构出来再通过 TensorFlow 做机器学习的训练。
4.平台架构 以上为趣头条的平台架构之前也是单节点只能做集群的任务发布目前改造成提供给用户的 HA 架构中间开发一层类似于发布机器的概念上面部了 Flink Gateway 即每集群在同样的 Gateway 上是可以随意切换的比如说 Server 1Server 2Server 3三个环境是一样的后续如果需要扩容也只需要去扩 Flink Gateway同样的再去部署一套就行了。
再下面 Flink Gateway 可以往 Hadoop 集群上发比如目前用的是 Hadoop Yarn是两个集群即 Gateway 可以任意切换到这两个集群发布任务。后续就是通过Filebeat将任务所有运行的记录及日志收集上来。收集完成之后也有基于Flink开发的通用日志统计和分析的工具将数据落到ELKElasticsearch Logstash Kibana以下简称 ELK里然后提供给用户。比如用户任务上线之后可能会出现一些异常包括统计等都会接到ELK里面由 ELK 提供可视化的界面这个就是平台的架构。
二Flink 应用
1.应用场景 第二部分就是 Flink 目前在基分的应用除了趣头条米读、米读极速版跟萌推目前这些产品包括数据流的统计数据中间处理环节基本已经换到 Flink 来了支撑整个集团的产品。业务场景大概主要是计费、监控、仓库画像包括算法、内容线六部分。
计费主要是算广告商接入的计费成本跟他们进行结算。每次广告点击完成后每个月可能会有类似于离线报表目前如果需要切换成实时基本只需要点击就会产生扣费环节这个算是非常核心的任务。监控有各种比如说机器层面的应用层面的。仓库目前基本是批量落数据比如说五分钟、十分钟类似于窗口的间隔时间去落数据画像即将用户画像的一些数据通过 Flink 清洗完成之后会落到 HDFS 上用来做训练。算法目前除了用户画像还有推荐目前的 APP 打开之后会给不同用户推荐不同的内容。内容线目前做的是风控可能有一些用户知道 APP 会去刷金币比如说打开某个内容之后不看内容而可能是在后台跑一百多个程序刷金币目前通过 Flink 可以做到实时风控能实时识别出某台设备究竟是不是真正的用户如果不是就会将其屏蔽掉。
2.用户声音
Flink 能用 Python/Golang 开发吗Flink 好学吗我就会 SQL 可以用吗有没有更简单的方式
以上四个问题是目前接触到的公司内部用户在 Flink 应用时经常会提到的包括最初去推实时平台时可能很多人都会问 Flink 怎么用、能否用 Python 或者 Golang 进行开发或者仅会 SQL 不会写代码也想用等。
Flink 究竟好不好用给业务线培养 Flink 的开发人员所面临情况在于部分业务线确实知道 Flink但是没有 Java 的背景语言上主要写 Golang或者每个月需要对产品进行一些策略的调整但如果没有数据去看基本就是摸黑的无法评估策略调完之后可能会给产品带来什么样的影响。
3.解决方案
针对以上问题我们也拿出了解决方案。在第一版的时候用户只需要写 SQL即会有类似于内存里的宽表Flink 把从 Kafka 消费过来的数据抽象成内存的一张表用户只需要打开如下界面根据自己的逻辑去写自定义 SQL就可以提供给产品和分析师包括其他想用平台的用户。有了这个解决方案之后其他用户就可以通过简单的方式来体验到 Flink 带来便捷。 SQL 配置化 1.0 版本中 SQL 是有限制的测试显示如果提供给用户写的 SQL 越来越多Checkpoint 的压力与 distinct 的这种计算结果会带来数据倾斜的这种压力导致任务可能会失败所以在设计 SQL 代码量时有一定的限制不会让用户无休止的加 SQL基本目前限制是 10 个。在 1.0 版本上线之后刚好 Blink 开源出来了我们知道 1.0 方案还是不够优雅(从工程化看)又参考 Flink 和开源出来的 Blink 方案升级到了第二版可以更大化的提供用户自定义的方式也可以把数据源抽象出来数据源就不仅仅是 Kafka 了很大程度上改善了原来 1.0 的版本。当所有的数据来了之后先到 Kafka目前数据源可以支持 HDFS、MySQL、MQ 等只需要创建 Source 源的概念。下面是平台较详细的截图基本是输入输出以及统计逻辑。 目前跟 Blink 基本如出一辙也是参考了 Blink 的一些设计思路和方法。这个功能已经上线基本有五、六十个任务已经在用了用户对当前的平台还是比较满意的。不过更期望写 SQL 基本就能完成统计指标这也是实时平台后续想要去做的尽可能的再去屏蔽一些资源设置比如tm/slot 一般用户不太懂。 三现状 第三部分是想分享一下趣头条实时平台的现状目前 Flink 1.9 版本已经出来了我们在测 Flink 1.9 的新特性Flink 对 Python 的支持是非常惊喜的内部很多用户还是比较喜欢脚本式语言的而 Python 的开发是写脚本式语言就能提交 Flink 任务这是我们当前测试内容的一部分。另一部分是 Flink 模板简化上面提到的 2.0 模板让用户写一大堆的 SQL还是比较麻烦的用户还是更倾向于统计逻辑的简单 SQL。我们最终的目标还是想把 Flink 推广到整个集团公司让更多的受众参与进来享受 Flink 带来的好处。
最后一块是 Flink SQL 的 HDFS 落库目前这个功能开发完了目标是将 Kafka 出来的数据做类似的实时仓库即数据可以实时落到 HDFS 上而上一个版本是通过 Flink 开发基本是按时间窗口去落的还不是实时的。
四未来计划 首先版本升级趣头条的实时平台目前用的是 Flink 1.7后续是想往 1.9 版本去切Flink 1.9 版本提供的 Task Fault Tolerance 的容错、Checkpoint 的容错等很好的修复了 1.7 版本中存在的问题。
第二实时仓库趣头条当前用到的 Flink 按时间窗口落可能数据也不是实时的后续想让它做到类似于秒级数据流入体大提升仓库服务数据能力。
第三平台智能诊断当前工作中更大一部分时间是在解答用户问题用户在使用中出现的各种报错无法自行解决需要平台提供技术上的支持这部分其实比较影响平台规划的目标方向的进度因此后面想开发平台智能诊断。常见的报错和最佳实践都归纳下来集成到平台中。出现问题时能够自动诊断识别推荐给用户解决方案。
第四Flink 弹性式资源计算这是目前面临的比较重要的问题。目前 300 多个任务集群的规模增长也比较迅猛大约每周将近 20 台机器的扩容速度后续的资源利用率也是非常重要的。目前我了解 Flink 社区是没有类似于这种弹性式资源计算也期待社区能解决这类问题。比如Flink 任务起来之后可能业务方已经将流已经停掉了如果用户不去看这个任务其实他还是在跑。最终内存、资源还是被占着没有释放。
最后是 Flink 机器学习实践。目前机器学习平台基本用的还是批训练后续还是想去做一些尝试 Demo 方案提供给机器学习团队争取他们可以后续往 Flink 方向切换。
11 月 28-30 日趣头条的王金海老师将出席于北京国家会议中心举办的 Flink Forward Asia 2019并分享《趣头条基于 FlinkClickHouse 构建实时数据分析平台》大会倒计时 21 天还没报名的同学抓紧时间啦 届时阿里、腾讯、美团、字节跳动、百度、英特尔、DellEMC、Lyft、Netflix 及 Flink 创始团队等近 30 家知名企业资深技术专家齐聚国际会议中心与全球开发者共同探讨大数据时代核心技术与开源生态。 双11福利来了先来康康#怎么买云服务器最便宜# [并不简单]参团购买指定配置云服务器仅86元/年开团拉新享三重礼1111红包瓜分百万现金31%返现爆款必买清单还有iPhone 11 Pro、卫衣、T恤等你来抽马上来试试手气 https://www.aliyun.com/1111/2019/home?utm_contentg_1000083110
原文链接 本文为云栖社区原创内容未经允许不得转载。
