关于flink:凭实力蝉联第一Flink-又双叒叕上榜啦

近期,Apache 软件基金会 2020 财年年度报告出炉,作为世界上最大的开源基金会,Apache 软件基金会治理着 2 亿多行代码,监督着 339+  Apache 我的项目。该报告回顾了 2020 财年基金会的次要成绩并对重大项目及重要事件进行盘点与总结。 其中,Flink 因为社区的参加和奉献在 Apache 我的项目中仍放弃着多项排名当先的记录: Mailing List 活跃度排名第一GitHub 访问量排名第二Commits 数排名第二与 2019 财年相比,Flink 邮件列表活跃度仍放弃 TOP 1,Commits 数排名由第三名回升至第二名,Github 访问量也有显著增长,在 Apache 我的项目中排名第二。 ▼ 以下为报告原文翻译 ▼ 往年是 Apache 软件基金会成立的第 21 个年头,从最后的仅 21 名创始人倒退至今,Apache 在报告中强调了其 “Apache 之道”(Apache Way)。报告中示意,正是这样一种社区驱动的 Apache 之道,促成了成千上万个开发者单干,使数百个我的项目走向成熟。报告还称,“地球上每个接入了互联网的国家都在应用 Apache 软件。” 2020 财年,Apache 软件基金会达成了以下次要成就: 增加了约 800 万行 Apache 代码,价值约 6 亿美元;总代码价值超过 200 亿美元;Apache 资料库中共治理着超过 2.27 亿行代码;选举了 34 名新的 ASF 集体成员,目前总计 813 名;超过 7,700 名代码提交者;206 个顶级社区,监督 339 个以上的 Apache 我的项目,以及数十个子项目和打算;9 个最新毕业的顶级我的项目;Apache 孵化器中目前有 45 个我的项目正在开发;apache.org 每周页面浏览量超过 3500 万;从 Apache 镜像下载的源代码大概有 2 PB;最沉闷的 Apache 我的项目前五名别离是:Kafka、Hadoop、Lucene、POI、ZooKeeper;提交次数排名前五的 Apache 我的项目别离是:Camel、Flink、Beam、HBase、Lucene Solr;按代码行排列的前五名 Apache 我的项目别离是:NetBeans、OpenOffice、Flex (combined)、Mynewt (combined)、Trafodion;2,892 个提交者在 174,889 次提交中更改了 60,132,710 行代码;12,413 人创立了 63,172 个新 issue;2,868 人敞开了 54,633 个 issue;19,396 位作者在 1,417 个邮件列表中针对 907,870 个主题发送了 2,137,560 封电子邮件;前 5 个最沉闷的邮件列表:Flink、Tomcat、Royale、Beam、Lucene Solr;2,045 个 git 存储库,蕴含约 250GB 代码和存储库历史记录;Apache HTTP Server 成立 25 周年(ASF 成立 21 周年);签订了 748 份集体贡献者许可协定(ICLA);签订了 33 份企业贡献者许可协定;签订了 40 项软件受权协定;以及ASF 间断 15 年负责 Google Summer of Code 的领导。点击下方链接可查看残缺报告~Flink 社区感激大家过来一年的参加和陪伴,Flink 成长的每一步都有你们的奉献,心愿将来也能持续与大家携手同行,迎接新挑战,发明新纪录! ...

August 5, 2020 · 1 min · jiezi

关于flink:单日课程超10万节VIPKID-如何通过实时计算提升上课体验

VIPKID 介绍VIPKID 是一家在线青少儿英语教育平台,成立七年以来,公司保持以赋能教育,启迪将来为使命,专一于一对一的线上教学模式,采纳 100% 的纯北美外教,学员遍布 63 个国家和地区。 截止目前,仅付费学生规模超 70 万人 ,单日一对一课量超 10 万节,顶峰时段课程并发最高达到 3.5 万节。领有笼罩了寰球 35 个国家的 5 条跨海专线,在 16 个国家、55 个城市实现数据中心传输节点布局,可能依据实时动静在一分钟内实现智能切换[1]。 外围业务场景次要场景介绍在一对一(一个老师和一个学生)模式的上课过程中,老师通过直播的模式以课件为辅助进行授课,互动的模式不仅包含直观的声音和视频还有聊天室以及在课件上写字划线拖动动作等,整个课程中波及多个组件模块。 各模块以协同依赖的形式提供服务,其中任意环节产生的事件对老师和学生都要做到可见和同步,如老师可看见学生在教室能力开始上课、学生可听见老师谈话、学生可看到老师翻页课件等能力持续失常上课直到完结。 在大规模网络教学中,流媒体实时互动直播和音讯实时数据传输重大依赖用户设施和网络,数据体量大,尤其咱们是跨海传输的状况下变得十分辣手,对于网络稳定性有着十分刻薄的要求。 与大班网课直播相比,1v1 更重视互动,所以对问题的容忍度极低,任何一方的问题都会影响上课体验。其中场景之一为当呈现网络等异样问题时,用户就会点击”Help“按钮进行求助,此时须要监课人员(以下简称“FM”,来自 Fireman 缩写)立即染指解决,这对服务人员的规模和操作实时性有较大的需要。 以后业务痛点目前在只有人工解决用户 Help 的模式下,因为日均 Help 申请量大(约占总课程的10%),人均监课量大,同时从接管到申请到监课人员染指解决问题也须要辗转多个流程,会有以下问题: 问题解决不及时,用户容易期待,阻断上课,带给用户体验差;人工解决效率低,课量减少以及大规模突发状况下,导致 FM 团队规模减少,须要更多人力;有些用户出了问题,没有分割监课人员的话,问题被暗藏;技术实现为了解决上文提到的业务痛点问题,通过各环节业务特征提取及梳理,咱们设计了一种通过实时计算来产出业务标签,并利用标签数据进行主动监课来解决用户 Help 的计划。下文将重点形容整个计划的技术实现细节:波及到数据体系建设、自动化业务零碎建设、外围问题与优化以及最终收益成果: 数据体系建设:介绍用于撑持整个实时计算的 Vlink 数据平台、以后场景下相干业务数据采集和业务标签数据计算,是业务实现的撑持;自动化业务零碎:介绍如何利用实时数据流来解决以后业务痛点;问题与优化:介绍实现过程中碰到的业务和技术问题以及解决方案;收益成果:介绍最终取得的收益成绩;数据体系建设整个数据体系建设的初衷是解决数据从哪里来、数据的业务逻辑是什么、如何计算、如何对立治理以及赋能更多场景,解决更多业务问题。 Vlink 数据平台:介绍一站式数据平台,提供数据接入明细:a.数据起源; b.数据的业务含意; c.数据打点法则,进步开发接入效率,解决上下游不明确问题; 业务数据采集:介绍以后场景下的业务数据采集;业务数据计算:介绍如何利用Flink来计算简单逻辑的业务数据;■ Vlink 数据平台Vlink 数据平台是基于在 Flink Streaming Job 开发过程中一些问题的反思后,借鉴服务端开发上线流程,以研发人员为核心的进步开发效率,升高保护老本为出发点而设计研发的零碎,并反对数据采集治理、打点接入治理、打点测试集成等性能。 次要性能点1.交互式运行作业 除 Flink Sql 外,业内对于 Streaming 类型的作业提交运行形式还是和官网提供的上传 Jar 包一样,打包 -> 期待并关注 -> 上传 -> 期待并关注 -> 运行。咱们联结运维团队,提供一键打包部署性能,可设置 AutoRun 在部署胜利后主动运行。 ...

August 4, 2020 · 2 min · jiezi

关于flink:Apache-Flink-Meetup-上海站精彩回顾附PPT下载

8月2日,往年首场线下 Apache Flink Meetup · 上海站圆满闭幕。久违的亲切脸孔,零距离交换互动以及标志性合照,还是原来的配方还是相熟的感觉!社区在尽力发明所有跟大家见面的可能! 本次上海站 Meetup,社区邀请了来自小红书、唯品会、英特尔、阿里巴巴的四位技术专家跟大家分享近期 Flink 的最新利用实际与最新社区动静。 Meetup 议题回顾:高能预警!Apache Flink Meetup · 上海站返场啦 流动亮点:唯品会批流交融的生产环境实际英特尔 Analytics Zoo 在 Flink 极客挑战赛中的利用案例分享Flink 在小红书实时平台中的利用Flink SQL 1.11 新性能与最佳实际▼合照▼ <关注公众号,回复“0802上海”即可获取直播回看链接及流动 PPT 合集> 关注 Flink 中文社区,获取更多技术干货

August 4, 2020 · 1 min · jiezi

关于flink:Flink生成dot文件的可视化执行计划图工具类使用

