Author Archives: DevOps

groupMapReduce in Scala, Ruby and Spark

Given the following dataset:

$ head -10 fruits.txt 
peach	1
apricot	2
apple	3
haw	1
persimmon	9
orange	2
litchi	9
orange	5
jackfruit	8
crab apple	0

We can group and aggregate to count the fruit’s number by their names.

In Scala it’s quite easy because this language has the built-in higher order functions for calculation. The implementation in Scala REPL:

scala> import scala.io.Source
import scala.io.Source

scala> val fd = Source.fromFile("tmp/fruits.txt").getLines().toList

scala> val regex = """(.+)\s+(\d+)""".r
val regex: scala.util.matching.Regex = (.+)\s+(\d+)

scala> fd.map{ case regex(x,y) => (x,y.toInt) }.groupMapReduce(_._1)(_._2)(_+_).toList.sortBy(-_._2).foreach(println)
(blueberry,166)
(cumquat,145)
(lemon,145)
(areca nut,139)
(haw,137)
(banana,134)
(greengage,134)
(raspberry,133)
(longan,132)
(nectarine,128)
(flat peach,125)
(tangerine,122)
(blackberry,121)
(litchi,120)
(watermelon,120)
(peach,117)
(bitter orange,117)
(strawberry,116)
(pawpaw papaya,113)
(persimmon,108)
(orange,104)
(tomato,102)
(mango,102)
(plum,99)
(wax apple,98)
(waxberry red bayberry,95)
(grape,92)
(jackfruit,92)
(pineapple,91)
(pear,89)
(loquat,89)
(coconut,86)
(apple,86)
(pomegranate,84)
(shaddock pomelo,84)
(musk melon,84)
(guava,82)
(honey peach,82)
(apricot,81)
(starfruit,80)
(sugar cane,79)
(crab apple,75)
(cherry,73)

Ruby also implements this job well by using its Array methods. Though Ruby has no built-in groupMapReduce method, but I have implemented one for which you can get from this repo. The code below is run in Ruby’s interactive shell (irb).

irb(main):001:0> require './bitfox'
=> true
irb(main):002:0> file = File.readlines('tmp/fruits.txt')

irb(main):011:-> file.map {|s| (x,y) = s.chomp.split("\t"); [x,y.to_i] }.reduceByKey {|x,y| x+y}.sort_by{ |s| -s[1] }
=> 
[["blueberry", 166],                                                                                                                               
 ["cumquat", 145],                                                                                                                                 
 ["lemon", 145],                                                                                                                                   
 ["areca nut", 139],                                                                                                                               
 ["haw", 137],                                                                                                                                     
 ["greengage", 134],                                                                                                                               
 ["banana", 134],                                                                                                                                  
 ["raspberry", 133],                                                                                                                               
 ["longan", 132],                                                                                                                                  
 ["nectarine", 128],                                                                                                                               
 ["flat peach", 125],                                                                                                                              
 ["tangerine", 122],                                                                                                                               
 ["blackberry", 121],                                                                                                                              
 ["litchi", 120],                                                                                                                                  
 ["watermelon", 120],
 ["peach", 117],
 ["bitter orange", 117],
 ["strawberry", 116],
 ["pawpaw papaya", 113],
 ["persimmon", 108],
 ["orange", 104],
 ["tomato", 102],
 ["mango", 102],
 ["plum", 99],
 ["wax apple", 98],
 ["waxberry red bayberry", 95],
 ["jackfruit", 92],
 ["grape", 92],
 ["pineapple", 91],
 ["pear", 89],
 ["loquat", 89],
 ["apple", 86],
 ["coconut", 86],
 ["pomegranate", 84],
 ["shaddock pomelo", 84],
 ["musk melon", 84],
 ["honey peach", 82],
 ["guava", 82],
 ["apricot", 81],
 ["starfruit", 80],
 ["sugar cane", 79],
 ["crab apple", 75],
 ["cherry", 73]]

In my implementation above, Ruby uses the method reduceByKey instead of groupMapReduce in Scala. That’s to say, Ruby and Spark use the method name “reduceBykey”, while Scala uses the name “groupMapReduce”. All three methods have the same effect.

The last is Spark’s implementation. It’s quite simple to run this statistics in spark-shell.

scala> val rdd = sc.textFile("tmp/fruits.txt")
rdd: org.apache.spark.rdd.RDD[String] = tmp/fruits.txt MapPartitionsRDD[1] at textFile at <console>:23

