Datalagring
Vektorlager, relationell databas, object storage — och varför vi använder alla tre.
Reelai är ett proptech-bolag — datan är en produkt i sig. Här är hur datan flödar från rå scrape till indexerade serving-vyer som mäklarportalen och Elly läser från: medallion-arkitektur, ADF-orkestrerad, allt versionerat och observability:at, allt EU-hostat. Applikationslagret wrappar funktioner i FastAPI som anropar stored procedures med parametrar — och de pekar i sin tur mot heavy-indexerade vyer. Det är så vi får millisekund-svar på komplexa queries även mot stora dataset.
Översikt — fyra lager
Datan rör sig genom fyra lager från rå källa till färdig query-yta. Varje övergång är orkestrerad, validerad och loggad så vi alltid kan reproducera state.
- •Lager 1 — Ingestion: scrapers droppar rådata i blob-containers per källa
- •Lager 2 — Orchestration: ADF-pipelines triggas event-baserat på blob drop, kör staging + dedup + clean i sekvens
- •Lager 3 — Normalisering: stored procedures för dedup, geo-berikning och relationell modellering
- •Lager 4 — Serving: indexerade materialized views + stored procedures som applikationen läser från
Lager 1 — Ingestion (raw blob storage)
Schemalagda scraping-jobb (slutpriser veckovis, aktiva listings dagligen, BRF-data kontinuerligt) droppar rådata i dedikerade blob-containers per källa. Idempotent — samma URL kan re-skrapas utan att förstöra historik.
Lager 2 — Orchestration (ADF event-driven)
När en scraper droppar nya filer triggas motsvarande Azure Data Factory-pipeline automatiskt. Vi har separata pipelines per datatyp (slutpriser, aktiva listings, mäklare, BRF-data) som alla följer samma flöde: load → dedup → clean. Pipeline-status loggas per körning så vi kan reproducera state vid fel.
Lager 3 — Normalisering (stored procedures)
Varje datatyp har sin egen kedja av stored procedures för dedup, geo-berikning (adress → koordinater), och relationell modellering. Här hanteras edge-cases som flera-mäklare-per-objekt, sålda objekt som åter-listas, och historisk integritet.
Lager 4 — Serving (indexerade materialized views)
Applikationen och Elly läser inte raw-data — de läser från denna nivå. Vi har fyra materialized views som driver allt: slutpriser, aktiva listings, BRF-register och mäklare-register. Varje vy är heavy-indexerad för olika query-mönster. Det är detta lager som gör Reelai's konkurrensanalyser och marknadsinsikter möjliga — komplexa queries över hela svenska bostadsmarknaden returneras på millisekunder. Det är också det som gör Elly snabb: när hon slår upp en BRF, hämtar mäklarstatistik eller jämför slutpriser går hon mot indexerade vyer, inte mot raw-tabeller.
| Slutpriser-vy | Driver konkurrensanalys, prisutveckling och mäklarstatistik. Indexerad för många query-mönster. |
| BRF-vy | Driver BRF-uppslag och föreningsanalys. Indexerad för snabb adress- och BRF-lookup. |
| Aktiva listings-vy | Aktuella objekt till salu i Sverige. Uppdateras dagligen. |
| Mäklare-vy | Driver mäklare-uppslag och konkurrentanalys per byrå. |
Pipeline observability
Varje pipeline-körning loggas i en dedikerad audit-tabell. Dashboards visualiserar pipeline-hälsa i realtid. Vid fel triggas alerts till data engineering-team innan applikationen påverkas.
| Mätvärden per körning | Starttid, varaktighet, antal hämtade records, nya rader, dedup-träffar, status, error-message |
| Granularitet | Per pipeline + per steg |
| Retention | Historik bevaras för regression-analys över tid |
Vektorlager (parallellt spår)
AI-data (embeddings, ingestion-events, kampanjer, frågor) lever i ett separat multi-tenant NoSQL-lager partitionerat per byrå. Detta är en operativ databas optimerad för semantisk sökning — separat från det analytiska datalagret.
| Spekulant-embeddings | Vektorrepresentationer av spekulant-preferenser, partitionerad per byrå |
| Objekts-embeddings | Vektorrepresentationer av aktiva objekt, partitionerad per byrå |
| Pre-market objekt | Diskret container för icke-publika objekt, partitionerad per byrå |
| Inflödes-kö | AI-parsade mail/SMS i review queue, partitionerad per mäklare |
| Kampanjhistorik | Outreach-kampanjer + leveransstatus, partitionerad per mäklare |
| Objektsfrågor | AI-Q&A per objekt, partitionerad per byrå |
Object storage (uppladdade dokument)
Mäklarens uppladdade årsredovisningar, energideklarationer och liknande dokument lagras separat med standard-redundans. Lifecycle-policies städar gamla artefakter automatiskt.
Multi-tenant data-isolering
Varje mäklare (eller byrå) får sin egen agent_id. Den används som partition key i alla relevanta containers. Queries filtreras alltid på agent_id. Resultatet: noll risk att en mäklare ser någon annans spekulanter eller objekt — varken via fel i UI eller fel i query.
Läs vidare
Vill du se Elly i din vardag?
30 minuter där vi kör henne på dina objekt och spekulanter. Inga säljpitcher.