1.啥也不说,先上工具类代码: import com.google.gson.Gson;import java.util.HashMap;import java.util.Map;import java.util.regex.Matcher;import java.util.regex.Pattern;public class FlinkUtils { private static class FlinkPlanEdge { private int id; private String ship_strategy; @SuppressWarnings("unused") private String side; public int getId() { return id; } public String getShip_strategy() { return ship_strategy; } } private static class FlinkPlanNode { private static final FlinkPlanEdge[] NO_EDGES = new FlinkPlanEdge[0]; private int id; private String type; @SuppressWarnings("unused") private String pact; private String contents; private int parallelism; private FlinkPlanEdge[] predecessors; public int getId() { return id; } public String getType() { return type; } public String getContents() { return contents; } public int getParallelism() { return parallelism; } public FlinkPlanEdge[] getPredecessors() { if (predecessors == null) { return NO_EDGES; } else { return predecessors; } } } private static class FlinkPlan { private FlinkPlanNode[] nodes; public FlinkPlanNode[] getNodes() { return nodes; } } /** * Given a JSON representation of a Flink Topology (from StreamExecutionEnvironment#getExecutionPlan), convert it to * a standard .dot format suitable for visualizing with OmniGraffle and other programs. * * See http://www.graphviz.org/doc/info/lang.html See http://www.graphviz.org/doc/info/attrs.html * * @param plan * JSON version of plan * @return dot format graph. */ public static String planToDot(String plan) { FlinkPlan flinkPlan = new Gson().fromJson(plan, FlinkPlan.class); StringBuilder result = new StringBuilder("digraph G {\n"); // Keep track of iteration sources, which are implicit. So we map from // the iteration number to the source id Map<Integer, Integer> iterationMap = new HashMap<Integer, Integer>(); final Pattern ITERATION_SOURCE_NAME = Pattern.compile("IterationSource\\-(\\d+)"); final Pattern ITERATION_SINK_NAME = Pattern.compile("IterationSink\\-(\\d+)"); final Pattern SOURCE_OR_SINK_NAME = Pattern.compile("(Source|Sink): (.*)"); FlinkPlanNode[] nodes = flinkPlan.getNodes(); for (FlinkPlanNode node : nodes) { Matcher m = SOURCE_OR_SINK_NAME.matcher(node.getType()); boolean isSourceOrSink = m.matches(); String nodeName = isSourceOrSink ? m.group(2) : node.getContents(); String nodeShape = isSourceOrSink ? "box" : "ellipse"; boolean isIterationSourceOrSink = ITERATION_SOURCE_NAME.matcher(node.getType()) .matches() || ITERATION_SINK_NAME.matcher(node.getType()).matches(); String fillColor = isSourceOrSink || isIterationSourceOrSink ? "8EFF4C" : "FFFFFF"; result.append( String.format(" %d [shape=\"%s\", fillcolor=\"#%s\", label=\"%s (%d)\"];\n", node.getId(), nodeShape, fillColor, nodeName, node.getParallelism())); m = ITERATION_SOURCE_NAME.matcher(node.getType()); if (m.matches()) { // Map from iteration number to the source node id iterationMap.put(Integer.parseInt(m.group(1)), node.getId()); } } // Now dump out the edges // 1 -> 2 [label = "blah"]; for (FlinkPlanNode node : nodes) { int nodeId = node.getId(); FlinkPlanEdge[] edges = node.getPredecessors(); for (FlinkPlanEdge edge : edges) { result.append(String.format(" %d -> %d [label = \"%s\"];\n", edge.getId(), nodeId, edge.getShip_strategy())); } // Now check if this node is an iteration sink. If so, add an explicit edge // from it to the corresponding source node. Matcher m = ITERATION_SINK_NAME.matcher(node.getType()); if (m.matches()) { int iterationID = Integer.parseInt(m.group(1)); result.append(String.format(" %d -> %d [label = \"ITERATION\"];\n", node.getId(), iterationMap.get(iterationID))); } } result.append("}\n"); return result.toString(); }}2.在flink中应用 ...

August 4, 2020 · 3 min · jiezi

关于flink:从-19-到-111聊聊-PyFlink-的核心功能演进附-Demo-代码

Flink 1.11 正式公布曾经三周了,其中最吸引我的个性就是 Hive Streaming。刚巧 Zeppelin-0.9-preview2 也在前不久公布了,所以就写了一篇 Zeppelin 上的 Flink Hive Streaming 的实战解析。本文次要从以下几局部跟大家分享: Hive Streaming 的意义Checkpoint & Dependency写入 KafkaHive Streaming SinkHive Streaming SourceHive Temporal TableHive Streaming 的意义很多同学可能会好奇,为什么 Flink 1.11 中,Hive Streaming 的位置这么高?它的呈现,到底能给咱们带来什么? 其实在大数据畛域,始终存在两种架构  Lambda 和 Kappa: Lambda 架构——流批拆散,静态数据通过定时调度同步到 Hive 数仓,实时数据既会同步到 Hive,也会被实时计算引擎生产,这里就引出了一点问题。数据口径问题离线计算产出延时太大数据冗余存储Kappa架构——全副应用实时计算来产出数据,历史数据通过回溯音讯的生产位点计算,同样也有很多的问题,毕竟没有一劳永逸的架构。消息中间件无奈保留全副历史数据,同样数据都是行式存储,占用空间太大实时计算计算历史数据力不从心无奈进行 Ad-Hoc 的剖析为了解决这些问题,行业内推出了实时数仓,解决了大部分痛点,然而还是有些中央力不从心。比方波及到历史数据的计算怎么办?我想做 Ad-Hoc 的剖析又怎么玩?所以行业内当初都是实时数仓与离线数仓并行存在,而这又带来了更多的问题:模型须要多份、数据产出不统一、历史数据的计算等等 。 而 Hive Streaming 的呈现就能够解决这些问题!再也不必多套模型了;也不须要同一个指标因为波及到历史数据,写一遍实时 SQL 再写一遍离线 SQL;Ad-Hoc 也能做了,怎么做?读 Hive Streaming 产出的表就行! 接下来,让咱们从参数配置开始,接着流式的写入 Hive,再到流式的读取 Hive 表,最初再 Join 上 Hive 维表吧。这一整套流程都体验后,想必大家对 Hive Streaming 肯定会有更深刻的理解,更可能领会到它的作用。 Checkpoint & Dependency因为只有在实现 Checkpoint 之后,文件才会从 In-progress 状态变成 Finish 状态,所以,咱们须要正当的去配置 Checkpoint,在 Zeppelin 中配置 Checkpoint 很简略。 ...

August 4, 2020 · 2 min · jiezi

关于flink:BIGO-实时计算平台建设实践

BIGO 寰球音视频业务对数据的实时能力要求越来越高,数据分析师心愿多维度实时看到新增用户、沉闷用户等业务数据以便尽快把握市场动向,机器学习工程师心愿实时拿到用户的浏览、点击等数据而后通过在线学习将用户偏好疾速退出到模型中,以便给用户推送以后最感兴趣的内容,APP 开发工程师心愿可能实时监控 APP 关上的成功率、解体率。 这些实时数据的能力都要依附实时计算平台来提供。从业界来看,实时化的趋势正在减速,本文将介绍 BIGO 基于 Flink 的实时计算平台的建设教训和成绩。 平台介绍BIGO 实时计算的倒退大略分为两个阶段,在 2018 年之前,实时场景还比拟少,实时的作业数量也不多,过后次要采纳 Spark Streaming 来反对。从 2018 年开始,在综合思考了 Flink 绝对于 Spark Streaming 的劣势之后,决定将实时计算平台切换到基于 Flink 的技术路线上来。通过近两年的倒退,BIGO 实时计算平台日趋完善,根本反对了公司内支流的实时计算场景,下图是 BIGO 实时计算平台的架构图: 实时计算的数据起源可分为两大类,一类是用户在 APP 或者浏览器里的浏览、点击等行为日志,通过 kafka 收集进入实时计算;另一类是用户的行为产生的关系型数据库里记录的扭转,这些改变产生的 biglog 被 BDP 抽取进入实时计算。 从图中能够看出,BIGO 实时计算平台底层基于 Yarn 来做集群资源管理,借助于 Yarn 的散布式调度能力,实现大规模集群下的调度。实时平台的计算引擎在开源 Flink 的根底上,为适配 BIGO 的场景进行了非凡的定制及开发。实时平台的下层是 BIGO 自研的一站式开发平台 BigoFlow,在这里,用户能够不便的进行作业的开发、调试以及监控运维。BigoFlow 提供了欠缺的 SQL 开发能力、自动化监控配置能力以及日志主动收集、查问能力,让用户仅须要一条 SQL,就能够实现一个业务作业。它具备以下性能: 提供了弱小的 SQL 编辑器,能够进行语法查看及主动提醒。能够对接公司所有的数据源及数据存储,省去了业务方自定义的工作。日志主动收集到 ES 里,用户能够不便的检索和查问,能够疾速的定位谬误。作业要害指标主动对接到公司的监控告警平台,用户不必再本人配置。收集所有作业的资源应用状况,主动进行剖析,帮忙辨认、治理不合理作业。实时计算出来的后果依据业务的需要,会寄存到不同的存储中。ETL 类作业的后果通常会入库到 Hive中,须要进行 Adhoc 查问的数据通常会放到 ClickHouse 外面。监控告警等类型的作业能够间接把后果输入到告警平台的 Prometheus 数据库里,供告警平台间接应用。 ...

August 3, 2020 · 2 min · jiezi

关于flink:从-19-到-111聊聊-PyFlink-的核心功能演进附-Demo-代码

1.PyFlink 的发展史 1.1、v1.8.xFlink 在 1.8 版本的时候就曾经提供 Python API,只在 Datase/Stream 上提供反对。存在一些问题,比方:Table API 不反对 Python。两套各自独立实现的一个 Python API。底层实现是 JPython,JPython 无奈反对 Python3.x。1.2、v1.9.x2019 年 8 月公布。反对 Python Table API。1.3、v1.10.x2020 年 2 月公布。提供了 Python UDF 的反对。提供 UDF 的依赖治理。1.4、将来倒退提供 Pandas UDF 的反对。提供用户自定义的一些 UDF Metrics。ML API。在易用性方面,提供 SQL DDL 反对 Python UDF。在前面的一些版本中,咱们也心愿越来越多的人可能参加到 PyFlink 的奉献和开发中去。2.PyFlink 外围性能及原理介绍PyFlink 外围性能将次要从每个版本的划分来跟大家进行介绍,第1个 PyFlink 1.9 版本外面提供 Python Table API 的反对,而后是 PyFlink 1.10 外面提供了 Python UDF 还有相干依赖治理,最初 1.11 版本外面提供了 Pandas UDF 和用户自定义的 Metrics。 ...

July 29, 2020 · 4 min · jiezi

关于flink:Flink-111-SQL-使用攻略

7 月 6 日,Apache Flink 1.11 正式公布。从 3 月初进行性能布局到 7 月初正式发版,1.11 用将近 4 个月的工夫重点优化了 Flink 的易用性问题,晋升用户的生产应用体验。 SQL 作为 Flink 中公认的外围模块之一,对推动 Flink 流批一体性能的欠缺至关重要。在 1.11 中,Flink SQL 也进行了大量的加强与欠缺,开发大性能 10 余项,不仅扩充了利用场景,还简化了流程,上手操作更简略。其中,值得注意的改变包含: 默认 Planner 曾经切到 Blink planner 上。引入了对 CDC(Change Data Capture,变动数据捕捉)的反对,用户仅用几句简略的 SQL 即可对接 Debezium 和 Canal 的数据源。离线数仓实时化,用户可不便地应用 SQL 将流式数据从 Kafka 写入 Hive 等。Flink SQL 演变随着流计算的倒退,挑战不再仅限于数据量和计算量,业务变得越来越简单,开发者可能是资深的大数据从业者、初学 Java 的爱好者,或是不懂代码的数据分析者。如何进步开发者的效率,升高流计算的门槛,对推广实时计算十分重要。SQL 是数据处理中应用最宽泛的语言,它容许用户简明扼要地展现其业务逻辑。Flink 作为流批一体的计算引擎,致力于提供一套 SQL 反对全副利用场景,Flink SQL 的实现也齐全遵循 ANSI SQL 规范。之前,用户可能须要编写上百行业务代码,应用 SQL 后,可能只须要几行 SQL 就能够轻松搞定。Flink SQL 的倒退大略经验了以下阶段: ...

July 28, 2020 · 6 min · jiezi

关于flink:Flink-111-SQL-使用攻略

7 月 6 日,Apache Flink 1.11 正式公布。从 3 月初进行性能布局到 7 月初正式发版,1.11 用将近 4 个月的工夫重点优化了 Flink 的易用性问题,晋升用户的生产应用体验。 SQL 作为 Flink 中公认的外围模块之一,对推动 Flink 流批一体性能的欠缺至关重要。在 1.11 中,Flink SQL 也进行了大量的加强与欠缺,开发大性能 10 余项,不仅扩充了利用场景,还简化了流程,上手操作更简略。其中,值得注意的改变包含: 默认 Planner 曾经切到 Blink planner 上。引入了对 CDC(Change Data Capture,变动数据捕捉)的反对,用户仅用几句简略的 SQL 即可对接 Debezium 和 Canal 的数据源。离线数仓实时化,用户可不便地应用 SQL 将流式数据从 Kafka 写入 Hive 等。Flink SQL 演变随着流计算的倒退,挑战不再仅限于数据量和计算量,业务变得越来越简单,开发者可能是资深的大数据从业者、初学 Java 的爱好者,或是不懂代码的数据分析者。如何进步开发者的效率,升高流计算的门槛,对推广实时计算十分重要。SQL 是数据处理中应用最宽泛的语言,它容许用户简明扼要地展现其业务逻辑。Flink 作为流批一体的计算引擎,致力于提供一套 SQL 反对全副利用场景,Flink SQL 的实现也齐全遵循 ANSI SQL 规范。之前,用户可能须要编写上百行业务代码,应用 SQL 后,可能只须要几行 SQL 就能够轻松搞定。Flink SQL 的倒退大略经验了以下阶段: ...

July 28, 2020 · 6 min · jiezi

关于flink:Flink-使用大状态时的一点优化

通过本文你能 get 到以下几点: Flink 内应用大状态时,该如何配置?常见的负载平衡策略有哪些?Flink 源码中在抉择 RocksDB 状态磁盘时,存在的问题。一些解决方案,并剖析了每种计划的利弊。一、为什么要优化?(优化背景)Flink 反对多种 StateBackend,当状态比拟大时目前只有 RocksDBStateBackend 可供选择。 RocksDB 是基于 LSM 树原理实现的 KV 数据库,LSM 树读放大问题比较严重,因而对磁盘性能要求比拟高,强烈建议生产环境应用 SSD 作为 RocksDB 的存储介质。然而有些集群可能并没有配置 SSD,仅仅是一般的机械硬盘,当 Flink 工作比拟大,且对状态拜访比拟频繁时,机械硬盘的磁盘 IO 可能成为性能瓶颈。在这种状况下,该如何解决此瓶颈呢? 应用多块硬盘来分担压力RocksDB 应用内存加磁盘的形式存储数据,当状态比拟大时,磁盘占用空间会比拟大。如果对 RocksDB 有频繁的读取申请,那么磁盘 IO 会成为 Flink 工作瓶颈。 强烈建议在 flink-conf.yaml 中配置 state.backend.rocksdb.localdir 参数来指定 RocksDB 在磁盘中的存储目录。当一个 TaskManager 蕴含 3 个 slot 时,那么单个服务器上的三个并行度都对磁盘造成频繁读写,从而导致三个并行度的之间互相争抢同一个磁盘 io,这样必然导致三个并行度的吞吐量都会降落。 庆幸的是 Flink 的 state.backend.rocksdb.localdir 参数能够指定多个目录,个别大数据服务器都会挂载很多块硬盘,咱们冀望同一个 TaskManager 的三个 slot 应用不同的硬盘从而缩小资源竞争。具体参数配置如下所示: state.backend.rocksdb.localdir: /data1/flink/rocksdb,/data2/flink/rocksdb,/data3/flink/rocksdb,/data4/flink/rocksdb,/data5/flink/rocksdb,/data6/flink/rocksdb,/data7/flink/rocksdb,/data8/flink/rocksdb,/data9/flink/rocksdb,/data10/flink/rocksdb,/data11/flink/rocksdb,/data12/flink/rocksdb留神:务必将目录配置到多块不同的磁盘上,不要配置单块磁盘的多个目录,这里配置多个目录是为了让多块磁盘来分担压力。 如下图所示是笔者测试过程中磁盘的 IO 使用率,能够看出三个大状态算子的并行度别离对应了三块磁盘,这三块磁盘的 IO 均匀使用率都放弃在 45% 左右,IO 最高使用率简直都是 100%,而其余磁盘的 IO 均匀使用率为 10% 左右,绝对低很多。由此可见应用 RocksDB 做为状态后端且有大状态的频繁读写操作时,对磁盘 IO 性能耗费的确比拟大。 ...

July 27, 2020 · 3 min · jiezi

关于flink:小白从零开始学ApacheFlink

1. Apache Flink 介绍起源:http://www.54tianzhisheng.cn/...Apache Flink 是近年来越来越风行的一款开源大数据计算引擎,它同时反对了批处理和流解决,也能用来做一些基于事件的利用。应用官网的一句话来介绍 Flink 就是 “Stateful Computations Over Streams”。 首先 Flink 是一个纯流式的计算引擎,它的根本数据模型是数据流。流能够是无边界的有限流,即个别意义上的流解决。也能够是有边界的无限流,这样就是批处理。因而 Flink 用一套架构同时反对了流解决和批处理。其次,Flink 的一个劣势是反对有状态的计算。如果解决一个事件(或一条数据)的后果只跟事件自身的内容无关,称为无状态解决;反之后果还和之前解决过的事件无关,称为有状态解决。略微简单一点的数据处理,比如说根本的聚合,数据流之间的关联都是有状态解决。 无穷数据集:无穷的继续集成的数据汇合有界数据集:无限不会扭转的数据汇合那么那些常见的无穷数据集有哪些呢? 用户与客户端的实时交互数据利用实时产生的日志金融市场的实时交易记录…数据运算模型有哪些呢: 流式:只有数据始终在产生,计算就继续地进行批处理:在事后定义的工夫内运行计算,当实现时开释计算机资源[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-i3IYaQm9-1595768814163)(https://ws3.sinaimg.cn/large/...] 2. What is Flink?[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-1KK2dXk1-1595768814167)(https://ws3.sinaimg.cn/large/...] [外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-8uDNlF7v-1595768814169)(https://ws2.sinaimg.cn/large/...] [外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-W7z6hQI9-1595768814171)(https://ws4.sinaimg.cn/large/...] [外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-4mHt3Iq8-1595768814173)(/Applications/Typora.app/Contents/Resources/TypeMark/Docs/img/006tNbRwly1fw6nu5yishj31kw0w04cm.jpg)] [外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-qGWVgGhG-1595768814174)(https://ws2.sinaimg.cn/large/...] 从下至上: 1、部署:Flink 反对本地运行、能在独立集群或者在被 YARN 或 Mesos 治理的集群上运行, 也能部署在云上。 2、运行:Flink 的外围是分布式流式数据引擎,意味着数据以一次一个事件的模式被解决。 3、API:DataStream、DataSet、Table、SQL API。 4、扩大库:Flink 还包含用于简单事件处理,机器学习,图形处理和 Apache Storm 兼容性的专用代码库。 3. Flink 数据流编程模型1. 形象级别[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-yZWEXSka-1595768814175)(https://ws2.sinaimg.cn/large/...] 最底层提供了有状态流。它将通过 过程函数(Process Function)嵌入到 DataStream API 中。它容许用户能够自在地解决来自一个或多个流数据的事件,并应用统一、容错的状态。除此之外,用户能够注册事件工夫和处理事件回调,从而使程序能够实现简单的计算。DataStream / DataSet API 是 Flink 提供的外围 API ,DataSet 解决有界的数据集,DataStream 解决有界或者无界的数据流。用户能够通过各种办法(map / flatmap / window / keyby / sum / max / min / avg / join 等)将数据进行转换 / 计算。Table API 是以 表 为核心的申明式 DSL,其中表可能会动态变化(在表白流数据时)。Table API 提供了例如 select、project、join、group-by、aggregate 等操作,应用起来却更加简洁(代码量更少)。你能够在表与 DataStream/DataSet 之间无缝切换,也容许程序将 Table API 与 DataStream 以及 DataSet 混合应用。 ...

July 26, 2020 · 8 min · jiezi

关于flink:阿里巴巴大规模应用-Flink-的实战经验常见问题诊断思路

1.常见运维问题1.1 作业运行环境本文中介绍的作业运行环境次要是在阿里巴巴团体内,构建在 Hadoop 生态之上的 Flink 集群,蕴含 Yarn、HDFS、ZK 等组件;作业提交模式采纳 yarn per-job Detached 模式。 第1步,作业提交是通过 Flink Yarn Client,将用户所写的作业代码以及编译好的 jar 包上传到 HDFS 上;第2步 Flink Client 与 Yarn ResourceManager 进行通信,申请所须要的的 Container 资源;第3步,ResourceManager 收到申请后会在集群中的 NodeManager 调配启动 AppMaster 的 Container 过程,AppMaster 中蕴含 Flink JobManager 模块和 Yarn 通信的 ResourceManager 模块;第4步,在 JobManager 中依据作业的 JobGraph 生成 Execution Graph,ResourceManager 模块向 Yarn 的 ResourceManager 通信,申请 TaskManager 须要的 container 资源,这些 container 由 Yarn 的 NodeManger 负责拉起。每个 NodeManager 从 HDFS 上下载资源,启动 Container(TaskManager),并向 JobManager 注册;JobManger 会部署不同的 task 工作到各个 TaskManager 中执行。■ 资源申请形式1. 指定资源大小提交时,指定每个 TaskManager、JobManager 应用多少内存,CPU 资源。2. 细粒度资源管制阿里巴巴团体内次要采纳 ResourceSpec 形式指定每个 Operator 所需的资源大小,根据 task 的并发聚合成 container 资源向 Yarn 申请。 ...

July 24, 2020 · 2 min · jiezi

关于flink:Flink-Weekly-每周社区动态更新

大家好,本文为 Flink Weekly 的第二十三期,由蒋晓峰、李本超独特整顿及 Review。本期次要内容包含:近期社区开发进展、邮件问题答疑、Flink 最新社区动静及技术文章举荐等。 Flink 开发进展Flink 社区近期开发最新动静将从 Release、DEV、FLIP、Discuss、Others 五局部跟大家分享。 RELEASE■ 1.11.1 版本的投票曾经通过,行将公布。该版本涵盖了比拟多重要的 Bugfix,倡议尝试 1.11.0 版本的用户都间接切换到这个版本。 [1]http://apache-flink-mailing-l... DEV■ Chenqin 发动了反对 Thrift Format 的探讨,目前看该个性还是比拟受欢迎的,而且的确有些场景是须要的。之前也有一个相干的 PR[3],社区心愿能够基于这个 PR 来持续推动一下这个工作。 [2]http://apache-flink-mailing-l...[3] https://github.com/apache/fli...  FLIP■ [FLIP-128] 伍翀发动 Refactor Descriptor API to register connectors in Table API 的提案,改良 Table API 中的“Connect API”,即用户用来在环境中形容/注册表的 API。 自 1.5.0 起 Flink 引入 Descriptor API 来配置和有效化 TableSources/TableSinks,即 TableEnvironment#connect API。以后的 Descriptor API 有诸多问题包含社区关注最新版本中的新 SQL DDL 性能。SQL DDL 通过精心设计具备许多丰盛的性能,然而 Descriptor API 短少许多要害性能例如计算列、主键、分区键等;以后连接器必须实现相应的描述符(例如 new Kafka())能力应用 “connect” API,心愿在没有相应描述符的状况下注册连接器,简化连接器的开发并且代替 registerTableSource/Sink;Descriptor API 和 SQL DDL 的根底实现不同,保护两个不同的代码门路十分低廉。 ...

July 24, 2020 · 3 min · jiezi

关于flink:Demo-示例如何原生的在-K8s-上运行-Flink

Kubernetes 简介什么是 Kubernetes?Kubernetes 置信大家都比拟相熟,近两年大家都在探讨云原生的话题,探讨 Kubernetes。那么什么是 Kubernetes 呢? K8s 是一个资源管理零碎。如果大家对 Yarn、 Mesos 相熟,假如给定一批裸的物理机,将资源管理零碎部署下来之后,能够在此之上基于它的 API 或者 SDK 开发一些分布式软件或者应用程序。例如能够在 Yarn 上开发传统的 MapReduce,在 K8s 上能够开发一些分布式的 Web Server,或者是大数据计算工作等等。 K8s 是一个容器编排零碎。不同于传统的 Yarn,K8s 在所有的过程运行过程中,是全副基于容器化的,但这里的容器并不只是单纯的 Docker 容器,它也包含 Rocket 等其余相干的隔离措施。如果在生产环境中要求比拟高的话,可能会有一些平安容器,比方 Kata Containers 等等。K8s 在 Slave 上部署的应用程序,都是用容器化的形式去做散发和治理,同时用容器化的技术做隔离。 K8s 是一个自动化运维零碎。它是一个申明式的 API,咱们只须要通知 K8s 集群须要创立一个 Deployment,设置的正本数量,须要达到一个什么样的状态,调度零碎也就是 K8s 就会帮忙咱们维持状态,直到达到设置的状态为止。如果两头产生了一些 failover 或者产生了一些失败,它会主动地将工作迁徙到其余的机器上,来满足以后的调度。 云原生。目前简直所有的云厂商都曾经提供了 K8s 服务反对,包含国内的阿里、国内上的 Amazon、Google 等等,包含传统的微软都曾经提供了对于 K8s 的 Managed 服务或者是 Unmanaged 服务。随着目前 Lambda 表达式或者 Function 计算的利用, Serverless 形式也变得更加风行。除了传统的部署小集群以外,通过云产生一个 manager,构建一个大的 Serverless 集群,而后用户按需进行计算资源付费,这也是一种新的模式。 ...

July 24, 2020 · 5 min · jiezi

关于flink:高能预警Apache-Flink-Meetup-上海站返场啦

近期,Flink 社区上线了一系列好玩乏味又干货十足的流动。错过的小伙伴能够看这里:如果您是 Flink 爱好者想疾速上手入门,Flink 极客训练营帮您从0到1学会 Flink;如果您对挑战自我解决难题感兴趣,Flink 极客挑战赛邀您一起挑战疫情防控的世界级难题。 Flink 极客训练营第二期预约:https://page.aliyun.com/form/...Flink 极客挑战赛详情: https://tianchi.aliyun.com/sp...然而,有同学说都是线上流动都是直播,线下 Meetup 什么时候能安顿? 小松鼠作为宠粉口头派,安顿,立马就给大家安顿!8月2日,Flink 社区邀请来自英特尔、小红书、唯品会、蚂蚁金服以及阿里巴巴的五位技术专家齐聚上海,线下跟大家分享近期 Flink 的最新利用实际与最新社区动静。 流动工夫: 2020年8月2日 13:00-17:30流动地点: 上海长宁金钟路凌空SOHO-携程总部12号楼11层 ■ 本次 Meetup 亮点: 大咖星散,来自英特尔、小红书、唯品会、蚂蚁金服、阿里巴巴的5位一线技术专家齐聚魔都,与您分享探讨 Flink 社区最新利用与社区动向。爆款话题,聚焦流批一体的生产环境利用、Flink SQL 1.11 新性能、机器学习、小红书实时平台利用、蚂蚁金服风控教训等精彩话题。社区交换,汇聚技术行业的精英人才,碰撞思维交换业界最新动静。多重大礼,报名加入,就有机会取得超多 Flink 独家定制的酷炫周边!8月2日下午 13:00 - 17:30,Apache Flink Meetup 上海站期待您的到来!本次 Meetup 在线下举办同时进行在线直播,会场限额 100 人,扫描下方二维码或点击报名链接即可报名,感兴趣的同学快来抢前排~ 《批流交融在唯品会的实际利用》王新春 | 唯品会 数据平台实时团队高级架构师 嘉宾简介:王新春,唯品会数据平台实时团队高级架构师。次要负责实时计算平台、机器学习平台、实时数据荡涤和实时报表等业务;在退出唯品会之前,是美团点评(原公众点评)数据平台高级架构师;从零开始搭建实时计算平台以及数据平台工具体系开发和建设等工作。 演讲简介:流式数据处理和批数据处理的体系深度交融,局部数据加工和打宽间接在流数据中解决,并作为批处理或者 OLAP 引擎(Spark SQL/Presto/ClickHouse)等的输出,以达到数据口径对立,并且升高批处理的资源耗费的指标。 具体的实际包含:应用 Flink 做流量数据实时 ETL;Flink 实时入仓 MySQL 数据;应用 Flink 加工实时宽表和实时轻度汇总层数据,并提供给离线宽表、举荐算法和数据产品等应用。 《Analytics Zoo 在 Flink 极客挑战赛中的利用》宋佳明 | 英特尔 机器学习工程师 嘉宾简介:开源我的项目 Analytics Zoo 的重要贡献者,在机器学习、大数据、常识图谱等畛域有超过2年的教训。 ...

July 23, 2020 · 1 min · jiezi

关于flink:专治数仓疑难杂症美团点评-Flink-实时数仓应用经验分享

实时数仓建设目标解决传统数仓的问题实时数仓是一个很容易让人产生混同的概念。实时数仓自身仿佛和把 PPT 彩色的背景变得更白一样,从传统的教训来讲,咱们认为数仓有一个很重要的性能,即可能记录历史。通常,数仓都是心愿从业务上线的第一天开始有数据,而后始终记录到当初。 但实时处理技术,又是强调以后解决状态的一门技术,所以咱们认为这两个绝对对抗的计划重叠在一起的时候,它注定不是用来解决一个比拟宽泛问题的一种计划。于是,咱们把实时数仓建设的目标定位为解决因为传统数据仓库数据时效性低解决不了的问题。 因为这个特点,咱们给定了两个准则: 传统数仓能解决的问题,实时数仓就不解决了。比方上个月的一些历史的统计,这些数据是不会用实时数仓来建设的。问题自身就不太适宜用数仓来解决,也不必实时数仓解决。比方业务性很强的需要,或者是对时效性要求特地高的需要。这些需要咱们也不倡议通过实时数仓这种形式来进行解决。当然为了让咱们整个零碎看起来像是一个数仓,咱们还是给本人提了一些要求的。这个要求其实跟咱们建设离线数仓的要求是一样的,首先实时的数仓是须要面向主题的,而后具备集成性,并且保障绝对稳固。 离线数仓和实时数仓的区别在于离线数据仓库是一个保留历史累积的数据,而咱们在建设实时数仓的时候,咱们只保留上一次批处理到以后的数据。这个说法十分的拗口,然而实际上操作起来还是蛮轻松的。 通常来讲解决方案是保留大略三天的数据,因为保留三天的数据的话,能够稳固地保障两天残缺的数据,这样就能保障,在批处理流程还没有解决完昨天的数据的这段间隙,仍然可能提供一个残缺的数据服务。 实时数仓的利用场景 实时 OLAP 剖析OLAP 剖析自身就非常适合用数仓去解决的一类问题,咱们通过实时数仓的扩大,把数仓的时效性能力进行晋升。甚至可能在剖析层面上都不必再做太多革新,就能够使原有的 OLAP 剖析工具具备剖析实时数据的能力。 实时数据看板这种场景比拟容易接受,比方天猫双11的实时大屏滚动展现外围数据的变动。实际上对于美团来讲,不光有促销上的业务,还有一些次要的门店业务。对于门店的老板而言,他们可能在日常的每一天中也会很关怀本人当天各个业务线上的销售额。 实时特色实时特色指通过汇总指标的运算来对商户或者用户标记上一些特色。比方屡次购买商品的用户后盾会断定为优质用户。另外,商户销售额稿,后盾会认为该商户商的热度更高。而后,在做实时精准经营动作时可能会优先思考相似的门店或者商户。 实时业务监控美团点评也会对一些外围业务指标进行监控,比如说当线上呈现一些问题的时候,可能会导致某些业务指标降落,咱们能够通过监控尽早发现这些问题,进而来缩小损失。 如何建设实时数仓实时数仓概念映射咱们通过离线数仓开发和实时数仓开发的对应关系表,帮忙大家疾速清晰的了解实时数仓的一些概念。 编程形式离线开发最常见的计划就是采纳 Hive SQL 进行开发,而后加上一些扩大的 udf 。映射到实时数仓里来,咱们会应用 Flink SQL ,同样也是配合 udf 来进行开发。 作业执行层面离线解决的执行层面个别是 MapReduce 或者 Spark Job ,对应到实时数仓就是一个继续一直运行的 Flink Streaming 的程序。 数仓对象层面离线数仓实际上就是在应用 Hive 表。对于实时数仓来讲,咱们对表的形象是应用 Stream Table 来进行形象。 物理存储离线数仓,咱们少数状况下会应用 HDFS 进行存储。实时数仓,咱们更多的时候会采纳像 Kafka 这样的音讯队列来进行数据的存储。 实时数仓的整体架构在此之前咱们做过一次分享,是对于为什么抉择 Flink 来做实时数仓,其中重点介绍了技术组件选型的起因和思路,具体内容参考《美团点评基于 Flink 的实时数仓建设实际》。本文分享的次要内容是围绕数据自身来进行的,上面是咱们目前的实时数仓的数据架构图。 《美团点评基于 Flink 的实时数仓建设实际》https://tech.meituan.com/2018/10/18/meishi-data-flink.html 从数据架构图来看,实时数仓的数据架构会跟离线数仓有很多相似的中央。比方分层构造;比如说 ODS 层,明细层、汇总层,乃至应用层,它们命名的模式可能都是一样的。尽管如此,实时数仓和离线数仓还是有很多的区别的。 跟离线数仓次要不一样的中央,就是实时数仓的档次更少一些。 以咱们目前建设离线数仓的教训来看,数仓的第二层远远不止这么简略,个别都会有一些轻度汇总层这样的概念,其实第二层会蕴含很多层。另外一个就是应用层,以往建设数仓的时候,应用层其实是在仓库外部的。在应用层建设好后,会建同步工作,把数据同步到利用零碎的数据库里。 在实时数仓外面,所谓 APP 层的利用表,实际上就曾经在利用零碎的数据库里了。上图,尽管画了 APP 层,但它其实并不算是数仓里的表,这些数据实质上曾经存过来了。 ...

July 22, 2020 · 2 min · jiezi

关于flink:为什么-Flink-无法实时写入-MySQL

作者:孙金城 摘要:本文为 Flink 生产环境利用中的疑难分析,Flink 无奈实时写入 MySQL 是初学者常见问题之一,由社区同学罗鹏程提出,Apache Flink PMC 孙金城(金竹)老师分享该问题的解决方案及剖析思路。次要分为以下四局部: 问题形容解决思路起因分析触类旁通Tips:更多生产环境问题交换及反馈请订阅 Flink 中文邮件列表~ 问题形容Flink 1.10 应用 flink-jdbc 连接器的形式与 MySQL 交互,读数据和写数据都能实现,然而在写数据时,发现 Flink 程序执行结束之后,能力在 MySQL 中查问到插入的数据。即,尽管是流计算,但却不能实时的输入计算结果? 相干代码片段: JDBCAppendTableSink.builder() .setDrivername("com.mysql.jdbc.Driver") .setDBUrl("jdbc:mysql://localhost/flink") .setUsername("root") .setPassword("123456") .setParameterTypes( BasicTypeInfo.INT_TYPE_INFO, BasicTypeInfo.STRING_TYPE_INFO) .setQuery("insert into batch_size values(?,?)") .build()如何解决?Flink 1.10 这个问题是晓得一秒钟,不知磨洋工的 Case,在初学时候非常容易遇上,那么真的是 Flink 不能实时写入 MySQL 吗?当然不是,下面代码根底之上简略的加上一行,就解决问题了: ....setBatchSize(1) //将写入MySQL的buffer大小为1。..起因分析那么问题尽管解决了,根本原因是个啥呢?兴许你看到这里会说,这问题很显著,就是 Flink 设计 JDBC Sink 的时候出于性能因素思考,对写入 buffer 做了默认值设置。 没错,这一点你说的很对,在 Flink 1.10 中 JDBC OutputFormat 的基类 AbstractJDBCOutputFormat 外面和这相干的变量 DEFAULT_FLUSH_MAX_SIZE 默认值是 5000,所以在你学习测试时候因为测试数据少(少于 5000),数据始终在 buffer 中,直到数据源数据完结,作业也完结了,才将计算结果刷入 MySQL,所以没有实时的(每条)写入 MySQL。如下: ...

July 22, 2020 · 1 min · jiezi

关于flink:进击的-Flink网易云音乐实时数仓建设实践

如何基于 Flink 的新 API 降级实时数仓架构? 背景介绍网易云音乐从 2018 年开始搭建实时计算平台,到目前为止曾经倒退至如下规模: 机器数量:130+单 Kafka 峰值 QPS:400W+在线运行工作数:500+开发者:160+业务笼罩:在线业务反对,实时报表统计,实时特色解决,实时索引反对2020 年 Q1 工作数增长 100%,处于高速倒退中 这是网易云音乐实时数仓 18 年的版本,基于 Flink 1.7 版本开发,过后 Flink SQL 的整体架构也还不是很欠缺。咱们应用了 Antlr (通用的编程语言解析器,它只需编写名为 G4 的语法文件,即可主动生成解析的代码,并且以对立的格局输入,解决起来非常简单。因为 G4 文件是通过开发者自行定制的,因而由 Antlr 生成的代码也更加简洁和个性化)自定义了一些 DDL 欠缺了维表 Join 的语法。通过 Antlr 实现语法树的解析当前,再通过 CodeGen(依据接口文档生成代码)技术去将整个 SQL 代码生成一个 Jar 包,而后部署到 Flink 集群下来。 此时还没有对立的元数据管理系统。在 JAR 包工作的开发上, 咱们也没有任何框架的束缚,平台也很难晓得 JAR 的工作上下游以及相干业务的重要性和优先级。这套架构咱们跑了将近一年的工夫,随着工作越来越多,咱们发现了以下几个问题: 反复的数据了解因为没有进行对立的元数据管理,每个工作的代码外面都须要事后定义 DDL 语句,而后再进行 Select 等业务逻辑的开发;音讯的元数据不能复用,每个开发都须要进行反复的数据了解,须要理解数据从哪里来、数据如何解析、数据的业务含意是什么;整个过程须要多方沟通,整体还存在了解谬误的危险;也不足对立的管理系统去查找本人想要的数据。 和官网版本越走越远因为晚期版本很多 SQL 的语法都是咱们本人自定义的,随着 Flink 自身版本的欠缺,语法和官网版本差异越来越大,功能完善性上也慢慢跟不上官网的版本,易用性天然也越来越差。如果你自身就是一名熟知 Flink SQL 的开发人员,可能还须要重新学习咱们平台本人的语法,整体不是很对立,有些问题也很难在互联网上找到相干的材料,只能靠运维来解决。 ...

July 21, 2020 · 2 min · jiezi

关于flink:字节跳动李本超一年成为-Committer我与-Flink-社区的故事

首先简略做个自我介绍,我是李本超,是字节跳动基础架构流式计算方向的工程师,次要负责 Flink SQL 方向。最近十分有幸受邀成为 Apache Flink Committer。 我参加社区次要是从19年下半年开始的,最开始次要是汇报一些应用过程中遇到的 bug,并且会力不从心的去修复它。与此同时也始终在关注 user 和 dev 邮件列表,一方面理解社区的最新进展和将来倒退方向;一方面也在从其他人的发问和答复中学习教训。起初随着理解的深刻,也就参加到了帮忙解答用户问题,参加设计的探讨、以及感兴趣的 issue 的探讨等。 社区筛选 Committer 的条件是比拟平衡的,各种模式的参加奉献社区,都会被记录和认可,比方奉献代码,奉献文档(包含翻译),参加各种模式的探讨,帮忙解答用户的发问等。从我集体的角度来讲,这些方面都做了肯定水平的参加,做的最突出的一个点次要是在 user 列表里沉闷的比较突出。 本篇文章次要是介绍我本人参加社区的过程和一些心得体会,次要从以下几个方面进行了介绍: 初识 Flink 社区如何融入社区在社区的播种对社区的奉献参加社区的倡议初识 Flink 社区我第一次接触 Flink 的工夫其实比拟早,2017 年我研究生毕业的时候,我过后的 mentor 给我定的方向就是流式计算,具体来说就是 Flink。过后我对于 Flink 还齐全是一个小白,工作上也齐全是一个小白,在读了几天 Flink 文档后,就失去了一个十分浅显的论断,Spark Streaming 应该就能够满足咱们的场景了(因为之前在实验室搞过 Spark,而且实习的时候又较为深度的应用过 Spark Streaming)。这一个浅显的论断让我跟 Flink 深度接触的时间延迟了 2 年。 第二次接触 Flink 是在 2018 年夏天的一次 Flink Meetup 上,对于过后的情景的印象到当初都还是很粗浅的。尤其是大沙老师过后的演讲尤其是对我影响比拟大,大沙对于 Flink 深入浅出的解说,给我的感觉就是 Flink 社区里都是一群大牛,而且 Flink 自身也十分的有意思。 过后就想,如果有幸哪天也可能跟这些人一起在社区参加工作,将会是如许幸福的一件事。值得一提的是,过后光芒老师也分享了 Flink 在字节跳动的落地应用,冥冥中注定吧,我当初也是他团队的一员了。在这之后咱们在公司(上家公司)内也做了一些对 Flink 利用落地应用的摸索,整体来讲 Flink 还是很好地满足了咱们的场景。然而因为公司的数据特点,并没有遇到太多大流量下的挑战,只是在应用层做了一些简略的工作。 ...

July 20, 2020 · 2 min · jiezi

关于flink:Flink-最佳搭档开发部署平台-Zeppelin-的自白

Flink 的学习者或者爱好者想必非常理解,除了须要相熟 Flink 自身之外,如果能有一款简略上手的 Flink 开发部署工具,不必写前端代码就能实现实时大屏、反对全副语言接口、反对多条 SQL,还能治理 Flink Job,这样的开发部署平台是不是齐全无奈回绝? 很侥幸,Apache 社区就有这么一款工具:Zeppelin,而且可能是开源界最好的 Flink 开发平台。 上面是 Zeppelin 和 Flink 的故事。 Zeppelin:Flink 最佳搭档Flink:我提供了 SQL、Java、Scala 还有 Python 等多种语言反对,不过每种语言都有本人的入口,多种语言混着用临时无奈实现。比方在 sql-client 中只能运行 SQL,不能写 UDF,在 Pyflink shell 里,只能用 Python 的 UDF,不能写和用 scala 和 java 的 UDF。有没有谁能帮我把这些语言全副买通? Zeppelin:我能够! Flink:我的一个很大的应用场景是实时大屏,然而我一个人办不到,往往须要借助第三方存储,还须要前端开发,有没有谁能让用户不必写前端代码就实现实时大屏? Zeppelin:我能够! Flink:我的 SQL 曾经很弱小了,然而用户在 sql-client 里不能写 comment,临时也不反对运行多条 SQL 语句,有谁能帮我把这些性能补齐下? Zeppelin:我能够! Flink:好多初学者说要跑一个 Flink job 须要多种配置并且须要学习各种命令行,有没有谁能让大家更容易提交和治理 Flink Job。 Zeppelin:我能够! Flink:Flink Job 提交目前只能一个个提交,有些同学想并行执行多个 Flink Job,谁能帮我搞定这个需要? Zeppelin:我能够! Flink:我有丰盛的 connector,用户须要把 connector 打包到 uber jar 里,或者 copy 到 Flink 的 Lib 下,这有可能把各种 connector jar 混在一起,容易发生冲突,有没有谁能提供一个洁净点的计划? ...

July 20, 2020 · 2 min · jiezi

关于flink:Flink-111-Unaligned-Checkpoint-解析

作为 Flink 最根底也是最要害的容错机制,Checkpoint 快照机制很好地保障了 Flink 利用从异样状态复原后的数据准确性。同时 Checkpoint 相干的 metrics 也是诊断 Flink 利用衰弱状态最为重要的指标,胜利且耗时较短的 Checkpoint 表明作业运行状况良好,没有异样或反压。然而,因为 Checkpoint 与反压的耦合,反压反过来也会作用于 Checkpoint,导致 Checkpoint 的种种问题。针对于此,Flink 在 1.11 引入 Unaligned Checkpint 来解耦 Checkpoint 机制与反压机制,优化高反压状况下的 Checkpoint 体现。 以后 Checkpoint 机制简述置信不少读者对 Flink Checkpoint 基于 Chandy-Lamport 算法的分布式快照曾经比拟相熟,该节简略回顾下算法的根底逻辑,相熟算法的读者可释怀跳过。Chandy-Lamport 算法将分布式系统形象成 DAG(临时不思考有闭环的图),节点示意过程,边示意两个过程间通信的管道。分布式快照的目标是记录下整个零碎的状态,即能够分为节点的状态(过程的状态)和边的状态(信道的状态,即传输中的数据)。因为零碎状态是由输出的音讯序列驱动变动的,咱们能够将输出的音讯序列分为多个较短的子序列,图的每个节点或边先后解决完某个子序列后,都会进入同一个稳固的全局统状态。利用这个个性,零碎的过程和信道在子序列的边界点别离进行本地快照,即便各局部的快照工夫点不同,最终也能够组合成一个有意义的全局快照。 从实现上看,Flink 通过在 DAG 数据源定时向数据流注入名为 Barrier 的非凡元素,将间断的数据流切分为多个无限序列,对应多个 Checkpoint 周期。每当接管到 Barrier,算子进行本地的 Checkpoint 快照,并在实现后异步上传本地快照,同时将 Barrier 以播送形式发送至上游。当某个 Checkpoint 的所有 Barrier 达到 DAG 末端且所有算子实现快照,则标记着全局快照的胜利。 在有多个输出 Channel 的状况下,为了数据准确性,算子会期待所有流的 Barrier 都达到之后才会开始本地的快照,这种机制被称为 Barrier 对齐。在对齐的过程中,算子只会持续解决的来自未呈现 Barrier Channel 的数据,而其余 Channel 的数据会被写入输出队列,直至在队列满后被阻塞。当所有 Barrier 达到后,算子进行本地快照,输入 Barrier 到上游并恢复正常解决。比起其余分布式快照,该算法的劣势在于辅以 Copy-On-Write 技术的状况下不须要 “Stop The World” 影响利用吞吐量,同时根本不必长久化解决中的数据,只用保留过程的状态信息,大大减小了快照的大小。 ...

July 20, 2020 · 3 min · jiezi

关于flink:Flink学习Flink-SQL-窗口函数

flink窗口函数蕴含滚动窗口、滑动窗口、会话窗口和OVER窗口 滚动窗口滚动窗口(TUMBLE)将每个元素调配到一个指定大小的窗口中。通常,滚动窗口有一个固定的大小,并且不会呈现重叠。例如,如果指定了一个5分钟大小的滚动窗口,有限流的数据会依据工夫划分为[0:00 - 0:05)、[0:05, 0:10)、[0:10, 0:15)等窗口。下图展现了一个30秒的滚动窗口。应用标识函数选出窗口的起始工夫或者完结工夫,窗口的工夫属性用于上级Window的聚合。 窗口标识函数返回类型形容TUMBLE_START(time-attr, size-interval)TIMESTAMP返回窗口的起始工夫(蕴含边界)。例如[00:10, 00:15) 窗口,返回00:10 。TUMBLE_END(time-attr, size-interval)TIMESTAMP返回窗口的完结工夫(蕴含边界)。例如[00:00, 00:15]窗口,返回00:15。TUMBLE_ROWTIME(time-attr, size-interval)TIMESTAMP(rowtime-attr)返回窗口的完结工夫(不蕴含边界)。例如[00:00, 00:15]窗口,返回00:14:59.999 。返回值是一个rowtime attribute,即能够基于该字段做工夫属性的操作,例如,级联窗口只能用在基于Event Time的Window上TUMBLE_PROCTIME(time-attr, size-interval)TIMESTAMP(rowtime-attr)返回窗口的完结工夫(不蕴含边界)。例如[00:00, 00:15]窗口,返回00:14:59.999。返回值是一个proctime attribute,即能够基于该字段做工夫属性的操作,例如,级联窗口只能用在基于Processing Time的Window上TUMBLE window示例 import org.apache.flink.api.common.typeinfo.TypeHint;import org.apache.flink.api.common.typeinfo.TypeInformation;import org.apache.flink.api.java.tuple.Tuple3;import org.apache.flink.streaming.api.TimeCharacteristic;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.streaming.api.functions.timestamps.AscendingTimestampExtractor;import org.apache.flink.table.api.EnvironmentSettings;import org.apache.flink.table.api.Table;import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;import java.sql.Timestamp;import java.util.Arrays;public class TumbleWindowExample { public static void main(String[] args) throws Exception { /** * 1 注册环境 */ EnvironmentSettings mySetting = EnvironmentSettings .newInstance()// .useOldPlanner() .useBlinkPlanner() .inStreamingMode() .build(); // 获取 environment StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // 指定零碎工夫概念为 event time env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); StreamTableEnvironment tEnv = StreamTableEnvironment.create(env,mySetting); // 初始数据 DataStream<Tuple3<Long, String,Integer>> log = env.fromCollection(Arrays.asList( //工夫 14:53:00 new Tuple3<>(1572591180_000L,"xiao_ming",300), //工夫 14:53:09 new Tuple3<>(1572591189_000L,"zhang_san",303), //工夫 14:53:12 new Tuple3<>(1572591192_000L, "xiao_li",204), //工夫 14:53:21 new Tuple3<>(1572591201_000L,"li_si", 208) )); // 指定工夫戳 SingleOutputStreamOperator<Tuple3<Long, String, Integer>> logWithTime = log.assignTimestampsAndWatermarks(new AscendingTimestampExtractor<Tuple3<Long, String, Integer>>() { @Override public long extractAscendingTimestamp(Tuple3<Long, String, Integer> element) { return element.f0; } }); // 转换为 Table Table logT = tEnv.fromDataStream(logWithTime, "t.rowtime, name, v"); Table result = tEnv.sqlQuery("SELECT TUMBLE_START(t, INTERVAL '10' SECOND) AS window_start," + "TUMBLE_END(t, INTERVAL '10' SECOND) AS window_end, SUM(v) FROM " + logT + " GROUP BY TUMBLE(t, INTERVAL '10' SECOND)"); TypeInformation<Tuple3<Timestamp,Timestamp,Integer>> tpinf = new TypeHint<Tuple3<Timestamp,Timestamp,Integer>>(){}.getTypeInfo(); tEnv.toAppendStream(result, tpinf).print(); env.execute(); }}sql逻辑,每十秒钟聚合执行后果:(2019-11-01 06:53:00.0,2019-11-01 06:53:10.0,603)(2019-11-01 06:53:20.0,2019-11-01 06:53:30.0,208)(2019-11-01 06:53:10.0,2019-11-01 06:53:20.0,204) ...

July 20, 2020 · 3 min · jiezi

关于flink:Flink学习Flink-on-Yarn

本文转载自:https://ververica.cn/develope...作者:周凯波(宝牛) Flink 架构概览Flink 架构概览–Job 用户通过 DataStream API、DataSet API、SQL 和 Table API 编写 Flink 工作,它会生成一个JobGraph。JobGraph 是由 source、map()、keyBy()/window()/apply() 和 Sink 等算子组成的。当 JobGraph 提交给 Flink 集群后,可能以 Local、Standalone、Yarn 和 Kubernetes 四种模式运行。 Flink 架构概览–JobManager JobManager的性能次要有: 将 JobGraph 转换成 Execution Graph,最终将 Execution Graph 拿来运行Scheduler 组件负责 Task 的调度Checkpoint Coordinator 组件负责协调整个工作的 Checkpoint,包含 Checkpoint 的开始和实现通过 Actor System 与 TaskManager 进行通信其它的一些性能,例如 Recovery Metadata,用于进行故障复原时,能够从 Metadata 外面读取数据。Flink 架构概览–TaskManager TaskManager 是负责具体任务的执行过程,在 JobManager 申请到资源之后开始启动。TaskManager 外面的次要组件有: Memory & I/O Manager,即内存 I/O 的治理Network Manager,用来对网络方面进行治理Actor system,用来负责网络的通信TaskManager 被分成很多个 TaskSlot,每个工作都要运行在一个 TaskSlot 外面,TaskSlot 是调度资源里的最小单位。 ...

July 20, 2020 · 2 min · jiezi

关于flink:Flink学习管理大型状态之增量-Checkpoint-详解

文章转载自:https://ververica.cn/develope...作者:邱从贤(山智) Apache Flink 是一个有状态的流计算框架,状态是作业算子中曾经解决过的内存状态,供后续解决时应用。状态在流计算很多简单场景中十分重要,比方: 保留所有历史记录,用来寻找某种记录模式保留最近一分钟的所有记录,用于对每分钟的记录进行聚合统计保留以后的模型参数,用于进行模型训练有状态的流计算框架必须有很好的容错性,能力在生产环境中施展用途。这里的容错性是指,不论是产生硬件故障,还是程序异样,最终的后果不丢也不重。 Flink 的容错性从一开始就是一个十分弱小的个性,在遇到故障时,可能保障不丢不重,且对失常逻辑解决的性能影响很小。 这外面的外围就是 checkpoint 机制,Flink 应用 checkpoint 机制来进行状态保障,在 Flink 中 checkpoint 是一个定时触发的全局异步快照,并长久化到长久存储系统上(通常是分布式文件系统)。产生故障后,Flink 抉择从最近的一个快照进行复原。有用户的作业状态达到 GB 甚至 TB 级别,对这么大的作业状态做一次 checkpoint 会十分耗时,耗资源,因而咱们在 Flink 1.3 中引入了增量 checkpoint 机制。 在增量 checkpoint 之前,Flink 的每个 checkpoint 都蕴含作业的所有状态。咱们在察看到状态在 checkpoint 之间的变动并没有那么大之后,反对了增量 checkpoint。增量 checkpoint 仅蕴含上次 checkpoint 和本次 checkpoint 之间状态的差别(也就是“增量”)。 对于状态十分大的作业,增量 checkpoint 对性能的晋升非常明显。有生产用户反馈对于 TB 级别的作业,应用增量 checkpoint 后能将 checkpoint 的整体工夫从 3 分钟降到 30 秒。这些工夫节俭次要归功于不须要在每次 checkpoint 都将所有状态写到长久化存储系统。 如何应用以后,仅可能在 RocksDB StateBackend 上应用增量 checkpoint 机制,Flink 依赖 RocksDB 外部的备份机制来生成 checkpoint 文件。Flink 会主动清理掉之前的 checkpoint 文件, 因而增量 checkpoint 的历史记录不会有限增长。 ...

July 18, 2020 · 2 min · jiezi

Flink学习内存管理

本文转载自:https://ververica.cn/develope... 作者:伍翀(云邪) 现在,大数据畛域的开源框架(Hadoop,Spark,Storm)都应用的  JVM,当然也包含 Flink。基于  JVM  的数据分析引擎都须要面对将大量数据存到内存中,这就不得不面对  JVM 存在的几个问题: Java 对象存储密度低。一个只蕴含 boolean 属性的对象占用了16个字节内存:对象头占了8个,boolean 属性占了1个,对齐填充占了7个。而实际上只须要一个bit(1/8字节)就够了。Full GC 会极大地影响性能,尤其是为了解决更大数据而开了很大内存空间的 JVM 来说,GC 会达到秒级甚至分钟级。OOM 问题影响稳定性。OutOfMemoryError 是分布式计算框架常常会遇到的问题,当 JVM 中所有对象大小超过调配给 JVM 的内存大小时,就会产生 OutOfMemoryError 谬误,导致 JVM 解体,分布式框架的健壮性和性能都会受到影响。所以目前,越来越多的大数据我的项目开始本人治理 JVM 内存了,像 Spark、Flink、HBase,为的就是取得像 C 一样的性能以及防止 OOM 的产生。本文将会探讨 Flink 是如何解决下面的问题的,次要内容包含内存治理、定制的序列化工具、缓存敌对的数据结构和算法、堆外内存、JIT 编译优化等。 踊跃的内存治理Flink 并不是将大量对象存在堆上,而是将对象都序列化到一个预调配的内存块上,这个内存块叫做 **MemorySegment**,它代表了一段固定长度的内存(默认大小为 32KB),也是 Flink 中最小的内存调配单元,并且提供了十分高效的读写办法。你能够把 MemorySegment 设想成是为 Flink 定制的 **java.nio.ByteBuffer**。它的底层能够是一个一般的 Java 字节数组(**byte[]**),也能够是一个申请在堆外的 **ByteBuffer**。每条记录都会以序列化的模式存储在一个或多个**MemorySegment**中。 Flink 中的 Worker 名叫 TaskManager,是用来运行用户代码的 JVM 过程。TaskManager 的堆内存次要被分成了三个局部: Network Buffers: 肯定数量的32KB大小的 buffer,次要用于数据的网络传输。在 TaskManager 启动的时候就会调配。默认数量是 2048 个,能够通过 **taskmanager.network.numberOfBuffers** 来配置。(浏览这篇文章理解更多Network Buffer的治理)Memory Manager Pool: 这是一个由 MemoryManager 治理的,由泛滥MemorySegment组成的超大汇合。Flink 中的算法(如 sort/shuffle/join)会向这个内存池申请 MemorySegment,将序列化后的数据存于其中,应用完后开释回内存池。默认状况下,池子占了堆内存的 70% 的大小。Remaining (Free) Heap: 这部分的内存是留给用户代码以及 TaskManager 的数据结构应用的。因为这些数据结构个别都很小,所以基本上这些内存都是给用户代码应用的。从GC的角度来看,能够把这里看成的新生代,也就是说这里次要都是由用户代码生成的短期对象。留神:Memory Manager Pool 次要在Batch模式下应用。在Steaming模式下,该池子不会预分配内存,也不会向该池子申请内存块。也就是说该局部的内存都是能够给用户代码应用的。不过社区是打算在 Streaming 模式下也能将该池子利用起来。 ...

July 17, 2020 · 4 min · jiezi

解决问题-1474-个Flink-111-究竟有哪些易用性上的改善

7月7日,Flink 1.11.0 正式公布了,作为这个版本的 release manager 之一,我想跟大家分享一下其中的经验感触以及一些代表性 feature 的解读。在进入深度解读前,咱们先简略理解下社区公布的个别流程,帮忙大家更好的了解和参加 Flink 社区的工作。 首先在每个版本的布局初期,会从志愿者中选出 1-2 名作为 Release Manager。1.11.0 版本我作为中国这边的 Release Manager,同时还有一名来自 Ververica 的 Piotr Nowojski 作为德国方的 Release Manager,这在某种程度上也阐明中国的开发者和贡献度在整个社区的占比很重要。接下来会进行这个版本的 Feature Kickoff。在一些大的方向上,社区的布局周期可能比拟久,会分阶段、分步骤逾越多个版本实现,确保品质。每个版本的侧重点也会有所不同,比方前两个版本侧重于批处理的增强,而这个版本更侧重于流解决易用性的晋升。社区规划的 Feature 列表会在邮件列表中发动探讨,以收集更多的用户/开发者意见和反馈。个别的开发周期为 2-3 个月工夫,提前会明确布局出大略的 Feature Freeze 工夫,之后进行 Release Candidate 的公布和测试、以及 Bug Fix。个别通过几轮的迭代周期后会正式投票通过一个绝对稳固的 Candidate 版本,而后基于这个版本正式公布。Flink 1.11.0 从 3 月初的性能布局到 7 月初的正式公布,历经了差不多 4 个月的工夫,对 Flink 的生态、易用性、生产可用性、稳定性等方面都进行了加强和改善,上面将一一跟大家分享。 一  综述Flink 1.11.0 从 Feature 解冻后公布了 4 次 Candidate 才最终通过。经统计,一共有 236 个贡献者参加了这次版本开发,解决了 1474 个 Jira 问题,波及 30 多个 FLIP,提交了 2325 个 Commit。 ...

July 16, 2020 · 5 min · jiezi

官方剧透111-发版前我们偷看了-Flink-中文社区发起人的聊天记录

Flink 1.11 行将 Release 啦!作为备受瞩目的新一代开源大数据计算引擎,Flink 无疑已成为 Apache 基金会和 GitHub 最为沉闷的我的项目之一。 自 2014 年正式开源, Flink 倒退十分迅速,在 GitHub 上其访问量在 Apache 我的项目中位居前三。去年年底 Flink Forward Asia 2019 大会颁布,仅仅 2019 年一年的工夫,Flink 在 GitHub 上的 star 数量就翻了一倍,Contributor 数量也呈现出持续增长的态势。 GitHub 地址指路:https://github.com/apache/flink越来越多的企业和开发者正在一直地退出 Flink 社区,中国开发者也为 Flink 开发做出了微小的奉献。最近,Flink 终于要迎来1.11版本的更新,不仅对 SQL 和 PyFlink 的反对进行了优化,还有 Hive 的兼容性,以及加强了拓展资源(GPU)的调度反对。 将在6月下旬发版的的 Flink 1.11 重要性能个性更新如下:(目前已在官网文档更新) 加强 Web UI 性能全新 Source APIDataStream API 反对 Kafka 载体实现子图 Failover晋升 DDL 易用性(动静 Table 属性,Primary Key反对)加强 Hive 流批一体化(Hive Streaming sink,Filesystem Connector)反对被 Zeppelin 集成,所有公布性能可用加强 PyFlink(Pandas反对,SQL DDL/Client集成),晋升 Python UDF 性能反对 Application 运行模式、加强 K8s 性能以及 Docker 镜像对立对立 Job Master 内存配置反对 GPU 调度调整 Savepoint 文件门路不便挪动Runtime 实现 Unalinged 模式提速反压场景下 CheckpointFlink 1.11 版本更新之际,大数据文摘跟阿里巴巴资深技术专家,实时计算负责人,也是 Flink 中文社区发起人王峰 (莫问)聊了聊,对于 Flink 此次新版的重点,以及将来社区的倒退布局,莫问老师都给了咱们一波官网剧透。 ...

July 15, 2020 · 2 min · jiezi

字节跳动基于Flink的MQHive实时数据集成

在数据中台建设过程中,一个典型的数据集成场景是将 MQ (Message Queue,例如 Kafka、RocketMQ 等)的数据导入到 Hive 中,以供上游数仓建设以及指标统计。因为 MQ-Hive 是数仓建设第一层,因而对数据的准确性以及实时性要求比拟高。 本文次要围绕 MQ-Hive 场景,针对目前字节跳动内已有解决方案的痛点,提出基于 Flink 的实时解决方案,并介绍新计划在字节跳动外部的应用现状。 已有计划及痛点字节跳动内已有解决方案如下图所示,次要分了两个步骤: 通过 Dump 服务将 MQ 的数据写入到 HDFS 文件再通过 Batch ETL 将 HDFS 数据导入到 Hive 中,并增加 Hive 分区 痛点工作链较长,原始数据须要通过屡次转换最终能力进入 Hive实时性比拟差,Dump Service、Batch ETL 提早都会导致最终数据产出提早存储、计算开销大,MQ 数据反复存储和计算基于原生 Java 打造,数据流量持续增长后,存在单点故障和机器负载不平衡等问题运维老本较高,架构上无奈复用公司内 Hadoop/Flink/Yarn 等现有基础设施不反对异地容灾基于 Flink 实时解决方案劣势针对目前公司传统解决方案的痛点,咱们提出基于 Flink 的实时解决方案,将 MQ 的数据实时写入到 Hive,并反对事件工夫以及 Exactly Once 语义。相比老计划,新计划劣势如下所示: 基于流式引擎 Flink 开发,反对 Exactly Once 语义实时性更高,MQ 数据间接进入 Hive,无两头计算环节缩小两头存储,整个流程数据只会落地一次撑持 Yarn 部署模式,不便用户迁徙资源管理弹性,不便扩容以及运维反对双机房容灾整体架构整体架构如下图所示,次要包含 DTS(Data Transmission Service) Source、DTS Core、DTS Sink 三大模块,具体性能如下: ...

July 15, 2020 · 3 min · jiezi

详解-Flink-实时应用的确定性

作者:林小铂(网易游戏) 确定性(Determinism)是计算机科学中非常重要的个性,确定性的算法保障对于给定雷同的输出总是产生雷同的输入。在分布式实时计算畛域,确定性是业界始终难以解决的课题,由此导致用离线计算修改实时计算结果的 Lambda 架构成为大数据畛域过来近十年的支流架构。 而在最近几年随着 Google The Dataflow Model 的提出,实时计算和离线计算的关系逐步清晰,在实时计算中提供与离线计算统一的确定性成为可能。本文将基于风行实时计算引擎 Apache Flink,梳理构建一个确定性的实时利用要满足什么条件。 确定性与准确性比起确定性,准确性(Accuracy)可能是咱们接触更多的近义词,大多数场景下两者能够混用,但其实它们稍有不同: 精确的货色肯定是确定的,但确定性的货色未必百分百精确。在大数据畛域,不少算法能够依据需要调整老本和准确性的均衡,比方 HyperLogLog 去重统计算法给出的后果是有肯定误差的(因而不是精确的),但却同时是确定性的(重算能够失去雷同后果)。 要分区确定性和准确性的缘故是,准确性与具体的业务逻辑严密耦合难以评估,而确定性则是通用的需要(除去多数场景用户成心应用非确定性的算法)。当一个 Flink 实时利用提供确定性,意味着它在异样场景的主动重试或者手动重流数据的状况下,都能像离线作业个别产出雷同的后果,这将很大水平上进步用户的信任度。 影响 Flink 利用确定性的因素投递语义常见的投递语义有 At-Most-Once、At-Least-Once 和 Exactly-Once 三种。严格来说只有 Exactly-Once 满足确定性的要求,但如果整个业务逻辑是幂等的, 基于 At-Least-Once 也能够达到后果的确定性。 实时计算的 Exactly-Once 通常指端到端的 Exactly-Once,保障输入到上游零碎的数据和上游的数据是统一的,没有反复计算或者数据失落。要达到这点,须要别离实现读取数据源(Source 端)的 Exactly-Once、计算的 Exactly-Once 和输入到上游零碎(Sink 端)的 Exactly-Once。 其中后面两个都比拟好保障,因为 Flink 利用出现异常会主动复原至最近一个胜利 checkpoint,Pull-Based 的 Source 的状态和 Flink 外部计算的状态都会主动回滚到快照工夫点,而问题在于 Push-Based 的 Sink 端。Sink 端是否能顺利回滚依赖于内部零碎的个性,通常来说须要内部零碎反对事务,然而不少大数据组件对事务的反对并不是很好,即便是实时计算最罕用的 Kafka 也直到 2017 年的 0.11 版本才反对事务,更多的组件须要依赖各种 trick 来达到某种场景下的 Exactly-Once。 总体来说这些 Trick 能够分为两大类: ...

July 15, 2020 · 2 min · jiezi

Apache-Flink-是什么

Apache Flink 是一个框架和分布式解决引擎,用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行,并能以内存速度和任意规模进行计算。 接下来,咱们来介绍一下 Flink 架构中的重要方面。 解决无界和有界数据任何类型的数据都能够造成一种事件流。信用卡交易、传感器测量、机器日志、网站或挪动应用程序上的用户交互记录,所有这些数据都造成一种流。 数据能够被作为 无界 或者 有界 流来解决。 1.无界流 有定义流的开始,但没有定义流的完结。它们会无休止地产生数据。无界流的数据必须继续解决,即数据被摄取后须要立即解决。咱们不能等到所有数据都达到再解决,因为输出是有限的,在任何时候输出都不会实现。解决无界数据通常要求以特定程序摄取事件,例如事件产生的程序,以便可能推断后果的完整性。 2.有界流 有定义流的开始,也有定义流的完结。有界流能够在摄取所有数据后再进行计算。有界流所有数据能够被排序,所以并不需要有序摄取。有界流解决通常被称为批处理。 Apache Flink 善于解决无界和有界数据集 准确的工夫管制和状态化使得 Flink 的运行时(runtime)可能运行任何解决无界流的利用。有界流则由一些专为固定大小数据集非凡设计的算法和数据结构进行外部解决,产生了杰出的性能。 通过摸索 Flink 之上构建的 用例 来加深了解。 部署利用到任意中央Apache Flink 是一个分布式系统,它须要计算资源来执行应用程序。Flink 集成了所有常见的集群资源管理器,例如 Hadoop YARN、 Apache Mesos 和 Kubernetes,但同时也能够作为独立集群运行。 Flink 被设计为可能很好地工作在上述每个资源管理器中,这是通过资源管理器特定(resource-manager-specific)的部署模式实现的。Flink 能够采纳与以后资源管理器相适应的形式进行交互。 部署 Flink 应用程序时,Flink 会依据应用程序配置的并行性主动标识所需的资源,并从资源管理器申请这些资源。在产生故障的状况下,Flink 通过申请新资源来替换产生故障的容器。提交或控制应用程序的所有通信都是通过 REST 调用进行的,这能够简化 Flink 与各种环境中的集成。 运行任意规模利用Flink 旨在任意规模上运行有状态流式利用。因而,应用程序被并行化为可能数千个工作,这些工作散布在集群中并发执行。所以应用程序可能充分利用无尽的 CPU、内存、磁盘和网络 IO。而且 Flink 很容易保护十分大的应用程序状态。其异步和增量的检查点算法对解决提早产生最小的影响,同时保障准确一次状态的一致性。 Flink 用户报告了其生产环境中一些令人印象粗浅的扩展性数字 解决每天解决数万亿的事件,利用保护几TB大小的状态, 和利用在数千个内核上运行。利用内存性能有状态的 Flink 程序针对本地状态拜访进行了优化。工作的状态始终保留在内存中,如果状态大小超过可用内存,则会保留在能高效拜访的磁盘数据结构中。工作通过拜访本地(通常在内存中)状态来进行所有的计算,从而产生非常低的解决提早。Flink 通过定期和异步地对本地状态进行长久化存储来保障故障场景下准确一次的状态一致性。 原文链接:https://flink.apache.org/zh/flink-architecture.html

July 15, 2020 · 1 min · jiezi

你与30W奖金只差一个-Apache-Flink-极客挑战赛的报名

万众瞩目的第二届 Apache Flink 极客挑战赛来啦! 去年,第一届 Apache Flink 极客挑战赛,会集了寰球11个国家和地区,233所高校,397家企业,4393位顶尖选手参赛! 在整个较量的过程中,通过实践和实战的超强联合,大家都播种满满,逐渐晋升了理论业务能力,刷新了古代大数据的认知,找到气味相投的 nice 团队,发明有限可能! 来康康大家的感触吧~ 理解了实践与实际的差距,明确了实际出真知的真谛。学术是一个无限输出有限资源的环境,理论场景却是一个有限输出无限资源的环境。在诸多的限度下实现实践的成果是一个挑战,也是一次播种。 ——中国科学院 Fractal 咱们对大数据与机器学习的联合利用也有了更粗浅的了解。在这个越来越智能的大数据时代,咱们深信 Flink 和 intel Analytics Zoo 定能发明更大的价值。 ——北京邮电大学 建文大帝 加入像 Flink 性能优化大赛、中间件性能挑战赛等工程类较量,是学习和进步编程技能的绝佳路径。 ——北京信息科技大学 乘蜗牛追乌龟 可能找到气味相投的人一起打较量是很 nice 的经验! ——电子科技大学 阿川的本色出演 掀起报名狂潮的 Apache Flink 极客挑战赛,在第二届进行了全面降级。赛制选题上,围绕全世界最为关注的“疫情”开展;助阵大咖会以业余角度参加到评审环节中,给大赛削减更多的含金量;不同的赛制规定也晋升了大赛的全面性;参赛人员的奖金和激励师处分特地值得大家期待,既放弃了偏心公正,同时也削减了趣味互动性。 大赛相干介绍2020 年从天而降的疫情对整个国家的公共卫生事件应答能力提出了很高的要求,如何利用科技伎俩对疫情流传进行精准无效的防控成为了要害。为了让科技更好地联合民生,让 IT 技术进一步造福社会,阿里云联手英特尔以及 Apache Flink 社区独特发动本次较量。心愿选手可能通过本次大赛获取更多技术启发,实质性的利用到咱们的生存当中,成就生存,发明价值! 即日起至9月16日中午12:00,Apache Flink 极客挑战赛报名正式开启! 第二届 Apache Flink 极客挑战赛由 Apache Flink Community China 发动,阿里云计算平台事业部、天池平台、intel 联结举办,达摩院提供向量搜寻的技术输入。 较量助阵大咖阵容 赛制制度赛题阐明 基于从安防摄像头视频脱敏后的人脸及人体数据,利用 Flink + Analytics Zoo + 向量搜索引擎 Proxima 对新冠确诊病例的历史和实时口头轨迹进行追踪。赛题背地的技术在 NLP、Computer Graphics、举荐零碎等方面都有相当宽泛的利用,因而较量也将考查解决方案通用性。 ...

July 14, 2020 · 1 min · jiezi

官宣-千呼万唤Apache-Flink-1110-正式发布啦

Apache Flink 社区很荣幸的发表 Flink 1.11.0 版本正式公布!超过 200 名贡献者参加了 Flink 1.11.0 的开发,提交了超过 1300 个修复或优化。这些批改极大的进步了 Flink 的可用性,并且加强了各个 API 栈的性能。其中一些比拟重要的批改包含: 外围引擎局部引入了非对齐的 Checkpoint 机制。这一机制是对 Flink 容错机制的一个重要改良,它能够进步重大反压作业的 Checkpoint 速度。实现了一套新的 Source 接口。通过对立流和批作业 Source 的运行机制,提供罕用的外部实现如事件工夫解决,watermark 生成和闲暇并发检测,这套新的 Source 接口能够极大的升高实现新的 Source 时的开发复杂度。Flink SQL 引入了对 CDC(Change Data Capture,变动数据捕捉)的反对,它使 Flink 能够不便的通过像 Debezium 这类工具来翻译和生产数据库的变动日志。Table API 和 SQL 也扩大了文件系统连接器对更多用户场景和格局的反对,从而能够反对将流式数据从 Kafka 写入 Hive 等场景。PyFlink 优化了多个局部的性能,包含对向量化的用户自定义函数(Python UDF)的反对。这些改变使 Flink Python 接口能够与罕用的 Python 库(如 Pandas 和 NumPy)进行互操作,从而使 Flink 更适宜数据处理与机器学习的场景。Flink 1.11.0 的二进制公布包和源代码能够在 Flink 官网的下载页面取得,对应的 PyFlink 公布包能够在 PyPI 网站下载。详情能够参阅公布阐明,公布性能更新与更新后的文档。 ...

July 9, 2020 · 5 min · jiezi

首次揭秘春晚活动下快手实时链路保障实践

摘要:本文由快手开发工程师刘建刚分享,主要介绍春晚活动下快手实时链路保障实践。内容主要包含以下四部分: 快手 Flink 简介春晚实时保障方案春晚实时大屏未来规划Tips:点击「阅读原文」链接可查看作者原版 PPT 及分享视频~ 一、快手 Flink 简介我们首先来看一下快手的实时计算架构图。主要分为4个部分,包括数据接入、数据计算、数据应用和数据展示。各层职责分明、衔接顺畅,方便用户开发。 快手的 Flink 集群规模大概有 3000 多台机器,日处理条目数为20万亿,峰值为38亿条。主要应用场景包含以下四类: 实时 SQL 平台,这是 Flink 托管的一个产品化的 SQL 平台。短视频、直播等指标的实时计算,涵盖了公司的主要业务和产品。机器学习的数据预处理,支撑着快手广告等各种模型的训练。快手所有的日志拆分、同步等实时的数据流。 二、春晚实时保障方案快手中标了2020年的央视春晚,春晚作为全球华人辞旧迎新的晚会,数据量之大前所未有。快手 Flink 作为公司的实时计算平台,支持春晚超大状态和千万并发等复杂计算。春晚项目的挑战主要体现在稳定性、实时性、准确性三个方面,我们为此制定了一系列方案为春晚保驾护航。 下面我会通过这4个方面来介绍一下我们为春晚做的努力。 第一个是过载保护,主要介绍极端压力下的技术应对方案;第二个是全系统的稳定性,确保各个方面都万无一失;第三个是压力测试,它是春晚的提前模拟;第四个是资源的保障,涉及到资源的管理和保障。 1.过载保护Flink 在流量激增或者单点性能不足的情况下,有可能会发生卡死、雪崩或者失败的情况。这个时候一旦我们的实时作业挂掉,整个作战计划就会被打乱,可能给公司带来很大的损失。 我们针对这种场景设计了一种健康检查、智能限速、源端控制相结合的柔性可用技术。为什么要通过源端控制?首先,如果出了问题,我们可以在下游的 task 上进行控制,但是这样的话可能带来一个问题,它会造成反压等阻塞行为,有可能会把整个作业卡死,所以我们通过控制数据源来从本质上解决问题。下面是我们技术实现: TaskManager 作为从节点,将自己的健康信息定期汇报到 Master 节点。Master 节点一旦检测到极端压力,立刻要求所有的 source 限速 50%。如果之后作业状态良好,就会慢慢的提高我们的输入 QPS,每次 10%。 然后看一下我们的测试效果图。流量高峰到来时 QPS 为 200K。一旦 Master 节点检测到极端压力,直接将 QPS 限速到 100K。之后检测到作业状态良好,就逐步地进行恢复。经过测试(随着逐渐恢复各项指标会有波动),我们的 CPU 使用率从最高的 100% 降到了 80%~90%,ygc 由每分钟的10秒降到了每分钟3秒以内,同时也避免了的 oom、心跳超时、卡死等各种问题。这种技术能够保障我们 Flink 在极度压力下的存活,起到了削峰保命的效果。 我们还设计了一种轻量级的热更新模型,在作业不停止的情况下通过 restful 接口实时的控制作业去应对各种压力,避免了繁琐的修改代码、打包、上线等耗时过程。常见功能包括关闭快照、设置采样率、source 源鲜素,如下图所示。 ...

July 6, 2020 · 1 min · jiezi

官方剧透111-发版前我们偷看了-Flink-中文社区发起人的聊天记录

简介: 自 2014 年正式开源, Flink 发展非常迅速,在 GitHub 上其访问量在 Apache 项目中位居前三。去年年底 Flink Forward Asia 2019 大会公布,仅仅 2019 年一年的时间,Flink 在 GitHub 上的 star 数量就翻了一倍,Contributor 数量也呈现出持续增长的态势。 原文链接:点击这里 Flink 1.11 即将 Release 啦!作为备受瞩目的新一代开源大数据计算引擎,Flink 无疑已成为 Apache 基金会和 GitHub 最为活跃的项目之一。 自 2014 年正式开源, Flink 发展非常迅速,在 GitHub 上其访问量在 Apache 项目中位居前三。去年年底 Flink Forward Asia 2019 大会公布,仅仅 2019 年一年的时间,Flink 在 GitHub 上的 star 数量就翻了一倍,Contributor 数量也呈现出持续增长的态势。 GitHub 地址指路: https://github.com/apache/flink越来越多的企业和开发者正在不断地加入 Flink 社区,中国开发者也为 Flink 开发做出了巨大的贡献。最近,Flink 终于要迎来1.11版本的更新,不仅对 SQL 和 PyFlink 的支持进行了优化,还有 Hive 的兼容性,以及增强了拓展资源(GPU)的调度支持。 ...

July 6, 2020 · 2 min · jiezi

如何使用-Apache-Flink-查询-Pulsar-流

在之前我们介绍了 Apache Pulsar 及其与其他消息系统的不同之处,并讲解了如何融合 Pulsar 和 Flink 协同工作,为大规模弹性数据处理提供无缝的开发人员体验。本文将介绍 Apache Pulsar 和 Apache Flink 的集成和最新研发进展,并详细说明如何利用 Pulsar 内置 schema,使用 Apache Flink 实时查询 Pulsar 流。 Apache Pulsar 简介Apache Pulsar 是一个灵活的发布/订阅消息系统,支持持久日志存储。Pulsar 的架构优势包括多租户、统一消息模型、结构化事件流、云原生架构等,这些优势让 Pulsar 能够完美适用于多种用户场景,从计费、支付、交易服务到融合组织中不同的消息架构。更多关于 Pulsar 的信息,点击 Apache Pulsar documentation 或通过 Slack 与 Pulsar 社区联系。 现有 Pulsar & Flink 集成(Apache Flink 1.6+)在现有的 Pulsar 和 Flink 集成中,Pulsar 作为 Flink 应用程序中的消息队列来使用。Flink 开发人员可以选择特定 Pulsar source,并连接到所需的 Puslar 集群和 topic,将 Pulsar 用作 Flink 的流 source 和流 sink: ...

July 3, 2020 · 4 min · jiezi

如何使用-Apache-Flink-查询-Pulsar-流

原作者: Sijie Guo、Markos Sfikas翻译:StreamNative-Sijia在之前的博客中,我们介绍了 Apache Pulsar 及其与其他消息系统的不同之处,并讲解了如何融合 Pulsar 和 Flink 协同工作,为大规模弹性数据处理提供无缝的开发人员体验。本文将介绍 Apache Pulsar 和 Apache Flink 的集成和最新研发进展,并详细说明如何利用 Pulsar 内置 schema,使用 Apache Flink 实时查询 Pulsar 流。 Apache Pulsar 简介Apache Pulsar 是一个灵活的发布/订阅消息系统,支持持久日志存储。Pulsar 的架构优势包括多租户、统一消息模型、结构化事件流、云原生架构等,这些优势让 Pulsar 能够完美适用于多种用户场景,从计费、支付、交易服务到融合组织中不同的消息架构。更多关于 Pulsar 的信息,点击 Apache Pulsar documentation 或通过 Slack 与 Pulsar 社区联系。 现有 Pulsar & Flink 集成(Apache Flink 1.6+)在现有的 Pulsar 和 Flink 集成中,Pulsar 作为 Flink 应用程序中的消息队列来使用。Flink 开发人员可以选择特定 Pulsar source,并连接到所需的 Puslar 集群和 topic,将 Pulsar 用作 Flink 的流 source 和流 sink: ...

July 3, 2020 · 4 min · jiezi

Flink的window时间语义Watermark机制多代码案例详解Flink学习入门三

大家好,我是后来,我会分享我在学习和工作中遇到的点滴,希望有机会我的某篇文章能够对你有所帮助,所有的文章都会在公众号首发,欢迎大家关注我的公众号" 后来X大数据 ",感谢你的支持与认可。通过前2篇flink的学习,已经基本掌握了flink的基本使用,但是关于flink真正内核的东西还没开始说,那先简单介绍一下,flink的核心亮点: 窗口时间语义精准一次性我们在第一篇的学习了解到了flink的wordCount,以及在第二篇的API 中,我们也只是获取到数据,进行简单的转换,就直接把数据输出。 但是我们在之前都是以事件为驱动,等于说是来了一条数据,我就处理一次,但是现在遇到的问题是: 我们可以简单的把wordCount的需求比做公司的订单金额,也就是订单金额会随着订单的增加而只增不减,那么如果运营部门提了以下需求: 每有1000条订单就输出一次这1000条订单的总金额每5分钟输出一次刚刚过去这5分钟的订单总金额每3秒输出一次最近5分钟内的累计成交额连续2条订单的间隔时间超过30秒就按照这个时间分为2组订单,输出前一组订单的总金额那么面对这个需求,因为时间一直是流动的,大家有什么想法? 基于这些需求,我们来讲一下flink的窗口。 窗口窗口:无论是hive中的开窗函数,还是Spark中的批次计算中的窗口,还是我们这里讲的窗口,本质上都是对数据进行划分,然后对划分后的数据进行计算。 那么Windows是处理无限流的核心。Windows将流分成有限大小的“存储桶”,我们可以在其上应用计算。 在flink中,窗口式Flink程序一般有2类, 键控流stream .keyBy(...) <- keyed versus non-keyed windows .window(...) <- required: "assigner" [.trigger(...)] <- optional: "trigger" (else default trigger) [.evictor(...)] <- optional: "evictor" (else no evictor) [.allowedLateness(...)] <- optional: "lateness" (else zero) [.sideOutputLateData(...)] <- optional: "output tag" (else no side output for late data) .reduce/aggregate/fold/apply() <- required: "function" [.getSideOutput(...)] <- optional: "output tag"非键控流stream .windowAll(...) <- required: "assigner" [.trigger(...)] <- optional: "trigger" (else default trigger) [.evictor(...)] <- optional: "evictor" (else no evictor) [.allowedLateness(...)] <- optional: "lateness" (else zero) [.sideOutputLateData(...)] <- optional: "output tag" (else no side output for late data) .reduce/aggregate/fold/apply() <- required: "function" [.getSideOutput(...)] <- optional: "output tag"唯一的区别是:对键控流的keyBy(…)调用window(…),而非键控流则是调用windowAll(…)。 ...

June 29, 2020 · 4 min · jiezi

免费下载-阿里云实时计算整体解决方案白皮书重磅发布

随着信息化程度的加深,大数据已成为国家基础性战略资源,掌握和运用大数据的能力正日益成为衡量国家和地区经济社会发展程度的重要标志。同时,以大数据、人工智能为代表的核心技术正飞速发展,逐渐成为推动整个产业运行和转型升级的核心驱动力量,各个传统产业也随之走上智能化升级的道路。 如何构建完整的数据体系,充分挖掘数据价值,构建企业核心竞争力正逐渐成为各个行业升级转型的关键所在。 随着阿里云实时计算在各行各业丰富场景中的应用,实时计算赢得了金融、物流、广告、IoT等行业一线企业的一致认可。为更好的助力各行业企业实现企业数字化转型,为企业的创新、重构核心竞争力提供坚实支撑;阿里云实时计算重磅推出金融、物流、IoT、广告等行业解决方案白皮书。 <p style="text-align:center"><font size=5>点击免费下载:《阿里云实时计算物流行业解决方案》</font><font size=5>《阿里云实时计算金融行业解决方案》</font><font size=5>《阿里云实时计算广告行业解决方案》</font><font size=5>《阿里云实时计算IoT行业解决方案》</font> 实时计算(Alibaba Cloud RealtimeCompute,Powered by Ververica)是阿里云提供的基于 Apache Flink 构建 的企业级大数据计算平台。实时计算在 PB 级别的数据集上可以支持亚秒级别的处理延时,赋能用户标准实时数 据处理流程和行业解决方案;在支持 Datastream API 作业开发的同时,提供了批流统一的 Flink SQL,弥补了社 区 SQL 功能缺失,使得 BI 场景下的开发变得更加简单;丰富的上下游 connector 保证了与用户已使用的大数据组 件无缝对接;智能作业调优和诊断功能进一步简化了用户的开发和使用。同时,实时计算在 Apache Flink 核心功能的基础上还增强了企业用户所关注的集群稳定、性能优化、安全控制、系统监 控和作业管理等。 如果您对阿里云实时计算感兴趣,想了解更多实时计算功能与场景应用,点击下方链接可了解更多: https://help.aliyun.com/produ... <p style="text-align:center">▼ 阿里云实时计算交流群 ▼</p> <p style="text-align:center"></p>

June 18, 2020 · 1 min · jiezi

数仓系列-深入解读-Flink-资源管理机制

作者:宋辛童(五藏)整理:王文杰(Flink 社区志愿者) 摘要:本文根据 Apache Flink 系列直播整理而成,由阿里巴巴高级开发工程师宋辛童分享。文章主要从基本概念、当前机制与策略、未来发展方向等三个方面帮助开发者深入理解 Flink 的资源管理机制。 基本概念当前机制与策略未来发展方向Tips:点击「下方链接」可查看更多数仓系列视频~https://ververica.cn/develope... 1. 基本概念1.1 相关组件我们今天介绍的主要是与 Flink 资源管理相关的组件,我们知道一个 Flink Cluster 是由一个 Flink Master 和多个 Task Manager 组成的,Flink Master 和 Task Manager 是进程级组件,其他的组件都是进程内的组件。 图1. Flink 资源管理相关组件 如图1所示,一个 Flink Master 中有一个 Resource Manager 和多个 Job Manager ,Flink Master 中每一个 Job Manager 单独管理一个具体的 Job ,Job Manager 中的 Scheduler 组件负责调度执行该 Job 的 DAG 中所有 Task ,发出资源请求,即整个资源调度的起点;JobManager 中的 Slot Pool 组件持有分配到该 Job 的所有资源。另外,Flink Master 中唯一的 Resource Manager 负责整个 Flink Cluster 的资源调度以及与外部调度系统对接,这里的外部调度系统指的是 Kubernetes、Mesos、Yarn 等资源管理系统。 ...

June 18, 2020 · 3 min · jiezi

实时即未来一个小微企业心中的流计算

摘要:本文由墨芷技术团队唐铎老师分享,主要讲述其技术团队内部引入流计算的整个过程,包括最初的决策、期间的取舍以及最终落地,一路走来他们的思考、感悟以及经验分享。 初识 Flink为什么一定要上 Flink一个小例子总结Tips:“实时即未来”在很多人的眼中可能只是一句口号,但在墨芷,这是他们亲手创造的故事。 大家好,我们是浙江墨芷信息科技有限公司,一个刚刚满3年的创业团队,主营业务是电商代运营,目前是淘宝四星级服务商。 我们的核心团队先后服务于国内知名女装、家电、母婴、男装、童装、珠宝饰品、化妆品等多个品类知名品牌商,具有丰富的品牌运营管理经验,服务过的品牌均在行业前列。 主营业务围绕泛时尚领域(服装、婴童、美妆、生活家居、珠宝饰品)互联网平台品牌运营及全网品牌推广,涉及品牌定位与推广、电商运营、商品企划与经营、视觉设计、营销推广、顾客服务、仓储物流等综合端到端服务。 本文将分享墨芷与流计算结缘的故事。 01 初识Flink第一次接触 Flink 流计算是在18年9月的云栖大会上,大沙老师与在场以及线上的开发者们分享 Flink,会场座无虚席,会场门外还围着三五层的听众。虽然老师的讲解时间不长,听的也是一知半解,却有种很强烈感觉,“实时,即是未来”。 从云栖小镇回来后,跟自己的团队讨论了一下,大家决定向 Flink 开进,但前进的难度是我们没有预料到的。那个时候学习资料很少,一本《Flink 基础教程》被我们翻来复去的看,动手实操门槛较高,进度非常不理想。 图1 云栖大会流计算分会场 19年3月,有幸参加了在杭州举行的 Flink 用户交流会,报名时只是抱着学习的心态去旁听,但到现场后震惊了,参会的不仅是 Flink 的深度用户,更甚的是每位都来自估值百亿以上的大厂。无论是讨论的内容还是出身都让我们感到自卑。 回来之后的第二天,一起去的五个人不约而同的都到公司加班,即便不说透,这次会议给大家带来的心丽冲击是巨大的,也促使了我们下定决心,即便难度再大也要把 Flink 应用起来。 在此一个月之后,我们用 Java 编写的 Flink Job 上线了,即便实现的功能很简单,但这是我们坚实的一小步。 图2 社区里广为流传的一张照片 2020年年初,疫情肆虐,团队人员变动,客观条件使我们不得不放弃之前用 Java 编写的一切,转投 Python。这个决定极其艰难,我们很清楚,一切将回到原点。 但我们与 Flink 的缘分还没结束。刚好,我们看到社区发起了 PyFlink 扶持计划,于是邮件咨询,也有幸被眷顾。接下来的一个月时间,我们在金竹、付典、断尘几位老师的帮助下,将原有的 Flink Job 迁移到了 PyFlink 上,同时也带着需求去学习 PyFlink 的特性。这才有了与大家分享学习成果的机会。 02 为什么一定要上Flink说到这,一定有同行问,为啥一个小微企业还要上流计算,用得上吗? 我们面临的是若干个严峻的事实: 人员数量的膨胀带来了成倍的开销。公司用了3年时间,将团队规模扩张到的150人,在嘉兴这个小城市里这是很不容易的一件事,而且主业是电商代运营,这种工作更像我们软件行业的项目外包。一提到外包,同行们肯定会联想到人力配备,简单讲,有项目做才能养活人,没项目的话,闲置的人力成本就是亏本买卖。人效提升困难,规定再严格的 KPI 也会有瓶颈。同事们每天上班第一件事就是发前一天的销售业绩,只是这个小小的日报,就要耗费半个小时的时间,数据的时效又是“T + 1”,略显滞后。在做直通车推广时,由于同事的疏忽,一些已经不再需要付费推广或可以降低竞价的商品还在按照原计划持续烧钱,人工监控很难及时地发现这些问题。作为 IT 规划的主导者,一直以来我都希望可以依托团队在电商经营上丰厚的经验及操盘能力,这样目标很明了,就是搭建我们自己的数据实时决策平台。 决策,我们暂且拆开来看,决断与策略。团队自有经验及做事的判断逻辑,我们把它划到策略一侧,现在我们缺少的是“决断的能力”,决断既要考虑准确性,又要顾及时效性,当然,如果决断时能渐进地优化策略也是极好的。所以我们大致规划了图3中的架构。从下至上依次为我们的 DataSource(数据源),Swarm(多源数据收集平台),DW(数据仓库),NB(电商离线数据中台),Radical(电商数据决策平台)。数据逐层向上被收集,保存,计算,展现,应用,而Flink在数据的生命周期内担当实时计算的重要任务。 还记得电商场景下商家被薅羊毛的新闻吗? 目前没有任何一款电商 ERP 有针对这方面的功能设计。如果可以编写一个基于 Flink 流计算的实时监控异常销售情况的小插件,在获取到订单中的实付金额去比对之前的商品价格,再结合最新的库存计算后判断得出结果,适时弹出告警,那样的悲剧是否可以避免? ...

June 18, 2020 · 5 min · jiezi

Flink作业问题分析和调优实践

摘要:本文主要分享 Flink 的 CheckPoint 机制、反压机制及 Flink 的内存模型。对这3部分内容的熟悉是调优的前提,文章主要从以下几个部分分享: 原理剖析性能定位经典场景调优内存调优Checkpoint 机制1.什么是 checkpoint简单地说就是 Flink 为了达到容错和 exactly-once 语义的功能,定期把 state 持久化下来,而这一持久化的过程就叫做 checkpoint ,它是 Flink Job 在某一时刻全局状态的快照。 当我们要对分布式系统实现一个全局状态保留的功能时,传统方案会引入一个统一时钟,通过分布式系统中的 master 节点广播出去给每一个 slaves 节点,当节点接收到这个统一时钟时,它们就记录下自己当前的状态即可。 但是统一时钟的方式也存在一定的问题,某一个 node 进行的 GC 时间比较长,或者 master 与 slaves 的网络在当时存在波动而造成时钟的发送延迟或者发送失败,都会造成此 slave 和其它的机器出现数据不一致而最终导致脑裂的情况。如果我们想要解决这个问题,就需要对 master 和 slaves 做一个 HA(High Availability)。但是,一个系统越是复杂,就越不稳定且维护成本越高。 Flink 是将 checkpoint 都放进了一个名为 Barrier 的流。 上图中就是一个 Barrier 的例子,从上游的第一个 Task 到下游的最后一个 Task,每次当 Task 经过图中蓝色的栅栏时,就会触发 save snapshot(快照)的功能。我们用一个例子来简单说明。 2.实例分析 这是一个简单的 ETL 过程,首先我们把数据从 Kafka 中拿过来进行一个 trans 的转换操作,然后再发送到一个下游的 Kafka ...

June 18, 2020 · 3 min · jiezi

深入分析-Flink-SQL-工作机制

作者 | 伍翀(云邪),阿里巴巴技术专家整理 | 陈婧敏(清樾),阿里巴巴技术专家 摘要:本文整理自 Flink Forward 2020 全球在线会议中文精华版,由 Apache Flink PMC 伍翀(云邪)分享,社区志愿者陈婧敏(清樾)整理。旨在帮助大家更好地理解 Flink SQL 引擎的工作原理。文章主要分为以下四部分: Flink SQL ArchitectureHow Flink SQL Works?Flink SQL OptimizationsSummary and FuturesTips:点击下方链接可查看作者分享的原版视频~ https://ververica.cn/develope... Apache Flink 社区在最近的两个版本(1.9 & 1.10 )中为面向未来的统一流批处理在架构层面做了很多优化,其中一个重大改造是引入了 Blink Planner,开始支持 SQL & Table API 使用不同的 SQL Planner 进行编译(Planner 的插件化)。 本文首先会介绍推动这些优化背后的思考,展示统一的架构如何更好地处理流式和批式查询,其次将深入剖析 Flink SQL 的编译及优化过程,包括: Flink SQL 利用 Apache Calcite 将 SQL 翻译为关系代数表达式,使用表达式折叠(Expression Reduce),下推优化(Predicate / Projection Pushdown )等优化技术生成物理执行计划(Physical Plan),利用 Codegen 技术生成高效执行代码。Flink SQL 使用高效的二进制数据存储结构 BinaryRow 加速计算性能;使用 Mini-batch 攒批提高吞吐,降低两层聚合时由 Retraction 引起的数据抖动;聚合场景下数据倾斜处理和 Top-N 排序的优化原理。 ...

June 18, 2020 · 5 min · jiezi

数仓大法好跨境电商-Shopee-的实时数仓之路

作者:黄良辉 本文讲述 Flink 在 Shopee 新加坡数据组(Shopee Singapore Data Team)的应用实践,主要内容包括: 实时数仓建设背景Flink 在实时数据数仓建设中结合 Druid、Hive 的应用场景实时任务监控Streaming SQL 平台化Streaming Job 管理未来规划优化方向建设背景Shopee 是东南亚与台湾领航电商平台,覆盖新加坡、马来西亚、菲律宾、台湾、印度尼西亚、泰国及越南七大市场,同时在中国深圳、上海和香港设立跨境业务办公室。 Shopee在2020年第一季的总订单量高达4.298亿,同比增长111.2%。根据App Annie, Shopee在 2020年第一季强势跻身全球购物类 App下载量前三名。同时斩获东南亚及台湾市场购物类 App 年度总下载量、平均月活数、安卓使用总时长三项冠军,并领跑东南亚两大头部市场,拿下印尼及越南年度购物类 App 下月活量双冠王。其中包括订单商品、物流,支付,数字产品等各方面的业务。为了支持这些互联网化产品,应对越来的越多的业务挑战,于是我们进行了数据仓库的设计和架构建设。 数据仓库挑战当前随着业务发展,数据规模的膨胀和商务智能团队对实时需求的不断增长,业务挑战越来越大: 业务维度而言,业务需求越来越复杂,有需要明细数据查询,又有实时各种维度聚合报表,实时标签培训和查询需求。同时大量业务共享了一些业务逻辑,造成大量业务耦合度高,重复开发。平台架构而言,当前任务越来越多,管理调度,资源管理,数据质量异常监控等也越来越重要。实时化也越来急迫,目前大量业务还是离线任务形式,导致凌晨服务负载压力巨大,同时基于 T+1(天、小时级)架构业务无法满足精细化、实时化运营需要。技术实现而言,现在实时业务大量采用 Spark Structured Streaming 实现,严重依赖 HBase 做 Stateful 需求,开发复杂;在异常故障事故,Task 失败,缺乏 Exactly Once 特性支持,数据易丢失、重复。为了解决上述问题,于是开始了 Flink 实时数仓的探索。 数据仓库架构为了支持这些互联网化产品不断增长的的数据和复杂的业务,Shopee 构建如下图数据仓库架构,从下到上层来看: 最底层是数据收集层,这一层负责实时数据,包括 Binlog、Service Log, Tracking Service Log,经过 Real-time Ingestion 团队数据将会被收集到 Kafka 、Hbase 中。Auto-Ingestion 团队负责数据库数离线日常收集到 HDFS。然后是存储层,这层主要是 Kafka 保存实时消息,加上 HDFS 保存 Hive 数据存储等,HBase 保存维度数据。在存储层上面是 Spark, Flink 计算引擎, Presto SQL 查询引擎。然后是调度管理层,各种资源管理,任务管理,任务调度,管理各种 Spark,Flink 任务。资源管理层上一层是 OLAP 数据存储层,Druid 用于存储时间序列数据,Phoenix(HBase)存储聚合报表数据、维度表数据、标签数据,Elastic Search 存储需要多维度字段索引的数据如广告数据、用户画像等。最上层是应用层,数据报表,数据业务服务,用户画像等。Flink 实时数据数仓实践 ...

June 18, 2020 · 3 min · jiezi

Flink-在快手实时多维分析场景的应用

作者:董亭亭、徐明 摘要:作为短视频分享跟直播的平台,快手有诸多业务场景应用了 Flink,包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播 CDN 调度等。此次主要介绍在快手使用 Flink 在实时多维分析场景的应用与优化。主要内容包括: Flink 在快手应用场景及规模快手实时多维分析平台SlimBase-更省 IO、嵌入式共享 state 存储Tips:点击下方链接可查看作者原版PPT及分享视频~ https://ververica.cn/develope... Flink 在快手应用场景及规模首先看 Flink 在快手的应用场景和规模。 1. 快手应用场景 快手计算链路是从 DB/Binlog 以及 WebService Log 实时入到 Kafka 中,然后接入 Flink 做实时计算,其中包括实时数仓、实时分析以及实时训练,最后的结果存到 Druid、Kudu、HBase 或者 ClickHouse 里面;同时 Kafka 数据实时 Dump 一份到 Hadoop 集群,然后通过 Hive、MapReduce 或者 Spark 来做离线计算;最终实时计算和离线计算的结果数据会用内部自研 BI 工具 KwaiBI 来展现出来。 Flink 在快手典型的应用场景主要分为三大类: 80% 统计监控:实时统计,包括各项数据的指标,监控项报警,用于辅助业务进行实时分析和监控;15% 数据处理:对数据的清洗、拆分、Join 等逻辑处理,例如大 Topic 的数据拆分、清洗;5% 数据处理:实时业务处理,针对特定业务逻辑的实时处理,例如实时调度。 Flink 在快手应用的典型场景案例包括: 快手是分享短视频跟直播的平台,快手短视频、直播的质量监控是通过 Flink 进行实时统计,比如直播观众端、主播端的播放量、卡顿率、开播失败率等跟直播质量相关的多种监控指标;用户增长分析,实时统计各投放渠道拉新情况,根据效果实时调整各渠道的投放量;实时数据处理,广告展现流、点击流实时 Join,客户端日志的拆分等;直播 CDN 调度,实时监控各 CDN 厂商质量,通过 Flink 实时训练调整各个 CDN 厂商流量配比。2. Flink 集群规模 ...

June 18, 2020 · 3 min · jiezi

Apache-Flink-误用之痛

摘要:本文根据 Flink Forward 全球在线会议 · 中文精华版整理而成,围绕着项目的开始、需求分析、开发,以及测试、上线、运维整个生命周期展开,介绍了 Apache Flink 实践中的一些典型误用情况,并给出了相应的更优实践方案。 Flink 实践中最首当其冲的误用就是不按迭代开发的过程操作。最佳实践应该遵循迭代开发的步骤进行,包含以下几个阶段: 项目开始涉及分析开发测试上线维护1. 项目开始在开始开发前,我们需要选择正确的切入方式,以下几种往往是最糟糕的开始: a) 从一个具有挑战性的用例开始(端对端的 Exactly-once、大状态、复杂的业务逻辑、强实时SLA的组合) b) 之前没有流处理经验 c) 不对团队做相关的培训 d) 不利用社区在开发的过程中,其实要认认真真的来规划我们的切入点,首先,要从简单的任务开始循序渐进。要有一定的大数据和流处理的知识积累,尽量参加一些培训,也要利用好社区资源。基于这样的想法,我们就能很快找到切入点。 怎么样去做?社区提供了很多的培训,包括 Flink Forward 和 Vererica 网站上有各种培训课程,大家可以去看。同时,可以充分利用社区。社区还建立了中文的邮件列表,大家可以充分利用中文邮件列表来解决手头的疑难杂症。另外,Stack Overflow 也是个提问的好地方,但在提问前尽量去看一看已有的提问,做到心中有数。 邮件列表:user@flink.apache.com/user-zh@flink.apache.org Stack Overflow:www.stackoverflow.com 2. 设计分析方案设计中的一些常见错误思维,往往是由于没有充分思考需求导致的,比如: a) 不考虑数据一致性和交付保证 b) 不考虑业务升级和应用改进 c) 不考虑业务规模问题 d) 不深入思考实际业务需求我们要认真分析需求,同时认真考虑实际交付情况。提到一致性和交付保障,其实可以通过几个问题来引导大家完成这件事,如下图所示: 第1个问题,是否在乎数据的丢失? 如果不在乎,你可以没有 Checkpoint。 第2个问题,是否在乎结果的正确性? 在很多的场景里面,我们非常关注结果的正确性,比如金融领域,但是另外一些场景比如监控或其他简单的使用场景仅需要一个概要的数据统计。如果不在乎结果的正确性,可以考虑用 at-least-once 的模式配置并使用可回放的数据源。相反,如果结果的准确性十分重要,且下游不关心重复记录,那么仅需设置 exactly-once 模式并使用可回放的数据源。如果下游要求数据不能重复,哪怕数据正确也只能发送一次,这种时候就对 sink 有更进一步的限制,在 exactly-once 的模式下,使用可回放的数据源,并且 sink 需要支持事务。 带着这样的思维方式分析业务,才能非常清晰地知道,怎么去使用 Flink,进而避免一些糟糕的事情发生。 完成分析之后,最终目的是什么?我们为什么要有这种选择,而不是一上来就选一个最好的方案? 因为世界上永远没有“最好”,这里的核心因素就是延迟,要根据业务的延迟和准确性需求来均衡去做选择。 当需求都分析好之后,还需要去思考应用是否需要升级。从一个正常的 Flink 作业来讲,我们有几个问题要考虑。第一个,Flink 作业一般都有状态读取,做升级时需要有 savepoint 机制来保障,将状态存储保留在远端,再恢复到新的作业上去。很多场景下都会有升级的需求,这简单列了几点: ...

