小编YFl*_*YFl的帖子

Poetry 官方文档严格建议使用官方安装程序。然而，自制有诗歌公式。

brew install poetry

通常，我喜欢将所有内容保留在自制程序中，以便轻松管理安装。

使用自制软件而不是推荐的安装脚本安装诗歌有什么缺点和风险？

默认情况下，poetry 在项目 root 之外创建虚拟环境。例如，在 mac 上，它在~/Library/Caches/pypoetry.

但是，我发现了以下建议：

# Configure poetry to create virtual environments inside the project's root directory
poetry config virtualenvs.in-project true

另外，诗歌文档本身指出了这两个选项：

默认情况下，poetry 在 {cache-dir}/virtualenvs（Windows 上为 {cache-dir}\virtualenvs）中创建一个虚拟环境。您可以通过编辑诗歌配置来更改缓存目录值。此外，您可以使用 virtualenvs.in-project 配置变量在项目目录中创建虚拟环境。

在项目目录内或外部创建项目虚拟环境有什么好处？

一些 python 进程崩溃：

objc[51435]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

这些是使用子 shell、分叉线程等的进程。MacOS 出于某些安全原因阻止它们（我不确定是什么，但人们就是这么说的）

解决方案是禁用此安全检查：

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

这对于已知的库和依赖项以及当前运行的 shell 来说是很好的。

将其设置为全局环境变量，在我的本地 mac 计算机中全局禁用此检查是否安全？

由于任何 Kafka Consumer 实际上都是批量消费，为什么与 Kafka Streams（将自己推销为真正的流媒体）相比，Spark Streaming 微批量（当使用 Kafka 作为源时）有如此多的批评？

我的意思是：很多批评都集中在 Spark Streaming 微批处理架构上。通常，人们说 Kafka Streams 是一个真正的“实时”工具，因为它逐一处理事件。

它确实会一一处理事件，但是根据我的理解，它使用（与几乎所有其他库/框架一样）消费者 API。Consumer API 批量轮询主题，以减轻网络负担（间隔可配置）。因此，消费者会做类似的事情：

while (true) {
        ConsumerRecords<String, String> records = consumer.poll(100);

        ///// PROCESS A **BATCH** OF RECORDS
        for (ConsumerRecord<String, String> record : records) {

            ///// PROCESS **ONE-BY-ONE**
        }
}

因此，尽管 Spark 的说法是正确的：

1. 由于其微批量最小间隔将延迟限制为最多 100 毫秒，因此可能具有更高的延迟（请参阅 Spark 结构化流 DOC）；
2. 成组处理记录（作为 RDD 的 DStream 或结构化流中的 DataFrame）。

但：

1. 可以在 Spark 中逐一处理记录 - 只需循环 RDD/行
2. Kafka Streams 实际上会轮询一批记录，但会逐一处理它们，因为它在底层实现了 Consumer API。

需要澄清的是，我并不是从“粉丝方面”提出问题（因此，这是一个意见问题），恰恰相反，我真的试图从技术上理解它，以便理解流媒体生态系统中的语义。

欣赏这件事上的每一条信息。

假设我们有一个abstract class（也有同样的问题traits）：

abstract class TypeParser[C <: Changes : TypeTag] extends Serializable {

  val enrichmentType: EnrichmentType
  protected def parseChanges(row: Row): C

}

其中实现如下所示：

object PlaceholderParser extends TypeParser[PlaceholderChanges] {

  val enrichmentType: EnrichmentType = PlaceholderType
  override protected def parseChanges(row: Row): PlaceholderChanges = ???

}

上面的实现是单例，但是，不能在将来的实现中强制它成为单例。因此，我们可以简单地将其实现为 a class，例如：

class PlaceholderParser2() extends TypeParser[PlaceholderChanges2] {

  val enrichmentType: EnrichmentType = PlaceholderType2
  override protected def parseChanges(row: Row): PlaceholderChanges2 = ???

}

有没有办法强制实现成为单例？

附带问题：强迫它有什么好处吗？