incubator-livy VS sparkmagic

Apache Livy - REST API For submitting jobs to a cluster. Used in conjunction with Jupyter or Zeppelin notebooks and you have a multi-tenant SQL only workload — https://livy.apache.org

There’s definitely some patching that still has to happen depending on the version (just found this Spark 3.2 PR), but I presume many folks that actively use it have to maintain their own forks. Latest version of EMR is Spark 3.1.2, but 3.2 is coming soon.

Apache Livy - an open-source REST API for interacting with Apache Spark from anywhere.

Spark 3 has some solid support for Kubernetes. Livy is a good addition to Spark on K8S, although support is not merged upstream yet (there's publicly available images and other in the PR). I'd strongly recommend to avoid running HDFS on top of Kubernetes. Either cloud-native buckets or on-premise bucket storage like Minio would be much better suited.

Please file an issue at https://github.com/jupyter-incubator/sparkmagic

I maintain several open source projects, most notably:

Sparkmagic (https://github.com/jupyter-incubator/sparkmagic)

Sparkmagic provides jupyter magics and kernels for working with remote Spark clusters. It's used by thousands of developers and companies like Pinterest, Amazon, more!

I've been maintaining for the past few years and would love help!

KSOPS (https://github.com/viaduct-ai/kustomize-sops)

KSOPS, or kustomize-SOPS, is a kustomize KRM exec plugin for SOPS encrypted resources. KSOPS can be used to decrypt any Kubernetes resource, but is most commonly used to decrypt encrypted Kubernetes Secrets and ConfigMaps. As a kustomize plugin, KSOPS allows you to manage, build, and apply encrypted manifests the same way you manage the rest of your Kubernetes manifests.

KSOPS is the most popular kustomize plugin and I'd love help maintaining and improving it from out GitOps fanatics.

Things get a bit more complicated on interactive sessions. We've created Sparkmagic compatible REST API so that Sparkmagic kernel could communicate with Lighter the same way as it does with Apache Livy. When a user creates an interactive session Lighter server submits a custom PySpark application which contains an infinite loop which constantly checks for new commands to be executed. Each Sparkmagic command is saved on Java collection, retrieved by the PySpark application through Py4J Gateway and executed.

Jupyter would be even better if it supported the seamless combination of Python and SQL code cells.

My notebook code typically involves a data prep stage with querying a SQL database, then downloading into Python for more complex analysis, ML modelling, integration with external data sources, etc. So the notebook has a Python kernel with SQL usually as embedded """-quoted strings.

Does anyone have a solution to treating selected code cells as SQL - with SQL highlighting and tooltips - exposed as string variables to the Python code?

Sparkmagic [1] does part of this for Python/SQL/Spark interoperability, but as far as I recall, doesn't support SQL syntax highlighting.

[1] https://github.com/jupyter-incubator/sparkmagic