问题标签 [near-real-time]

我在通过 SOLR 建议器近乎实时地显示结果时遇到了一些麻烦。尽管，如果我尝试使用搜索处理程序，它可以正常工作以进行近乎实时的搜索。如果我添加一个文档，我可以通过搜索处理程序在接近 rel 的时间内检索该文档，但只有在我重新加载核心后，相同的记录才在建议程序中可用。为什么会发生这种情况？这是我在 solr-config.xml 中的建议者条目

这是我的自动提交和软提交条目（使用默认值）

如何使用 Mahout 实现在线推荐。我想使用诸如 REST API 之类的机制实时从 mahout 推荐引擎获得推荐。

请分享我任何实施想法

问候。

我正在开发一个 Web 应用程序（Angular 2 和 Asp.net Web API），当另一个用户创建了某个任务（数据库中的任务表上的一个条目）时，它会通知用户。通知可以类似于 Facebook 通知。

可以使用哪些技术来实现这种实时通知？我是实时应用程序的新手，所以请帮助我选择正确的路径。

我的公司开发了一款 Windows 分析应用程序。我们被要求找到调用此 Windows 应用程序的方法，以便我们能够使用 Azure 提供实时分析。

数据源可以是 Azure 事件中心或 Azure 服务总线或任何东西。我们已经在 Azure VM 中安装了这个应用程序，但我们不知道如何调用这个应用程序。

我们搜索了 Azure 函数和 Azure 逻辑应用，但找不到任何东西。

有人可以帮忙吗？

我正在使用 Lucene 6.6.0，我想使用 Lucene 的近实时搜索功能。但是，我无法实现它。我尝试获取该功能的方式如下：

我初始化一个 IndexReader 实例：

让我们假设已经通过 IndexWriter 实例对索引进行了一些更改。然后，如果我理解正确，我需要第二个 IndexReader 实例来提交更新：

这里的问题是由于以下错误，代码无法编译：The method openIfChanged(DirectoryReader) in the type DirectoryReader is not applicable for the arguments (IndexReader).

我应该如何更新IndexReader呢？

其次，如果我再次更新索引，我将需要另一个 IndexReader 实例，不是吗？在程序执行期间自由更新索引的最佳方法是在每次更新后在 2 个 IndexReader 实例之间切换吗？

谢谢你。

我知道 Spark Streaming 使用微批处理来处理数据，但在某些情况下处理时间不到一秒。我的问题是“在那个场景中，它不能被称为纯实时处理而不是接近实时处理吗？”

我在减少 PHP 上的 TTFB 时遇到了麻烦。

即使文件为空，它也需要大约 100 毫秒。.php 或 .html 没关系，两者都需要相同的时间。

我在 HETZNER 上有一个不错的服务器，服务器没有加载，应该没有任何问题。

Cpanel会不会有问题？

php 7.0（空文件）是否可以降低 TTFB？

我设法通过将 DNS 服务器从 hostgator (LaunchPad) 更改为 cloudflare（大约 100 毫秒，现在大约 1.5 毫秒）来减少连接时间。

有什么建议么？

问题

1. 使用 Snowpipe 加载小文件（例如 4K）比 16K、500K 或 1-10Mb（推荐的文件大小）要贵多少。注意：这个问题意味着加载小文件比推荐的 1-10Mb 更昂贵。

2. 了解最佳实践是加载大小为 1-10Mb 的文件，但我需要近乎实时的交付（几分钟）。我可以连接文件以使它们更大，但不能等待超过 60 秒才能将微批处理发送到 S3 并因此发送到 Snowpipe。我目前每 30 秒写一次我所有的内容，但我每 60 秒看到一次 Snowpipe 报告。这是否意味着将文件写入 S3 的频率超过 60 秒是没有意义的？IE。如果我每 30 秒发送一次文件，它实际上会减少平均延迟，或者是 60 秒的最小雪管周期。

3. 加载 4K 文件（每天大约 200Mb，每个文件 4K），每 GB 大约需要 20 个积分，这非常昂贵。如果我加载（例如）1-10Mb 范围内的 CSV 文件，使用 Snowpipe 时每 GB 的成本应该是多少？如果我保持在 1-10Mb 范围内，每 GB 的成本会下降吗？

4. 有没有更快/更便宜的替代方法将数据输入雪花？注意：目前使用 Parquet 格式的 Snowpipe 到 VARIANT，然后使用 STREAMS 和 TASKS 重构数据以进行近乎实时的分析。了解使用 Snowpipe 比使用虚拟仓库更便宜。这是真的？我怀疑真正的答案是“这取决于”。但是“取决于什么”。

5. 除了我的近实时要求外，我还有许多系统提供批量提要（CSV 格式，大约每 4 小时一次，预计延迟在 30 分钟内处理和呈现以供分析。文件大小在此处有所不同，但大多数为 1Mb到 1Gb 范围。我应该使用相同的 Snowpipe 解决方案，还是我最好从 Airflow 编排工作并在专用虚拟仓库上使用 COPY 命令和 SQL 语句？或者实际上，您会推荐什么替代方案？

6. 我可以看到 Snowpipe 加载 4K 文件很昂贵，而且可能比更大的文件便宜。如果我加载超过 10Mb 的文件，这些文件会再次变得更加昂贵吗？IE。成本是“钟形曲线”还是趋于平缓。

背景

1. 我正在使用 Snowpipe 提供近乎实时 (NRT) 的数据加载解决方案。
2. 我大约每 30 秒从大约 30 个表中将数据从 Kafka 复制到 S3，并且使用 Snowpipe 自动将其加载到 Snowflake。
3. 数据以 Parqet 格式传递给我，加载到 Variant 中，然后是一个视图以将属性提取到表中，然后再使用 Tasks 和 SQL 进行重组以进行分析。
4. 在一天之内，我发现加载了 50,000 个文件，文件大小各不相同，但每个文件的平均文件大小为 4K。
5. 我可以看到每分钟加载大约 30 个文件（即每分钟加载大约 100K）。
6. 我正在尝试平衡几个非功能性需求。a) 有效使用积分。意识到小文件很昂贵。b）减少延迟（我试图从 Kafka 到仪表板的管道最长大约 2-5 分钟）。c) 简单 - IE。它需要易于理解和维护，因为我希望解决方案能够大规模增长 - IE。从大约 20 张桌子到数百张桌子 - 都需要近乎实时
7. 我将（在接下来的 3 个月内）每 4 小时进行一次 CSV 批量加载。它们是完全独立的数据源（来自 NRT），并且具有更密集的处理和 ELT。我想知道我是否应该为这些使用 Snowpipe 或 COPY。