Apache Flink有一个splitAPI，可用于分支数据流：
val splited = datastream.split { i => i match {
case i if ... => Seq("red", "blue")
case _ => Seq("green")
}}
splited.select("green").flatMap { .... }
它还提供了另一种称为Side Output的方法（https://ci.apache.org/projects/flink/flink-docs-release-1.5/dev/stream/side_output.html），使您可以执行相同的操作！
这两种方式有什么区别？他们是否使用相同的较低层结构？它们的价格一样吗？我们何时以及如何选择其中之一？
我正在使用Typesafe Activator的最新版本(1.2.8与Scala 2.11.x).
当我"org.apache.httpcomponents" %% "httpclient" % "4.4-alpha1"向我的项目中添加依赖项时build.sbt,如下所示:
libraryDependencies ++= Seq(
"com.typesafe.akka" %% "akka-actor" % "2.3.4",
"com.typesafe.akka" %% "akka-testkit" % "2.3.4",
"org.scalatest" %% "scalatest" % "2.1.6" % "test",
"junit" % "junit" % "4.11" % "test",
"com.novocode" % "junit-interface" % "0.10" % "test",
"org.apache.httpcomponents" %% "httpclient" % "4.4-alpha1" // my added dependency
)
...并尝试更新项目(在激活器的cli中)我收到一个错误:
[error] (*:update) sbt.ResolveException: unresolved dependency: org.apache.httpcomponents#httpclient_2.11;4.4-alpha1: not found
我知道scala的版本不是二进制兼容的,但我试图获得一个纯java库org.apache.httpcomponent#httpclient!为什么激活器在artifactId的末尾添加"_2.11"并制作错误的URL ...？怎么解决？
我正在使用 Sliex 框架。当我使用方法时，我遇到了重定向问题\Silex\Application::redirect。我发现当我尝试通过 http-headers 重定向时，响应似乎调用了该__toString方法，而不是 symfony“发送”。
这是我的卷曲输出：
bash-4.2$ curl -v http://127.0.0.1:8082/
* About to connect() to 127.0.0.1 port 8082 (#0)
* Trying 127.0.0.1...
* Adding handle: conn: 0x1ea0970
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1ea0970) send_pipe: 1, recv_pipe: 0
* Connected to 127.0.0.1 (127.0.0.1) port 8082 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.32.0
> Host: 127.0.0.1:8082
> Accept: */*
>
< HTTP/1.1 200 …Flink de/serialise operator state 的频率如何？每个获取/更新还是基于检查点？状态后端是否有所作为？
我怀疑在具有不同键（数百万）和每个键每秒数千个事件的键控流的情况下，反/序列化可能是一个大问题。我对吗？
我在ElasticSearch的单节点集群上做了一些基准测试.
我面临的情况是,更多分片会降低索引性能 - 至少在单个节点中 - (在延迟和吞吐量方面)
这些是我的一些数字:
我使用批量API获得了相同的结果.所以我想知道这是什么关系以及为什么会这样？
注意:我没有资源问题!资源是免费的(CPU和内存)
我正在寻找一个容错的流处理引擎。出于这个原因，我用一个简单的工作来测试 Flink：从文本套接字读取单词的 SocketTextStreamWordCount 示例！我在一个有 3 个任务管理器的独立集群上运行它，我找到了负责从套接字读取的任务管理器！我杀死了 TaskManger (kill -9) 并等待查看结果：大约 30 秒后，JobManger 删除了死的 TaskManger！并将工作分配为失败！
看来容错保证不是一般的东西，取决于Job！我对吗？有没有可以解释的参考资料？