Data
Engineering

Field Notes

Data Engineering / Field Notes

Self

2017 • Data Scientist
Recommender systems at Trackuity.

2019 • Researcher
Open/Linked data at Ghent University - imec.

2021 • Software Engineer
GPS and map data at TomTom.

2022 • Data Engineer
Hotel data at Lighthouse.

Data Engineering / Field Notes

The visuals are AI generated.
GPT 6 Astra is weird.

Fun opinions ahead.
They do not represent my employer.

I have sources though.
Links to Open Access papers. Not always the first publication though.

Data Engineering / Field Notes

So many job titles

Data

  • database administrator
  • data engineer
  • big data engineer
  • data platform engineer
  • data architect

Also Data

  • data analyst
  • BI analyst
  • BI developer
  • BI engineer
  • analytics engineer
  • data scientist

Also Data

  • machine learning engineer
  • AI engineer
  • ML platform engineer
  • research engineer
  • product data engineer
Data Engineering / Field Notes

Why start with history?

Donald Knuth at the Computer History Museum in 2011
Donald Knuth, 2011 · Alex Handy · Wikimedia Commons · CC BY-SA 2.0
To understand the process of discovery.
To understand the process of failure.
Telling historical stories is the best way to teach.
To learn how to cope with life.

Let’s Not Dumb Down the History of Computer Science

Communications of the ACM · 2021

Data Engineering / Field Notes

01 Introduction

02 History

03 Google

04 Observations

05 Cases

Data Engineering / Field Notes

History

Data Engineering / Field Notes

1970 — Dawn of the SQL

The relational model is an abstraction

Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).

This paper is concerned with the application of elementary relational theory to systems ... of formatted data.

Orderly tables floating above the complex storage machinery they abstract away.
Codd, E. F. (1970). A relational model of data for large shared data banks.
Communications of the ACM, 13(6), 377–387. doi:10.1145/362384.362685
Data Engineering / Field Notes

1992 — Parallel databases

Highly parallel database systems are beginning to displace traditional mainframe computers

Ten years ago the future of highly parallel database machines seemed gloomy

They describe:

  • partitioning
  • parallel scans
  • parallel joins
  • scale-out execution
Industrial processing lanes dividing a workload between parallel machines.
DeWitt, D., & Gray, J. (1992). Parallel database systems: The future of high performance database systems.
Communications of the ACM, 35(6), 85–98. doi:10.1145/129888.129894
Data Engineering / Field Notes

1997 — Dawn of the OLAP

Data warehousing and on-line analytical processing (OLAP) are essential elements of decision support

Typically, the data warehouse is maintained separately from the organization’s operational databases

OLAP operations include rollup and drill-down along one or more dimension hierarchies, slice_and_dice, and pivot

A mechanical analytical cube with a separated slice and an inspection lens.
Chaudhuri, S., & Dayal, U. (1997). An overview of data warehousing and OLAP technology.
ACM SIGMOD Record, 26(1), 65–74. doi:10.1145/248603.248616
Data Engineering / Field Notes

2002 — CAP

It is impossible to reliably provide atomic, consistent data when there are partitions in the network

It is feasible to achieve any two of the three properties: consistency, availability, and partition tolerance.

Two computer outposts separated by a broken communication link.
Gilbert, S., & Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services.
ACM SIGACT News, 33(2), 51–59. doi:10.1145/564585.564601
Data Engineering / Field Notes

Becoming webscale

  • huge logs
  • crawled documents
  • enormous graphs
  • cheap, unreliable machines
  • huge write volumes
  • horizontal scaling

Google had these problems very early.

Data Engineering / Field Notes

History: Google

Data Engineering / Field Notes

2003 - Google File System

Machines fail. The files survive.

It provides fault tolerance while running on inexpensive commodity hardware
The largest cluster to date provides hundreds of terabytes of storage across thousands of disks

The Google File System

Data Engineering / Field Notes

2004 - MapReduce

map function that processes a key/value pair to generate a set of intermediate key/value pairs
reduce function that merges all intermediate values associated with the same intermediate key

The runtime hid all the partitioning, scheduling, networking, ...

MapReduce: Simplified Data Processing on Large Clusters

Data Engineering / Field Notes

No CAP

GFS has a relaxed consistency model that supports our highly distributed applications well but remains relatively simple and efficient

As most of our files are append-only, a stale replica usually returns a premature end of chunk rather than outdated data.

MapReduce + GFS did not guarantee consistency nor availability

Google made it work for their use cases

Origins of Big Data and NoSQL (through BigTable)

Data Engineering / Field Notes

2011 - Dremel / BigQuery

Interactive SQL becomes a product.

Running aggregation queries over trillion-row tables in seconds.

A novel columnar storage representation for nested records.

Dremel: Interactive Analysis of Web-Scale Datasets

Data Engineering / Field Notes

2012 - Spanner

CAP is back.

It is the first system to distribute data at global scale and support externally-consistent distributed transactions.

We should no longer depend on loosely synchronized clocks and weak time APIs in designing distributed algorithms.

If you read any paper -- make it this one

Spanner: Google's Globally-Distributed Database

Data Engineering / Field Notes

2013 - F1

SQL is back.

Built at Google to support the AdWords business

Scalability of NoSQL systems like Bigtable, and the consistency and usability of traditional SQL databases

F1: A Distributed SQL Database That Scales

Data Engineering / Field Notes

Observations

Data Engineering / Field Notes

Google did it first

