我有一个用例，apache flink进程必须集成来自多个源的近实时数据流（事件），但由于不同系统中缺少统一的密钥，我需要使用现有数据库中的代理密钥（sk）查找。sk数据集非常大（超过5000万个密钥）。在没有数据库查找的情况下，是否可以/建议缓存这样的数据集以进行流内转换（Map）？如果是，缓存限制是什么？如果不是，那么flink有什么替代方案？
lbsnaicq1#
有几个选择
如果代理密钥从未更改，则可以直接将其加载 RichMapFunction#open 并执行查找。当然，这意味着您必须调整内存设置，以便flink不会尝试将所有内存用于自己的操作。快速计算：假设两个键都是长度为10的字符串。它们在内存中需要40字节的字符。在一些对象开销的情况下，每个条目大约有50个字节。有50万个条目，我们需要2.5 gb的ram来存储。因为哈希Map会有一些开销，所以我计划使用3gbram。如果你的任务管理器有8gb，我会 taskmanager.memory.size 到4 gb。ofc，您需要确保同一任务管理器的不同任务不会两次加载同一Map。另外，我会选择一种适合于尽快加载数据的格式（例如avro），因为缓慢的解析将大大减少启动和恢复时间。
RichMapFunction#open
taskmanager.memory.size
如果内存有问题或数据正在更改，也可以将查找数据建模为Map状态。我会为查找数据添加第二个输入，并使用 KeyedCoProcessFunction . 将来自第二个输入的任何内容馈送到map状态。状态应该使用rocks db后端，这样数据就可以有效地驻留在磁盘上。
KeyedCoProcessFunction
查找也可以建模为联接。如果您已经在使用表api，请看一下join with temporal table。这将在内部使用基于状态的方法，但更加简洁。还可以将数据流与表混合使用。
1条答案
按热度按时间lbsnaicq1#
有几个选择
本地Map
如果代理密钥从未更改，则可以直接将其加载
RichMapFunction#open并执行查找。当然，这意味着您必须调整内存设置，以便flink不会尝试将所有内存用于自己的操作。快速计算：假设两个键都是长度为10的字符串。它们在内存中需要40字节的字符。在一些对象开销的情况下，每个条目大约有50个字节。有50万个条目，我们需要2.5 gb的ram来存储。因为哈希Map会有一些开销，所以我计划使用3gbram。
如果你的任务管理器有8gb，我会
taskmanager.memory.size到4 gb。ofc，您需要确保同一任务管理器的不同任务不会两次加载同一Map。另外，我会选择一种适合于尽快加载数据的格式（例如avro），因为缓慢的解析将大大减少启动和恢复时间。
基于州
如果内存有问题或数据正在更改，也可以将查找数据建模为Map状态。我会为查找数据添加第二个输入，并使用
KeyedCoProcessFunction. 将来自第二个输入的任何内容馈送到map状态。状态应该使用rocks db后端，这样数据就可以有效地驻留在磁盘上。连接数据
查找也可以建模为联接。如果您已经在使用表api，请看一下join with temporal table。这将在内部使用基于状态的方法，但更加简洁。还可以将数据流与表混合使用。