Upload
romi-kuntsman
View
2.564
Download
0
Embed Size (px)
Citation preview
Multidimensional Aggregations using Spark and DataFrames2015-11-10Romi Kuntsman, Senior Big Data Engineer
About me• Leading adoption of Apache Spark in Totango• Working with Spark for 1.5 years from version 1.0• Passionate about actionable big data analytics• Working with web scale and cloud since 2008• Previously: Outbrain, Foresight, RockeTier,
Mamram• B.Sc. in Bioinformatics from Open University • LinkedIn: https://il.linkedin.com/in/romik• email: [email protected]
Agenda
• Totango Data Flow Overview
• Apache Spark DataFrames Introduction
• Merging Multiple Results Efficiently
• Open issues and questions
Data Flow Overview“Numbers have an important story to tell.They rely on you to give them a voice.”
– Stephen Few
Let's talk about aggregations
You've all done this...
SELECTmodule,count(*)
FROMactivities
GROUP BYmodule
Aggregations with big data
You probably done or seen this before as well...
Life isn't so simple
Multiple levels of calculations
Different points of view
• First level aggregations (across last 7, 14, 30 days etc)–Counts (per account, activity, module, user etc)–Distinct counts (unique users in module etc)–Sessions (multiple activities grouped by time proximity)–Activity days (how many days had any activity)
• Higher level analytics:–Engagement Score (overall activity compared to others)–Change Metrics (how activity changes over time)–Account Health (good, average or poor)
• And more...
What do we need
• Easy way to develop a new aggregations• No boilerplate code, just business logic• Scalable and distributed• Accurate results (often underestimated)• Fast (short batch, but not realtime in this case)• Idempotent (same results on every run on same
input)• Multi-tenant (same computations on isolated
datasets)
Spark DataFrames“Simple things should be simple,
complex things should be possible.”– Alan Key
Spark DataFrames
• Table-like abstraction on top of Big Data• Able to scale from kilobytes to petabytes, node to
cluster• Transformations available in code or SQL• User defined functions can add columns• Actively developed optimizer• Spark 1.3 (March 2015) - initially released • Spark 1.4 (June 2015) - mature and usable• Spark 1.5 (September 2015) - performance optimized• Spark 1.6 (not yet released) - more optimizations
Look ma, no map reduce!
• module counts:–events.groupBy(module).count
• module unique users:–events.groupBy(module,user).count.group
By(module).count
User defined function
• activity days:
–udfRegistration.register("date_to_days",
new DateToDays())
–eventsWithDate = sqlContext.query(
"select *,date_days(date) from events")
–eventsWithDate.groupBy(module,day).count
RDDs interoperate with DataFrames
Note: sometimes we do need to go from DataFrame to Java and back to accomplish some things:
RDD<FooBar> myRdd =
dataframe.toJavaRDD.map(...).groupBy(...)
newDataFrame = createDataFrame(myRdd,
FooBar.class)
Advantage: speed, ease of development
Disadvantages: less flexible, limited aggregations,
strict simple schema
When going from DF to RDD: toJavaRDD forces
computation; losing Catalyst optimizer in the
transition
Future: maybe can be replaced by UDAF (user
defined aggregate function) in upcoming Spark
releases
DataFrames vs. RDDs
Merge Multiple Results
Merge the results
We've calculated aggregations across various dimensions. Now it's time to collect them grouped by entity (account, user, etc).
Partitioning scheme
• RDD<Value> - not partitioned by key (there is not key…)→ Union of many RDD results will shuffle everything
• DataFrames are not partitioned by column (to be fixed…)→ Union of many DFs results will shuffle everything
• PairRDD<Key,Value> with partitionBy(partitioner) is partitioned→ Union of many PairRDDs which used the same partitioner will be partitioned together!Partitioner interface: (default HashPartitioner fits most cases)
int getPartition(key)
int numPartitions
Number of partitions
• Processing always happens in chunks that can fit into one executor memory
• Too few partitions - some may not fit and you get a OOM
• Too many partitions - many small steps and overall long time
• In a multitenant environment - have to find a formula by input size that works for everyone, from smallest to largest
• When re-partitioning, take note of data being reshuffled
• No magic formula for the optimal number of partitions :-(
Name your stages• Stages can be named
sparkContext.setCallSite (per thread)
To cache or not to cache
• With RDDs you cache at every intersection
• With DataFrames, best to cache input, then optimizer
plans
• Cache when dividing input into sub sections (like time
slices)
• For Caching DataFrame - need to cause computation,
otherwise only LogicalPlan is cache and optimizer
decides what to do (for example when we cache for
time data subset)
More Spark gotchas...
• When loading from Parquet, can't partition by column hash, only by column value
• Use Kryo for serialization (register all classes)• Use standalone shuffle service to avoid losing
shuffles when worker crashes (like in OutOfMemory)
We'll upload separate posts aboutthese and others on our blog
http://labs.totango.com/
• Check out our blog: http://labs.totango.com/• We're hiring!
http://www.totango.com/jobs/–Backend / Big Data Engineers–DevOps–Application / FrontEnd
• Stay in touch–[email protected]–https://il.linkedin.com/in/romik
Questions?