A cloud data lakehouse for an online vehicle-trading platform

A cloud data lakehouse for an online vehicle-trading platform

A fast-growing online vehicle-trading marketplace now runs business intelligence and analytics across data that was previously locked apart, and it reached that point with a working, demonstrable product built within weeks. That speed matters: the design was deliberately future-proof and low-maintenance, a fit with the platform's own fast-moving development culture.

The problem was fragmentation, not absence, of data. The platform captured information right across the business, but that information lived in relational databases, NoSQL stores and spreadsheets, each with its own format and access pattern, none of them connected to the others. Every team could see its own slice of the business through its own system. Nobody could easily see the whole of it. That mattered because the platform's ambitions for business intelligence and advanced analytics both depend on relational, queryable data, and the underlying estate was not built that way. Questions that crossed system boundaries were harder to answer than questions that stayed within a single system, and left unaddressed that gap between what the business wanted to ask of its data and what the fragmented estate could answer would only have widened as the platform continued to grow.

QuantSpark's response was to design and build a cloud-based data lakehouse: an architecture able to take in structured, semi-structured and unstructured data from disparate sources and resolve it into a single relational store, rather than forcing a rigid warehouse-only model onto data that never started out relational. The build ran as a staged workflow. It began with an audit that mapped every source system and its format, so the true scope of the fragmentation was understood before any architecture was chosen. From there, the lakehouse pattern itself was selected specifically for its ability to scale on cloud infrastructure without heavy ongoing maintenance, a deliberate fit with a company that moves fast and does not want a data platform that becomes its own maintenance burden. Integration pipelines were then built to pull every relational, NoSQL and spreadsheet source into a common ingestion layer, which fed the centralisation step proper: landing all of that integrated data into one relational cloud data warehouse, giving every downstream analysis a single, consistent structure to query against. The final step connected self-service business-intelligence tools directly to that warehouse, so business users could explore data themselves with minimal technical training, rather than routing every question through engineering. Throughout, the team prioritised getting a working version in front of the business within weeks over running an extended specification phase, testing design choices against real use early rather than late.

The systems that underpin this are best described categorically, since the source does not name specific vendors: a cloud data platform hosting the lakehouse, the lakehouse layer itself unifying the disparate inputs, a relational cloud data warehouse as the single queryable store, and self-service BI tooling sitting on top for business users. The original siloed systems, relational databases, NoSQL stores and spreadsheets, remain the source systems feeding in, just no longer the endpoint for analysis.

The value delivered is qualitative but concrete. Analysis is now possible across datasets that were previously siloed by system and format. Business users can query the centralised data directly through self-service BI, without needing deep technical skills to do so. And because the architecture was designed to be low-maintenance and cloud-scalable from the outset, operational overheads stay manageable as the platform continues to grow, rather than compounding alongside it. No specific financial return is quantified in the available material, so none is claimed here; the honest way to describe the return on an engagement like this is by the shape of the saving, less specialist engineering time spent reconciling data and building bespoke reports, more direct self-service query time for the business, and a lower marginal cost of scaling one warehouse compared with an ever-multiplying set of disconnected systems, rather than by a specific number.