Hacker News Reader

Author here: All good points - I should have been more specific: I'm really talking here about the data transformation logic. I live in a world where raw data generally gets loaded into a data lake, and data engineering proceeds from that point - but appreciate that's not the general case.

I'm really contrasting SQL to other commonly used data manipulation APIs and dataframe libraries like dplyr, pandas, polars etc., but again, appreciate this should be clearer in the blog

In a datalake, PySpark should be the default for large operations with multiple transformations. Since you're essentially working with jupyter notebooks, it allows you to lay out your transformation steps in a way that's more clear to the reader what each step does than with SQL.

The PySpark API has methods for SQL-like operations, so it's familiar to people like you and me who know and love SQL. There is no point to Pandas on a datalake since PySpark has dataframes.

I'm a huge proponent of SQL. I'm dubious of ORMs and think a lot of websites would be more performant if people just learned SQL, or whatever the idiomatic querying language for their chosen DB is. But with datalakes, pyspark is great.

I worry that if I write significant amounts of code in pyspark it will have fallen out of fashion in ten year's time and someone will end up either rewriting it or running an ancient, unmaintained version of pyspark forever just to keep my stuff working.

I'm much less worried about that happening to SQL scripts.

In addition to being good at what it does, SQL has Lindy on it's side like no other language used today.

Lindy?

https://en.wikipedia.org/wiki/Lindy_effect

Thanks, that's an idea that makes a certain sense. The counter point is that technical things get replaced quickly at times when something vastly superior arrives. We don't use cpm computers or apple IIs any more. I think saying sql has the lindy affect is a clever slam against it. We don't use system 360 assembler any more. X86 seemed to be certain to own the world, maybe arm or risc-v will usurp it.

PySpark is such a performance killer. How many startups will there be that just have a goal to improve performance and reduce cost. It locks you into a small number of platforms (bc many dbs don't have an impl and details vary), every database vendor eventually struggles to make their own implementation.

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).

> I can grind through 10 TB of data for like $50

Is this hosted databricks ?

EMR

$50 to analyze 10TB over the course of a few hours is an insanely expensive and inefficient setup.

Not 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.

a 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.

Polars would be worth looking into too. $50 and hours seems orders of magnitude too high vig 10tb

I 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.

> 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.

About 20 years ago I wrote a bunch of complex reports using SQL. The engineer who came after me tried briefly to understand it, decided it all needed to be rewritten in "a real language", broke all the reports, and they never really got them back.

So merely writing in a language that we believe will be around forever does not prevent your code from being rewritten.

I think that's always a risk (the old "which idiot wrote this? clearly needs a full rewrite!" followed by the rewriter rediscovering all the bugs the original had fixed), but with a well established language like SQL hopefully the risk is lower.

The fact is that, word for word, SQL is incredibly more efficient for reporting than most programming languages. But since few programmers treat it as a real language, it tends to be written without formatting. Which makes it hard to read.

Also unfamiliarity will make SQL feel inefficient for non-SQL programmers. The experience of rewriting SQL teaches some this lesson. But others find that the familiarity of the language of the rewrite makes it seem better to them, even though it is objectively worse. An objectively worse that only becomes visible when someone needs to optimize it for performance reasons. And it is seldom the programmer who did the inefficient write who has the skills to optimize it back to what SQL did in the first place!

(Yeah, I've had to do those optimization fixes.)

Many developers, good developers haven't worked with complex SQL queries.

So on seeing one they can sometimes think it's quicker to redo this in a language I know rather than upskill enough to understand this.

While I agree with the sentiment, in practice I haven't seen it go over well. I find the tooling around SQL to be severely lacking.

Either you work with data that’s not really big data or you have some super awesome engineers who know spark very well, because spark is pretty much not declarative as much as it says so. You have to constantly battle crap like GC errors, data skew, etc. Even on supposedly managed solutions like databricks. As opposed to solutions like snowflake which are a lot more declarative (nothing is perfect of course).

And the vendors are happy to tell you to throw more cores at it instead of grapple with the core issues.

One of the biggest problems with spark imo is that people think that the magic cloud is going to make it go fast, when it actually means that the REPL is just muuuuch slower to iterate on.

As someone who is written tons of spark code. I disagree is that is it somehow more immune to code rot than sql.

There are couple of famous examples

https://shopify.engineering/build-production-grade-workflow-...

This doesn't really respond to the article. The argument here is "jupyter notebooks are clearer", but that's pretty subjective, and the article specifically addresses this kind of point:

"By using SQL, a much wider range of people can read your code, including BI developers, business analysts, data engineers and data scientists."

If you really want to advocate for PySpark in this context, you've gotta contend with everything the article brings up:

- More people will be able to understand your code

- Future proofed, with automatic speed improvements and ‘autoscaling’

- Make data typing someone else’s problem

- Simpler maintenance, with less dependency management

- Compatibility with good practice software engineering

- SQL is more expressive and versatile than it used to be

This isn't even an either/or proposition. You can inline SQL in pyspark just fine: df = spark.sql("...")

Even for data transformation logic, SQL isn’t the best choice. How would you handle the case when you need to apply the same transformations to few dozens or hundreds columns?

I'm not sure I understand the question, you can create tables/views based on others that have the transformations applied to them, tools like dbt[1] make this easy.

[1]: https://www.getdbt.com/

Some SQL engines support generating and evaluating queries. I stumbled upon a function in MariaDB code base that is introduced and keps specifically for that use case (it returns properly quoted SQL value as a string, including "NULL" string for null values). It is aptly named QUOTE [1].

[1] https://mariadb.com/kb/en/quote/

You can then specify columns as a query, group_concat the result and evaluate resulting statement [2].

https://mariadb.com/kb/en/execute-immediate/

I hope that helps.

Even on the manipulation side I tend to disfavor sql.

Even though it’s improved a lot the testing situation in sql is still not where a more traditional programming language is, modularity comes either in the form of ever nested cte, stored procs or dbt style templates. And sql types are wholly dependent on the sql engine, which can lead to wacky transforms.

Sql is great for adhoc analysis. If something isn’t adhoc, there is almost always a better tool.

Agreed. I would also point out maintainability. How do you test some SQL logic in isolation?

Additionally, in this day and age where enriching the data by running it through some ML model isn't that rare, doing it in SQL by exposing it through an API and invoking some UDF on a per-row basis is extremely inefficient due to network RTT. In my opinion it is much better to use something like Apache Beam and load the model in memory of your workers and run predictions "locally" on batches of data at the time.

On the other hand I see the value in expressing "simple" logic in SQL, especially when joining a series of tabular sources. That's why I am super happy with Apache beam SQL extensions (https://beam.apache.org/releases/pydoc/2.30.0/apache_beam.tr...) which, IMHO, has the benefits of both worlds.

> How do you test some SQL logic in isolation?

I do this using sql

1. Extracting an 'ephemeral model' to different model file

2. Mock out this model in upstream model in unit tests https://github.com/EqualExperts/dbt-unit-testing

3. Write unit tests for this model.

This is not different than regular software development in a language like java.

I would argue its even better better because unit tests are always in tabular format and pretty easy to understand. Java unit tests on other hand are never read by devs in practice.

> in this day and age where enriching the data by running it through some ML model isn't that rare,

Still pretty rare, This constitutes a very minor percentage of ETL in an typical enterprise.

> Java unit tests on other hand are never read by devs in practice.

You should get to know better java developers. :-)