June 18, 2020 · 2 min · jiezi

记录一次Flink作业异常的排查过程

本文来自: PerfMa技术社区PerfMa(笨马网络)官网 最近2周开始接手apache flink全链路监控数据的作业,包括指标统计,业务规则匹配等逻辑,计算结果实时写入elasticsearch. 昨天遇到生产环境有作业无法正常重启的问题,我负责对这个问题进行排查跟进。 第一步,基础排查首先拿到jobmanager和taskmanager的日志,我从taskmanager日志中很快发现2个基础类型的报错,一个是npe,一个是索引找不到的异常 elasticsearch sinker在执行写入数据的前后提供回调接口让作业开发人员对异常或者成功写入进行处理,如果在处理异常过程中有异常抛出,那么框架会让该task失败,导致作业重启。 npe很容易修复,索引找不到是创建索引的服务中的一个小bug,这些都是小问题。 重点是在日志中我看到另一个错误: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Unknown Source) at org.apache.flink.runtime.io.network.api.writer.RecordWriter.<init>(RecordWriter.java:122) at org.apache.flink.runtime.io.network.api.writer.RecordWriter.createRecordWriter(RecordWriter.java:321) at org.apache.flink.streaming.runtime.tasks.StreamTask.createRecordWriter(StreamTask.java:1202) at org.apache.flink.streaming.runtime.tasks.StreamTask.createRecordWriters(StreamTask.java:1170) at org.apache.flink.streaming.runtime.tasks.StreamTask.<init>(StreamTask.java:212) at org.apache.flink.streaming.runtime.tasks.StreamTask.<init>(StreamTask.java:190) at org.apache.flink.streaming.runtime.tasks.OneInputStreamTask.<init>(OneInputStreamTask.java:52) at sun.reflect.GeneratedConstructorAccessor4.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at org.apache.flink.runtime.taskmanager.Task.loadAndInstantiateInvokable(Task.java:1405) at org.apache.flink.runtime.taskmanager.Task.run(Task.java:689) at java.lang.Thread.run(Unknown Source)这种异常,一般是nproc设置太小导致的,或者物理内存耗尽,检查完ulimit和内存,发现都很正常,这就比较奇怪了。 第二步、分析jstack和jmapperfma有一个产品叫xland,我也是第一次使用,不得不说,确实牛逼,好用!首先把出问题的taskmanager的线程栈信息和内存dump出来,具体命令: jstatck pid > 生成的文件名jmap -dump:format=b,file=生成的文件名 进程号接着把这两个文件导入xland,xland可以直接看到线程总数,可以方便搜索统计线程数、实例个数等等 最先发现的问题是这个taskmanager 线程总数竟然有17000+,这个数字显然有点大,这个时候我想看一下,哪一种类型的线程比较大,xland可以很方便的搜索,统计,这时候我注意到有一种类型的线程非常多,总数15520 更上层的调用信息看不到了,只看到来自apache http client,根据作业流程,首先想到的就是es sinker的RestHighLevelClient用到这个东西 ...

