bigdatakenan的博客

本文提供了一个LangChain框架的综合资源库，包括低代码工具、服务、代理、模板等，还列举了知识管理和聊天机器人等开源项目，以及学习笔记、视频教程等学习资料，旨在帮助开发者更好地利用和学习LangChain。摘要由CSDN通过智能技术生成。

加上了上面的依赖继续跑然后又报错了：NoClassDefFoundError: org/apache/flink/connector/file/src/reader/BulkFormat$RecordIterator。用idea在本地读取paimon的表时需要添加的依赖除了官网提出的和hadoop相关的，paimon-flink之类相关的除外还需要其他额外依赖。从上面大概可以看出应该是缺flink-connector-files依赖，添加上去之后成功了。

事实上，这两种情况之间的区别是非常小的：在有界/批处理情况中，枚举器生成固定数量的分片，而且每个分片都必须是有限的。但在无界流的情况下，则无需遵从限制，也就是分片大小可以不是有限的，或者枚举器将不断生成新的分片。是基于同步读取/轮询的 Source 的高级（high-level）API，例如 file source 和 Kafka source 的实现等。核心的 SourceReader API 是完全异步的， 但实际上，大多数 Sources 都会使用阻塞的操作，例如客户端（如。

新版本使用了Flink最新的Source接口和SinkWriter接口，可以使用一套代码完成流式读取数据和批量读取数据。

由于源码分析系列文档较多，本人绘制了Flink文档脑图。和下面的文档目录对应。各位读者可以选择自己感兴趣的模块阅读并参与讨论。此脑图不定期更新中……

以下为sql读取结果，直接将redis数据解析成我们需要的表格形式。

在许多情况下，开发人员不需要从头开始创建新的连接器，而是希望稍微修改现有的连接器或 hook 到现有的 stack。在其他情况下，开发人员希望创建专门的连接器。本节对这两种用例都有帮助。它解释了表连接器的一般体系结构，从 API 中的纯粹声明到在集群上执行的运行时代码实心箭头展示了在转换过程中对象如何从一个阶段到下一个阶段转换为其他对象。

GeminiStateBackend是一款面向流计算场景的KV存储引擎，作为实时计算Flink版产品的默认状态存储后端（StateBackend）。性能卓越：在 Nexmark 测试中，Gemini 所有用例的性能都比 RocksDB 更优，其中约一半用例的性能领先 RocksDB 70%以上。

本文整理自俞航翔、陈婧敏、黄鹏程老师所撰写的大状态作业调优实践指南。由于内容丰富，本文分享，主要分为以下三个部分：状态算子的产生问题诊断方法调优方法点击作为一种特定领域语言，SQL 的设计初衷是隐藏底层数据处理的复杂性，让用户通过声明式语言来进行数据操作。而Flink SQL 由于其架构的特殊性，在实现层面通常需引入状态后端 配合 checkpoint 来保证计算结果的最终一致性。

Apache Flink 是一个开源的流处理框架，用于处理和分析实时数据流。在 Flink 中，状态管理是流处理应用的核心概念之一，它允许算子（operators）在处理事件时保持和操作状态信息。在 Flink 中，状态可以被视为算子的“记忆”，它使得算子能够在处理无界流数据时保持对历史数据的跟踪。状态可以是简单的键值对，也可以是更复杂的数据结构，如列表、集合或自定义对象。状态的更新和查询对于实现复杂的流处理逻辑至关重要。具体说来，首先，Checkpoint 是 Flink 的一种容错机制。

本文整理自 Flink Forward 2020 全球在线会议中文精华版，由 Apache Flink PMC 伍翀（云邪）分享，社区志愿者陈婧敏（清樾）整理。旨在帮助大家更好地理解 Flink SQL 引擎的工作原理。

本系列课程由 Apache Flink Community China 官方出品。旨在为具备一定大数据基础、对 Apache Flink 感兴趣的同学提供系统性的入门教程，课程分为 基础篇、进阶篇、运维篇、实时数仓篇等，持续更新。PPT视频回放讲师：程鹤群（军长）（Apache Flink PMC，阿里巴巴技术专家）PPT视频回放讲师：戴资力（Apache Flink PMC）

截至当前，Flink 作业的状态后端仍然只有 Memory、FileSystem 和 RocksDB 三种可选，且 RocksDB 是状态数据量较大（GB 到 TB 级别）时的唯一选择。RocksDB 的性能发挥非常仰赖调优，如果全部采用默认配置，读写性能有可能会很差。但是，RocksDB 的配置也是极为复杂的，可调整的参数多达百个，没有放之四海而皆准的优化方案。如果仅考虑 Flink 状态存储这一方面，我们仍然可以总结出一些相对普适的优化思路。本文先介绍一些基础知识，再列举方法。

好久不见（鞠躬最近处在转型期，每天忙到飞起，关注具体技术细节的精力自然就比较少了（上一篇许下的周更承诺也食言了 = =）。上周帮助他人快速解决了一个因误用Flink状态类型引发的性能问题，在这里做个quick notes，并简要介绍一下Flink状态序列化方面的基础知识。

我们先看看元数据中心有哪些功能，举个例子，我们先点击mysql数据源可以清楚的看到mysql数据库中有哪些库点开dinky数据库的dlink_alert_group,可以看到这个表的所有元数据信息，内容非常的全面然后点击数据查询页面可以看到这个表中的数据，也可以根据筛选条件和排序字段进行自定义查询点击SQL生成可以生成相关的DDL sql在控制台就可以自己写各种sql操作我们的数据库和表。

dinky源码将作业分类三类，common sql, flink sql 和flink jar然后调用不同方法进行提交。

这几天研究了一下Dinky，确实是一款很不错的软件，功能很强大，也很实用，可以极大的方便我们flink sql的开发工作，同时他也支持其他一些主流数据库的SQL,像starrocks。Dinky号称基于Flink二次开发，没有侵入Flink,所以这一点就值得我们学习，为了了解Dinky我自己也搭建了一套Dinky环境，确实使用起来非常舒适 ，搭建过程也是比较容易，下面简单列一下搭建过程。

里面有大约六七十个handler，如果客户端使用fink run的方式来提交一个job，最终会由WebMonitorEndpoint的submitJobHandler来处理。负责接收用户提交的jobGraph，然后启动Jobmaster。Flink集群的资源管理器，关于slot的管理和申请工作都由他负责。

上一节我们分析到了在jobmaster启动后，会将JobGraph转换成ExecutionGraph,同时也会将checkpoint相关配置传给executionGraph,并且还创建了checkpointCoordinator。下面我们接着上节的地方继续往下分析。

Flink chcekpoint作为flink中最重要的部分，是flink精准一次性的重要保证，可以这么说flink之所以这么成功和她的checkpoint机制是离不开的。之前大概学习了一下flink的checkpoint源码，但是还是有点晕乎乎的，甚至有点不理解我们作业中设置的checkpoint配置flink是如何读取到的，并且他是如何往下传播的。