scala> val regex = """(.+)\s+(\d+)""".r
regex: scala.util.matching.Regex = (.+)\s+(\d+)

scala> rdd.map{ case regex(x,y) => (x,y.toInt) }.reduceByKey( _+_ ).sortBy(-_._2).foreach(println)
(blueberry,166)
(cumquat,145)
(lemon,145)
(areca nut,139)
(haw,137)
(banana,134)
(greengage,134)
(raspberry,133)
(longan,132)
(nectarine,128)
(flat peach,125)
(tangerine,122)
(blackberry,121)
(watermelon,120)
(litchi,120)
(bitter orange,117)
(peach,117)
(strawberry,116)
(pawpaw papaya,113)
(persimmon,108)
(orange,104)
(tomato,102)
(mango,102)
(plum,99)
(wax apple,98)
(waxberry red bayberry,95)
(grape,92)
(jackfruit,92)
(pineapple,91)
(pear,89)
(loquat,89)
(apple,86)
(coconut,86)
(musk melon,84)
(shaddock pomelo,84)
(pomegranate,84)
(guava,82)
(honey peach,82)
(apricot,81)
(starfruit,80)
(sugar cane,79)
(crab apple,75)
(cherry,73)

It’s not hard to understand how groupMapReduce is implemented. If you have checked my code in Github, you will find the code is little.

    def reduceByKey
        if block_given?
            group_by {|x| x[0]}.map {|x,y| y.reduce {|x,y| [ x[0], yield(x[1],y[1]) ]}}
        else
            raise "no block given"
        end
    end

Perl and Python can implement this method as well. But they are not that convenient. For data programming, Scala and Spark are really the best. If no considering the performance, Ruby is fun too.

Time difference on handling the file larger than memory

Apache Spark can deal with big file well even if file size is much larger than the memory.

For instance, I have the file “rate.csv” which is 3.2GB in size:

$ du -h rate.csv 
3.2G	rate.csv

But my VPS has only 2GB total memory:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           1992        1652         206           4         134         197
Swap:          1023         521         502

Even though Spark can read and handle this file well. For example, I load the file into spark and issue a SQL query via its Dataframe API.

// define the schema
scala> val schema="uid STRING,item STRING,rate FLOAT,time INT"
val schema: String = uid STRING,item STRING,rate FLOAT,time INT

// load csv file into spark as a dataframe
scala> val df = spark.read.format("csv").schema(schema).load("skydrive/rate.csv")
val df: org.apache.spark.sql.DataFrame = [uid: string, item: string ... 2 more fields]

// print the schema
scala> df.printSchema()
root
 |-- uid: string (nullable = true)
 |-- item: string (nullable = true)
 |-- rate: float (nullable = true)
 |-- time: integer (nullable = true)

// get the items count
scala> df.count()
val res1: Long = 82677131   

// get the partitions number
scala> df.rdd.getNumPartitions
val res3: Int = 26

// issue a query by grouping item and aggregating rate
scala> df.groupBy("item").agg(avg("rate").alias("avg_rate")).orderBy(desc("avg_rate")).show()
+----------+--------+                                                           
|      item|avg_rate|
+----------+--------+
|0001061100|     5.0|
|0001543849|     5.0|
|0001061127|     5.0|
|0001019880|     5.0|
|0001062395|     5.0|
|0000143502|     5.0|
|000014357X|     5.0|
|0001527665|     5.0|
|000107461X|     5.0|
|0000191639|     5.0|
|0001127748|     5.0|
|0000791156|     5.0|
|0001203088|     5.0|
|0001053744|     5.0|
|0001360183|     5.0|
|0001042335|     5.0|
|0001374400|     5.0|
|0001046810|     5.0|
|0001380877|     5.0|
|0001050230|     5.0|
+----------+--------+
only showing top 20 rows

As you see above, the query run pretty well. Spark didn’t throw out any memory overflow error. The total query time is: 1 min 46 seconds.

Apache Drill is quite memory sensitive, even so it can make the job done under this limited memory. For example:

> select columns[1] as `item`, avg(cast(columns[2] as Float)) as `avg_rate`
> from `rate.csv` group by `item` order by `avg_rate` desc limit 20;
+------------+----------+
|    item    | avg_rate |
+------------+----------+
| 0004133900 | 5.0      |
| 0005019222 | 5.0      |
| 0002557991 | 5.0      |
| 0002214830 | 5.0      |
| 0002720213 | 5.0      |
| 0002326817 | 5.0      |
| 0002254352 | 5.0      |
| 000225316X | 5.0      |
| 0002199203 | 5.0      |
| 0001712705 | 5.0      |
| 0002617501 | 5.0      |
| 0002113848 | 5.0      |
| 0001840266 | 5.0      |
| 0002117576 | 5.0      |
| 0001360183 | 5.0      |
| 0000202010 | 5.0      |
| 0002179083 | 5.0      |
| 0001954792 | 5.0      |
| 0002005468 | 5.0      |
| 0005097231 | 5.0      |
+------------+----------+
20 rows selected (119.311 seconds)

As you see Drill run well on this scenario too. The total query time is: 1 min 59 seconds.

Then I gave Mysql a try. I know for limited memory Mysql handles this scale of data very slow. Though the VM has only 2GB memory, I had to adjust two important memory arguments for Mysql.

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 402653184 |
+-------------------------+-----------+
1 row in set (0.01 sec)

mysql> show variables like 'key_buffer_size';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| key_buffer_size | 134217728 |
+-----------------+-----------+
1 row in set (0.02 sec)

The tuning to Mysql includes ‘innodb_buffer_pool_size’ was set to 384MB, ‘key_buffer_size’ was set to 128MB.

After then I created the table, and loaded the data into this table by using the statements below.

mysql> create table rate(userId varchar(24), itemId varchar(24),rating float, time int);
Query OK, 0 rows affected (0.11 sec)

mysql> load data local infile 'skydrive/rate.csv' into table rate FIELDS TERMINATED BY ',';
Query OK, 82677131 rows affected (21 min 21.25 sec)
Records: 82677131  Deleted: 0  Skipped: 0  Warnings: 0

Loading the data takes time 21 min 21 sec. And I need to add an index to the queried column, in this case it’s itemId.

mysql> create index itemIndex on rate(itemId);
Query OK, 0 rows affected (9 min 22.60 sec)
Records: 0  Duplicates: 0  Warnings: 0

Finally I made the query in Mysql:

mysql> select itemId, avg(rating) as avg_rate from rate group by itemId order by avg_rate desc limit 20;
+------------+----------+
| itemId     | avg_rate |
+------------+----------+
| 0000191639 |        5 |
| 0000143529 |        5 |
| 0000143502 |        5 |
| 0000202010 |        5 |
| 0000053155 |        5 |
| 0001019880 |        5 |
| 0001018043 |        5 |
| 000014357X |        5 |
| 000077135X |        5 |
| 0001026038 |        5 |
| 0000401048 |        5 |
| 0000000078 |        5 |
| 0000230022 |        5 |
| 0000913154 |        5 |
| 0000143588 |        5 |
| 0000466603 |        5 |
| 0001024388 |        5 |
| 0001006657 |        5 |
| 0000791156 |        5 |
| 0000174076 |        5 |
+------------+----------+
20 rows in set (16 min 29.75 sec)

Mysql’s total query time is: 16 min 30 seconds.

For comparison to Mysql, I installed Postgresql in this VM. It’s the default installation from Ubuntu apt source, with the basic tuning as below.

postgres=# show shared_buffers;
 shared_buffers 
----------------
 384MB
(1 row)

postgres=# show work_mem;
 work_mem 
----------
 16MB
(1 row)

I created the same table as in Mysql and setup the index to the queried column.

bigdata=# \d rate
                       Table "public.rate"
 Column |         Type          | Collation | Nullable | Default 
--------+-----------------------+-----------+----------+---------
 userid | character varying(24) |           |          | 
 itemid | character varying(24) |           |          | 
 rating | double precision      |           |          | 
 time   | integer               |           |          | 
Indexes:
    "itemindex" btree (itemid)

Then I loaded the data from csv to the table:

bigdata=# \copy rate FROM '/home/pyh/skydrive/rate.csv' DELIMITER ',' CSV;
COPY 82677131

And the same query was issued to Postgresql. As you see the command top’s output following, Postgresql uses 3 threads in the progress of shuffling. This consumes out all the available memory.

0945 postgres  20   0 1311264 640036   3336 D  20.9 31.4   0:20.64 postgres                                                                      
30944 postgres  20   0 1335840 637304   3356 D  18.6 31.2   0:20.86 postgres                                                                      
30330 postgres  20   0 1383316 558332   3272 R  49.3 27.4   4:45.60 postgres 

But finally Postgresql finished the job as well:

bigdata=# select itemId, avg(rating) as avg_rate from rate group by itemId order by avg_rate desc limit 20;
   itemid   | avg_rate 