June 17, 2020 · 1 min · jiezi

Flink流处理API代码详解含多种SourceTransformSink案例Flink学习入门二

大家好,我是后来,我会分享我在学习和工作中遇到的点滴,希望有机会我的某篇文章能够对你有所帮助,所有的文章都会在公众号首发,欢迎大家关注我的公众号" 后来X大数据 ",感谢你的支持与认可。又是一周没更文了,上周末回运城看牙去了,一直都在路上,太累了。说回正题,关于flink的入门在上一篇已经讲过了。 今天主要说一下关于流处理的API,这一篇所有的代码都是scala。 那么我们还得回到上次的WordCount代码,Flink程序看起来像转换数据集合的常规程序。每个程序都包含相同的基本部分: 获得execution environment加载/创建初始数据指定对此数据的转换指定将计算结果放在何处触发程序执行 获取执行环境所以要想处理数据,还得从获取执行环境来说起。StreamExecutionEnvironment是所有Flink程序的基础,所以我们来获取一个执行环境。有以下3种静态方法 getExecutionEnvironment()createLocalEnvironment()createRemoteEnvironment(host: String, port: Int, jarFiles: String*) //获取上下文环境val contextEnv = StreamExecutionEnvironment.getExecutionEnvironment//获取本地环境val localEnv = StreamExecutionEnvironment.createLocalEnvironment(1)//获取集群环境val romoteEnv = StreamExecutionEnvironment.createRemoteEnvironment("bigdata101",3456,2,"/ce.jar")但一般来说,我们只需要使用第一种getExecutionEnvironment(),因为它将根据上下文执行正确的操作;也即是说,它会根据查询运行的方式决定返回什么样的运行环境,你是IDE执行,它会返回本地执行环境,如果你是集群执行,它会返回集群执行环境。 预定义的数据流源好了,获取到环境之后,我们就开始获取数据源,flink自身是支持多数据源的,首先来看几个预定义的数据流源 基于文件 readTextFile(path)- TextInputFormat 逐行读取文本文件,并将其作为字符串返回,只读取一次。readFile(fileInputFormat, path) -根据指定的文件输入格式读取文件,只读取一次。但事实上,上面的2个方法内部都是调用的readFile(fileInputFormat, path, watchType, interval, pathFilter, typeInfo)我们来看看源码:我们选择其中第一个比较简单的方法进入,就看到了下图,发现其实上述的2种方法最终都会落到这个readFile(fileInputFormat, path, watchType, interval, pathFilter)方法上,只不过后面的参数都是默认值了。所以,这些参数当然也可以自己指定。好了,这个方法大家也不常用,所以就简单介绍下,有需要的小伙伴自己试试这些后面的参数。 基于套接字socketTextStream-从套接字读取。元素可以由定界符分隔。这里提到了套接字,这个我在终于懂了TCP协议为什么是可靠的,计算机基础(六)之运输层是讲过的,这里再说一下:套接字 socket = {IP地址 : 端口号},示例:192.168.1.99 :3456代码使用如下: val wordDS: DataStream[String] = contextEnv.socketTextStream("bigdata101",3456)套接字是抽象的,只是为了表示TCP连接而存在。 基于集合fromCollection(Seq)-从Java Java.util.Collection创建数据流。集合中的所有元素必须具有相同的类型。fromCollection(Iterator)-从迭代器创建数据流。该类指定迭代器返回的元素的数据类型。fromElements(elements: _*)-从给定的对象序列创建数据流。所有对象必须具有相同的类型。fromParallelCollection(SplittableIterator)-从迭代器并行创建数据流。该类指定迭代器返回的元素的数据类型。generateSequence(from, to) -并行生成给定间隔中的数字序列。这些预设的数据源使用的也不是很多,可以说是几乎不用。所以大家可以自己尝试一下。当然注意,如果使用 fromCollection(Seq),因为是从Java.util.Collection创建数据流,所以如果你是用scala编程,那么就需要引入 隐式转换 import org.apache.flink.streaming.api.scala._获取数据源Source大家也能发现,以上的方法几乎都是从一个固定的数据源中获取数据,适合自己测试,但在生产中肯定是不能使用的,所以我们来看看正儿八经的数据源:官方支持的source与sink如下: Apache Kafka(源/接收器)Apache Cassandra(接收器)Amazon Kinesis Streams(源/接收器)Elasticsearch(接收器)Hadoop文件系统(接收器)RabbitMQ(源/接收器)Apache NiFi(源/接收器)Twitter Streaming API(源)Google PubSub(源/接收器)加粗的3个日常中比较常用的,那么也发现其实数据源只有kafka,sink有ES和HDFS,那么我们先来说说kafka Source,关于Kafka的安装部署这里就不讲了,自行Google。我们来贴代码与分析。 ...