haha same!. Ppl saying sql is unreadable need to know better sql developers.

sql is so pretty and so very readable and maintable if done by people who know what they are doing.

> Even though it’s improved a lot the testing situation in sql is still not where a more traditional programming language is, modularity comes either in the form of ever nested cte, stored procs or dbt style templates.

See my comment here https://news.ycombinator.com/item?id=34580675

I don't use nested cte/stored procedures . I simply extract extract it to a new file and mark it 'ephemeral' in dbt, no different than what you'd do in a regular programming language.

FYI: MySQL has CREATE EVENT. Postgres has pg_cron. DB2, Oracle, and MS SQL all have built in schedulers (aka time-based triggers) as well.

> Manipulating the data? Sure, use SQL, as long as you're operating on data from one database. Trying to collate data from multiple databases may have unpredictable performance issues even in the engines that support it.

Depending on how big your data & org is - orgs solve this by writing their own query engines that can query many different data formats.

It is much more practical to optimize an engine, than to expect every data engineer to know how to optimally manipulate data from many different formats.

And why shouldn't this engine accept SQL queries as well if it's accessing existing SQL databases (probably just with different weights, retries, and batching/spooling)?

It usually does!

If you want to use the same logic / language to query some exotic dataset for specific use cases - it can often be worth it to write a custom engine that can do it - rather than expect all end-users to learn the ins & outs of the other databases & datasets (not to mention, to learn something beside SQL).

Instead, a single team (the query engine owners) can optimize the query engine - rather than individual users trying to optimize every script individually.

Your users can become masters of their engine / language (SQL) - because it can be used for the vast majority of cases.

For many reasons - you might want to store data in a format that MySQL / Postgres does not support natively (see Google Spanner). But, ideally, you'd still be able to leverage the fact that almost every programmer in the world can write SQL.

The simplicity and (relative) consistency of SQL makes it such a great choice. Sure, there are language variations but those can be avoided if that is a goal of the team.

Orchestration and data movement can be expressed with SQL. Assign shards however you need, run queries.

I am working on the (parallel, distributed) SQL engine and you can't even fathom how often I see SQL queries disguised-as/hand-compiled-into for loops in C++. Essentially, whatever SQL engine works on can and should be expressed as data tables and their processing and transformation should also be SQL-expressed.

> Moving data? There are much better options.

shameless plug but if you want an open source/YC backed solution for data movement pipelines try Airbyte https://news.ycombinator.com/item?id=34533429 :)

What is then, in your opinion, an actually good ETL stack? Many use Spark/Databricks/Synapse, which has all 3, but these seem bulky and needlessly complicated for many smaller projects. Even TB sized datasets don’t need Spark, in my opinion.

I'd advocate starting as simple as possible. It's very context specific, but one very simple architecture to consider if seeing if duckdb can handle your data (maybe on quite a large machine).

For larger data, i'm a fan of writing everything in SQL, and executing it using AWS Athena (a Presto engine), which is extremely cheap.

If you have even larger data, you can consider AWS Glue (steering clear of any aws specific stuff and literally using it as spark SQL as a service). For many simple cases you don't really need to know any Spark, and you're just submitting SQL to AWS for execution.

But all of this assumes you're storing your data as files on disk (e.g. parquet). I'm less experienced in running everything in more traditional SQL engines like MS SQL server or postgres.

> Trying to collate data from multiple databases may have unpredictable performance issues

Why would this be more predictable in something you handroll vs using something like trino.

What solutions exist to manage data movement efficiently and effectively across multiple databases?

There's AWS Glue and Azure Data Factory, integration tools like Qlik Replicate or FiveTran Replication, or ConnX solutions if you have enterprise-scale money to burn.

We don't use any of them though, we have custom C# ingestion code that can talk to most databases and Odata API's. .Net's lazy collections make it quite easy to create a consumer/producer pipeline for streaming large datasets without too much overhead.

SQL Agent = time triggers lol