Migration of all RDD functionality over to DataFrames

[lintool]

We need to migrate all current RDD functionality over to DataFrames. This means porting all matchbox UDFs over to DF UDFs.

There are two possible ways to do this - we can simply take matchbox UDFs and wrap them, or rewrite them from scratch. I suggest we revisit one by one, which will give us an opportunity to refine the UDF we actually want.

For example, the current RDD matchbox ExtractDomain is implemented a bit differently than the DF version we've been playing with... it, for example, strips the prefix www, whereas the RDD impl doesn't. I like the newer implementation better, but open to discussion.

Also, this is an issue we'll come across sooner or later:
https://stackoverflow.com/questions/33664991/spark-udf-initialization

I have a general question we need to look into from the performance perspective: what's the lifecycle status of a Spark DF UDF? In particular, if there's initialization like compiling regexp, we don't want to do that over and over again... we want to have an init stage?

@TitusAn let's start developing in parallel the DF versions of the apps in #222 and try and work this out?

[ruebot]

@jrwiebe I have a note here from our call to "Go through the scala dir and identify all the functions that take in RDD and do not take in DF, then create tickets for JWb." Do you want me to do that granular of a level, or do you want to use this issue to take care of it?

[jrwiebe]

This is fine.

[ruebot]

@ianmilligan1 @lintool this look the basic inventory?

rdd	data frame
keepValidPages
extractValidPages	extractValidPagesDF
	extractHyperlinksDF
	extractImageLinksDF
	extractImageDetailsDF
keepImages
keepMimeTypes
keepUrls
keepUrlPatterns
keepDomains
keepLanguages
keepContent
discardMimeTypes
discardDate
discardUrls
discardUrlPatterns
discardDomains
discardContent
extractFromRecords
extractFromScrapeText
WriteGEXF
ExtractPopularImages
DomainFrequencyExtractor
DomainGraphExtractor
PlainTextExtractor
ExtractGraphX

[lintool]

I think we should just leave this as a "catch-all" issue, open.

IMO, this should be driven by the documentation update - go through docs, everything that we do with RDDs, we make sure there's a corresponding DF code example. When the docs have everything in both RDD and DF, I think we're done.

[ruebot]

@SinghGursimran this one is tied to #372, and should become a lot clearer as to what needs to be done to close this one. I think we're pretty close here.

[ruebot]

From @lintool

Sorry to be late to the party... I seem to faintly recall that we were going to rename all our UDFs to MyFuncDF and MyFuncRDD to disambiguate. Were we still going to do that? Circle around in another PR?

This spawned from a Slack convo Jimmy and I had in a non-public channel that never made it to the ticket.

I have a branch working through this now.

[ruebot]

@SinghGursimran we still need to do discardMimeTypesTikaDF. Looks like you have discardMimeTypesDF duplicated.

[ruebot]

@SinghGursimran nvm. I see it now :-)

aut/src/main/scala/io/archivesunleashed/package.scala

Lines 243 to 250 in bc0d663

	/** Removes all data but selected mimeTypeTikas specified.
	*
	* @param mimeTypesTika a list of Mime Types Tika
	*/
	def keepMimeTypesTikaDF(mimeTypes: Set[String]): DataFrame = {
	val takeMimeTypeTika = udf((mimeTypeTika: String) => mimeTypes.contains(mimeTypeTika))
	df.filter(takeMimeTypeTika(DetectMimeTypeTikaDF($"bytes")))
	}

[ruebot]

Created three new issues that should cover the Python implementations of most of the work here.

• Implement Python versions of Matchbox utilities #408
• Implement Python versions of App utilities #409
• Implement Python versions of Serializable APIs #410

[ruebot]

Merging #441 fully resolved this.

[lintool]

🎉

[ruebot]

We forgot about ExtractBoilerplateRDD 🤦‍♂️

[ruebot]

Oh, it's there ExtractBoilerpipeTextDF.

Sorry for the confusion. 🤦‍♂️