June 17, 2020 · 4 min · jiezi

Flink-110-Container-环境实战

作者 | 唐云(茶干),阿里巴巴高级开发工程师整理 | 张壮壮(Flink 社区志愿者) 摘要:本文根据 Apache Flink 系列直播整理而成,由阿里巴巴高级开发工程师唐云(茶干)分享。主要内容如下: 容器管理系统的演变Flink on K8S introFlink on K8S实战分享DemoTips:点击下方可查看更多 1.10 系列直播视频~ 1.10系列直播: https://ververica.cn/develope... 本文第一部分将简明扼要地介绍容器管理系统的演变;第二部分是 Flink on K8S 简介,包括集群的部署模式调度原理等等;第三部分是我们这一年以来关于 Flink on K8S 的实战经验分享,介绍我们遇到的问题、踩过的坑;最后一部分是 Demo,将手把手演示集群部署、任务提交等等。 容器管理系统的演变 首先是以一个 Kubernetes 非内核开发人员的角度去探讨其和 YARN 之间的关系。众所周知,Apache Hadoop YARN 可能是在国内用途最广的一个调度系统,主要原因在于 Hadoop HDFS 在国内或者是在整个大数据业界,是一个使用最广泛的存储系统。因此,基于其上的 YARN 也自然而然成为了一个广为使用的一个调度系统,包括早期的 Hadoop MapReduce。随着 YARN 2.0 之后 Framework 的开放,Spark on YARN 以及 Flink on YARN 也可以在 YARN 上进行调度。 当然 YARN 本身也存在一定的局限性。 如资源隔离,因为 YARN 是以 Java 为基础开发的,所以它很多资源方面的隔离有一些受限。另外对 GPU 支持不够,当然现在的 YARN 3.0 已经对 GPU 的调度和管理有一定支持,但之前版本对GPU 支持不是很好。所以在 Apache 基金会之外,CNCF 基金会基于 Native Cloud 调度的 Kubernetes 出现了。 ...

