Jokainen sekunti ratkaisee - pilvipalvelun kustannuksissa piilee jopa 80% säästöpotentiaali

Tavanomainen liiketoiminnan tunnuslukujen raportoiminen saattaa kerryttää organisaation pilvipalveluihin pitkään piilossa pysyviä piilovirheitä ja turhia kustannuksia. Tässä blogissa kerron, mistä piilovirheet tavanomaisesti syntyvät ja miten kustannuksia on mahdollista optimoida Databricks- ja Microsoft Fabric-ympäristössä.

Tyypillisesti pilvipalveluiden piilovirheet ja -kustannukset alkavat kertyä jo suunnitteluvaiheesta, tai paremminkin suunnittelun puutteesta. Ei esimerkiksi ole lainkaan harvinaista, että dataa ajetaan konesaleihin automaattiasetuksilla, järjestelmiä ei kytketä pois päältä tai ajotehtäviä ei lopeteta oikein. Konesalit saattavat jauhaa säännöllisesti jokaisena viikonloppuna täysin hukkaan heitettyä dataa kenenkään tietämättä. Tämän ennaltaehkäiseminen ei vaadi puolen vuoden räätälöintiprojektia. Usein muutama tunti enemmän suunnitteluaikaa ja oikeiden kysymysten kysyminen estäisivät ongelmien muodostumisen. Kokonaisuuden suunnitteluun investoitava aika tuottaa pitkällä aikavälillä merkittäviä säästöjä. Kustannusoptimoidun datatekemisen perustukset rakentuvat pilvinatiivin tietovarastoinnin varaan. Kustannusten näkökulmasta parhaimmat ratkaisut voidaan jakaa kahteen kokonaisuuteen: datan varastointiin ja pilvilaskennan kapasiteetin käytön optimoimiseen.

Lineaarisesta logaritmiseen kustannuskehitykseen

Liiketoiminnan tunnuslukujen raportointi on usein ensimmäinen tiedolla johtamisen työkalu, josta pilviteknologian ja datan hyötyjä aletaan ensimmäisenä etsiä. Tyypillisesti ratkaisua kokeillaan ensin osassa tai vain yhdessä liiketoimintayksikössä. Kokeilusta syntyy uusia johtamisen ja tuotannonohjauksen työkaluja, innostusta ja halua laajentaa ratkaisu laajemmin organisaation eri yksiköihin. Kun organisaation datatekeminen alkaa laajentua, alkaa konepellin alla syntyä ratkaisuja, jotka eivät huomioi eri yksiköiden tekemistä. Piilokustannuksia alkaa kertyä, jos kukin liiketoimintayksikkö alkaa laajentaa omaa dataputkistoaan omista lähtökohdistaan, käsittelee dataa omista lähtökohdistaan, eikä huomioi esimerkiksi datan yhteiskäytön mahdollisuuksia. Tällöin dataa saatetaan ajaa laskentaan tuhansia tai kymmeniä tuhansia rivejä useita kertoja vuorokaudessa. Tuloksena on saatu samat asiat, jotka olisi saatu ajamalla datasetti kertaalleen. Tästä syntyvät ajan myötä lineaarisesti kasvavat ja pitkään piilossa pysyvät kustannukset. Lineaarisen kasvukäyrän sijaan tavoitteena tulisi olla logaritminen kustannuskehitys: mitä enemmän dataa ja laskentaa, sitä vähemmän kustannuksia suhteessa datan määrään ja tuloksiin.

Delta Lake ratkaisee valtaosan kustannusongelmista

Databricksiin tai Microsoft Fabriciin integroitava Delta Lake tarjoaa kokonaisvaltaisen lähestymistavan kustannusten optimointiin koko datan elinkaaren ajan. Kyseessä on eräänlainen datan välivarasto, joka toimii olemassa olevan raakadataa tallentavan varaston päällä. Usein pelkästään Delta Laken käyttöönotto ratkaisee valtaosan datan käsittelyn kustannusongelmista. Parhaimmillaan ratkaisu on tuottanut jopa 80 prosentin säästöt pilvikustannuksiin.

Delta Lake