------------+----------
 0001006657 |        5
 0001024388 |        5
 0000913154 |        5
 0000791156 |        5
 0001019880 |        5
 0000466603 |        5
 000077135X |        5
 0000191639 |        5
 0000174076 |        5
 000014357X |        5
 0001018043 |        5
 0000202010 |        5
 0000143529 |        5
 0000230022 |        5
 0000000078 |        5
 0000401048 |        5
 0000053155 |        5
 0000143588 |        5
 0000143502 |        5
 0001026038 |        5
(20 rows)

Time: 156100.056 ms (02:36.100)

The total query time in Postgresql is: 2 min 36 seconds.

So, for this limited memory and this scale of dataset, the specific big data apps have much more efficiency than the traditional Mysql. Though Postgresql is one of the RDBMs, it’s much faster than Mysql too. Because it uses multi-threading for the shuffling progress, while the drawback is it consumes the most memory than all the three others.

All queries above were run for several times, the minimum values were taken as the final results.

The query time comparison:

Data AppSparkDrillMysqlPostgresql
Query Time106 sec119 sec990 sec156 sec

Here are the App’s versions:

// Mysql version
mysql> select version();
+-------------------------+
| version()               |
+-------------------------+
| 5.7.37-0ubuntu0.18.04.1 |
+-------------------------+
1 row in set (0.01 sec)

// Postgresql version
bigdata=# select version();
                                                               version                                                                
--------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 10.19 (Ubuntu 10.19-0ubuntu0.18.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
(1 row)

// Drill version
apache drill (dfs.skydrive)> select version from sys.version;
+---------+
| version |
+---------+
| 1.20.0  |
+---------+
1 row selected (0.641 seconds)

// Spark version
version 3.2.1        
Using Scala version 2.13.5 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_321)

The VM I was using for this test has 2G dedicated memory, 2 Intel cores, 50G NVME disk. It’s good to see all Apps run well under this limited memory. But Mysql is really slow comparing to the others.

A simple comparison for three SQL engines

I have a data from our production environment. The data is just words list, which contains 11922695 items.

I load the data into Mysql, Spark and Drill for a simple test against their query performance.

The test environment:

  • OS: Ubuntu 18.04 Linux x86_64, KVM instance
  • Hardware specs: 2 AMD cores, 4GB memory, 40GB NVME disk
  • Java: Openjdk version 11.0.13
  • Mysql: version 5.7.36, default installation, only one change by setting key_buffer_size to 256MB
  • Spark: version 3.2.0, deployed as local mode
  • Drill: version 1.20, run as drill-embedded

I load the words into the above databases first.

In spark:

scala> val list = sc.textFile("words.txt").toDF("word")
list: org.apache.spark.sql.DataFrame = [word: string]

In mysql:

mysql> create table words (word varchar(32));
Query OK, 0 rows affected (0.01 sec)

mysql> load data local infile './words.txt' into table words;
Query OK, 11922695 rows affected (29.88 sec)

In drill I need to rename the file to a csv, then query it directly like:

apache drill (dfs.pyh)> select * from `words.csv` limit 2;
+------+
| WORD |
+------+
| on   |
| jan  |
+------+
2 rows selected (0.235 seconds)

Hence I can make a simple SQL query to the three data objects. The purpose is to group the words and count their numbers.

First query in spark:

scala> list.groupBy("word").count.orderBy(desc("count")).show(20)
+----+------+                                                                   
|word| count|
+----+------+
| the|597563|
|  to|466569|
|   a|228042|
|  is|223282|
| and|215099|
|  in|176847|
|   i|174579|
| for|165258|
|  on|164483|
|  of|161266|
|this|159244|
| you|128854|
|that|126949|
|  at|126562|
|  it|117224|
|  be| 89777|
|from| 87112|
|with| 86998|
| not| 85245|
|  if| 82798|
+----+------+
only showing top 20 rows

Spark doesn’t show its query time. I got the time roughly by iOS’s Stopwatch app. I have run above queries some times, the average query time is about 3.7 second.

Second query in mysql:

mysql> select word,count(*) as dd from words group by word order by dd desc limit 20;
+------+--------+
| word | dd     |
+------+--------+
| the  | 597563 |
| to   | 466569 |
| a    | 228042 |
| is   | 223282 |
| and  | 215099 |
| in   | 176847 |
| i    | 174579 |
| for  | 165258 |
| on   | 164483 |
| of   | 161266 |
| this | 159244 |
| you  | 128854 |
| that | 126949 |
| at   | 126562 |
| it   | 117224 |
| be   |  89777 |
| from |  87112 |
| with |  86998 |
| not  |  85245 |
| if   |  82798 |
+------+--------+
20 rows in set (11.05 sec)

