Data warehousing & architecture
Lakehouse Implementation
I combine the flexibility of a data lake with the reliability of a warehouse in a Lakehouse architecture — one place for raw and processed data, BI and machine learning.
What is Lakehouse
A Lakehouse combines the reliability and ACID guarantees of a classic warehouse (DWH) with the flexibility and scale of a data lake and support for any data type. This is achieved through open table formats (Apache Iceberg, Delta Lake), which provide ACID operations, versioning, time travel and schema evolution directly on object storage. The result is a single source of truth instead of duplicate DWHs and data lakes. BI reporting and ML model training run on the very same data at the same time.
What the service includes
Audit and target architecture
I run a technical and business audit of your current data landscape. The result is a target architecture and stack, plus a migration plan with domains prioritised.
Data ingestion
I set up batch and streaming loads from a variety of sources — ETL, CDC, Kafka, API. I ensure reliable delivery of data into the warehouse.
Cleansing and data marts
I implement bronze → silver → gold layers: raw data, cleansing and enrichment, business marts. On top I add a semantic and ML layer for analytics and models.
Storage and catalogue
I deploy object storage with the open Iceberg format — ACID, time travel and schema evolution on top of Parquet. I connect a catalogue and schema management.
Query engines
I add a query-engine layer (Trino, Spark, ClickHouse) with compute and storage decoupled. Several engines read the same tables, and compute scales independently of storage.
Governance and DataOps
I set up the catalogue, RBAC, row- and column-level access control, encryption and auditing. I build orchestration, Data Quality, a feature store and CI/CD for data and models. I deploy on-prem, in the cloud or hybrid, and provide support with monitoring.
What stages a Lakehouse implementation consists of
- 01
Audit and architecture selection
I assess sources, volumes and use cases, and analyse the current data landscape. On that basis I choose the target architecture and stack for the business's needs.
- 02
Design and migration plan
I design the target lakehouse architecture by layers and cross-cutting services. I prepare a phased migration plan with a clear rollout sequence.
- 03
MVP on priority domains
I assemble a working circuit on priority domains (for example finance, sales, inventory). I go through the full path: ingestion → bronze → silver → gold.
- 04
Governance and security
I set up the catalogue, lineage, RBAC and row-level security, encryption and auditing. I introduce data-quality control on the transitions between layers.
- 05
DataOps and MLOps
I build orchestration, CI/CD for data and models, a feature store and monitoring. I make the processes reproducible and observable.
- 06
Expansion and operations
I gradually onboard the remaining business areas and train the client's teams. I move the platform into operation with monitoring, SLAs and cost management.
An example Lakehouse reference architecture
The data flows top to bottom: sources → ingestion → S3/MinIO object storage with Iceberg and bronze/silver/gold layers → query engines (compute decoupled from storage) → consumption; cross-cutting services run down the side. The stack is fully open-source and is deployed in the client's infrastructure.
Sources
Operational systems and data streams: accounting systems, PostgreSQL, Kafka, APIs, files. This is everything from which data enters the platform.
Ingestion (batch + streaming + CDC)
Data ingestion in batch (Airbyte/dlt) and as a change stream (Debezium + Kafka). Stream processing, when needed, is handled by Flink or Spark Structured Streaming.
Object storage + Iceberg
The heart of the lakehouse: data sits as Parquet files in object storage, and the Iceberg format adds ACID, time travel and schema evolution on top of it; inside are the bronze → silver → gold layers, with transitions built by dbt or Spark. Schemas and table versions are managed by a REST catalogue (Polaris/Nessie).
Query engines (compute)
Trino for federated ANSI SQL, Spark for batch/stream/ML, ClickHouse or StarRocks for fast OLAP under BI. Compute is decoupled from storage — several engines read the same Iceberg tables, and compute scales independently of storage.
Consumption
BI dashboards (Superset/Metabase), ML (MLflow + Feast feature store) and AI scenarios (RAG, assistants) all run on the very same data at once. There's no need to copy data for each tool.
Cross-cutting services
They run across all layers: orchestration (Airflow/Dagster), Data Quality (Great Expectations/Soda), the Iceberg catalogue (Polaris/Nessie without Hive), governance and lineage (DataHub/OpenMetadata), security (RBAC, row-level security, encryption). They provide the manageability and reliability of the platform.
Projects
Analytics platform for the digital agency YA AGENCY
Analytical data warehouse and dashboards for Ash
End-to-end analytics and infrastructure migration for WiseAdvice-IT
Dashboards for the SaaS platform Entera
Analytical data warehouse for a chain of bars and restaurants
Analytical data warehouse for the Neolombard pawnshop chain
Unified data warehouse and dashboards for the delivery service Edostav
Data warehouse for the financial analytics project VISUALSECTORS
Tech stack
Apache Iceberg 
DuckDB 
Airbyte 
dbt Clients
Testimonials
The main value of a lakehouse is that BI and ML run on the very same data, not on copies from different systems. Analysts build dashboards while models train on the same vetted bronze/silver/gold tables, with a single catalogue, quality control and governance. This shortens the path from data to insight, removes duplication and gives the business a single source of truth for reports, decisions and AI scenarios.
Shall we discuss your task?
FAQ
How does a lakehouse differ from a classic DWH and from a data lake? +
A classic DWH provides structure, ACID and manageability, but copes poorly with large volumes and unstructured data. A data lake offers scale and any data type, but without transactions, versioning and order it easily turns into a swamp. A lakehouse combines both approaches: open table formats add ACID and manageability directly to object storage. As a result, a single environment covers both raw data and the marts for BI and ML.
When do you need a lakehouse, and when is an ordinary database or DWH enough? +
A lakehouse is justified when there's a lot of data, advanced analytics are needed, the business is growing, there are regulatory requirements and AI/ML is part of the strategy. It's especially useful when data is duplicated between separate DWHs and data lakes and you want a single source of truth. But if there isn't much data and you only need simple reports, a classic database or DWH is enough. I don't propose a lakehouse where it would be overkill.
What do open table formats like Iceberg give you? +
They unlock capabilities in object storage that used to exist only in a DWH. These include ACID transactions, data versioning and time travel — the ability to read the state of a table at a given moment. Schema evolution belongs here too: columns can be added and changed without rewriting the data. All of this works on top of ordinary Parquet files, and the formats are open and standardised.
What does "compute decoupled from storage" mean, and what's the benefit? +
Data storage and compute are two independent layers. Data sits in object storage in the Iceberg format, and query engines (Trino, Spark, ClickHouse) read the same tables without copying them. Thanks to this, compute scales independently of the storage volume, and you can pick the right engine for each task. This lowers costs and removes data duplication.
What about governance, security and vendor lock-in? +
I build governance using the DAMA-DMBOK methodology, with Data Mesh approaches where desired. Security includes a catalogue and lineage, RBAC, row- and column-level access control, encryption and auditing. Because the platform is assembled from open formats and components, there's no lock-in to a specific vendor, and storage and compute scale independently. This lowers TCO and preserves freedom in choosing tools.