Spark & Cassandra at DataStax Meetup on Jan 29, 2015

Editor's Notes

• #2: Q) Who knows why the project was named Spark? REMEMBER to say out loud the % of hands that go up for each of these: Q-1) How many people are Cassandra people.. sstables, bloom filters, vnodes? Q-2) How many people have launched a any Spark REPL like Scala or PySpark or Spark SQL and typed in anything at all? So, anyone who has hands-on experience with typing a Spark Transformation or Action? Q-3) I’ll be asking 2 questions, you can raise your hand for either or? How many people will be deploying Spark on Hadoop vs. people deploying Spark on Cassandra? Q-4) Will be deploying Spark in the Amazon Cloud? (You guys would be our ideal customers…) Mention that I was a Datastax Authorized Training partner and have been using C* since 2010. DS sent me to Singapore, Malaysia, Mexico, San Diego, NYC… just overall, I got to visit 20 countries and around 50 cities. But recently I started getting interested in Apache Spark and tried to learn it on my own and getting beyond the basics was really hard. So, I decided to join Databricks to *really* learn Spark. When you get stuck with something obscure like how preservesPartitioning works, it helps to be sitting a few feet away from Matei Zaharia when you’re studying how the engine that he built works. So, anyway, the goal of this talk teach you some of what I’ve learned in the past 6 months. I hope this talk will bootstrap you on the way to really understanding Spark and save you some of the headaches along the way. Say that the goal of this talk is to get you up and running with Spark’s Python API, basic programming in Spark, understanding it’s architecture and using SparkSQL
• #3: Here’s the Agenda for tonight, in no particular order
• #4: So, Data AmpLab was founded in Jan 2011 with a 6 year plan, has 65 students, faculty and postdocs. Matei designed the Fair Scheduler for Hadoop in mid-2008: https://issues.apache.org/jira/browse/HADOOP-3746 “The default job scheduler in Hadoop has a first-in-first-out queue of jobs for each priority level. The scheduler always assigns task slots to the first job in the highest-level priority queue that is in need of tasks. This makes it difficult to share a MapReduce cluster between users because a large job will starve subsequent jobs in its queue, but at the same time, giving lower priorities to large jobs would cause them to be starved by a stream of higher-priority jobs. This JIRA proposes a job scheduler based on fair sharing. Fair sharing splits up compute time proportionally between jobs that have been submitted, emulating an "ideal" scheduler that gives each job 1/Nth of the available capacity. When there is a single job running, that job receives all the capacity. When other jobs are submitted, tasks slots that free up are assigned to the new jobs, so that everyone gets roughly the same amount of compute time. This lets short jobs finish in reasonable amounts of time while not starving long jobs. This is the type of scheduling used or emulated by operating systems - e.g. the Completely Fair Scheduler in Linux. Fair sharing can also work with job priorities - the priorities are used as weights to determine the fraction of total compute time that a job should get.”
• #5: Remind audience to add me on LinkedIn and I’ll let them know of my next upcoming trainings.
• #6: Spark runs everywhere.. Hadoop, Mesos, standalone or in the cloud.. Amazon, Rackspace, Azure. Even Docker, the list just goes on and on… So, our goal is that you’ll be able to learn one processing engine and then re-use your knowledge against any data source or environment. But you do have to make that initial investment in learning Spark, and hopefully this presentation will get you going along the way. A philosophy of tight integration has several benefits. First, all libraries and higher level components in the stack benefit from improvements at the lower layers. For example, when Spark’s core engine adds an optimization, SQL and machine learning libraries automatically speed up as well. Second, the costs (deployment, maintenance, testing, support) associated with running the stack are minimized, because instead of running 5-10 independent software systems, an organization only needs to run one. This also means that each time a new component is added to the Spark stack, every organization that uses Spark will immediately be able to try this new component. This changes the cost of trying out a new type of data analysis from downloading, deploying, and learning a new software project to upgrading Spark. Finally, one of the largest advantages of tight integration is the ability to build applications that seamlessly combine different processing models. For example, in Spark you can write one application that uses machine learning to classify data in real time as it is ingested from streaming sources. Simultaneously analysts can query the resulting data, also in real-time, via SQL, e.g. to join the data with unstructured log files. In addition, more sophisticated data engineers & data scientists can access the same data via the Python shell for ad-hoc analysis. Others might access the data in standalone batch applications. All the while, the IT team only has to maintain one software stack. Why Scala from Matei: “When we started Spark, we wanted it to have a concise API for users, which Scala did well. At the same time, we wanted it to be fast (to work on large datasets), so many scripting languages didn't fit the bill. Scala can be quite fast because it's statically typed and it compiles in a known way to the JVM. Finally, running on the JVM also let us call into other Java-based big data systems, such as Cassandra, HDFS and HBase.” Note that Python 3 is not yet supported. You will have to use Python 2.6 or a newer 2.x branch.
• #7: Quote, Keep the simple things simple and make the complex possible. Today we’ll just keep the simple things simple and not get into the complexities of Machine Learning and advanced visualizations
• #8: This was just a preview academic paper
• #9: By the way, the original Google MapReduce whitepaper from 2008 was cited 12,600 times.
• #10: In the code: Counting tweets on a sliding window Build applications through high-level operators. Stateful exactly-once semantics out of the box. Combine streaming with batch and interactive queries.
• #11: In the code: Apply functions to results of SQL queries. Run unmodified Hive queries on existing warehouses. Connect through JDBC or ODBC. Special Interest Group for Management of Data This was an invited paper for the Industrial track to be held in Melbourne, Australia in early June 2015
• #13: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives
• #14: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives
• #15: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives As far as choosing a "good" number you generally want at least as many as the number of executors for parallelism. There already exists some logic to try and determine a "good" amount of parallelism, and you can get this value by calling sc.defaultParallelism
• #16: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives
• #17: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives
• #18: You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives Coalesce: “Decrease the number of partitions in the RDD to numPartitions. Useful for running operations more efficiently after filtering down a large dataset.” The coalesce function is only used to reduce the number of partitions
• #19: NEED TO FIX ANIMATIONS HERE (after save to C* addition) You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives
• #20: To-do: Put the ones for k/v pairs in a different color Map: Return a new distributed dataset formed by passing each element of the source through a function func. FlatMap: Similar to map, but each input item can be mapped to 0 or more output items (so func should return a Seq rather than a single item). Filter: Return a new dataset formed by selecting those elements of the source on which func returns true. Pipe: Pipe each partition of the RDD through a shell command, e.g. a Perl or bash script. RDD elements are written to the process's stdin and lines output to its stdout are returned as an RDD of strings. Sample: Sample a fraction fraction of the data, with or without replacement, using a given random number generator seed. Coalesce: Decrease the number of partitions in the RDD to numPartitions. Useful for running operations more efficiently after filtering down a large dataset.
• #21: Actions force the evaluation of the transformations required for the RDD they are called on, since they are required to actually produce output.
• #27: Wide dependency pretty much always means a shuffle Map, mappartitions, filters are cheap and can be pipelined Two different types of transformations: Narrow & Wide Wide dependencies are MORE expensive. Narrow transformations: where the input data depends on a constant # of partitions of the parent data. Like map, filter, mapPartitions. Wide transformations: where the input data depends on a variable # of partitions of the parent data. Like groupByKey or reduceByKey. Some operations can be narrow or wide depending on if the data has the same partitioning, like join.
• #28: Figure 5: Example of how Spark computes job stages. Boxes with solid outlines are RDDs. Partitions are shaded rectangles, In black if they are already in memory. To run an action on RDD G, we build stages at wide dependencies and pipeline nar- row transformations inside each stage. In this case, stage 1’s output RDD is already in RAM, so we run stage 2 and then 3. Sameer notes: Here the RDD B is hash partitioned, and is probably a much larger RDD than E. The data from E is having to be sent over the network.. More on this later. Not correct: Even during the join, Spark understands that these 2 RDDs (from Stage 1 and Stage 2) are hash partitioned to the same node. So, there is no need to over the network shuffling to make the Stage 3 RDD.
• #29: The set of stages produced for a particular action is termed a job . In each case when we invoke actions such as count , we are creating a job composed of one or more stages. Once the stage graph is defined, tasks are created and dispatched to an internal scheduler which varies depending on the deployment mode being used. Stages in the physical plan can depend on each other, based on the RDD lineage, so they will be executed in a specific order. For instance a stage that outputs shuffle data most occur before one that relies on that data being present.
• #30: The set of stages produced for a particular action is termed a job . In each case when we invoke actions such as count , we are creating a job composed of one or more stages. Once the stage graph is defined, tasks are created and dispatched to an internal scheduler which varies depending on the deployment mode being used. Stages in the physical plan can depend on each other, based on the RDD lineage, so they will be executed in a specific order. For instance a stage that outputs shuffle data most occur before one that relies on that data being present.
• #31: Mention that in YARN we can set spark.dynamicAllocation.enabled to True with minExecutors, maxExecutors and 3 timeouts. In cluster mode Spark depends on a cluster manager to launch executors and, in certain cases, to launch the driver. The cluster manager is a pluggable component in Spark. Each one of these resource managers has different pros and cons. One nice thing about running Spark in YARN, for example, is that you can dynamically resize the # of Executors in the application. This feature is not yet possible in Standalone mode. Static Partitioning: With this approach, each application is given a maximum amount of resources it can use, and holds onto them for its whole duration. Mesos: In “fine-grained” mode (default), each Spark task runs as a separate Mesos task. This allows multiple instances of Spark (and other frameworks) to share machines at a very fine granularity, where each application gets more or fewer machines as it ramps up and down, but it comes with an additional overhead in launching each task. This mode may be inappropriate for low-latency requirements like interactive queries or serving web requests. The “coarse-grained” mode will instead launch only one long-running Spark task on each Mesos machine, and dynamically schedule its own “mini-tasks” within it. The benefit is much lower startup overhead, but at the cost of reserving the Mesos resources for the complete duration of the application. In Standalone and Mesos course-grained, you can control the maximum number of resources Spark will acquire. By default, it will acquire all cores in the cluster (that get offered by Mesos), which only makes sense if you run just one application at a time. You can cap the max # of cores using conf.set("spark.cores.max", "10") (for example).
• #32: In YARN, ZooKeeper makes the SM HA You can make the Driver HA in standalone by setting the Boolean for –supervise to true when using Spark Submit (https://github.com/apache/spark/search?utf8=%E2%9C%93&q=supervise) In YARN the driver is HA via YARN primitives Spark.cores.max = the maximum amount of CPU cores to request for the application from across the cluster (not from each machine). If not set, the default will bespark.deploy.defaultCores on Spark's standalone cluster manager
• #33: As far as C* goes, for example, in my 15 GB VM, the Cassandra JVM gets about 3.5 GB of RAM The Driver runs within it a Task Scheduler. This scheduler schedules tasks on different Executors. When running in cluster mode, Spark utilizes a master-slave architecture with one central coordinator (called Driver) and many distributed Executors. A driver and its executors are together termed a Spark application. A Spark driver is responsible for compiling a user program into units of physical execution called tasks. # Directory for Spark temporary files. It will be used by Spark Master, Spark Worker, Spark Shell and Spark applications. export SPARK_TMP_DIR="/tmp/spark" # Directory where RDDs will be cached export SPARK_RDD_DIR="/var/lib/spark/rdd"
• #34: RDD Storage: when you call .persist() or .cache(). Spark will limit the amount of memory used when caching to a certain fraction of the JVM’s overall heap, set by spark.storage.memoryFraction Shuffle and aggregation buffers: When performing shuffle operations, Spark will create intermediate buffers for storing shuffle output data. These buffers are used to store intermediate results of aggregations in addition to buffering data that is going to be directly output as part of the shuffle. User code: Spark executes arbitrary user code, so user functions can themselves require substantial memory. For instance, if a user application allocates large arrays or other objects, these will content for overall memory usage. User code has access to everything “left” in the JVM heap after the space for RDD storage and shuffle storage are allocated.
• #36: You can also specify the column order by stating explicitly which columns you want returned…
• #37: Spark asks an RDD for a list of its partitions (splits) Each split consists of one or more token-ranges For every RDD partition: Spark asks RDD for a list of preferred nodes to process on Spark creates a task and sends it to one of the nodes for execution
• #38: DataStax Enterprise 4.5.2 and later can control the memory and cores offered by particular Spark Workers in semi­automatic fashion. The initial_spark_worker_resources parameter in dse.yaml file specifies the fraction of system resources available to the Spark Worker. The SPARK_WORKER_MEMORY option configures the total amount of memory that you can assign to all executors that a single Spark Worker runs on the particular node. The SPARK_WORKER_CORES option configures the number of cores offered by Spark Worker for use by executors. A single executor can borrow more than one core from the worker. The number of cores used by the executor relates to the number of parallel tasks the executor might perform. The number of cores offered by the cluster is the sum of cores offered by all the workers in the cluster.
• #39: export SPARK_REPL_MEM="256M“ will be removed in newer versions of DSE: “SPARK_REPL_MEM is a left-over from some earlier Spark version where I guess SPARK_DRIVER_MEM was not present.We're going to remove this setting in the next version. I created a ticket for this: https://datastax.jira.com/browse/DSP-4495”
• #40: DataStax Enterprise 4.5.2 and later can control the memory and cores offered by particular Spark Workers in semi­automatic fashion. The initial_spark_worker_resources parameter in dse.yaml file specifies the fraction of system resources available to the Spark Worker. The SPARK_WORKER_MEMORY option configures the total amount of memory that you can assign to all executors that a single Spark Worker runs on the particular node. The SPARK_WORKER_CORES option configures the number of cores offered by Spark Worker for use by executors. A single executor can borrow more than one core from the worker. The number of cores used by the executor relates to the number of parallel tasks the executor might perform. The number of cores offered by the cluster is the sum of cores offered by all the workers in the cluster.
• #41: To filter rows, you can use the filter transformation provided by Spark. Filter transformation fetches all rows from Cassandra first and then filters them in Spark. Some CPU cycles are wasted serializing and deserializing objects excluded from the result.  To avoid this overhead, CassandraRDD has a method that passes an arbitrary CQL condition to filter the row set on the server.
• #42: Spark Speculation will enable speculative execution of tasks, so tasks that are running slowly will be re-launched (this can help cut down on straggler tasks in large clusters). SE only kicks in after 75% of tasks are done (this is separate for each stage). This is off by default. There are 3 other settings: spark.speculation.interval (default 100: How often Spark will check for tasks to speculate, in milliseconds), spark.speculation.quantile (default 0.75; percentage of tasks which must be complete before speculation is enabled for a particular stage, spark.speculation.multiplier (default 1.5; how many times slower a task is than the median to be considered for speculation) Locality.wait defaults to 3000 ms. This is how long to wait to launch a data-local task before giving up and launching it on a less-local node. There are many locality levels (process-local, node-local, rack-local, any). You should increase this setting if your tasks are long and see poor locality. Spark.serializer: Class to use for serializing objects that will be sent over the network or need to be cached in serialized form. JavaSerializer is slow, but works with any object. Consider using org.apache.spark.serializer.KryoSerializer. Can be any subclass of org.apache.spark.Serializer
• #43: Research some cool things to say about the different RDDs and what they are used for
• #44: Why Scala from Matei: “When we started Spark, we wanted it to have a concise API for users, which Scala did well. At the same time, we wanted it to be fast (to work on large datasets), so many scripting languages didn't fit the bill. Scala can be quite fast because it's statically typed and it compiles in a known way to the JVM. Finally, running on the JVM also let us call into other Java-based big data systems, such as Cassandra, HDFS and HBase.”
• #45: Organizations from around the world often build dedicated sort machines (specialized software and sometimes specialized hardware) to compete in this benchmark.. Spark actually tied for 1st place with a team from University of California San Diego who have been working on creating a specialized sorting system called TritonSort. Winning this benchmark as a general, fault-tolerant system marks an important milestone for the Spark project. It demonstrates that Spark is fulfilling its promise to serve as a faster and more scalable engine for data processing of all sizes, from GBs to TBs to PBs.  Named after Jim Gray, the benchmark workload is resource intensive by any measure: sorting 100 TB of data following the strict rules generates 500 TB of disk I/O and 200 TB of network I/O. Requires read and write of 500 TB of disk I/O and 200 TB of network (b/c you have to replicate the output to make it fault taulerant) First time a system based on a public cloud system has won
• #46: Zero-Copy (terminology): With Netty, the data from disk only gets sent to one NIC buffer and sent out to other node from there. Older implementation (normal) would have to first copy to FileSystem kernel buffer cache, then to a Executor JVM user-space buffer, and then to kernel NIC buffer and out to the remove reducer node GC: Netty does an explicit managed memory, malloc (outside of JVM). Netty is in the normal Executor JVM process that allocates a bunch of memory buffers off-heap and manages these transport buffers entirely by itself.
• #47: In HDFS, reads normally go through the DataNode. Thus, when the client asks the DataNode to read a file, the DataNode reads that file off of the disk and sends the data to the client over a TCP socket. So-called "short-circuit" reads bypass the DataNode, allowing the client to read the file directly. Obviously, this is only possible in cases where the client is co-located with the data. Short-circuit reads provide a substantial performance boost to many applications. <name>dfs.client.read.shortcircuit</name> <value>true</value>
• #48: No network usage at all in the Map phase In the Reduce stage, each reducer fetches its own range of data as determined by the partitioner from all the map outputs. It then sorts these outputs using TimSort and writes the sorted output to HDFS. 48 MB is the amount in flight at a time In both shuffles: R talks to 5 maps at a time and grabs 48 MB from each Right now if there are 3 file handles open for each map
• #49: The sort based shuffle basically doesn’t require writing a separate file for each reduce task from each mapper Defaults to sort in 1.2
• #50: The sort based shuffle basically doesn’t require writing a separate file for each reduce task from each mapper Reducer hasn’t changed (basically the same) Only where you fetch the data has changed
• #52: Why Scala from Matei: “When we started Spark, we wanted it to have a concise API for users, which Scala did well. At the same time, we wanted it to be fast (to work on large datasets), so many scripting languages didn't fit the bill. Scala can be quite fast because it's statically typed and it compiles in a known way to the JVM. Finally, running on the JVM also let us call into other Java-based big data systems, such as Cassandra, HDFS and HBase.”
• #53: This is based on regular C python… it’s not jython. So that means all python libraries are compatible. If you use numpy or NLTK or something else that has a c extension, then you can import that into PySpark. It’s a regular unmodified python interpreter. Right now
• #55: Built on top of the Java API. It’s a very thin layer that sits on top of Scala and Java Spark. It provides a way to get data in and out of python and it reuses a lot of the Spark Scala functionality.
• #56: You process all the data in python, so all of the UDFs you write will be python. But Spark will persist + transfer it through the network and storage layers in Scala + Java.
• #57: Py4J enables Python programs running in a Python interpreter to dynamically access Java objects in a Java Virtual Machine. Essentially, you just call Java methods from your python code as if they were python methods. These are executor JVMs where num_cores = 2 In the Executor JVM, Pyrolite is used to unpickle the data or to pickle it. “This library allows your Java or .NET program to interface very easily with the Python world. It uses the Pyro protocol to call methods on remote objects. (See https://github.com/irmen/Pyro4). Pyrolite contains and uses a feature complete pickle protocol implementation to exchange data with Pyro/Python. “ Why does the local disk get used on the driver machine? Py4J is very inefficient for transferring large data b/c it uses a text based protocol.. It has to encode in base 64 so really slow. A collect or broadcast may be huge, so Py4j writes one file to the local FS. The final unpickling happens in the Python process on the Driver Machine. Python functions and closures (with dependencies) are serialized using PiCloud’s CloudPickle module You could also use Py4J. There is an example on the frontpage and lots of documentation, but essentially, you just call Java methods from your python code as if they were python methods: You first write a java program where you create a class and run that java program in a JVM. Then you write a Python program that can access that java object via a network socket. Here is what happens behind the scenes. On my local machine, I have the Spark Context object… top level entry point for Spark.. Used to create RDDs. SC runs in the Python process. When a SC is made, behind the scenes it creates a Java Spark context, running on top of regular Spark. Py4J is used to talk (copy data) between a JVM and python using reflection so you can call a java call just as if it was a native python method. It’s pretty cool. So the python Spark Context is controlling the Java Spark Context. A local file system is also used for communication through multiple files for doing things like collecting results. The integration with Py4J and Python is fine for like control point stuff, but you don’t want to transfer a whole lot of data through it because reflection is just too expensive. When you submit a job to the cluster, your job (the Python transformations and stuff) gets mapped down to just a few transformations on this special Python RDD object. Behind the scenes when these objects are shipped to the Spark executor, they actually spin up a bunch of actual python processes. And the Spark Executors communicate with the Python code over pipes using a special format to pass the functions that the user is writing. SO The executor will pipe all the data into the python processes, get all the results back and serialize it and transfer it. Naturally, there is some serialization involved there is one Python process per executor thread (we need this due to Python’s GIL so that CPU-bound tasks can benefit from multiple cores).  In older versions of PySpark, we’d end up launching a new Python worker process per task.  In newer versions (1.2.0+), executors launch Python processes as needed, keep them around in a pool, and terminate them if they’re idle for too long (1 minute by default); see https://github.com/apache/spark/pull/2259 and the followup patches for more details.  The actual subprocess architecture is a little bit complicated because we use a separate process for managing the Python worker processes in order to work around some fork() performance issues in the JVM.  This may mean that you’ll see up to 5 Python processes on an executor with 4 threads: one Python process per core, plus the daemon.py middle layer; see https://github.com/apache/spark/pull/1680 for some additional context.  Python UDFs are executed in regular Python interpreters, so things like sc.map(lambda x: some_arbitrary_python_code(x)) are run in Python interpreters, not through anything like Jython.  Spark SQL and MLlib may actually end up executing code that runs in the JVM for doing heavy number-crunching and I expect that we’ll see more in-JVM execution of certain operations in future versions of Spark.  See also: the (woefully out-of-date) PySpark internals page on the Spark wiki: https://cwiki.apache.org/confluence/display/SPARK/PySpark+Internals.  I really ought to update this page to reflect some of these recent developments. 
• #59: CPython is the original Python implementation. It is the implementation you download from Python.org.  CPython compiles your python code into bytecode (transparently) and interprets that bytecode in a evaluation loop. So CPython does not translate your Python code to C by itself. It instead runs a interpreter loop. There is a project that does translate Python-ish code to C, and that is called Cython. Pypy uses just in time compilation (JIT) or dynamic translation, so it runs faster. This means that compilation is done during the execution of the program (at run time) rather than just prior to execution. - - - C Foreign Function Interface for Python. The goal is to provide a convenient and reliable way to call compiled C code from Python using interface declarations written in C. - - - Pypy uses just in time compilation (JIT) or dynamic translation, so it runs faster. This means that compilation is done during the execution of the program (at run time) rather than just prior to execution. A JIT compiler is a program that turns Java bytecode (instructions that must be interpreted) into instructions that can be sent directly to the processor. After you've written a Java program, the source language statements are compiled by the Java compiler into bytecode rather than into code that contains instructions that match a particular hardware platform's processor (for example, an Intel Pentium microprocessor or an IBM System/390 processor). The bytecode is platform-independent code that can be sent to any platform and run on that platform. In the past, most programs written in any language have had to be recompiled, and sometimes, rewritten for each computer platform. One of the biggest advantages of Java is that you only have to write and compile a program once. The Java on any platform will interpret the compiled bytecode into instructions understandable by the particular processor. However, the virtual machine handles one bytecode instruction at a time. Using the Java just-in-time compiler (really a second compiler) at the particular system platform compiles the bytecode into the particular system code (as though the program had been compiled initially on that platform). Once the code has been (re-)compiled by the JIT compiler, it will usually run more quickly in the computer. - - - Good explanation of JIT: A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it's called) into a form that's usually faster, typically the host CPU's native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently. This is in contrast to a traditional compiler that compiles all the code to machine language before the program is first run. To paraphrase, conventional compilers build the whole program as an EXE file BEFORE the first time you run it. For newer style programs, an assembly is generated with pseudocode (p-code). Only AFTER you execute the program on the OS (e.g., by double-clicking on its icon) will the (JIT) compiler kick in and generate machine code (m-code) that the Intel-based processor or whatever will understand. - - - - - Research: https://github.com/apache/spark/blob/master/bin/pyspark#L54 https://github.com/apache/spark/pull/2144
• #60: In general, PySpark with CPython will run 3-10x slower than Scala/Java.. Unless you use PyPy
• #61: One more thing…
• #63: This will definitely be sold out Let audience know that - I’ll be teaching the 1-day Advanced Training sessions @ Spark Summit East (NYC) on March 18-19 or Summit West
• #64: Mention that we’re adding many interesting, new features to DBC that will be revealed soon. And say that I demoed many features of DBC from ETL to Exploration and Dashboards.