Mahdollistaa ACID-transaktiot varmistavat tietojen eheyden datanlukujen ja kirjoitusten aikana. Tämä vähentää tarvetta kalliisiin tietojen palautusprosesseihin tai monimutkaisiin kiertotoimenpiteisiin johdonmukaisuusongelmien yhteydessä.
Mahdollistaa tehokkaan ja skaalautuvan metatietojen käsittelyn. Tämän avulla se kykenee käsittelemään petatavuja dataa miljardeissa tiedostoissa minimaalisella suorituskykyvaikutuksella.
Käsittelee tehtäväkohtaista ja reaaliaikaista dataa samalla tavalla. Tämän ansiosta tietojenkäsittelyputket saadaan rakennettua mahdollisimman tehokkaiksi. Yhtenäinen käsittelytapa vähentää tarvetta erillisille järjestelmille erityyppisten datatyökuormien käsittelyyn. Tämä vähentää suoraan infra- ja ylläpitokustannuksia.
Vähentää kyselyiden aikana skannattavien tietojen määrää. Tämä ei ainoastaan nopeuta kyselyaikoja, vaan voi myös alentaa tietojenkäsittelyyn liittyviä kustannuksia pilviympäristössä.
Tiivistää ja indeksoi tiedot ja parantaa kyselyiden suorituskykyä, mikä voi vähentää merkittävästi tietojenkäsittelytehtävien vaatimia laskentaresursseja ja kustannuksia.
Tukee tietojen inkrementaalista lataamista ja aikaisempien versioiden kyselyitä. Tämä tarkoittaa, että kaikkia tietoja ei tarvitse käsitellä uudelleen jokaisen uuden tietoerän yhteydessä. Inkrementaalinen tietojenkäsittelyominaisuus vähentää käyttökustannuksia käsittelemällä vain sitä dataa, joka on muuttunut edellisestä ajosta.
Virtaviivaistaa ja yksinkertaistaa ETL-prosesseja (Extract, Transform, Load), mikä vähentää tietojen syöttämiseen ja valmisteluun liittyviä kustannuksia.

Tehtäväklusterit säästävät rahaa

Databricks ja Microsoft Fabric mahdollistavat pilvilaskentakapasiteetin optimoinnin sekä räätälöityjen laskentatehtävien määrittelyn ja käsittelyn kustannustehokkaasti. Tehtäväklusterit määritellään rajattujen töiden suorittamista varten siten, että ne käyttävät vain tehtävän suorittamiseen tarvittavan laskentakapasiteetin. Työt voidaan ajoittaa suoritettaviksi tiettyinä aikoina, esimerkiksi silloin, kun laskentakapasiteetin hinnat ovat ruuhka-aikoja halvempia. Tehtävä voidaan ajastaa Microsoftin tarjoamille Spot-tunneille, jolloin yhtiö myy konesaliensa ylijäämäkapasiteettia alennuksella. Databricks esimerkiksi automatisoi klustereiden hallinnan käyttöönotosta skaalaamiseen ja lopettamiseen. Tämä vähentää käyttäjille aiheutuvia toimintakustannuksia ja tehostaa kapasiteetin käyttöä merkittävästi.

Tehtäväklusteri määritellään koon, tyypin (esim. CPU- tai GPU-pohjainen) ja muiden asetusten, kuten automaattisen skaalautumisen mukaisesti loppukäyttäjän tarpeiden mukaisesti. Databricksissa tehtävän käsite viittaa laskentatehtävään tai tehtäväsarjaan, kuten tietojenkäsittelyyn, analysointiin tai koneoppimismallien koulutukseen. Työ määritellään yhdellä tai useammalla tehtävällä, jotka voivat olla Notebook-tehtäviä, Spark jar -tehtäviä, Python-tehtäviä jne. Jokainen tehtävä määrittää suoritettavan koodin ja sen vaatimat parametrit.

Databricks ja MS Fabric

Mahdollistaa modernin tietovarastoinnin ja tarvittavan kerroksellisuuden, jolla saadaan joustava ja organisaation tarpeisiin vastaava ratkaisu.
Suunniteltu suurten datamäärien käsittelyyn ja analysointiin. Se yhdistää datan
valmistelun, datatieteen, koneoppimisen ja liiketoiminta-analytiikan yhteen alustaan. Tiimien yhteistyössä ei ole tarvetta siirtää dataa eri työkalujen ja alustojen välillä.
Rakentuu Apache Sparkin päälle. Spark tarjoaa nopeat analytiikka- ja datankäsittelyominaisuudet suurille datamäärille hajautetun laskennan avulla. Käyttäjät voivat helposti skaalata laskentaresursseja ylös tai alas datan käsittelyn vaatimusten mukaisesti.
Tarjoaa organisaatioiden sisäiseen yhteistyöhön notebook-ympäristön, jossa käyttäjät voivat kirjoittaa ja suorittaa koodia (esim. Python, Scala, SQL), visualisoida dataa ja jakaa tuloksia tiiminsä kanssa.

