SVENSKA

Databricks TPC-DS benchmarkresultat och analysplattformens krig

171

Skriven av Andrew Brust, bidragsgivare Andrew Brust Contributor

Andrew Brust har arbetat i mjukvarubranschen i 25 år som utvecklare, konsult, entreprenör och CTO, specialiserad på applikationsutveckling, databaser och business intelligence-teknologi. Han har varit krönikör och konferensföreläsare för utvecklare sedan mitten av 90-talet och en teknikbokskribent och bloggare sedan 2005.

Fullständig biografi publicerad i Big on Data den 24 januari 2022 | Ämne: Big Data

När datakällor och volymer växer, och eftersom en datadriven orientering i allt högre grad anses vara en konkurrenskraftig nödvändighet, är kriget mellan plattformsleverantörer för att tillhandahålla det primära arkivet för vår data intensiv. Kriget har flera fronter, varav en är analys. Och inom den omfattningen är datalagret och datasjölägren de viktigaste stridandena.

Datalagersidan är stark, eftersom den inkluderar en kombination av trofasta etablerade leverantörer som Teradata och Vertica (nu en del av Micro Focus), alla tre stora molnleverantörer och branschälsklingen Snowflake. På datasjösidan är oberoende leverantörer, som Cloudera och ovannämnda Databricks, de kanske mest emblematiska konkurrenterna. För några månader sedan sa Databricks att det uppnådde rekordprestandaresultat som gör det segrande i striden och besegrat datalagermodellen och leverantörerna som kämpar för den. Även om detta inte längre är de senaste nyheterna, trodde jag att en analys av tillkännagivandet fortfarande var på sin plats.

Trampa inte bara vatten

Medan förespråkare för datasjön (och “lakehouse”, som Databricks gärna kallar sin egen plattform) kan kritisera lagret som föråldrat, är det senare beprövat och åtnjuter en viss dominans. Det lägger bevisbördan på datasjösidan för att visa att den kan hantera samma arbetsbelastning som lagret, med konkurrenskraftig prestanda.

Databricks tror nu att de har det beviset. I november förra året tillkännagav företaget resultaten av en uppsättning benchmarks som granskats av och baserade på standarder från Transaction Processing Performance Council (TPC). Testerna kördes mot den relativt nya och ännu mer nyligen förbättrade Databricks SQL-plattformen, företagets grund för den tidigare nämnda lakehouse-arkitekturen. Specifikt använde benchmark-konfigurationen Databricks SQL 8.3, som inkluderar Databricks egenutvecklade Photon-motor, en vektorbearbetande, frågeprocessoroptimerad ersättning för Spark SQL, skriven i C++.

Databricks SQL specifikt, och lakehouse-arkitekturen i allmänhet, använder datasjöteknologi i kärnan, kombinerat med förbättringar – som ACID-kompatibilitet, återskrivning och vektorbearbetning – som hjälper till att ge kapacitetsparitet med datalagerplattformar. Databricks SQL använder fortfarande kluster av maskiner som kör den Spark-baserade Databricks Runtime, men optimerar noderna på dessa kluster för de typer av frågor och användarbehovsmönster som är vanliga i användningsfall för datalager och business intelligence (BI).

DS, FTW

Databricks använde TPC-DS stabila tester, länge en industristandard för benchmarking av datalagersystem. Riktmärkena utfördes på ett mycket biffigt Databricks SQL-kluster med 256 noder och 2112 kärnor, vars molninfrastruktur prissattes till norr om 5 miljoner USD av Databricks. “DS” står förresten för “decision support”, en föregångare till termen business intelligence, som, med tanke på Databricks SQLs design och uppdrag, är ganska apropos.

Databricks kännetecknar benchmarkresultaten genom att säga att det satte ett nytt världsrekord för TPC-DS-prestanda utförd på vilken plattform som helst, vare sig det är lager, sjö eller sjö. Den tidigare rekordhållaren för prestanda i skalan av Databricks TPC-DS benchmarkkörningar var Alibaba. Den kinesiska internet- och e-handelsjätten hade uppnått ett resultat på 14 861 137 QphDS @ 100 TB (beslutsstödsfrågor per timme, baserat på frågor som involverar 100 TB data), med hjälp av sitt eget specialbyggda – och även ganska biffiga – datalager systemet.

Databricks meddelade samtidigt att det uppnådde ett resultat på 32 941 245 QphDS @ 100TB, det vill säga mer än dubbelt Alibabas prestanda. Det gjorde det på ett system som, enligt företaget, var 10 % lägre i kostnad än Alibabas hembryggningsplattform. Och medan riktmärkena utfördes av Databricks själv, granskades resultaten av TPC.

Enligt Databricks uppfattning satte det rekord genom tiderna. Företaget anser vidare att alla blockerare som hindrade kunder från att använda en sjöplattform i stället för en lagerplattform nu borde rensas. Det är betydelsefullt eftersom Databricks, även i sitt förespråkande av sjöhusmetoden, tidigare medgav att lagerplattformar presterade bättre för vissa arbetsbelastningar, och företaget förstod att detta prestationsunderskott hindrade kunder från att komma över till sjösidan.

