4 ms·
Spark is useful in that it’s pretty cheap and flexible. I can grind through 10 TB of data for like $50 and a few hours. If my experiments work, I can use it as
by afpx 4y ago
Spark is useful in that it’s pretty cheap and flexible. I can grind through 10 TB of data for like $50 and a few hours. If my experiments work, I can use it as a component in other projects. Plus, I can use (slightly non-standard) SQL right in pyspark, if I want to. And, it often performs faster because of the query optimizer.
If your db is scalable enough (like Snowflake) and you have the money, you can use SQL directly in the same way. But, I've seen data analysts writing bad SQL against Snowflake costing thousands of dollars per query.
It’s really tough to future proof anything. At least with pyspark you will have the code. And, there will always be experts out there. Worse case, if it’s important enough, someone will wrap it in an API and use it until something better comes along (see: 50 year old mainframes still in use).
- dangwhy 4y ago> I can grind through 10 TB of data for like $50 Is this hosted databricks ?
- afpx 4y agoEMR
- berkle4455 4y ago$50 to analyze 10TB over the course of a few hours is an insanely expensive and inefficient setup.
- afpx 4y agoNot analyze. Transform. I'm not talking about a query. But, tell me more. I always like a better way. Is it more efficient to read/write from SSD? Right now, I need everything in memory.
- berkle4455 4y agoa single node of clickhouse would likely be sufficient for a fraction of the cost and time. use attached nvme disks (ebs on aws) or a physical local disk.
- eskaytwo 4y agoPolars would be worth looking into too. $50 and hours seems orders of magnitude too high vig 10tb
- rnk 4y agoI don't want to pile on, but I do see startup after startup that is focused on improving the cost/perf payoff of pyspark. Pyspark seems to be basically implemented by having the databricks query planner embedded in it, then it generates multiple queries to evaluate it. I think there's nothing inherent in that process that should make it faster than raw sql queries. There's theoretical advantages of maybe looking at the overall giant pyspark query and decomposing it into efficient pieces. Compare that to someone who wrote a series of separate sql queries to accomplish the same thing, and the qp can't take advantage of any reused computation.
- threeseed 4y ago> I think there's nothing inherent in that process that should make it faster than raw sql queries You can choose when to cache the data in memory. And it's the fact that you can write the code in Python, Scala etc instead of SQL.