Använd ett REST-API för datamappningar, inte nattliga Excelimporter
De flesta analysplattformar läser referensdata från en fil. En CSV-fil i en mapp. En Excelfil på SharePoint. Ett platt uttag ur ett annat system. Varje natt hämtar ett jobb filen och laddar in den i staging. Sedan tar pipelinen över.
Upplägget är bekvämt. Filer är enkla och lätta att felsöka, och du kan öppna dem och titta. Problemet är att filer har en brist som aldrig går över: de ligger alltid lite efter. Och de kan gå sönder på sätt som ett API inte kan.
Vad fördröjningen kostar
En användare ändrar kundmappningen kl. 15:00. Nattjobbet gick kl. 02:00. Den nya mappningen hamnar inte i datalagret förrän i morgon bitti. Alla som frågar datalagret mellan kl. 15:00 och nästa körning får gårdagens svar.
Om ändringen gjordes för att någon hade en brådskande fråga är svaret på den frågan fortfarande fel.
Med ett API försvinner glappet. Ändringen gäller direkt. System längre ned i kedjan läser när frågan körs eller får en notis.
Fel som bara uppstår med filer
| Fel | Filbaserat | API-baserat |
|---|---|---|
| Schemaändringar | En ny kolumn förskjuter tyst de andra | Ett nytt fält är ett nytt fält |
| Teckenkodning | UTF-8 BOM förstör första cellen | JSON har en definierad teckenkodning |
| Förlorade ändringar | Två datorer skriver över varandra | Transaktionella skrivningar |
| Spårbarhet | Bara filens ändringstid | Vem som gjorde varje ändring |
| Behörigheter | Allt eller inget per mapp | Per klient och omfång |
Det vanligaste felet i praktiken är att schemat ändras. Någon lägger till en kolumn i exporten, kolumnordningen förskjuts och parsern längre ned i kedjan börjar tyst läsa fel kolumner. Siffrorna ser fortfarande rimliga ut. Det märks först tre veckor senare, när en rapport hämtar fel kolumn. Med ett API-kontrakt kan det inte hända: ett nytt fält dyker upp som ett eget fält.
Att bygga in något av de här skydden i en egen filpipeline är ett rejält jobb. När du är klar har du byggt ett API. Det är billigare att börja där.
Vad bytet innebär
Det första du vinner är ett schema som faktiskt gäller. Autentisering, omförsök och övervakning kommer sedan naturligt. Felhanteringen kring ”filen kanske saknas, kanske är tom, kanske har en kolumn för mycket” försvinner i stort sett.
Det du ger upp är att kunna läsa datan som en fil. En pipeline som gjorde många små uppslag mot en lokal CSV-fil gör nu nätverksanrop i stället. De flesta pipelines klarar det. Undantagen är pipelines som slår upp stora mängder enskilda rader. De behöver batchanrop eller en cache.
En migrering i fyra steg
Kontrollera att resultaten stämmer. Jämför det API:et returnerar med CSV-filen vid samma tidpunkt. Inte ungefär. Exakt. Lägg en vecka på att stämma av skillnaderna.
Kör skuggtrafik. Varje pipeline anropar API:et samtidigt som den läser CSV-filen och skriver resultatet till en plats vid sidan av. Logiken i pipelinen är densamma, och API-svaret används inte skarpt än.
Byt en pipeline i taget. Börja med den som ställer till minst skada om något går fel. Håll koll på den i en vecka. Går något sönder backar du. Går inget sönder går du vidare.
Fasa ut CSV-filen. Först när alla pipelines läser från API:et och inget annat system läser CSV-filen. Låt filen finnas kvar en månad efter det sista bytet. Någonstans finns ett hemsnickrat skript som läser den.
Använder du gridmap för mappningarna är det här precis vad Lookup API är till för. Enskilda uppslag och batchuppslag, behörigheter per nyckel, loggning av användningen och samma granskningslogg som du ser när du redigerar.
Vanliga frågor
Hur snabbt behöver API:et vara? För de flesta analysjobb känns under 100 ms bra. Under 50 ms märks det inte alls. Räcker inte det cachar du hela mappningen i minnet när pipelinen startar.
Kan vi köra filer och API parallellt för alltid? Det går, men då får ni dubbelt underhåll. Bestäm ett slutdatum.
Hur gör vi med system som inte kan läsa från ett API alls? En schemalagd filexport från API:et ger det gamla systemet en fil, medan allt nyare läser direkt. Då är filen en kopia av sanningen, inte en mellanhand framför den.