3 天前 / 逗逗
摘要：本文由知乎技术平台负责人孙晓光分享，主要介绍知乎 Flink 数据集成平台建设实践。内容如下： 业务场景 历史设计 全面转向 Flink 后的设计 未来 Flink 应用场景的规划 Tips：点击文末「阅读原文」即可回顾作者原版分享视频～ 一、业务场景 很高兴和大家分享近期知乎以 Flink 为基础，重构上一代数据集成平台过程中的一些收获。数据集成平台作为连接各种异构数据的纽带，需要连接多种多样的存储系统。而不同的技术栈和不同的业务场景会对数据集成系统提出不同的设计要求。 我们首先来看一下在知乎内部数据集成的业务场景。
10 天前 / hivefans东杰
摘要：本文由同城艺龙大数据开发工程师张军分享，主要介绍同城艺龙 Flink 集成 Iceberg 的生产实践。内容包括： 背景及痛点 Flink + Iceberg 的落地 Iceberg优化实践 后续工作 总结 Tips：点击文末「阅读原文」可查看更多生产实践～ 一、背景及痛点 业务背景 同程艺龙是一个提供机票、住宿、交通等服务的在线旅游服务平台，目前我所在的部门属于公司的研发部门，主要职责是为公司内其他业务部门提供一些基础服务，我们的大数据系统主要承接的业务是部门内的一些大数据相关的数据统计、分析工作等。
30 天前 / 数栈DTinsightu580540
2 月 2 日，FlinkX 与 FlinkStreamSQL 系列课程第 11 期专场直播。第 11 讲由袋鼠云数栈技术研发团队工程师刘星（花名：吹雪）主讲，主题为《任务运维和数据指标相关的使用》。错过直播的朋友可以点击阅读原文或者钉钉扫描文末的二维码，回看直播。 1 实时开发常见问题 问 一个实时计算任务该分配多少资源？ 建议：一些简单 ETL 任务，并且源数据流量在一定范围内， tm 个数 1、全局并行度 1、内存 1G。
37 天前 / sjf0115
作者 | Robin 翻译 | 周凯波 Contentsquare 公司的 Robin 总结了他们将 Spark 任务迁移到 Flink 遇到的 10 个『陷阱』。对于第一次将 Flink 用于生产环境的用户来说，这些经验非常有参考意义。 采用新的框架总是会带来很多惊喜。当你花了几天时间去排查为什么服务运行异常，结果发现只是因为某个功能的用法不对或者缺少一些简单的配置。 在 Contentsquare[1]，我们需要不断升级数据处理任务，以满足越来越多的数据上的苛刻需求。这也是为什么我们决定将用于会话 [2]处理的小时级 Spark 任务迁移到 Flink[3]流服务。
43 天前 / 木小丰
611 次浏览一、背景 Flink 在处理流式任务的时候有很大的优势，其中 windows 等操作符可以很方便的完成聚合任务，但是 Flink 是一套独立的服务，业务流程中如果想使用需要将数据发到 kafka，用 Flink 处理完再发到 kafka，然后再做业务处理，流程很繁琐。 比如在业务代码中想要实现类似 Flink 的 window 按时间批量聚合功能，如果纯手动写代码比较繁琐，使用 Flink 又太重，这种场景下使用响应式编程 RxJava、Reactor 等的 window、buffer 操作符可以很方便的实现。
45 天前 / sjf0115
摘要：本文由快手实时计算负责人董亭亭分享，主要介绍快手基于 Flink 的持续优化与实践的介绍。内容包括： Flink 稳定性持续优化 Flink 任务启动优化 Flink SQL 实践与优化 未来的工作 Tips：点击文末「阅读原文」即可回顾作者原版分享视频～一、Flink 稳定性持续优化 第一部分是 Flink 稳定性的持续优化。该部分包括两个方面，第一个方面，主要介绍快手在 Flink Kafka Connector 方面做的一些高可用，是基于内部的双机房读或双机房写和一些容错的策略。第二部分关于 Flink 任务的故障恢复。我们在加速故障恢复方面做了一些优化工作。
46 天前 / sjf0115
本文属于 Flink 在生产环境的大规模 CPU 优化实战，大并发任务预计节省 30~50% 的 CPU 消耗。下文会详细分析优化相关的实现原理、问题定位以及优化过程。往往在做性能优化时就会发现：当已经定位到性能瓶颈时，很容易想到优化思路去解决或优化。但定位问题的过程其实是最难的，也就是找性能瓶颈的这个过程更具有意义。本文问题定位的过程以及用到的性能分析工具、命令可能对于广大的技术同学更有收益。 0、 结论 Flink 大并发任务（超过 500 并发）在使用 keyBy 或者 rebalance 的情况下，将 bufferTimeout 设置为 1s 可以节省 30~50% 的 CPU 消耗。
48 天前 / 木小丰
164 次浏览一、背景 Flink 在处理流式任务的时候有很大的优势，其中 windows 等操作符可以很方便的完成聚合任务，但是 Flink 是一套独立的服务，业务流程中如果想使用需要将数据发到 kafka，用 Flink 处理完再发到 kafka，然后再做业务处理，流程很繁琐。 比如在业务代码中想要实现类似 Flink 的 window 按时间批量聚合功能，如果纯手动写代码比较繁琐，使用 Flink 又太重，这种场景下使用响应式编程 RxJava、Reactor 等的 window、buffer 操作符可以很方便的实现。
57 天前 / sjf0115
在之前的文章中我们已经了解了 Flink 的窗口机制，并介绍了其中涉及的组件：WindowAssigner、WindowFunction、Trigger、Evictor。在Flink 窗口如何使用中我们知道窗口可以有不同类型的 Assigner。在指定 Assigner 后，我们需要在每个窗口上指定我们要执行的计算逻辑，这是窗口函数（Windows Function）的责任。一旦系统确定窗口准备好处理数据，窗口函数就会被调用来处理窗口中的每个元素。 窗口函数可以是 ReduceFunction，AggregateFunction 或者 ProcessWindowFunction。前两个函数执行效率更高，因为 Flink 可以在每个元素到达窗口时增量地进行聚合。
60 天前 / hivefans东杰
来源 |「Stream Processing with Apache Flink」 作者|Fabian Hueske and Vasiliki Kalavri 翻译|吴邪大数据 4 年从业经验，目前就职于广州一家互联网公司，负责大数据基础平台自研、离线计算 & 实时计算研究 校对 |gongyouliu 编辑 | auroral-L Apache Flink 是一个开源的分布式流处理引擎，为有状态数据流处理应用程序提供了丰富的 api 接口，以实现各种简单或复杂的计算功能。不仅如此，它能够高效地支持大规模有状态流应用程序运行，并保证了程序的容错性，在这一点上会比其他的流式计算引擎凸显更多优势。
63 天前 / sjf0115
之前看到群里好多同学提问： Flink 状态存在 heap 中，作业失败下次重启从 State 恢复，是不是数据就丢了？TM 本地状态恢复跟 Checkpoint 之间有什么关系？Operator State 是不是只能存在 heap 中？ 如果有类似的疑问，相信本文能让你彻底搞懂 Flink 的状态数据到底存到了哪里。想加群的小伙伴可以在公众号菜单栏右下角联系博主。 0、结论按照状态类型进行划分，State 分为 Operator State 和 KeyedState。 无论何种 StateBackend，Operator State 在运行期间全部存储在 TM 的内存中。Checkpoint 时，MemoryStateBackend 会将状态数据保存到 JM 的内存中。
65 天前 / 逗逗
一、简介 Flink 官网的自我介绍：Apache Flink — Stateful Computations over Data Streams，可以看出状态计算是 Flink 引以为豪的杀手锏。那什么是带状态的计算呢？简单说计算任务的结果不仅仅依赖于输入，还依赖于它的当前状态。 实时计算如果任务失败导致中间状态丢失，将是一个非常可怕的事情。 比如实时计算每天的 pv,uv 等指标，任务掉线后中间状态也丢失了，那只能从凌晨数据重新计算。 如果是有状态的计算大可不必担心，从任务掉线的时刻继续计算，妈妈再也不用担心我的任务掉线了。 下面介绍一下 Flink 如何实现状态计算和状态管理。
66 天前 / 逗逗
一、Flink 整体架构 Flink 集群整体遵循 Master ，Worker 这样的架构模式。JobManager 是管理节点，有以下几个职责：接受 application，包含 StreamGraph（DAG），JobGraph（优化过的）和 JAR，将 JobGraph 转换为 Execution Graph 申请资源，调度任务，执行任务，保存作业的元数据，如 Checkpoint 协调各个 Task 的 Checkpoint。TaskManager 是工作节点，负责数据交换，跑多个线程的 task，执行任务。Client 是客户端，接收用户提交的 jar 包，产生一个 JobGraph 对象，提交到 JobManager。