Then I created an index for this mysql table and query again:

mysql> create index wordIndex on words(word);
Query OK, 0 rows affected (40.21 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> select word,count(*) as dd from words group by word order by dd desc limit 20;
+------+--------+
| word | dd     |
+------+--------+
| the  | 597563 |
| to   | 466569 |
| a    | 228042 |
| is   | 223282 |
| and  | 215099 |
| in   | 176847 |
| i    | 174579 |
| for  | 165258 |
| on   | 164483 |
| of   | 161266 |
| this | 159244 |
| you  | 128854 |
| that | 126949 |
| at   | 126562 |
| it   | 117224 |
| be   |  89777 |
| from |  87112 |
| with |  86998 |
| not  |  85245 |
| if   |  82798 |
+------+--------+
20 rows in set (5.10 sec)

As you see mysql has huge performance improvement after adding the index.

The last query in drill:

apache drill (dfs.pyh)> select word,count(*) as dd from `words.csv` group by word order by dd desc limit 20;
+------+--------+
| word |   dd   |
+------+--------+
| the  | 597563 |
| to   | 466569 |
| a    | 228042 |
| is   | 223282 |
| and  | 215099 |
| in   | 176847 |
| i    | 174579 |
| for  | 165258 |
| on   | 164483 |
| of   | 161266 |
| this | 159244 |
| you  | 128854 |
| that | 126949 |
| at   | 126562 |
| it   | 117224 |
| be   | 89777  |
| from | 87112  |
| with | 86998  |
| not  | 85245  |
| if   | 82798  |
+------+--------+
20 rows selected (3.507 seconds)

I have run the above queries some times, choose an average running time 3.5 second.

So the comparison of query time in three applications:

SparkMysqlDrill
Query time3.7swith index: 5.1s
without index: 11s
3.5s
Query time comparison in three SQL engines

It’s not surprised that for big data Mysql is not as efficient as the other two. Spark and Drill have the similar performance in this scenario. While Drill is much easier to use as you don’t have to know Scala programming.

Regex comparison in Perl and Scala

Perl’s regex is still very fast. Its running speed is amazing. Scala’s regex can work, but it’s as 3 times slower as Perl. Just got the result from my experience.

Here is the use case. Reads from a text file which is as big as gigs. Filters the lines with regex, and splits the line into words, then filters the words with another regex. Finally prints out the words.

This is perl script:

use strict;

open HDW,">","words.txt" or die $!;
open HD,"msg.txt" or die $!;

while(<HD>) {
  next if /^[^0-9a-zA-Z\s]/;
  chomp;
  my @words = split/\s+/,$_;
  for my $w (@words) {
    $w=lc($w);
    if ($w=~/^[a-z0-9]+$/ and length($w) < 30){
       print HDW $w,"\n";
    }
  }
}

close HD;
close HDW;

This is scala script:

import scala.io.Source

val patt1 = """^[^0-9a-zA-Z\s].*$"""
val patt2 = """^[a-z0-9]+$"""

val lines = Source.fromFile("msg.txt").getLines().filter(! _.matches(patt1))

for (x <- lines) {
  x.split("""\s+""").map(_.toLowerCase).filter(_.matches(patt2)).filter(_.size < 30).foreach {println}
}

Though scala is compiled as class, its executing time is 3 times to perl.

$ scalac -Xscript SplitWords words-parse.scala 
$ time scala SplitWords > scala-words.txt 

real	0m36.858s
user	0m25.494s
sys	0m13.449s

$ time perl words-parse.pl 

real	0m12.115s
user	0m11.770s
sys	0m0.184s

And, I found a feature that, scala’s regex must be full matching, while perl’s can be part matching.

Such as this matching in scala gets false:

scala> val str = "hello word"
val str: String = hello word

scala> str.matches("^hello")
val res0: Boolean = false

But in perl it’s always true:

$ perl -le '$str ="hello word"; print "true" if $str=~ /^hello/'
true

Regardless of language features, doing the right thing with the right tool is always right.

[ Update 1 ]

Thanks to the guy on scala forum, who points out that I can compile the regex only once. Then I improved the program as below:

import scala.io.Source

val patt1 = """[^0-9a-zA-Z\s].*""".r
val patt2 = """[a-z0-9]+""".r

val lines = Source.fromFile("msg.txt").getLines()

for {
  line <- lines
  if ! patt1.matches(line)
  word <- line.split("""\s+""").map(_.toLowerCase)
  if patt2.matches(word) && word.size < 30
} {
  println(word) 
}

Re-run and it takes less 6 seconds than before, about 30 seconds to finish the job. Still much slower than perl.

Please notice: this updated program works only in scala 2.13. My Spark application requires scala 2.12, which doesn’t work as the way.

[ Update 2 ]

Scala’s regex is anchored by default. So it takes the full matching. To take a part matching as perl, could use this (in scala 2.13):

scala> val regex = """^hello""".r.unanchored
val regex: scala.util.matching.UnanchoredRegex = ^hello

scala> regex.matches("hello word")
val res0: Boolean = true

As you see, when declared as unanchored, the regex can take part matching.

programming with Spark structure streaming

In my last blog I played programming with Spark streaming, which is called DStream.

This article I program with Spark structure streaming, which is a new way for streaming handling.

What’s the difference between DStream and structure streaming? The former is based on Spark’s traditional RDD API, while the latter is based on Spark’s SQL engine.

From my thought, if you want more transforms to the original data such as data cleaning, DStream is more useful. Since RDD provides a lot of higher order functions for data transform, such as map, reduce etc.

If you want more aggregate functions, such as statistics and reports, structure streaming is more convenient. Since SQL engine is powerful for implementation of this kind of jobs, such as group, count, sort etc.

But, structure streaming is much easier to use than DStream. It’s higher optimized. You can just program with structure streaming as the way of regular spark session.

To play with the demo, first we need a socket server which prints the data continuously to remote socket. And a streaming client will receive the data from the socket.

The socket server has been given in my last blog. Please start up it in a separate terminal.

Then, I follow the official demo to get the scala code below to handle the streaming.

import org.apache.spark.sql.SparkSession

object Myjob {
  def main(args: Array[String]): Unit = {
    if (args.length < 2) {
      System.err.println("Usage: StructuredNetworkWordCount <hostname> <port>")
      System.exit(1)
    }

    val host = args(0)
    val port = args(1).toInt

    val spark = SparkSession
      .builder
      .appName("StructuredNetworkWordCount")
      .getOrCreate()

    import spark.implicits._

    // Create DataFrame representing the stream of input lines from connection to host:port
    val lines = spark.readStream
      .format("socket")
      .option("host", host)
      .option("port", port)
      .load()

    // Split the lines into words
    val words = lines.as[String].flatMap(_.split(" "))

    // Generate running word count
    val wordCounts = words.groupBy("value").count()

    // Start running the query that prints the running counts to the console
    val query = wordCounts.writeStream
      .outputMode("complete")
      .format("console")
      .start()

    query.awaitTermination()
  }
}

How to package and deploy the app? Please see my last blog, they are almost the same.

The final step is to run the structure streaming from Spark:

$ spark-submit --class "Myjob" --master local[2] target/scala-2.12/my-strucutre-streaming-job_2.12-1.0.jar localhost 9999

We can see the continuous output in the screen for words counting:

-------------------------------------------
Batch: 190
-------------------------------------------
+-------+-----+
|  value|count|
+-------+-----+
| orange|  360|
|  apple|  372|
|  mango|  380|
| tomato|  362|
|apricot|  357|
| cherry|  366|
| banana|  328|
|  lemon|  341|
|   plum|  365|
|  peach|  372|
+-------+-----+


-------------------------------------------
Batch: 191
-------------------------------------------
+-------+-----+
|  value|count|
+-------+-----+
| orange|  362|
|  apple|  378|
|  mango|  382|
| tomato|  363|
|apricot|  358|
| cherry|  368|
| banana|  332|
|  lemon|  342|
|   plum|  367|
|  peach|  377|
+-------+-----+

-------------------------------------------
Batch: 192
-------------------------------------------
+-------+-----+
|  value|count|
+-------+-----+
| orange|  363|
|  apple|  381|
|  mango|  386|
| tomato|  364|
|apricot|  361|
| cherry|  374|
| banana|  333|
|  lemon|  344|
|   plum|  369|
|  peach|  378|
+-------+-----+

The application environment:

  • OS: ubuntu 18.04 x86_64, a KVM instance
  • Ram: 4GB dedicated
  • CPU: double AMD 7302 processor
  • Spark: 3.2.0
  • Scala: 2.12.15