Att konfrontera Snowflake

Databricks kände tydligt att dessa benchmark-resultat gynnade det, konkurrenskraftigt, med datalagerets älskling Snowflake. På tal om vilket, bortom själva TPC-referensresultaten, hyllar Databricks arbete utfört av Barcelona Supercomputing Center (BSC) som jämför Databricks SQL och Snowflake. Databricks säger att detta arbete, som var baserat på TPC-DS-riktmärken men inte TPC-reviderat, visar att Databricks SQL är 2,7 gånger snabbare (se bilden nedan, från ett Databricks-blogginlägg om ämnet). BSC rapporterar också att ett Databricks SQL-kluster är 12 gånger bättre när det gäller prisprestanda än en Snowflake-uppställning av liknande storlek.

Databricks TPC-DS benchmark-resultat och analysplattformens krig

Det finns gott om spinn här, men vad TPC- och BSC-resultaten visar är att lakehouse-arkitekturen kan ta på sig dessa BI-arbetsbelastningar och göra det på ett respektfullt sätt. Detta är viktigt eftersom de flesta Spark-baserade system, inklusive Databricks, tidigare hade varit bäst för datateknik, maskininlärning och intermittenta frågor inom analysområdet. Det var svårare att få ett sådant system att betjäna pågående analysarbetsbelastningar, eller ad hoc-analys som involverade flera frågor som bygger på varandra.

Om frågan är om detta betyder att sjöhuset nu är en fullt möjlig ersättning för ett lager, då är svaret oklart. Den främsta orsaken till denna otydlighet har att göra med kundernas kriterier och kundernas åsikter om varför en sjö eller ett sjöhus inte var ett lämpligt substitut tidigare. Ja, för vissa var anledningen till att hålla fast vid ett lager prestanda, och den här sviten av TPC-riktmärken kan ta itu med dessa problem och påverka kunder som förespråkade dem.

En fråga om formalitet

För andra kunder handlar kriterierna mer om paradigmet — inklusive datamodellering och på sätt och vis datastyrning — än om prestanda i sig. En sjös etos är att lagra data i form av namngivna filer i öppna format, så att data är kompatibla med och kan användas av en rad databas- och analysmotorer. Och eftersom data lagras som filer på en disk eller i molnlagring, minskar behovet (och viljan) att modellera det. Detta gör uppgifterna mindre formell, ofta mindre granskade och också mindre granskade. Kontrollen är mer delegerad, vilket gör det lättare att lägga in data. (Dessa egenskaper hos en datasjö gäller även för sjöhusscenarier.)

Ett datalager är mer formellt, mer kontrollerat, vilket vanligtvis tillämpar en mer explicit och heltäckande datamodell. Det är mindre smidigt, vilket frustrerar användarna, men det har också mer av ett filter, som kan korrelera med en generellt högre grad av datakvalitet och användarförtroende.

Stora riktmärken för big data

Ett system med infrastruktur till ett värde av 5 miljoner USD och enorma datavolymer kan vara ett av de största och kan ta sig an Alibabas riktmärke, men det är inte typiskt för vad de flesta kunder behöver eller har råd med. Det visar att Databricks SQL kan ta på sig enorma arbetsbelastningar, och för vissa kunder kommer det i sig att vara viktigt.

Betydelsen av Databricks benchmarkresultat kan bäst förstås genom korrekt inramning av frågan. Databricks skulle rama in det i termer av vilken modell som regerar. Men kanske är frågan mer om vilken modell som tilltalar specifika kunder mer, i synnerhet användningsfall, och om prestandan nu är tillräcklig med båda modellerna.

I slutändan kan de flesta företag förmodligen dra nytta av ett datalager och ett datasjö(hus). Lagret kan vara ett arkiv för välbevakade, noggrant anpassade och modellerade data, för att driva rapportering, operativa instrumentpaneler och ad hoc-frågor i sfären av “kända okända”. Sjöar och sjöhus kan under tiden ta emot mer data, med en kortare ombordstigningsprocess, med mindre “modellering vid skrivning” och användas för utforskande analyser och improviserade visualiseringar.

Vinsten, inte vinnaren

TPC-resultaten gör det tydligt att båda modellerna fungerar bra, ger utmärkta resultat, kan samverka vid behov, arbeta med samma BI-verktyg och är kostnadseffektiv, moln-först, elastisk och smidig. Men även om frågan om lager/sjöhus inte behöver kräva ett antingen/eller-val, finns det en uppsida med att leverantörer ser det så: deras konkurrens om samma kunder och samma arbetsbelastning resulterar i fortsatt innovation som gynnar kunden.

Om TPC-riktmärken är den ultimata bedömningen av vad som är bäst beror på köparens kriterier. Men Databricks TPC-DS-resultat är imponerande, oavsett. De är en milstolpe för branschen och en tvingande funktion för att se till att leverantörer antar ett tillvägagångssätt för ständiga förbättringar, oavsett om de visar sjön, sjön eller lagret.