Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From Pipelines to Refineries: Scaling Big Data Applications

756 views

Published on

Big data tools are challenging to combine into a larger application: ironically, big data applications themselves do not tend to scale very well. These issues of integration and data management are only magnified by increasingly large volumes of data.

Apache Spark provides strong building blocks for batch processes, streams and ad-hoc interactive analysis. However, users face challenges when putting together a single coherent pipeline that could involve hundreds of transformation steps, especially when confronted by the need of rapid iterations.

This talk explores these issues through the lens of functional programming. It presents an experimental framework that provides full-pipeline guarantees by introducing more laziness to Apache Spark. This framework allows transformations to be seamlessly composed and alleviates common issues, thanks to whole program checks, auto-caching, and aggressive computation parallelization and reuse.

Published in: Software
  • Be the first to comment

  • Be the first to like this

From Pipelines to Refineries: Scaling Big Data Applications

  1. 1. From pipelines to refineries: scaling big data applications Tim Hunter
  2. 2. About Me • Tim Hunter • Software engineer @ Databricks • Ph.D. from UC Berkeley in Machine Learning • Very early Spark user • Contributor to MLlib • Author of TensorFrames and GraphFrames
  3. 3. Introduction • Spark 2.2 in the release process • Spark 2.3 being thought about • This is the time to discuss Spark 3 • This presentation is a personal perspective on a future Spark
  4. 4. Introduction As Spark applications grow in complexity, what challenges lie ahead. Can we find some good foundations for building big data frameworks? There is nothing more practical than a good theory. James Maxwell
  5. 5. What category does Spark live in? An applicative? A monad? A functor?
  6. 6. Introduction • Anything presented here can be implementedin a modern programming language • No need to know Haskell or category theory
  7. 7. Outline • State of the union • What is goodaboutSpark? • What are the trends? • Classics to the rescue • Fightingthe fourhorsemen of the datapocalypse • Laziness to the rescue • From theory to practice • Makingdata processing great again
  8. 8. State of the union • What we strive for Ad-hoc Queries Input Stream Output Sink Continuous Application StaticData >_
  9. 9. State of the union • What we deal with: • Coordinatinga few tasks
  10. 10. State of the union • The (rapidly approaching) future • Thousandsof inputsources • Thousandsof concurrent requests • Mixinginteractive,batch, streaming • How do we enable this?
  11. 11. The state of the union • The image of a pipeline gives you the illusion of simplicity • One inputand one output • Current big data systems: the tree paradigm • Combine multipleinputsinto a single output • The SQL paradigm • Followed by Spark • A forest is more than a set of trees • Multipleinputs,multipleoutputs • The DAG paradigm
  12. 12. Data processing as a complex system • Orchestrating complex flows is nothing new: • Tracking andscheduling:Gantt,JIRA, etc. • Buildtools:Bazel (Blaze), Pants, Buck • General schedulers: AirFlow, FBLearner, Luigi • Successfully used for orchestrating complex data processing • But they are general tools: • They miss the fact that we are dealingwith data pipelines • Separate system for schedulingandfor expressing transforms • No notionof schema, no control of the side effects
  13. 13. Data processing as a complex system • Any software becomes an exercise in managing complexity. • Complexity comes from interactions • Howto reduce interactions? • How to build more complex logic based on simpler elements? • Howto compose data pipelines? • Continuous evolution • Let’s changethe enginesin mid-flight,because it soundsgreat
  14. 14. The ideal big processing system: • Scalability • in quantity (big data) and diversity (lots of sources) • Chaining • express the dependencies between the datasets • Composition • assemble morecomplex programsout of simpler ones • Determinism • given a set ofinput data, the outputshould be unique* • Coffee break threshold • quick feedback to the user
  15. 15. How is Spark faring so far? • You can do it, but it is not easy • Spark includes multiple programming models: • The RDD model: low-level manipulation of distributed datasets • Mostly imperativewith some lazy aspects • The Dataset/Dataframes model: • Same as RDD,with some restrictions anda domain-specificlanguage • The SQL model: only one output, only one query
  16. 16. What can go wrong with this program? all_clicks = session.read.json("/tables/clicks/year=2017") all_clicks.cache() max_session_duration = all_clicks("session_duration").max() top_sessions = all_clicks.filter( all_clicks("session_duration") >= 0.9 * max_session_duration) top_ad_served = top_sessions("ad_idd") top_ad_served.write.parquet("/output_tables/top_ads") leak typo missing directory a few hours…
  17. 17. The 4 horsemen of the datapocalypse • Eager evaluation • Missing source or sink • Resource leak • Typing (schema) mismatch
  18. 18. Classics to the rescue
  19. 19. Theoretical foundations for a data system • A dataset is a collection of elements, all of the same type • Scala: Dataset[T] • Principle: the content of a dataset cannot be accessed directly • A dataset can be queried • An observable is a single element, with a type • intuition: datasetwith a singlerow • Scala: Observable[T]
  20. 20. Theoretical foundations for a data system Transform President Kitesurfer Still senator Observe count = 3 largest hand =
  21. 21. Theoretical foundations for a data system • Principle: the observation only dependson the content of the dataset • You cannotobserve partitions,ordering of elements, locationon disk, etc. • Mathematical consequence: all reduction operations on datasets are monoids: • f(AUB) = f(A) + f(B) = f(B) + f(A) • f(empty) = 0
  22. 22. Theoretical foundations for a data system • Principle: closed world assumption • All the effects are modeledwithin the framework • The inputsand the transforms are sufficientto generate the outputs • Practical consequence: strong checks and sci-fi optimizations
  23. 23. Examples of operations • They are what you expect: • Dataset[Int] : a datasetof integers • Observable[Int]: an observationon a dataset • max: Dataset[Int] => Observable[Int] • union: (Dataset[Int], Dataset[Int]) => Dataset[Int] • collect: Dataset[Int] => Observable[List[Int]]
  24. 24. Karps • An implementation of these principles on top of Spark (Haskell + Scala) • It outputs a graph of logical plans for Spark (or other systems) • Follows the compiler principle: • I willtry to prove you wronguntilyou have a good chance of being right • Karps makes a number of correctness checks for your program • It acts as a global optimizer for your pipeline
  25. 25. Demo 1
  26. 26. This is useless! • Lazy construction of very complex programs • Most operations in Spark can be translated to a small set of primitive actions with well-defined composition rules. • The optimizer can then rewrite the program without changing the outcome • Optimizations can leverage further SQL optimizations
  27. 27. Dealing with In and Out • The only type of I/O: read and write datasets • This is an observable • Operations are deterministic+ results are cached • -> only recompute when the data changes • Demo
  28. 28. Example: Caching 1 data.json count (+) data.json timestamp=2 hash=3ab5 count hash=6e08 data.json count 1 (+) hash=1aac data.json timestamp=2 hash=3ab5 count hash=6e02 1 (+) hash=1aad
  29. 29. Example: graph introspection
  30. 30. Future directions • Python interface (interface + pandas backend) • Writer module • Finish GroupBy (cool stuff ahead) • SQL (simple and cool stuff to do in this area)
  31. 31. Conclusion: trends in data processing • How to manage the complexity of data flows? • Taking inspiration from the functional world • Spark provides solid foundation • Laziness, declarative APIs alleviate complexity
  32. 32. Trying this demo • https://github.com/krapsh/kraps-haskell • Notebooks + Docker image: • https://github.com/krapsh/kraps-haskell/tree/master/notebooks • Server part (scala): • https://github.com/krapsh/kraps-server
  33. 33. SPARK SUMMIT 2017 DATA SCIENCE AND ENGINEERING AT SCALE JUNE 5 – 7 | MOSCONE CENTER | SAN FRANCISCO ORGANIZED BY spark-summit.org/2017
  34. 34. Thank You

×