Issue: MessageDigest was used as a singleton for this UDF exposed function. As MessageDigest is not threadSafe, it caused duplicate hash values when a large volume of concurrent data was processed.
Solution: So changed the logic to initialize the object for each call.
So see below the old and new approaches highlighted below (obsolete code can be removed)
Further reference:
how-to-solve-non-serializable-errors-when-instantiating-objects-in-spark-udfs/
SELECT id,
crew_id,
amount,
CASE type
WHEN @curType THEN @curRow := @curRow + 1
ELSE @curRow := 1
END AS rank,
@curType := type AS type
FROM Table1 p
JOIN (SELECT @curRow := 0, @curType := '') r
ORDER BY crew_id, typeSELECT foreignId, createTimestamp,CASE executionId WHEN @curType THEN @curRow := @curRow + 1 ELSE @curRow := 1 END AS rank, @curType := executionId AS executionId FROM job_queue_prd p JOIN (SELECT @curRow := 0, @curType := '') r WHERE p.executionID in (204626, 204851) ORDER BY executionId, createTimestamp asc;
### Getting current & prior instanceId & the rank based on execId & createTimestampSET @instanceId=0; SELECT foreignId, createTimestamp, @instanceId prior_foreignId, @foreignId:=foreignId foreignId,
CASE executionId WHEN @curExecId THEN @curRow := @curRow + 1 ELSE @curRow := 1 END AS rank, @curExecId := executionId AS executionId FROM job_queue_prd p JOIN (SELECT @curRow := 0, @curExecId := '') r WHERE p.executionID in (204626, 204851) ORDER BY executionId, createTimestamp asc;
Git is a distributed version control system.
Stash is a repository management system of Atlassian - in 2015 its renamed to BitBucket - So, its a management tool for Git
There are many repository management systems you can use with Git.
One of the most popular is Stash in Enterprise world.
But when you look to open source world, GitHub is the most popular one as far as I know.
Ref: https://stackoverflow.com/questions/32294534/what-is-the-relationship-between-git-and-stash
@Builder annotation - if applied on a class (POJO) will create its Builder class automatically
Support @Builder on Person class will create PersonBuilder class ad you can set it as below
Person.builder().firstName("Adam").lastName("Savage") .city("San Francisco").jobTitle("TV Personality").build();
https://www.geeksforgeeks.org/tail-recursion-in-scala/
https://www.scala-exercises.org/scala_tutorial/tail_recursion
Example: GCD aka GCF https://www.khanacademy.org/math/cc-sixth-grade-math/cc-6th-factors-and-multiples/cc-6th-gcf/v/greatest-common-divisor
Closures
Trait
List manipulation
var myList = List.empty[String]
myList :+= "sree"
myList
res2: List[String] = List(sree)
Immutable by design - helps with concurrent programming
Option -
Yield - produces a value for each iteration
Null, Nil, None, Nothing
Null - absense of value
Nil - end of list
None - value of an Option which has no value in it
Nothing - lowest type in the entire type system (Method which throws exception returns Nothing as the return type; all values under val, var falls under this)
Extractor Object - with unapply method (match the value and take it apart)
Pattern matching - case statement
def matchValue(x: Int): String = x match {
case 1 => "One"
case 2 => "Two"
case _ => "many"
}
Queue val emptyQ = new scala.collection.mutable.Queue[Int]
Scala Closures are functions which uses one or more free variables and the return value of this function is dependent of these variable. The free variables are defined outside of the Closure Function and is not included as a parameter of this function. So the difference between a closure function and a normal function is the free variable. A free variable is any kind of variable which is not defined within the function and not passed as the parameter of the function. A free variable is not bound to a function with a valid value. The function does not contain any values for the free variable.
Example:
If we define a function as shown below:
Example: udf, rdd, dataframe
Given a you have a Scala object holding some data that you want to store or send around by serializing the object. It turns out that the object is also capable of performing some complex logic and it stores the results of these calculations in its field values. While it might be efficient to store the calculation results in memory for later lookup, it might be a bad idea to also serialize these fields as this will consume space you do not want to sacrifice or as this will increase network throughput (e.g., in Spark) resulting in more time being consumed than it requires to recalculate the fields. Now one could write a custom serializer for this task, but let us be honest: thats not really the thing we want to spent our time on.
This is where the @transient lazy val pattern comes in. In Scala lazy val denotes a field that will only be calculated once it is accessed for the first time and is then stored for future reference. With @transient on the other hand one can denote a field that shall not be serialized.
Putting this together we can now write our "recalculate rather than serialize logic":
http://fdahms.com/2015/10/14/scala-and-the-transient-lazy-val-pattern/
In Scala lazy val
denotes a field that will only be calculated once it is accessed for the first
time and is then stored for future reference.
With @transient
on the other hand one can denote a field that shall not be serialized.
So @transient lazy val --> as used in udf's utility Class --> tell the execution Engine that
dont serialize the variable (say cryptoLib object) while broadcasting the to be UDF object
(the UtilClass with the fuction to expose as udf closure) and once the object is @ spark
executor - create it only once ("lazy") for all records.
Decide what data goes into each dashboard based on who will use the dashboard and why they will use the dashboard.
https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/