June 10, 2020 · 6 min · jiezi

如何从-0-到-1-参与-Flink-社区

整理:许世伟、秦佳奇(Flink 社区志愿者)校对:秦佳奇、许世伟(Flink 社区志愿者) 摘要:本文根据 Apache Flink 系列直播整理而成,由 Apache Flink Committer,阿里巴巴技术专家付典分享。主要内容如下: 参与开源社区的意义参与开源社区的原则如何参与 Flink 社区如何提交第一个 PRTips:点击下方链接可回顾更多社区成长类教程~ 社区成长: https://ververica.cn/develope...本文首先介绍为何要参与开源社区以及在参与开源社区的过程中需要注意什么,然后重点介绍如何参与 Flink 社区以及在社区里面提交 PR 的整个流程。 一、参与开源社区的意义 目前很多大公司都纷纷拥抱开源,从最初只是开始参与开源社区,到近年科技巨头们又陆续将自己的一些项目开源化。作为一个码农来说,参与开源社区肯定对于自己的职业发展是有着巨大好处的。 另外,参与开源社区,你可以和相关领域里面最优秀的人一起工作交流,快速的提升自己。不管在技术讨论、还是贡献代码方面,所有的过程都是公开的。参与到开源社区的讨论交流中,我相信你看到的不仅是最终代码所呈现出来的结果,而且还能了解到更多的设计思想,做到知其然,知其所以然。在社区中,每个人都希望将自己最好的一面给展示出来,这个无疑是促进自身不断进步的动力。 在享受开源社区带给我们好处的同时,我们也可以反哺开源社区。改了某几行代码,或者修正了文档上面某个小错误,这些都是在为开源社区贡献自己的力量。我们与社区之间要相互 build trust,可以从简单的贡献做起。不要因为对某个领域不熟悉或者说贡献太小而有放弃的想法,这是不太对的。 当我们为开源社区做的贡献足够多之后,可能会得到社区的认可,成为社区的 Contributor、Committer、PMC、Apache Member 等等,这是社区对我们个人能力的一种认可。 总结而言,参与开源的意义在于: 顺势而为无国界导师为世界带来微小而美好的变化业界身份证二、参与开源社区的原则参与开源社区,有两个基础且重要的原则需要大家注意: 公开沟通公开沟通是参与开源社区很重要的原则。任何问题及所有的讨论记录最好都公开化,做到可追溯,尽量避免私下讨论,这样才能更好地发挥社区的力量。 保持尊重在社区里面,要保持相互尊重。社区的贡献是以自愿为基本原则的,在社区的讨论中要避免情绪化,绝对禁止人身攻击。 三、如何参与 Flink 社区1.订阅邮件列表 关于邮件列表的更多具体信息:https://flink.apache.org/comm...参与 Flink 社区,先从订阅邮件列表入手,上面的表格是 Flink 社区常用的几个邮件及邮件用途信息,建议大家先订阅这几个邮件。订阅方式如下: 1.发送邮件到相应的邮件列表进行订阅 xxx-subscribe@flink.apache.org xxx-unsubscribe@flink.apache.org2.回复确认邮件2.参与用户邮件列表讨论■ 2.1 用户邮件提问注意事项事先搜索有无类似问题这几个地方可能有你想要的答案: Apache Pony: https://lists.apache.org/list... Nabble: http://apache-flink-user-mail... StackOverFlow: https://stackoverflow.com/que...问题描述应尽可能详细例如:使用的 Flink 版本、planner、和问题相关的配置、异常 log、复现问题的步骤;如果可能的话,提供可复现问题的最小功能代码(尽可能去除无关代码);尽量不要在邮件里直接贴图片,如果确实有需要,先将图片上传到外部网站,然后把图片链接贴到邮件里。 避免将 Flink 使用问题发到开发邮件尽量用英文在 user 邮件中讨论■ 2.2 用户邮件提问正反面示例反面示例❌ 缺少Flink版本❌ 缺少所用planner❌ 缺少示例代码 ...

