7 ms·
Nice, but I can't find any reason to choose Spark over modern Distributed SQL databases (CockroachDB, CitusDB, TiDB etc. or cloud vendor-specific SQL DBs)
by truth_seeker 7y ago
Nice, but I can't find any reason to choose Spark over modern Distributed SQL databases (CockroachDB, CitusDB, TiDB etc. or cloud vendor-specific SQL DBs)
- madenine 7y agodepends what you’re doing. For querying large datasets? 100% with you. For data cleaning, processing, analytics, ML on decently large datasets? Spark wins out
- missosoup 7y agoWhat does spark win at exactly? Dask+Perfect is a much better experience all round including perf, with virtually none of the cluster management hell involved.
- ai_ja_nai 7y agoVery interesting. Can't find references to "Perfect", though; could you please point to a link?
- sandGorgon 7y agoCould you talk about Prefect ? we are in the process of moving from Spark to Dask. I have never heard of prefect. what do you use it for ?
- missosoup 7y agotl;dr we use it for a similar set of tasks that one would use Airflow for. Unlike Airflow, this lends itself to microbatching and streaming. Plus a bunch of housekeeping items ticked off that Airflow never got around to. With a bit of devops engineering time, you can have perfect manage the size of your worker cluster on k8s and scale it up/down with ingest demand, etc. I'll say one thing though. The Perfect website used to be a lot more technical and explicit about what it is and isn't. Now it's mostly sales gobbledegook. Maybe not a good sign. I've seen this happen before with dremio.
- sandGorgon 7y agoThis is super interesting! Do you run dask on k8s ? I have been concerned that dask does not leverage kubernetes HPA for autoscaling...but instead chooses to run an external scheduler. How has your experience been ?
- maximente 7y agolooks like dask is python-only, so it's a nonstarter (loser) for already existing JVM code that runs on spark
- missosoup 7y agoSpark stacks inevitably end up with PySpark though. It's rework for people who already committed to Spark, sure. And for bigger projects that committed to Spark this change isn't justifiable. But for a greenfield project, choosing Spark is just silly today.
- truth_seeker 7y agoSay for an example, I am using PostgreSQL 12 + CitusDB extension Data cleaning -> PL/SQL and various inbuilt functions for the transformation of data (or new UDF if required at all) Processing -> PostgreSQL Parallel processing on the local node and Citus DB extension for distributed computing and sharding Analytics -> Many options here. Materialized views OR Triggers OR Streaming computation with PipelineDB extension OR Using Logical replication for stream computation ML -> PG support variety of statistics functions. It also supports PL/R and PL/Python extension to interface with ML libraries. Also, there are various kinds of Foreign Data Wrappers supported by PG - https://wiki.postgresql.org/wiki/Foreign_data_wrappers https://wiki.postgresql.org/wiki/Foreign_data_wrappers
- missosoup 7y agoYeah that's not going to work for what people call analytics workloads today. PG is great but it's not suitable to be a feature store and sure as hell not suitable to fan out ML workloads. In a modern ML stack, PG might play the role of the slow but reliable master store that the rest of the ML pipeline feeds off.
- riku_iki 7y ago> hell not suitable to fan out ML workloads depends on the scale? Not everyone processes petabytes of data. > PG might play the role of the slow You have any benchmark in your hand to support this? I believe highly optimized C code in PG can be significantly faster than Scala inside Spark.
- missosoup 7y ago> I believe highly optimized C code in PG can be significantly faster than Scala inside Spark. There's no question about this. If you can express your task in terms of PG on a single instance, then you probably should. When you get to more complex tasks, like running input through GloVe and pushing ngrams to a temporal store, PG offers very little - which is fine, it's not at all what PG is designed for. Inter-node IO eclipses single node perf, which is why Spark is used despite being a terribly inefficient thing (although in the case of Spark, it's so inefficient that for interim sized workloads you'd actually be better off vertically scaling a single node and using something else). PG won't help at all with these tasks. Also, that smorgasbord of extensions GP listed isn't offered by any cloud vendor as a managed service afaik, meaning you must roll and manage your own. Depending on your needs, that might be a show stopper.
- nxpnsv 7y agoIf you want a more complicated transform on lots of data your fancy sql won’t help.
- truth_seeker 7y agoPlease give me an example. I can't think of any transform which cannot be done by using SQL or inbuilt Functions or new UDF.
- ai_ja_nai 7y agoSpark != SQL It's also graph analysis and ML models.
- truth_seeker 7y agoGraph analysis -> Recursive common table expression (https://www.postgresql.org/docs/current/queries-with.html https://www.postgresql.org/docs/current/queries-with.html) ML models - I already mentioned how to uplift R and Python functions to SQL function. even if you are not using PostgreSQL many other databases help you with uplifting and interfacing with existing ML libraries through FFI
- brokensegue 7y agotrain a set of sklearn models one each per a random partition of the data (computed distributed). then combine all those models using averaging and evaluate them all against an even larger dataset. how do you do that in SQL
- truth_seeker 7y agoSharding the table can help scale the problem across many machines and as I mentioned earlier you can use PL/R or PL/Python language extension to lift all sorts of ML functions to SQL functions.
- brokensegue 7y ago
- mvitorino 7y agoHow would you efficiently keep continuously updated complex metrics (aggregations, windowed functions, etc) calculated on top of unbounded/streaming data using a database? I'm not saying that Spark is the ideal solution, but there are a set of problems that require tools such as Spark.
- truth_seeker 7y agoOne example could be PipelineDB extension for PostgreSQL http://docs.pipelinedb.com/introduction.html http://docs.pipelinedb.com/introduction.html
- bsg75 7y agohttps://www.pipelinedb.com/blog/pipelinedb-is-joining-confluent https://www.pipelinedb.com/blog/pipelinedb-is-joining-conflu...
- truth_seeker 7y agoI know. But at the same time, 1.0 is pretty much capable. Give it a try and you will realize it.
- aloknnikhil 7y agoSpark is specifically useful for querying streaming data. How would a distributed database help with that? You'd have to build your own stream executor on top of that.
- dominotw 7y agoisn't all data streaming data? whats so specail about streaming data.
- truth_seeker 7y agoAgreed. at the same time, Building stream execution pipeline is not rocket science. I am not saying modern distributed SQL Databases are exact replacement or clones of Spark. I am saying with little more help from the application server they are much more capable than Spark. You can use the following options individually or in combination. Option 1 : Pipeline DB extension (PostgreSQL) Option 2 : Service broker in commercial SQL databases or building PUSH/PULL queue if not supported. There are many libraries in each programming language which tries to do that. Also see option 4. Option 3 : Using CDC or Replication for synchronous or asynchronous streamed computation on single or multi node cluster Option 4 : Transducers. For example, you can compose many sql functions or procedures to act on a single chunk of data instead of always doing async streamed computation after each stage of transformation.
- RocketSyntax 7y agodistributed in-memory computing for massive datasets to big to fit into vertically scaled memory. generic tabular files, not tables. delta lake.
- truth_seeker 7y agoYes those features help and all of the distributed SQL databases have data and query cache.
- RocketSyntax 7y agoThen once the subset of data is in distributed memory... you hittem w pyspark and all compatible libraries.
- outside1234 7y agoI see you haven't worked with a truly titantic amount of data then :)
- truth_seeker 7y agoI see you assume too much. :)