问题标签 [rebalancing]

我正在尝试执行如下函数来平衡火车组与包 ROSE：

调用上述脚本会生成以下错误消息：

ovun.sample(...)相反，当我在本地函数之外调用函数时，一切都很好rose，即：

ovun.sample(..., data=train,...)我知道在rose()中调用函数时会出现问题，但我不知道为什么。可能是环境变量的问题？

任何想法？

我们的生产 MarkLogic DB 有 1.2 TB 的数据，分布在 6 个森林中。我们计划增加 2 个新森林以减少每森林数量的林分。

现在，添加新森林开始重新平衡数据。没关系，这需要时间。但是，每当合并与再平衡同时开始时，这个再平衡时间就会不断增加。有时需要，估计8小时，突然到16小时。因此，平均而言，整个过程大约需要 24 小时。

我的问题是- 如果我们在添加新森林之前禁用合并并在重新平衡完成后不久启用手动合并（在添加森林之后），合并过程会更快吗？而且，这样做安全吗？

我有一个投资组合组件的数据集，它提供了我的投资组合中在每个重新平衡日期（每月）持有的 10 只股票的信息。

一个只有 4 个日期和 4 个股票的示例数据框：

股票在日期之间会有所不同，因此我需要根据我购买、持有或出售每只股票来计算直接交易成本。我想要的是根据这个添加一个值为 0,1,2 的列，以便：

• 如果股票在时间 t-1 和时间 t 持有，则值为 0
• 如果股票在时间 t-1 持有，但在时间 t 卖出，价值 1
• 如果股票在时间 t-1 买入，并且在时间 t 持有（未卖出），则价值 1
• 如果股票在时间 t-1 买入，在时间 t 卖出，则值为 2

将值分配给 t-1 时的库存。

这看起来像的例子：

我正在使用 Kafka：2.11-1.0.1。应用程序包含主题“X”的并发数=5 的消费者，分区数=5。

当应用程序重新启动并且消息在分区分配之前发布到主题'X'上时，主题'X'的5个消费者找到组协调器并向组协调器发送加入组请求。预计会从组协调员那里得到响应，但没有收到响应。

我检查了 Kafka 服务器日志，但找不到相关日志，发现 DEBUG 日志级别。

当我运行描述消费者组命令时，会进行以下观察：

1. 消费群体正在重新平衡
2. 有一定滞后的老消费者
3. 具有一些随机名称的新消费者。随着时间的推移，新的消费者数量正在增加。

新消息发布在主题“X”上，但消费者没有收到。

heartbeat 和 session.time.out 设置为默认值。

如果在为主题“X”及其使用者分配分区之前发布消息，则会出现此问题。

我的疑问是：为什么重新平衡没有完成，以至于新的消费者开始消费新产生的消息？

是否可以从源任务中触发 Kafka 连接器重新平衡。该任务可以检测到一些可能保证连接器重新平衡的异常情况。SourceTaskContext 没有像 SourceConnectorContext 所拥有的 requestTaskReconfiguration 这样的重新平衡方法。

我需要在任务而不是连接器中触发重新平衡。

仅一次运行 3 个 Kafka Streams 实例，但在重新启动其中一个流实例时遇到数据丢失（另外 2 个正在重新平衡）。如果我快速重新启动实例（在 内session.timeout.ms），而其他 2 没有重新平衡，一切都按预期工作。

• 输入和输出主题由 6 个分区创建。
• 运行 3 个 Kafka 代理。
• 在循环中使用单个 python 生产者生成数据 ( acks='all')。
• 使用配置的单个 Kafka Connect 将数据输出到 SQLconsumer.override.isolation.level=read_committed

我期望聚合数据与我的 python 循环的输出具有相同的计数。只要 Kafka Streams 不进入重新平衡状态，这就可以正常工作。

简而言之，流实例会：

1. 收集会话数据，并更新会话状态。
2. 然后使用窗口聚合对会话状态的增量更新进行重新分区和求和。

通过我自己的调试输出，我倾向于认为问题与转移聚合状态有关：

