The library wraps Java APIs in Scala thereby providing:
- much better type inference in Scala
- less boilerplate in application code
- the usual builder-style composition that developers get with the original Java API
The design of the library was inspired by the work started by Alexis Seigneurin in this repository.
kafka-streams-scala
is published and cross-built for Scala 2.11
, and 2.12
, so you can just add the following to your build:
val kafka_streams_scala_version = "0.1.1"
libraryDependencies ++= Seq("com.lightbend" %%
"kafka-streams-scala" % kafka_streams_scala_version)
Note:
kafka-streams-scala
supports onwards Kafka Streams1.0.0
.
The API docs for kafka-streams-scala
is available here for Scala 2.12 and here for Scala 2.11.
The library comes with an embedded Kafka server. To run the tests, simply run sbt testOnly
and all tests will run on the local embedded server.
The embedded server is started and stopped for every test and takes quite a bit of resources. Hence it's recommended that you allocate more heap space to
sbt
when running the tests. e.g.sbt -mem 1500
.
$ sbt -mem 1500
> +clean
> +test
Here's a sample code fragment using the Scala wrapper library. Compare this with the Scala code from the same example in Confluent's repository.
// Compute the total per region by summing the individual click counts per region.
val clicksPerRegion: KTableS[String, Long] = userClicksStream
// Join the stream against the table.
.leftJoin(userRegionsTable, (clicks: Long, region: String) => (if (region == null) "UNKNOWN" else region, clicks))
// Change the stream from <user> -> <region, clicks> to <region> -> <clicks>
.map((_, regionWithClicks) => regionWithClicks)
// Compute the total per region by summing the individual click counts per region.
.groupByKey(Serialized.`with`(stringSerde, longSerde))
.reduce(_ + _)
Notes:
- The left quotes around "with" are there because
with
is a Scala keyword. This is the mechanism you use to "escape" a Scala keyword when it's used as a normal identifier in a Java library.- Note that some methods, like
map
, take a two-argument function, for key-value pairs, rather than the more typical single argument.
The wrapped Scala APIs also incur less boilerplate by taking advantage of Scala function literals that get converted to Java objects in the implementation of the API. Hence the surface syntax of the client API looks simpler and less noisy.
Here's an example of a snippet built using the Java API from Scala ..
val approximateWordCounts: KStream[String, Long] = textLines
.flatMapValues(value => value.toLowerCase.split("\\W+").toIterable.asJava)
.transform(
new TransformerSupplier[Array[Byte], String, KeyValue[String, Long]] {
override def get() = new ProbabilisticCounter
},
cmsStoreName)
approximateWordCounts.to(outputTopic, Produced.`with`(Serdes.String(), longSerde))
And here's the corresponding snippet using the Scala library. Note how the noise of TransformerSupplier
has been abstracted out by the function literal syntax of Scala.
textLines
.flatMapValues(value => value.toLowerCase.split("\\W+").toIterable)
.transform(() => new ProbabilisticCounter, cmsStoreName)
.to(outputTopic, Produced.`with`(Serdes.String(), longSerde))
Also, the explicit conversion asJava
from a Scala Iterable
to a Java Iterable
is done for you by the Scala library.