June 10, 2020 · 2 min · jiezi

数仓系列-Flink-窗口的应用与实现

作者 | 张俊(OPPO大数据平台研发负责人)整理 | 祝尚(Flink 社区志愿者)校对 | 邹志业(Flink 社区志愿者) 摘要:本文根据 Apache Flink 系列直播整理而成,由 Apache Flink Contributor、OPPO 大数据平台研发负责人张俊老师分享。主要内容如下: 整体思路与学习路径应用场景与编程模型工作流程与实现机制Tips:点击「下方链接」可查看更多数仓系列直播视频~ <u>数仓系列直播: </u>https://ververica.cn/develope...整体思路与学习路径 当我们碰到一项新的技术时,我们应该怎样去学习并应用它呢?在我个人看来,有这样一个学习的路径,应该把它拆成应用和实现两块。首先应该从它的应用入手,然后再深入它的实现。 应用主要分为三个部分,首先应该了解它的应用场景,比如窗口的一些使用场景。然后,进一步地我们去了解它的编程接口,最后再深入了解它的一些抽象概念。因为一个框架或一项技术,肯定有它的编程接口和抽象概念来组成它的编程模型。我们可以通过查看文档的方式来熟悉它的应用。在对应用这三个部分有了初步的了解后,我们就可以通过阅读代码的方式去了解它的一些实现了。 实现部分也分三个阶段,首先从工作流程开始,可以通过 API 层面不断的下钻来了解它的工作流程。接下来是它整体的设计模式,通常对一些框架来说,如果能构建一个比较成熟的生态,一定是在设计模式上有一些独特的地方,使其有一个比较好的扩展性。最后是它的数据结构和算法,因为为了能够处理海量数据并达到高性能,它的数据结构和算法一定有独到之处。我们可以做些深入了解。 以上大概是我们学习的一个路径。从实现的角度可以反哺到应用上来,通常在应用当中,刚接触某个概念的时候会有一些疑惑。当我们对实现有一些了解之后,应用中的这些疑惑就会迎刃而解。 为什么要关心实现举个例子: 看了这个例子我们可能会有些疑惑: ReduceFunction 为什么不用计算每个 key 的聚合值?当 key 基数很大时,如何有效地触发每个 key 窗口计算?窗口计算的中间结果如何存储,何时被清理?窗口计算如何容忍 late data ?当你了解了实现部分再回来看应用这部分,可能就有种醍醐灌顶的感觉。 应用场景与编程模型实时数仓的典型架构 ■ 第一种最简单架构,ODS 层的 Kafka 数据经过 Flink 的 ETL 处理后写入 DW 层的 Kafka,再通过 Flink 聚合写入 ADS 层的 MySQL 中,做这样一个实时报表展现。 缺点:由于 MySQL 存储数据有限,所以聚合的时间粒度不能太细,维度组合不能太多。 ■ 第二种架构相对于第一种引入了 OLAP 引擎,同时也不用 Flink 来做聚合,通过 Druid 的 Rollup 来做聚合。 ...

June 10, 2020 · 3 min · jiezi

直播-阿里快手Databricks网易云音乐国内外大数据大佬齐聚一堂要聊啥

一线开发者同学一直面临着巨大的学习压力,除了需要解决业务上线后日常神出鬼没的bug与难题,还得面对开源软件不断发版更新导致的措手不及。 <p style="text-align:center">于是<p style="text-align:center">黑眼圈日益浓重稀疏的头发间距更大皮肤越来越干燥最后直接躺平</p> <p style="text-align:center">“实在是学不动了!!!”</p> 但是,如果每次发新版的软件都能帮你圈一下重点,再搭配一个详细解读,把新增功能、重大变更、整体优势都一一讲解,这种体验会不会很棒? 6月14日,阿里巴巴计算平台事业部联合阿里云开发者社区共同举办的大数据+AI Meetup 系列第一季即将重磅开启,此次 Meetup 邀请了来自阿里巴巴、Databricks、快手、网易云音乐等国内外多位技术专家齐聚一堂,与你探讨大数据及AI领域的热门话题! Meetup 亮点Flink、Spark、Alink 等大数据热门开源软件核心开发者帮你圈出最新版本重点实时数仓、数据湖、HSAP 架构能干啥一次讲清楚更有一线生产环境实战,春晚快手项目、网易云音乐 Flink + Kafka 落地实践的独家宝贵经验分享<p style="text-align:center">▼ Meetup 完整议程 ▼</p><p style="text-align:center"></p> 本文将分享此次 Meetup 上午半场3位资深技术专家的详细主题简介。 01 深入研究 Apache Spark 3.0 的新功能李潇 | Databricks Spark 研发部主管 演讲简介:Apache Spark 3.0旨在实现更快、更轻松、更智能的目标,本次发布提供了3000多种已解决的JIRA。涵盖以下功能: accelerator-aware scheduling, adaptive query execution, dynamic partition pruning, join hints, new query explain, better ANSI compliance, observable metrics, new UI for structured streaming, new built-in functions, new unified interface for Pandas UDF, and various enhancements in the built-in data sources [e.g., parquet, ORC and JDBC]. ...

June 10, 2020 · 1 min · jiezi

一文详解Flink-ExactlyOnce

前言Flink的 ”精确一次“ 处理语义是,Flink提供了一个强大的的语义保证,也就是说在任何情况下都能保证数据对应用的效果只有一次,不会多也不会少。 那么Flink是如何实现”端到端的精确一次处理“语义的呢?其实做到端到端的精确一次处理主要考虑两个方面: 怎么保证数据不丢失怎么保证数据不重复背景通常情况下,流式计算系统都会为用户提供数据处理的可靠模式功能,用来表明在实际生产运行中会对数据处理做哪些保障。一般来说,流处理引擎通常为用户的应用程序提供三种数据处理语义:最多一次,至少一次和精确一次。 最多一次(At-most-Once):这种语义理解起来很简单,用户的数据只会被处理一次,不管成功还是失败,不会重试也不会重发。至少一次(At-least-Once):这种语义下,系统会保证数据或事件至少被处理一次。如果发生错误或者丢失,那么会从源头重新发送一条然后进入处理系统。所以同一个事件或者消息会被处理很多次。精确一次(Exactly-Once):表示每一条数据只会被精确地处理一次,不多也不少。Exactly-Once是Flink,Spark等流处理系统的核心特性之一,这种语义会保证每一条消息只被流处理系统处理一次。”精确一次“语义是Flink 1.4.0版本引入的一个重要特性,而且,Flink号称支持”端到端的精确一次“语义。这里解释一下”端到端的精确一次“,它指的是Flink应用从Source端开始到Sink端结束,数据必须经过的起始点和结束点。Flink自身是无法保证外部系统”精确一次“语义的,所以Flink若要实现所谓”端到端的精确一次“的要求,那么外部系统必须支持”精确一次“语义,然后借助Flink提供的分布式快照和两阶段提交才能实现。 分布式快照机制Flink提供了失败恢复的容错机制,而这个容错机制的核心就是持续创建分布式数据流的快照来实现,这也为了数据不丢失提供了基础保障。 同Spark相比,Spark仅仅是针对Driver的故障恢复Checkpoint。而Flink的快照可以到算子级别,并且对全局数据也可以做快照。BarrierFlink分布式快照的核心元素之一是Barrier(数据栅栏),可以把Barrier简单理解成为一个标记,该标记是严格有序的,并且随着数据流往下流动。每个Barrier都带有自己的ID,Barrier极其轻量,并不会干扰正常的数据处理。 如上图所示,假如我们有一个从左向右流动的数据流,Flink会依次生成snapshot 1,snapshot 2,snapshot 3....Flink中有一个专门的”协调者“负责收集每个snapshot的位置信息,这个协调者也是高可用的。 Barrier会随着正常数据继续往下流动,每当遇到一个算子,算子会插入一个标识,这个标识的插入时间是上游所有的输入流都接受到了snapshot n。与此同时,当我们sink算子接收到所有上游流发送的Barrier时,那么就表明这一批数据处理完毕,Flink会向协调者发送确认消息,表明当前snapshot n完成了。当所有sink算子都确认这批数据成功处理后,那么本次的snapshot被标识完成。这里就会有一个问题,因为Flink运行在分布式环境中,一个operator的上游会有很多流,每个流的barrier n到达的时间不一致怎么办?这里Flink采取的措施是:快流等慢流 当其中一个流到的早,其他流到的晚。当第一个barrier n到来后,当前的operator会继续等待其他流的barrier n。直到所有barrier n到来后,operator才会把所有的数据向下发送。异步和增量按照上面介绍的机制,每次把快照存储到我们的状态后端时,如果同步进行就会阻塞正常任务,从而引入延迟。因此Flink在做快照存储的时候,可采用异步方式。 此外,由于checkpoint是一个全局状态,用户保存的状态可能非常大,多数达G或者T级别。在这种情况下,checkpoint的创建会非常慢,而且执行时占用的资源也比较多,因此Flink提出了增量快照,也就是说,每次都是进行的全量checkpoint,是基于上次进行更新的。两阶段提交上文提到基于checkpoint的快照操作,快照机制能够保证作业出现fail-over后可以从最新的快照进行恢复,即分布式快照机制可以保证flink系统内部的”精确一次“处理。但是我们实际生产系统中,Flink会对接各种各样的外部系统,比如kafka,HDFS等,一旦Flink作业出现失败,作业会重新消费旧数据,这个时候就会出现重新消费的情况,也就是重复消费。 针对这种情况,Flink在1.4版本引入了一个很重要得功能:两阶段提交,也即是TwoPhaseCommitSinkFunction。两阶段搭配特定得source和sink(特别是0.11版本kafka)使得”精确一次处理语义“成为可能。 在Flink中两阶段提交的实现方式被封装到TwoPhaseCommitSinkFunction这个抽象类中,我们只需要实现其中的beginTransaction,preCommit,commit,abort四个方法就可实现”精确一次“的处理语义,实现的方式可以在官网中查到。 beginTransaction,在开启事务之前,我们在目标文件系统的临时目录中创捷一个临时文件,后面在处理数据时将数据写入此文件。preCommit,在预提交阶段,刷写(flush)文件,然后关闭文件,之后就不能再写入文件了。我们还将为属于下一个检查点的任何后续写入启动新事务。commit,在提交阶段,我们将预提交的文件原子性的移动到真正的目标目录中,这里会增加输出数据可见性的延迟abort,在中止阶段,删除临时文件。 如上图所示,Kafka-Flink-Kafka案例实现”端到端精确一次“语义的过程,整个过程包括: 从kafka读取数据窗口聚合操作将数据写回kafka整个过程可以总结为下面四个阶段: 一旦Flink开始做checkpoint操作,那么就会pre-commit阶段,同时Flink JobManger会将检查点Barrier注入数据流中;当所有的Barrier在算子中成功进行一遍传递,并完成快照,则pre-commit阶段完成。等所有算子完成”预提交“,就会发起一个”提交“的动作,但是任何一个”预提交“失败都会导致Flink回滚到最近的checkpoint;pre-commit完成,必须要确保commit也要成功,上图中的Sink Operators和Kafka Sink会共同来保证。现状目前Flink支持的精确一次Source列表如下表所示,可以使用对应的connector来实现对应语义要求: 数据源语义保证备注Apache Kafkaexactly once需要对应的kafka版本AWS Kinesis Streamsexactly once RabbitMQat most once(v 0.10)/exactly once(v 1.0) Twitter Streamingat most once Collectionsexactly once Filesexactly once Socketsat most once 如果需要实现真正的”端到端精确一次语义“,则需要sink的配合。目前Flink支持的列表如下表所示: 写入目标语义保证备注HDFS rolling sinkexactly once依赖Hadoop版本Elasticsearchat least once kafka producerat least once/exactly once需要kafka 0.11及以上Cassandra sinkat least once/exactly once幂等更新AWS Kinesis Streamsat least once Flie sinksat least once Sockets sinksat least once Standard outputat least once Redis sinkat least once 总结由于强大的异步快照机制和两阶段提交,Flink实现了”端到端的精确一次语义“,在特定的业务场景下十分重要,我们在进行业务开发需要语义保证时,要十分熟悉目前Flink支持的语义特性。 ...

June 10, 2020 · 1 min · jiezi

使用mvn命令创建Flink-Maven项目

