在 Flink 中，Source 代表从外部获取数据源，Transfromation 代表了对数据进行转换操作，Sink 代表将内部数据写到外部数据源
在这篇文章中我们将结合例子逐步讲解 Flink 是如何与 Kafka 工作来确保将 Kafka Topic 中的消息以 Exactly-Once 语义处理。
来自Flink Forward Berlin 2017的最受欢迎的会议是Robert Metzger的“坚持下去：如何可靠，高效地操作Apache Flink”。 Robert所涉及的主题之一是如何粗略地确定Apache Flink集群的大小。 Flink Forward的与会者提到他的群集大小调整指南对他们有帮助，因此我们将他的谈话部分转换为博客文章。 请享用！
Apache Kafka是一个分布式发布-订阅消息传递系统。 它最初由LinkedIn公司开发，LinkedIn于2010年贡献给了Apache基金会并成为顶级开源项目。Kafka用于构建实时数据管道和流式应用程序。它具有水平扩展性、容错性、极快的速度，目前也得到了广泛的应用。
表的输出，是通过将数据写入 TableSink 来实现的。TableSink 是一个通用接口，可以 支持不同的文件格式、存储数据库和消息队列。
作者介绍：董亭亭，快手大数据架构实时计算引擎团队负责人。目前负责 Flink 引擎在快手内的研发、应用以及周边子系统建设。2013 年毕业于大连理工大学，曾就职于奇虎 360、58 集团。主要研究领域包括：分布式计算、调度系统、分布式存储等系统。
《大数据面试题 V3.0》，这次不仅是之前自己收集的部分，还有就是把牛客上别人分享的经验贴给爬了，现在暂时做了个初步总结。
分区分配策略：保障每个消费者尽量能够均衡地消费分区的数据，不能出现某个消费者消费分区的数量特别多，某个消费者消费的分区特别少
在某些场景中，例如读取 compacted topic 或者输出（更新）聚合结果的时候，需要将 Kafka 消息记录的 key 当成主键处理，用来确定一条数据是应该作为插入、删除还是更新记录来处理。为了实现该功能，社区为 Kafka 专门新增了一个 upsert connector（upsert-kafka），该 connector 扩展自现有的 Kafka connector，工作在 upsert 模式（FLIP-149）下。新的 upsert-kafka connector 既可以作为 source 使用，也可以作为 sink 使用，并且提供了与现有的 kafka connector 相同的基本功能和持久性保证，因为两者之间复用了大部分代码。
Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。
Flink 是 stateful 计算引擎，不同于 Storm。在 Storm 这类无状态计算引擎中，并行的任务实例（通常一个任务实例运行在一个线程中）是不存储计算状态的，即使有一些运行时的程序元信息也是放在了像 ZooKeeper 这种第三方的高可用分布式协调者介质中。怎么理解这里的“无状态”呢？可以理解为流中的每个元素流过每个任务实例时，任务实例不会将此次处理的一些信息带到下一次处理元素中，即任务实例所在的线程是不存在记忆的。Flink 则相反，但是为了实现 stateful 需要付出非常大的代价，尤其是在分布式环境中，还要保证状态的全局一致性。就是说分布式在各个并行度线程中的任务实例所保存的状态必须是针对某个一致的语义平面上建立的，否则就无法保证在分布式环境中遇到故障后重启时恢复状态后的程序一致性了。
本文是关于如何在实时分析中使用云原生应用程序对股票数据进行连续 SQL 操作的教程。
在上一篇文章「checkpoint【1】」中，我们讨论过在2PC过程的每个阶段出现故障时Flink的处理方式：
CDC 是变更数据捕获（Change Data Capture）技术的缩写，它可以将源数据库（Source）的增量变动记录，同步到一个或多个数据目的（Sink）。在同步过程中，还可以对数据进行一定的处理，例如分组（GROUP BY）、多表的关联（JOIN）等。
面试题总结是一个长期工作，面试不停，这份面试题总结就不会停。以后会慢慢把Java相关的面试题、计算机网络等都加进来，其实这不仅仅是一份面试题，更是一份面试参考，让你熟悉面试题各种提问情况，当然，项目部分，就只能看自己了，毕竟每个人简历、实习、项目等都不一样。
基于 Hive 的离线数仓往往是企业大数据生产系统中不可缺少的一环。Hive 数仓有很高的成熟度和稳定性，但由于它是离线的，延时很大。在一些对延时要求比较高的场景，需要另外搭建基于 Flink 的实时数仓，将链路延时降低到秒级。但是一套离线数仓加一套实时数仓的架构会带来超过两倍的资源消耗，甚至导致重复开发。
最初，BIGO 的消息流平台主要采用开源 Kafka 作为数据支撑。随着数据规模日益增长，产品不断迭代，BIGO 消息流平台承载的数据规模出现了成倍增长，下游的在线模型训练、在线推荐、实时数据分析、实时数仓等业务对消息流平台的实时性和稳定性提出了更高的要求。开源的 Kafka 集群难以支撑海量数据处理场景，我们需要投入更多的人力去维护多个 Kafka 集群，这样成本会越来越高，主要体现在以下几个方面：
断点续传是指数据同步任务在运行过程中因各种原因导致任务失败，不需要重头同步数据，只需要从上次失败的位置继续同步即可，类似于下载文件时因网络原因失败，不需要重新下载文件，只需要继续下载就行，可以大大节省时间和计算资源。
Debezium 是一个分布式平台，它将现有的数据库转换为事件流，应用程序消费事件流，就可以知道数据库中的每一个行级更改，并立即做出响应。
顾名思义，生产者就是生产消息的组件，它的主要工作就是源源不断地生产出消息，然后发送给消息队列。生产者可以向消息队列发送各种类型的消息，如狭义的字符串消息，也可以发送二进制消息。生产者是消息队列的数据源，只有通过生产者持续不断地向消息队列发送消息，消息队列才能不断处理消息。
背景 Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用（可参考 Storm 的可靠性保证测试），有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。 而 Apache Flink（以下简称“Flink”）在近期倍受关注，具有高吞吐、低延迟、高可靠和精确计算等特性，对事件窗口有很好的支持，目前在美团点评实时计算业务中也已有一定应用。 为深
CDC 变更数据捕获技术可以将源数据库的增量变动记录，同步到一个或多个数据目的。本文基于腾讯云 Oceanus 提供的 Flink CDC 引擎，着重介绍 Flink 在变更数据捕获技术中的应用。 一、CDC 是什么？ CDC 是变更数据捕获（Change Data Capture）技术的缩写，它可以将源数据库（Source）的增量变动记录，同步到一个或多个数据目的（Sink）。在同步过程中，还可以对数据进行一定的处理，例如分组（GROUP BY）、多表的关联（JOIN）等。 例如对于电商平台，用户的订单
Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用，有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。
Flink 在1.4.0 版本引入『exactly-once』并号称支持『End-to-End Exactly-Once』“端到端的精确一次”语义。
在 Flink 社区中，最常被问到的问题之一是：在从开发到生产上线的过程中如何确定集群的大小。这个问题的标准答案显然是“视情况而定”，但这并非一个有用的答案。本文概述了一系列的相关问题，通过回答这些问题，或许你能得出一些数字作为指导和参考。
一、Hadoop 二、Hive 三、Spark 四、Kafka 五、HBase 六、Flink 七、数仓业务方面 八、算法
作者 | 陈航 BIGO 于 2014 年成立，是一家高速发展的科技公司。基于强大的音视频处理技术、全球音视频实时传输技术、人工智能技术、CDN 技术，BIGO 推出了一系列音视频类社交及内容产品，包括 Bigo Live（直播）和 Likee（短视频）等，在全球已拥有近 1 亿用户，产品及服务已覆盖超过 150 个国家和地区。 1挑战 最初，BIGO 的消息流平台主要采用开源 Kafka 作为数据支撑。随着数据规模日益增长，产品不断迭代，BIGO 消息流平台承载的数据规模出现了成倍增长，下游的在线模型训练
启动zk：nohup bin/zookeeper-server-start.sh config/zookeeper.properties &
1. 背景 Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用（可参考 Storm 的可靠性保证测试：https://tech.meituan.com/test-of-storms-reliability.html），有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。而 Apache Flink（以下简称“Flink”）在近期倍受关注，
来源:知乎(https://zhuanlan.zhihu.com/p/77677075)
摘要：小米业务线众多，从信息流，电商，广告到金融等覆盖了众多领域，小米流式平台为小米集团各业务提供一体化的流式数据解决方案，主要包括数据采集，数据集成和流式计算三个模块。目前每天数据量达到 1.2 万亿条，实时同步任务 1.5 万，实时计算的数据 1 万亿条。
Flink是使用Kafka链接计算任务,利用kafka的exactly once实现流计算的不重不丢,而Kafka 的 Exactly Once 语义是通过它的事务和生产幂等两个特性来共同实现的
作为全球新冠疫情数据的实时统计的权威，约翰斯—霍普金斯大学的实时数据一直是大家实时关注的，也是各大媒体的主要数据来源。在今天早上的相当一段长的时间，霍普金斯大学的全球疫情分布大屏中显示，全球确诊人数已经突破200万。
Flink内置了一些基本数据源和接收器，并且始终可用。该预定义的数据源包括文件，目录和插socket，并从集合和迭代器摄取数据。该预定义的数据接收器支持写入文件和标准输入输出及socket。
本文主要从大数据起源谈起，介绍了几种主要的大数据处理框架，包括其中的容错机制，实现细节及原理等。再主要介绍了使用storm进行大数据开发的具体过程，以及开发过程中遇到的坑和一些优化。以下内容基于本人上次部门内分享整理，去掉了一些业务性的内容，尽量给大家展现一些技术细节。
https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/connectors/index.html
Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用（可参考 Storm 的 可靠性保证测试），有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。而 Apache Flink（以下简称“Flink”）在近期倍受关注，具有高吞吐、低延迟、高可靠和精确计算等 特性，对事件窗口有很好的支持，目前在美团点评实时计算业务中也已有一定应用。 为深入熟悉了解 Flink 框架，验证其稳定性和可靠性，评估其实时处理性能，识别该体系中的 缺点，找到其性能瓶颈并进行优化，给用户提供最适合的实时计算引擎，我们以实践经验丰富 的 Storm 框架作为对照，进行了一系列实验测试 Flink 框架的性能，计算 Flink 作为确保“至 少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框 架选择、性能调优等决策及 Flink 平台的建设提出建议并提供数据支持，为后续的 SLA 建设提供一定参考。 Flink 与 Storm 两个框架对比：
表的输出，是通过将数据写入 TableSink 来实现的。TableSink 是一个通用接口，可以支持不同的文件格式、存储数据库和消息队列。
主要讲解了技术原理，入门与生产实践，主要功能：全增量一体化数据集成、实时数据入库入仓、最详细的教程。Flink CDC 是Apache Flink的一个重要组件，主要使用了CDC技术从各种数据库中获取变更流并接入到Flink中，Apache Flink作为一款非常优秀的流处理引擎，其SQL API又提供了强大的流式计算能力，因此结合Flink CDC能带来非常广阔的应用场景。例如，Flink CDC可以代替传统的Data X和Canal工具作为实时数据同步，将数据库的全量和增量数据同步到消息队列和数据仓库中。也可以做实时数据集成，将数据库数据实时入湖入仓。还可以做实时物化视图，通过SQL对数据做实时的关联、打宽、聚合，并将物化结果写入到数据湖仓中。
二、TwoPhaseCommitSinkFunction与FlinkKafkaProducer源码分析
最进再看官方flink提供的视频教程,发现入门版本因为时间关系都是基于1.7.x讲解的. 在实际操作中跟1.12.x版本还是有差距的, 所以整理一下从1.7 版本到1.12版本之间的相对大的变动. 做到在学习的过程中可以做到心里有数.
在上一期内容中，菌哥已经为大家介绍了电商用户行为数据分析的主要功能和模块介绍。本期内容，我们需要介绍的是实时热门商品统计模块的功能开发。
最近公司要把Storm集群给下线啦，所以我们都得把Storm的任务都改成Flink。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
