> A data warehouse on the other hand is an OLAP database and is optimized to work on columns
A bit of a pedantic nit here: a data warehouse is a usage pattern. It’s not necessarily tied to any specific technology, however it is commonly implemented with OLAP systems like Snowflake, BigQuery, etc. But there’s nothing stopping you from building out your data warehouse in Postgres or MySQL. If you’re stitching together disparate datasets to build a unified model for analytics, you’ve got yourself a data warehouse no matter what system it lives on.
It's a good all-round primer, well written.
Would love to hear more about larger-than-memory tasks and running local Dask clusters. I processed many-a-dataset that way that would normally make pandas choke.
Well, I find this post looks good, but a like lot of 'data for developers' posts it's just a list of tools. As if a collection of tools banded together actually makes your customer successful.
What's missing?
1. There's nothing about deployment. How do I take this collection of tools and code and actually deploy it into production, or actually regression test it functionally? How do I make a small change in a database table and not have a massive regression? How do you do that automatically? How do you do it quickly?
2. It's cursory on testing. One of the biggest differences from a software developer to a data engineer is that your data providers give you crap data all the time. It could break. How do you test data? How do you get adequate test coverage? These things are essential for software developers and are actually doubly essential for data engineers and building analytics systems.
3. It's what success looks like. It's not just about a collection of tech; it's about making your customers successful. What does it mean to deliver good insight? How do you do it? How do you measure customer success, and measure your success? As a team, you wouldn't talk about software engineering without mentioning DevOps or DORA metrics. There's nothing here about that.
Great post! Also, I dig your site -- it's attractive and highly usable, and the "personal" toggle in the footer is a clever affordance I haven't seen before for separating professional content.
excluding Denodo from the list sows this is more of a non-enterprise guide to data management and tools. There is only one real semantic layer that can cover operational and historical data and thats Denodo. If you use snowflake horizon or unity, all the data needs to be loaded first and not real time.
Now I'll be thinking of "L" in ETL as "Land" and not "Load".
Although the article doesn't propose that but uses a lot of "Land" terminology.
"Load" => "load where? or FROM where?" - ambiguous
"Land" => "land where?" - clear
> A data warehouse on the other hand is an OLAP database and is optimized to work on columns
A bit of a pedantic nit here: a data warehouse is a usage pattern. It’s not necessarily tied to any specific technology, however it is commonly implemented with OLAP systems like Snowflake, BigQuery, etc. But there’s nothing stopping you from building out your data warehouse in Postgres or MySQL. If you’re stitching together disparate datasets to build a unified model for analytics, you’ve got yourself a data warehouse no matter what system it lives on.
It's a good all-round primer, well written. Would love to hear more about larger-than-memory tasks and running local Dask clusters. I processed many-a-dataset that way that would normally make pandas choke.
Well, I find this post looks good, but a like lot of 'data for developers' posts it's just a list of tools. As if a collection of tools banded together actually makes your customer successful. What's missing? 1. There's nothing about deployment. How do I take this collection of tools and code and actually deploy it into production, or actually regression test it functionally? How do I make a small change in a database table and not have a massive regression? How do you do that automatically? How do you do it quickly? 2. It's cursory on testing. One of the biggest differences from a software developer to a data engineer is that your data providers give you crap data all the time. It could break. How do you test data? How do you get adequate test coverage? These things are essential for software developers and are actually doubly essential for data engineers and building analytics systems. 3. It's what success looks like. It's not just about a collection of tech; it's about making your customers successful. What does it mean to deliver good insight? How do you do it? How do you measure customer success, and measure your success? As a team, you wouldn't talk about software engineering without mentioning DevOps or DORA metrics. There's nothing here about that.
sigh
Great post! Also, I dig your site -- it's attractive and highly usable, and the "personal" toggle in the footer is a clever affordance I haven't seen before for separating professional content.
excluding Denodo from the list sows this is more of a non-enterprise guide to data management and tools. There is only one real semantic layer that can cover operational and historical data and thats Denodo. If you use snowflake horizon or unity, all the data needs to be loaded first and not real time.
Good to finally know the difference between a lake and a warehouse
This was great, thanks for writing it up. Even as someone in the data space for a long time, I learned quite a bit.
Apache Avro has 2 encodings: binary AND json.
Are you sure? I can't find any reference indicating that.
Update: Huh, TIL https://avro.apache.org/docs/%2B%2Bversion%2B%2B/specificati...
Now I'll be thinking of "L" in ETL as "Land" and not "Load". Although the article doesn't propose that but uses a lot of "Land" terminology. "Load" => "load where? or FROM where?" - ambiguous "Land" => "land where?" - clear
always understood "land" as the raw data layer though, i.e only the bronze layer in the article.
Data is the new oil