摘要： 
数据的价值在其产生之后，将随着时间的流逝逐渐降低。因此，为了获得最大化的数据价值，尽可能实时、快速地处理新产生的数据就显得尤为重要。实时数据处理将在越来越多的场景中体现出更大的价值所在 —— 实时即未来。
在本章中，我们将详细探讨流处理系统的基石之一：watermark。
具体来说，我们研究了 watermark 是如何在源处创建的，如何在整个管道中传播的。我们探究了更改输出窗口时间戳对 watermark 的影响。最后，我们探讨了流行的流处理系统中 watermark 的实现机制。
在我们了解了 watermark 的工作机制后，接下来我们将继续探讨当使用窗口和触发器进行更复杂查询的时候，watermark 是如何发挥更大作用的。 阅读全文
数据的价值在其产生之后，将随着时间的流逝逐渐降低。因此，为了获得最大化的数据价值，尽可能实时、快速地处理新产生的数据就显得尤为重要。实时数据处理将在越来越多的场景中体现出更大的价值所在 —— 实时即未来。
在本章中，我们将详细探讨流处理系统的基石之一：watermark。
具体来说，我们研究了 watermark 是如何在源处创建的，如何在整个管道中传播的。我们探究了更改输出窗口时间戳对 watermark 的影响。最后，我们探讨了流行的流处理系统中 watermark 的实现机制。
在我们了解了 watermark 的工作机制后，接下来我们将继续探讨当使用窗口和触发器进行更复杂查询的时候，watermark 是如何发挥更大作用的。 阅读全文
posted @ 2022-04-28 07:50
watermark's
阅读(466)
评论(0)
推荐(0)
本章中，我们首先详细讨论了以下流处理核心概念：
1. 窗口：处理无界数据的有效方式是采用窗口的方式对无界数据进行切分。
2. 触发器：用于定义何时触发计算结果更新动作。
3. 水位线：一种推断数据完整性的理念，对于处理无界数据中的乱序、迟到、缺失等问题非常有效。
4. 累积：当窗口结果需要多次更新时如何修正之前的结果。
其次，我们通过对 what，where，when，how 这 4 个问题的回答，逐步揭开流处理过程的全貌：
What：计算什么结果？
Where：在哪里计算结果？
When：在什么时间计算结果？
How：如何修正计算结果？ 
数据的价值在其产生之后，将随着时间的流逝逐渐降低。因此，为了获得最大化的数据价值，尽可能实时、快速地处理新产生的数据就显得尤为重要。实时数据处理将在越来越多的场景中体现出更大的价值所在 —— 实时即未来。
在本章中，我们完成了以下工作：
1. 澄清了一些术语的定义，专注于‘流’的定义，而不是已有流计算系统的实现。
2. 研究了目前 批/流 系统的能力，强调，在功能上，流是批的超集。
3. 提出了如果流系统在功能上要超越批系统，需要具备的两个能力，分别是：正确性和在各时间域处理数据的能力。
4. 强调了事件时间和处理时间的巨大区别。提出了基于这两个时间处理数据的难点。
5. 回顾了主流数据处理系统处理有界和无界数据的方式。 
流式数据是一种源源不断产生的数据，没有预定的开始与结束，至少理论上来说，它的数据输入永远不会结束。因此流式数据处理与传统的批处理技术不同，必须具备持续不断地对到达的数据进行处理的能力。
因为流式数据源源不断地产生，对流式数据做去重就十分困难，因为一条数据重复与否需要与之前的数据痕迹作比对，数据是无穷尽产生的，倘留存之前的数据，势必占据大量的存储空间，判重的过程也会随着数据量的增加而变得复杂耗时。
本文探索了一种流式大数据的实时去重方法，不一定适用于所有场景，不过或许可以给面对相似问题的你一点点启发。 
在实际的生产应用场景中，实时流式数据与维表数据的关联并生成宽表是极为常见的需求。面对这样的需求，存在多种维表关联方式可供选择。本文聚焦于其中三种常见方式展开具体实现与研究，分别是 1. 预加载维表、2. 异步 IO 3. 广播维表。
为了让读者更直观、深入地理解这三种实现方式，本文采用了实验和图解原理相结合的方法，不仅如此，还对每种方法的优点和缺点进行了细致比较。此外，为了便于读者实践和进一步探索，每种实现方式都附上了源码，同时搭配动态效果图，让复杂的技术内容变得更加清晰易懂。 
DateHistogram 用于根据日期或时间数据进行分桶聚合统计。它允许你将时间序列数据按照指定的时间间隔进行分组，从而生成统计信息，例如每小时、每天、每周或每月的数据分布情况。Elasticsearch 就支持 DateHistogram 聚合，在关系型数据库中，可以使用 GROUP BY 配合日期函数来实现时间分桶。但是当数据基数特别大时，或者时间分桶较多时，这个聚合速度就非常慢了。如果前端想呈现一个时间分桶的 Panel，这个后端接口的响应速度将非常感人。于是我决定用 Flink 做一个实时的 DateHistogram。 
在大数据处理领域，Flink消费Kafka数据并将其写入到ElasticSearch是极为常见的业务场景。然而，要确保数据能精准无误、一条不差地从Kafka经Flink最终落入ElasticSearch，实现端到端的数据一致性，并非易事。这背后的关键在于对Flink的Checkpoint机制有着深刻且透彻的理解。为了帮助大家更好地掌握其中的奥秘，本文别具匠心地采用了实验与图解原理相结合的方式。通过精心设计的实验，让大家直观感受数据流转过程；再辅以生动形象的图解，深入剖析Checkpoint机制如何保障数据一致性，带你一探究竟。 
当我们在不同数据库迁移、同步数据时，首先要做的就是把库和表的结构在目标端创建出来。当我们把数据库的结构 dump 出来之后，这个 DDL 在目标端大概率是无法直接运行的，至少数据类型在不同数据库之间就不相同，有的数据类型在目标端根本不存在，有的数据类型即使存在但存储精度、存储空间完全不一样，这给数据同步工作带来了很多困难。这是一个很常见的需求，navicat 的 data transfer 功能就可以做到这一点。但如果想把这个功能集成在自研的产品中，很遗憾 navicat 并不开源。这件事应该并不难，在异构数据源之间迁移数据，数据类型的映射是必不可少的，只要数据类型映射准确，DDL 转换应该就是正确的。说干就干，我决定自己实现一个 DDL 转换工具。目前支持 MySQL、Oracle、PostgreSQL 和达梦数据库之间的转换。 
vue 图片下拉选择控件 
在数据处理与迁移的场景中，实时同步数据至关重要。本文聚焦于利用 Flink CDC 达成 Oracle 到 Oracle 的数据实时同步。详细阐述了 Oracle 数据库的配置要点，为同步工作奠定坚实基础。给出了源码实现，便于开发者参考借鉴，能够快速上手并进行定制化开发。分享了在实践过程中的踩坑记录，为大家提前避开潜在问题提供指引。此外，还配有同步效果录屏，通过直观的动态展示，让读者清晰了解同步过程和最终呈现的效果，助力大家高效完成 Oracle 数据库间的数据实时同步任务。 
Flink 遇到了报错 Could not find ExecutorFactory in classpath，原来是 maven 打包 SPI 的姿势不对~ 
在数据处理与迁移的场景中，实时同步数据至关重要。本文聚焦于利用 Flink CDC 达成 MySQL 到 MySQL 的数据实时同步。详细阐述了 MySQL 数据库的配置要点，为同步工作奠定坚实基础。给出了源码实现，便于开发者参考借鉴，能够快速上手并进行定制化开发。分享了在实践过程中的踩坑记录，为大家提前避开潜在问题提供指引。此外，还配有同步效果录屏，通过直观的动态展示，让读者清晰了解同步过程和最终呈现的效果，助力大家高效完成 MySQL 数据库间的数据实时同步任务。 
在大数据处理领域，Flink 凭借其强大的流处理能力备受青睐，而将 Flink Application 部署到 YARN 集群能实现资源的高效管理与调度。本文聚焦于部署 Flink Application 到 YARN 集群的详细实践步骤。首先会清晰阐述前期的准备工作，包括集群环境的检查与配置、相关依赖的安装等。接着，逐步讲解部署过程中的每一个关键环节，如作业提交的具体命令、参数的合理设置等。还会深入剖析可能遇到的问题及对应的解决方案，让读者少走弯路。通过本文的详细指引，无论是初学者还是有一定经验的数据开发者，都能顺利完成 Flink Application 在 YARN 集群上的部署，充分发挥两者结合的优势，提升数据处理效率。 
浙公网安备 33010602011771号