Google’s influence: GFS and MapReduce to Hadoop, Spark and Databricks; GFS to BigTable, all of NoSQL and failed startups; Dremel to Parquet, Iceberg and Delta lakes; BigQuery to Snowflake, Clickhouse and DuckDB; Spanner to NewSQL, with a connection back to BigQuery.
Data Engineering / Field Notes

Big data is solved

The same tools are used for all data volumes

The only limiting factor is your wallet

Keeping costs down is arguably harder than before

Google needs your money to fund their AI

Data Engineering / Field Notes

It's all data engineering

Three connected purposes of data engineering: product, decisions, and governance
PRODUCTBuild things with data
DECISIONSInform the company
GOVERNANCEAgree what the data means

The Hadoop/Spark crowd met with the database crowd, both crowds often build data warehouses

Data Engineering / Field Notes

SQL is everywhere

We went from NoSQL to SQL abuse

  • Extract: SQL
  • Transform: SQL
  • Load: SQL
Data Engineering / Field Notes

PySpark should be abandoned

Even Databricks isn't using Spark for their raw SQL products anymore (replaced by Photon)

Spark still excells for non-SQL workloads though, but just use Scala then

Data Engineering / Field Notes

1998 — The Golden Hammer

It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail

The Golden Hammer thrives in organizations where software teams fail to invest in education

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Brown et al., 1998)

Just because you can express a problem in SQL doesn't mean you should

SQL Antipatterns: Avoiding the Pitfalls of Database Programming (Bill Karwin, 2010)

Data Engineering / Field Notes

1982 — The Turing tarpit

Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

A language can be universal yet offer little help with the task at hand.

Perlis, A. J. (1982). Epigrams on programming. ACM SIGPLAN Notices, 17(9), 7–13.
Epigram 54 · doi:10.1145/947955.1083808 · Open text at Yale
Data Engineering / Field Notes

ETL and ELT

Just buzzwords

Both terms refer to data warehouses: do you let the data warehouse handle the transformations?

Platforms like Databricks blend the boundaries so much it's a useless distinction

Never made sense outside of data warehouses, and therefore, outside of data analytics

Data Engineering / Field Notes

OLAP vs OLTP

Transactional and analytical systems are converging

DuckDB + Postgres

Postgres+DuckDB query engine

pg_duckdb brings analytical queries inside Postgres.

DuckLake

SQL catalog→Parquet lake

Multi-table ACID transactions; small writes can stay in the catalog.

ClickHouse

UPDATE→patch parts→SELECT

Read updated values before background merges.

Databricks

Lakebase→open storage←analytics

LTAP: one logical dataset, specialised Postgres and analytical engines.

Data Engineering / Field Notes

Lake Transactional/Analytical Processing (LTAP)

OLAP and OLTP on a single copy of data in the lake, eliminating ETL, replicas, and pipelines by design

Databricks is the world's first LTAP platform

No more copying of operational data to data warehouses

Google did it first with Spanner Data Boost

Data Engineering / Field Notes

Cases

Data Engineering / Field Notes

Data at Lighthouse

Processing the largest database in the industry (over 140 terabytes daily) allows Lighthouse to deliver global insights on pricing

Mostly HTML, and rest is mostly XML

'Modern' data tools bill per byte

Majority of transformations are Python running on Kubernetes

Data Engineering / Field Notes

Handling HTML

Hotel listing showing a member price of 212 euros and a public price of 235 euros.

What is the price?

AI is great at extraction but too expensive

AI is also great at generating regular expressions

Data Engineering / Field Notes

Handling transactions

XML transaction record with receipt, market, date and room fields.

Streaming parser using xml.etree

Transformations in DuckDB and Polars (why both?)

Parquet writtem to GCS, merged into BigQuery as external tables

Data Engineering / Field Notes

Handling migrations

SQL unions old and new tables, then uses QUALIFY with the maximum source ID per property and stay date to prefer new data.
Data Engineering / Field Notes

Data at TomTom

OpenStreetMap (256 GB RAM)

Proprietary map data

Massive amounts of GPS data

Sensor derived data

Data Engineering / Field Notes

Handling GPS data

Challenges:

  • Matching traces to roads is intensive
  • Low quality data (i.e., old iPhones)
  • Traffic violations by our 'enterprise' partners

Not convinced these issues are fixable

Data Engineering / Field Notes

Handling GPS data

Challenges:

  • Matching traces to roads is intensive
  • Low quality data (i.e., old iPhones)
  • Traffic violations by our 'enterprise' partners

Not convinced these issues are fixable

Value per trace is low; costs per trace must be low

Data Engineering / Field Notes

Example:
parallel roads

Aerial view of closely spaced parallel roads and a bridge, illustrating ambiguity when matching GPS traces.
Data Engineering / Field Notes

Data at Trackuity

Item data from marketplaces
(Immoweb, VDAB)

New items every day and
newest items are most valuable

Data Engineering / Field Notes

Handling multiple channels

Property listing with a partial address and an image containing agency banners and annotations.

Vague addresses

Edited images
(banners, cropping)

Data Engineering / Field Notes

Perceptual Hashing

Two similar images are divided into grids, hashed, and compared to determine a similarity degree.

Nothing like cryptographic hashes

Locality Sensitive Hashing (LSH)

Perceptual hashes can be as simple as thresholds of average luminosity

Data Engineering / Field Notes

Done

Data Engineering / Field Notes

Companion to the Golden Hammer: overusing a favourite tool is a different problem from having expressive power without useful abstractions. Tie this back to tool choice; this is not a blanket claim that SQL is a Turing tarpit.