Jaettu klusteri pitää koneen lämpimänä

Siinä missä tehtäväklusterit on tarkoitettu vain ajastetuille ajoille, jaetuissa klustereissa on mahdollista tehdä data-ajoja yhtä aikaa kehitystyön kanssa.
Tyypillisesti kustannusongelmia alkaa syntyä, kun jokaiselle kehittäjälle varataan oma klusteri jaettujen klustereiden sijaan. Kustannuksia saattaa kerryttää 10–20 klusteria, kun kaksi riittäisi.

Jaetut klusterit nopeuttavat datan käsittelyä konesaleissa. Ne mahdollistavat muutosten tekemisen ilman, että konesalissa laskentaa tekevä kone ehtii sammua. Kun koneen ylösajo vie muutaman minuutin, optimoimattomat kehityksen menetelmät alkavat kerryttää piilokustannuksia, joista ajan myötä syntyy merkittäviä kuluja. Esimerkiksi Databricksissä kustannukset lasketaan sekunnin tarkkuudella, ja tässäkin tapauksessa pienistä puroista kertyy lopulta vuolas kustannusten virta, mikäli kehitystyön käytännöt eivät ole kustannusoptimoituja ja yhteisesti sovittuja.

Kustannusten optimointi on mahdollista monin eri tavoin. Meille tuttuja työkaluja tämän saavuttamiseen ovat muun muassa koodin optimointi, yksikköjen varaus, suora orkestrointi Databriksillä, Databricks Photon. Lisää vaihtoehtoja löytyy Microsoftin sivuilta ja Fabricista sisäänrakennettuina ominaisuuksina.

Datakulttuurin kehitysmatka

Pilvipalveluiden perusidea on mahdollistaa tiedon jakaminen keskitetysti laajalle joukolle käyttäjiä. Liian usein tämä peruslähtökohta unohtuu.
Lopulta kyse on ihmisistä ja organisaation kyvykkyyksistä. Kustannusyllätysten taustalla on usein samankaltaisia piirteitä, jotka kertovat toisaalta innostuksesta laajentaa datakehitystä organisaatiossa, mutta vielä kehittymässä olevasta datakulttuurista. Datakehitykseen liittyvää päätöksentekoa ajaa liiketoimintatavoitteet. Tämä on oikea lähestymistapa, mutta usein päätöksenteon rakenteet eivät huomioi riittävästi sitä, mitä datakehityksen konepellin alla tapahtuu ja miksi.

Datakehitystä jäykistää, usein turhaan, esimerkiksi datan käyttöoikeuksiin liittyvät kysymykset. On olennaista kysyä, mitä tuloksia kukin liiketoimintayksikkö tavoittelee ja mitkä ovat datakehityksen erityistarpeet. Kustannustehokkuuden kannalta olennaista on kysyä, minkälaista yhteistä dataa eri liiketoimintayksiköt kykenevät hyödyntämään. Pilvilaskennan kustannustehokkuus vaatii suunnittelussa selkeitä omistajuuden ja datan hallinnoimisen käytänteitä sekä IT:n ja organisaation eri liiketoimintayksiköiden sujuvaa yhteistyötä.

Datakehityksen ja sovellusten tulee aina olla liiketoimintalähtöisiä. Samaan aikaan se vaatii liiketoimintapäättäjältä kokonaisuuden hahmottamista ja riittävästi malttia, jotta tuloksia saadaan aikaiseksi kustannustehokkaasti. Datakulttuurin rakentaminen on vaiheittain etenevä kehitysmatka, jossa alkuvaiheen vauhdinjako ratkaisee menestyksen. Säästöjen hakeminen väärässä kohdassa datakehitysmatkaa saattaa olla lopulta kallis kiertotieksi osoittautunut oikotie.