1.使用命令行创建Flink Maven Quickstart Scala项目 mvn archetype:generate \ -DarchetypeGroupId=org.apache.flink \ -DarchetypeArtifactId=flink-quickstart-scala \ -DarchetypeVersion=1.10.0 \ -DgroupId=org.apache.flink.quickstart \ -DartifactId=flink-scala-project \ -Dversion=0.1 \ -Dpackage=org.apache.flink.quickstart \ -DinteractiveMode=false2.pom.xml文件内容 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.apache.flink.quickstart</groupId> <artifactId>flink-scala-project</artifactId> <version>0.1</version> <packaging>jar</packaging> <name>Flink Quickstart Job</name> <url>http://www.myorganization.org</url> <repositories> <repository> <id>apache.snapshots</id> <name>Apache Development Snapshot Repository</name> <url>https://repository.apache.org/content/repositories/snapshots/</url> <releases> <enabled>false</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <flink.version>1.10.0</flink.version> <scala.binary.version>2.11</scala.binary.version> <scala.version>2.11.12</scala.version> </properties> <dependencies> <!-- Apache Flink dependencies --> <!-- These dependencies are provided, because they should not be packaged into the JAR file. --> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-scala_${scala.binary.version}</artifactId> <version>${flink.version}</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-streaming-scala_${scala.binary.version}</artifactId> <version>${flink.version}</version> <scope>provided</scope> </dependency> <!-- Scala Library, provided by Flink as well. --> <dependency> <groupId>org.scala-lang</groupId> <artifactId>scala-library</artifactId> <version>${scala.version}</version> <scope>provided</scope> </dependency> <!-- Add connector dependencies here. They must be in the default scope (compile). --> <!-- Example: <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka-0.10_${scala.binary.version}</artifactId> <version>${flink.version}</version> </dependency> --> <!-- Add logging framework, to produce console output when running in the IDE. --> <!-- These dependencies are excluded from the application JAR by default. --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.7.7</version> <scope>runtime</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> <scope>runtime</scope> </dependency> </dependencies> <build> <plugins> <!-- We use the maven-shade plugin to create a fat jar that contains all necessary dependencies. --> <!-- Change the value of <mainClass>...</mainClass> if your program entry point changes. --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.1.1</version> <executions> <!-- Run shade goal on package phase --> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <excludes> <exclude>org.apache.flink:force-shading</exclude> <exclude>com.google.code.findbugs:jsr305</exclude> <exclude>org.slf4j:*</exclude> <exclude>log4j:*</exclude> </excludes> </artifactSet> <filters> <filter> <!-- Do not copy the signatures in the META-INF folder. Otherwise, this might cause SecurityExceptions when using the JAR. --> <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>org.apache.flink.quickstart.StreamingJob</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin> <!-- Java Compiler --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.1</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> <!-- Scala Compiler --> <plugin> <groupId>net.alchim31.maven</groupId> <artifactId>scala-maven-plugin</artifactId> <version>3.2.2</version> <executions> <execution> <goals> <goal>compile</goal> <goal>testCompile</goal> </goals> </execution> </executions> <configuration> <args> <arg>-nobootcp</arg> </args> </configuration> </plugin> <!-- Eclipse Scala Integration --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-eclipse-plugin</artifactId> <version>2.8</version> <configuration> <downloadSources>true</downloadSources> <projectnatures> <projectnature>org.scala-ide.sdt.core.scalanature</projectnature> <projectnature>org.eclipse.jdt.core.javanature</projectnature> </projectnatures> <buildcommands> <buildcommand>org.scala-ide.sdt.core.scalabuilder</buildcommand> </buildcommands> <classpathContainers> <classpathContainer>org.scala-ide.sdt.launching.SCALA_CONTAINER</classpathContainer> <classpathContainer>org.eclipse.jdt.launching.JRE_CONTAINER</classpathContainer> </classpathContainers> <excludes> <exclude>org.scala-lang:scala-library</exclude> <exclude>org.scala-lang:scala-compiler</exclude> </excludes> <sourceIncludes> <sourceInclude>**/*.scala</sourceInclude> <sourceInclude>**/*.java</sourceInclude> </sourceIncludes> </configuration> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.7</version> <executions> <!-- Add src/main/scala to eclipse build path --> <execution> <id>add-source</id> <phase>generate-sources</phase> <goals> <goal>add-source</goal> </goals> <configuration> <sources> <source>src/main/scala</source> </sources> </configuration> </execution> <!-- Add src/test/scala to eclipse build path --> <execution> <id>add-test-source</id> <phase>generate-test-sources</phase> <goals> <goal>add-test-source</goal> </goals> <configuration> <sources> <source>src/test/scala</source> </sources> </configuration> </execution> </executions> </plugin> </plugins> </build></project>3.使用”胖jar“打包 ...

June 6, 2020 · 2 min · jiezi

这场大数据AI-Meetup一次性安排了大数据当下热门话题

6月14日,阿里巴巴计算平台事业部与阿里云开发者社区共同举办的大数据+AI Meetup 系列第一季即将重磅开启,此次 Meetup 邀请了来自阿里巴巴、Databricks、快手、网易云音乐的7位技术专家,集中解读大数据当前热门话题!近年来,随着工业界多年的努力以及新兴技术的不断涌现,数据规模庞大的问题已逐步得到解决,而数据处理的时效性、数据价值的挖掘正成为企业及开发者面临的新的巨大挑战。也因此,大数据计算引擎、AI、数据仓库、数据湖等成为当前无可争议的热门话题。 当前大数据计算引擎各有千秋,如何选择适合自己的?数据仓库、数据湖、HSAP 架构,它们究竟能解决什么问题?机器学习平台那么多,好用的有哪些? 6月14日,阿里巴巴计算平台事业部与阿里云开发者社区共同举办的大数据+AI Meetup 系列第一季即将重磅开启,此次 Meetup 邀请了来自阿里巴巴、Databricks、快手、网易云音乐的7位技术专家,集中解读大数据当前热门话题! <p style="text-align:center">▼ 活动亮点 ▼</p> <p style="text-align:center">> 超豪华嘉宾阵容!多位资深技术专家在线分享对行业趋势的洞察!</p> <p style="text-align:center">> 极丰富干货分享!集结大数据热门议题,一次看完:数据处理、数仓、数据湖、AI 等技术实践与生产应用落地。</p> <p style="text-align:center">> 多种奖品拿到手软!直播间已准备超多精美礼品,现场送送送!预约直播并参与互动即有机会领走哦。</p> 本次 Meetup 您将了解: Spark 3.0 有哪些新功能从 Lambda 架构到 HSAP,数仓未来趋势如何流批一体机器学习算法平台 Alink 易用性的提升Flink + Kafka 在网易云音乐的落地实践数据湖如何解决数据实时入库问题2020 春晚活动中快手实时链路保障独家实践分享Flink 1.11 最新版本功能特性深度解读如何观看: 时间:6月14日 10:00 — 18:00直播预约链接:https://developer.aliyun.com/...报名方式:扫描下方二维码<p style="text-align:center"></p><p style="text-align:center">(扫码报名)</p> 《深入研究 Apache Spark 3.0 的新功能》李潇 | Databricks Spark 研发部主管 嘉宾简介: 李潇,就职于 Databricks,Spark 研发部主管,领导 Spark,Koalas,Databricks runtime,OEM 的研发团队。Apache Spark Committer、PMC 成员。2011 年从佛罗里达大学获得获得了博士学位。曾就职于 IBM,获发明大师称号(Master Inventor),是异步数据库复制和一致性验证的领域专家,发表专利十余篇。(Github: gatorsmile) ...

June 3, 2020 · 1 min · jiezi

Flink-Weekly-每周社区动态更新20200520

大家好,本文为 Flink Weekly 的第十六期,由王雷整理,张成 Review。本期主要内容包括:近期社区开发进展、邮件问题答疑、Flink 最新社区动态及技术文章推荐等。 Flink 开发进展1.Release■ Piotr Nowojski 宣布 release-1.11 分支冻结。 [1]http://apache-flink-mailing-l... ■ 1.10.1 已成功发版,发版日志见下链接。 [2]https://issues.apache.org/jir... ■ 1.10.1 发版后,Seth Wiesman 发现 FLINK-16684 修改了 StreamingFileSink (@PublicEvolving) 的 API,导致 1.10.0 和 1.10.1 之间存在二进制不兼容问题。 [3]http://apache-flink-mailing-l... 2.Dev■ 当用户使用 per-job 模式提交任务时,当前的 History Server 无法聚合的显示这些任务。Gyula 对 History Server 进行了修改,实现了一个可以聚合不同集群任务的看板。 [4]http://apache-flink-mailing-l... 3.FLIP■ [Runtime] Aljoscha Krettek 宣布 FLIP-126 投票通过,FLIP-126 旨在对 Watermark Assigners 进行重构。 [5]http://apache-flink-mailing-l... 4.Discuss■ [Config] Stephan Ewen 发起了将 state.backend.fs.memory-threshold 的默认值从 1K 提升到 100K 的讨论,目的是减少小文件。大家对该改动可能导致 state 变大,从而导致 OOM 的问题进行了讨论。 ...

June 3, 2020 · 2 min · jiezi

Flink-完美搭档数据存储层上的-Pravega

本文将从大数据架构变迁历史,Pravega 简介,Pravega 进阶特性以及车联网使用场景这四个方面介绍 Pravega,重点介绍 DellEMC 为何要研发 Pravega,Pravega 解决了大数据处理平台的哪些痛点以及与 Flink 结合会碰撞出怎样的火花。作者 | 滕昱 DellEMC 研发总监整理 | 赵海凯 DellEMC 实习生 本文将从大数据架构变迁历史,Pravega 简介,Pravega 进阶特性以及车联网使用场景这四个方面介绍 Pravega,重点介绍 DellEMC 为何要研发 Pravega,Pravega 解决了大数据处理平台的哪些痛点以及与 Flink 结合会碰撞出怎样的火花。 大数据架构变迁Lambda 架构之痛 如何有效地提取和提供数据,是大数据处理应用架构是否成功的关键之处。由于处理速度和频率的不同,数据的摄取需要通过两种策略来进行。上图就是典型的 Lambda架构:把大数据处理架构分为批处理和实时流处理两套独立的计算基础架构。 对于实时处理来说,来自传感器,移动设备或者应用日志的数据通常写入消息队列系统(如 Kafka), 消息队列负责为流处理应用提供数据的临时缓冲。然后再使用 Spark Streaming 从 Kafka 中读取数据做实时的流计算。但由于 Kafka 不会一直保存历史数据,因此如果用户的商业逻辑是结合历史数据和实时数据同时做分析,那么这条流水线实际上是没有办法完成的。因此为了补偿,需要额外开辟一条批处理的流水线,即图中" Batch "部分。 对于批处理这条流水线来说,集合了非常多的的开源大数据组件如 ElasticSearch, Amazon S3, HDFS, Cassandra 以及 Spark 等。主要计算逻辑是是通过 Spark 来实现大规模的 Map-Reduce 操作,优点在于结果比较精确,因为可以结合所有历史数据来进行计算分析,缺点在于延迟会比较大。 这套经典的大数据处理架构可以总结出三个问题: 两条流水线处理的延迟相差较大,无法同时结合两条流水线进行迅速的聚合操作,同时结合历史数据和实时数据的处理性能低下。数据存储成本大。而在上图的架构中,相同的数据会在多个存储组件中都存在一份或多份拷贝,数据的冗余无疑会大大增加企业客户的成本。并且开源存储的数据容错和持久化可靠性一直也是值得商榷的地方,对于数据安全敏感的企业用户来说,需要严格保证数据的不丢失。重复开发。同样的处理流程被两条流水线进行了两次,相同的数据仅仅因为处理时间不同而要在不同的框架内分别计算一次,无疑会增加数据开发者重复开发的负担。流式存储的特点在正式介绍 Pravega 之前,首先简单谈谈流式数据存储的一些特点。 如果我们想要统一流批处理的大数据处理架构,其实对存储有混合的要求。 对于来自序列旧部分的历史数据,需要提供高吞吐的读性能,即 catch-up read对于来自序列新部分的实时数据,需要提供低延迟的 append-only 尾写 tailing write 以及尾读 tailing read重构的流式存储架构 ...

June 3, 2020 · 3 min · jiezi

Flink-110-SQLHiveCatalog-与事件时间整合示例

Flink 1.10 与 1.9 相比又是个创新版本,在我们感兴趣的很多方面都有改进,特别是 Flink SQL。本文用根据埋点日志计算 PV、UV 的简单示例来体验 Flink 1.10 的两个重要新特性: 一是 SQL DDL 对事件时间的支持;二是 Hive Metastore 作为 Flink 的元数据存储(即 HiveCatalog)。 这两点将会为我们构建实时数仓提供很大的便利。 添加依赖项示例采用 Hive 版本为 1.1.0,Kafka 版本为 0.11.0.2。 要使 Flink 与 Hive 集成以使用 HiveCatalog,需要先将以下 JAR 包放在 ${FLINK_HOME}/lib 目录下。 flink-connector-hive_2.11-1.10.0.jarflink-shaded-hadoop-2-uber-2.6.5-8.0.jarhive-metastore-1.1.0.jarhive-exec-1.1.0.jarlibfb303-0.9.2.jar后三个 JAR 包都是 Hive 自带的,可以在 ${HIVE_HOME}/lib 目录下找到。前两个可以通过阿里云 Maven 搜索 GAV 找到并手动下载(groupId 都是org.apache.flink)。 再在 pom.xml 内添加相关的 Maven 依赖。 Maven 下载: https://maven.aliyun.com/mvn/...<properties> <scala.bin.version>2.11</scala.bin.version> <flink.version>1.10.0</flink.version> <hive.version>1.1.0</hive.version> </properties> <dependencies> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-scala_${scala.bin.version}</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-scala-bridge_${scala.bin.version}</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-planner-blink_${scala.bin.version}</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-sql-connector-kafka-0.11_${scala.bin.version}</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-hive_${scala.bin.version}</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-json</artifactId> <version>${flink.version}</version> </dependency> <dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-exec</artifactId> <version>${hive.version}</version> </dependency> </dependencies>最后,找到 Hive 的配置文件 hive-site.xml,准备工作就完成了。 ...

June 3, 2020 · 3 min · jiezi

深度解读-Flink-111流批一体-Hive-数仓

Flink 1.11 中流计算结合 Hive 批处理数仓,给离线数仓带来 Flink 流处理实时且 Exactly-once 的能力。另外,Flink 1.11 完善了 Flink 自身的 Filesystem connector,大大提高了 Flink 的易用性。Flink 1.11 features 已经冻结,流批一体在新版中是浓墨重彩的一笔,在此提前对 Flink 1.11 中流批一体方面的改善进行深度解读,大家可期待正式版本的发布。 首先恭喜 Table/SQL 的 blink planner 成为默认 Planner,撒花、撒花。 Flink 1.11 中流计算结合 Hive 批处理数仓,给离线数仓带来 Flink 流处理实时且 Exactly-once 的能力。另外,Flink 1.11 完善了 Flink 自身的 Filesystem connector,大大提高了 Flink 的易用性。 数仓架构离线数仓 传统的离线数仓是由 Hive 加上 HDFS 的方案,Hive 数仓有着成熟和稳定的大数据分析能力,结合调度和上下游工具,构建一个完整的数据处理分析平台,流程如下: Flume 把数据导入 Hive 数仓调度工具,调度 ETL 作业进行数据处理在 Hive 数仓的表上,可以进行灵活的 Ad-hoc 查询调度工具,调度聚合作业输出到BI层的数据库中这个流程下的问题是: 导入过程不够灵活,这应该是一个灵活 SQL 流计算的过程基于调度作业的级联计算,实时性太差ETL 不能有流式的增量计算实时数仓针对离线数仓的特点,随着实时计算的流行,越来越多的公司引入实时数仓,实时数仓基于 Kafka + Flink streaming,定义全流程的流计算作业,有着秒级甚至毫秒的实时性。 ...

June 3, 2020 · 4 min · jiezi

一文了解Flink-State-Backends

当我们使用Flink进行流式计算时,通常会产生各种形式的中间结果,我们称之为State。有状态产生,就必然涉及到状态的存储,那么Flink中定义了哪些形式的状态存储呢,下面一一给大家介绍一下。State BackendsMemoryStateBackendFsStateBackendRocksDBStateBackendMemoryStateBackend顾名思义,MemoryStateBackend状态后端是将状态数据以Object的形式存放于Java Heap中。 当执行检查点时,MemoryStateBackend会为当前的状态生成snapshot,然后将快照信息作为检查点ack消息的一部分发送给JobManager(master节点),JobManager会将收到的快照数据存放于自己的堆内存中。 MemoryStateBackend默认采用异步snapshots的方式来避免数据流管道阻塞,这是一种比较推荐的方式。当然,我们也可以通过配置来禁用这种方式。 new MemoryStateBackend(MAX_MEM_STATE_SIZE, false); // MAX_MEM_STATE_SIZE表示最大允许的状态容量MemoryStateBackend的使用限制 每个状态的大小默认限制为5MB,可以通过构造函数设置状态大小不管如何配置最大状态大小,都不能超过akka帧大小聚合状态大小必须合乎JobManager的内存大小基于以上这些限制,我们通常建议在如下场景中使用MemoryStateBackend: 本地开发调试无状态作业或者保存少量状态的作业此外,官方建议将托管内存(Managed Memory)设置为0,这样可以确保为JVM上的用户程序分配最大的内存。 FsStateBackendFsStateBackend需要配置一个文件系统URL,如:“hdfs://namenode:40010/flink/checkpoints” or “file:///data/flink/checkpoints”。FsStateBackend将作业执行过程中的动态数据存放在TaskManager的内存当中,当执行检查点时,状态快照数据会被存储在配置的文件系统目录中,还有一部分metadata数据会被存储在JobManager的内存当中。 同样的,FsStateBackend也是默认采用异步snapshot的方式。我们可以通过实例化FsStateBackend来更改快照生成方式。 new FsStateBackend(path, false);官方建议在以下场景中使用FsStateBackend: 作业中包含大状态、长窗口以及大键值状态高可用应用场景同样官方建议将托管内存(Managed Memory)设置为0,这样可以确保为JVM上的用户程序分配最大的内存。 RocksDBStateBackendRocksDBStateBackend同样需要配置一个文件系统URL:“hdfs://namenode:40010/flink/checkpoints” or “file:///data/flink/checkpoints”。 RocksDBStateBackend将作业执行过程中的动态数据存放在RocksDB数据库中,RocksDB数据库默认存储在TaskManager的数据目录下。当执行检查点时,整个RocksDB数据库会被存档到配置的文件系统目录下。只有少量的metadata数据存储在JobManager的内存当中。 同样地,RocksDBStateBackend通常也采用异步snapshot的方式。 使用上的一些限制: 由于RocksDB的JNI bridge API是基于byte[]的,因此可支持的最大key值大小是2^31 byte。这个限制一般情况下不会有问题,但当作业中的状态是基于不断地merge操作生成时,很容易超过这个大小限制,这个时候就会出现检索失败的错误。官方建议在以下场景中使用RocksDBStateBackend: 作业中包含大状态、长窗口以及大键值状态高可用应用场景乍一看,好像跟FsStateBackend没啥区别?其实不是,这里需要注意的是,当我们使用RocksDBStateBackend作为状态存储时,可以维护的状态大小仅仅受限于程序可访问的磁盘空间大小。这就使得我们可以维护比FsStateBackend更大的作业状态。 当然,这也带来一个问题:由于与状态后端之间的所有读写操作都要经过de-/serialization,因此这种方式牺牲了一定的吞吐量。 总结MemoryStateBackend、FsStateBackend都是基于堆的状态存储RocksDBStateBackend是目前唯一的一种支持增量checkpoint的状态后端

June 2, 2020 · 1 min · jiezi

flink-DataStream算子中如何实时更新变量

1.问题描述,如下图:在写机器学习算法时遇到这样一个场景,在第一个map需要用到变量currentCenter,然后我输出的结果需要更新currentCenter(最后一个map),但是没办法更新。因为map函数是并行的,传入的currentCenter实际上是一个复制品,在map中修改currentCenter复制品是不会改变原变量的。2.方案(1)数据库/文件系统使用外部数据库/文件系统,在第一个map函数不断的读取外部数据库/文件系统数据,第二个map函数中不断更新外部数据库/文件数据,可以达到实时动态更新变量的效果。但这样的缺点就是频繁的io开销,相当于将flink退化成了mapreduce的计算模型。pass3.方案(2)迭代流+广播流这里有个很明显的特征,就是我需要在下游的流中更新到上游的流数据,这不就是迭代流吗?不熟悉迭代流的可以查一下官网或看一下我的示例:https://segmentfault.com/a/11...方向已经明确了,我需要对我的实时变量进行迭代流操作。还有一个问题就是我的实时变量是通过输入流的数据和实时变量计算得到的,所以这里就需要把我的迭代流广播到输入流计算,然后生成新的实时变量流继续迭代,大致的流程图如下:成功解决!还有在迭代流中还可以使用windows操作。4.方案(3)使用Flink的DataStreamUtils。实验未成功,成功的大佬分享一下!欢迎查看相关入门博客:https://segmentfault.com/a/11...

May 29, 2020 · 1 min · jiezi