1. 作为会话 X 的更新的记录 A 将 0 添加到聚合中。
2. 聚合的输出现在是 6
3. 作为对会话 X 的更新的记录 B 将 1 添加到聚合中。
4. 聚合的输出现在是 7
5. 再平衡
6. 对会话 X（可能是也可能不是重播或记录 A）的更新正在将 0 添加到聚合中。
7. 聚合的输出现在是 6

代码的简化和剥离版本：（不是真正的 Java 开发人员，对非最佳语法感到抱歉）

和：

在运行一个项目时，我遇到了一些RebalanceInProgressException每周发生一次或两次并导致消费者失败的情况。这是消息：

我想了解 Kafka 的基本原理以及导致此异常的幕后实际发生了什么。这是否意味着在重新平衡进行时发生了提交？为什么它被禁止并导致异常？

假设我有状态 Kafka Streams 应用程序使用 3 个分区的主题数据。目前，我有 2 个上述应用程序实例正在运行。让我们这样说：instance1有分区part1并part2分配，instance2有part3.

所以现在我想添加新实例以完全利用并行化。

据我了解，一旦我启动一个新实例，就会发生重新平衡：分区之一part1或part2相应的本地状态存储将从现有实例迁移到新添加的实例。在这个例子中，让我们假设part1迁移到instance3.

同时，我意识到新实例instance3在从 changelog 主题恢复本地状态存储之前不会开始处理新数据，这可能需要很长时间。

从启动应用程序到恢复状态存储期间：

• 这是否意味着在完成启动part1之前没有处理并卡住来自的数据？instance3
• instance3如果是，那么有什么方法可以估计建立当地的州立商店需要多少时间？
• 在此期间，其他实例是否不受重新平衡的影响并继续处理数据而没有停机时间 ( instance1 - part2, instance2 - part3)？

请帮助解决以下问题。

给出了以下实体：

1. 应用。应用程序驻留在存储上，它们通过服务节点生成流量。
2. 服务。服务分为几个节点。每个节点都可以访问本地或/和共享存储。
3. 贮存。这是应用程序所在的位置。它可以是本地的（仅连接到一个服务节点）或由多个节点共享。

规则：

1. 每个应用程序都放置在某个特定的存储上。并且无法更改存储。
2. 只要新的服务节点可以访问应用程序的存储，就可以将应用程序的服务节点更改为另一个服务节点。

例如，如果 App 驻留在 Node0 的本地存储上，则它只能由 Node0 提供服务。但如果 App 驻留在存储 shared0 上，它可以由 Node0、Node1 或 Node2 提供服务。

考虑到所有应用程序都已放置在它们的数据存储中，问题在于找到在服务节点之间重新平衡应用程序的算法。并尽可能公平地进行这种重新平衡。

如果我们以 shared2 存储为例，解决方案似乎很简单：我们计算 Node3 和 Node4 的应用程序数量，并在它们之间平均分配所有应用程序。但是当涉及到 shared1 时，它变得更加复杂，因为 Node2 也可以访问 shared0 存储。因此，在重新平衡组 [Node2, Node5] 中的应用程序时，我们还必须考虑组 [Node0, Node1, Node2] 中的应用程序。组 [Node2, Node5] 和 [Node0, Node1, Node2] 相交，应立即对所有组执行重新平衡。

我怀疑这个问题应该有众所周知的工作算法，但仍然找不到。

我需要建立一个股票指数来代表我国股市的表现。这是我最后一年的本科论文。

据我了解，我的要求是：

a) 我必须想出一个机器学习解决方案，从所有表现良好并代表市场的股票中挑选出 20 只股票。

b) 使用 ML 分配权重（从选定的股票中构建最佳投资组合）。

c) 每月重新平衡库存。

d) 我需要使用 Python 作为编程语言。

我想知道从哪里开始，有没有参考资料？如果有，请分享，我找不到一个。

任何想法如何实现这些目标？制作一个活跃的股票指数。

谢谢你。