06.11.2017 | Blogi

Data DevOps – kuinka puhaltaa uutta elämää eläviin kuolleisiin?

Nykyään ajatellaan usein, että tietovarastointi on hidasta, ei-niin-ketterää tai jopa kuollutta. Moni ajattelee myös, että riittää kun ottaa käyttöön vain jonkin/joitain geneerisiä pilvipalveluita ja alkaa ajamaan analytiikkaa niissä. Moni on kuitenkin väärässä tämän suhteen. Tietovarasto- ja analytiikkakehittäminen vaatii Data DevOps:ia syntyäkseen uudestaan. Me olemme kehittäneet lääkkeen tähän vaivaan.

On nimittäin elintärkeää pitää tieto koherenttina ja hyvin mallinnettuna etenkin, kun maailma menee yhä enemmän operatiivisemman ja jatkuvamman analytiikan suuntaan. Tietoa on tärkeää myös hallita yhä automaattisemmin, jotta järjestelmillä saavutetaan jatkuva 24/7/365 operatiivinen luonne. Tämän lisäksi kehitystiimin tulee tuottaa liiketoiminnallista hyötyä jo ensimmäisestä päivästä lähtien.

Ohjelmoijien vallankumous tiedonhallinnassa

Ohjelmoijien vallankumous tiedonhallinnassa alkoi yli kymmenen vuotta sitten NoSQL-tietokannoista ja Hadoop-alustan kehittämisestä. Ne syntyivät tarpeeseen ja kasvoivat isoiksikin tekijöiksi alalla. Mutta loppujen lopuksi näiden teknologioiden ja ohjelmoijien piti palata relaatiomalliin ja SQL:ään, jolloin NoSQL kääntyi SQL -fraasiksi ja SQL-toteutuksille Hadoopin päälle tuli myös huutava pula (SQL on Hadoop ja SQL in Hadoop). Tämä vallankumous aiheutti sen, että ennen niin selviä, tai vähintään yli toteutusten yhteneviä SQL-kyselyitä alettiin ohjelmoida räätäliohjelmanpätkinä. Puhumattakaan transaktionaalisuuden ja optimaalisen suorituskyvyn uhraamisesta.

Ohjelmoijien vallankumous tiedonhallinnassa alkoi yli kymmenen vuotta sitten NoSQL-tietokannoista ja Hadoop-alustan kehittämisestä.

Pilvi data lake -toteutusten kanssa voi pahimmillaan käydä samalla tavalla. Lisäksi pilvitoteutukset tuovat tiedonhallinnan tekemiseen tarpeen hallita perinteisesti IT-infraan liittyviä asioita. Kuitenkin, tiedonhallinnan periaatteet ja tietomallinnus sekä tiedon hyödyntäminen ovat se ”pihvi”, joka tuottaa liiketoimintahyötyä. Teknologia ja metodologia -pinot ovat kasvaneet entisestään. Tästä syystä tulee olla valppaana, että henkilösidonnaisuus ja räätälitekeminen eivät kasva kestämättömän kokoisiksi tiedonhallinnan hankkeissa.

Nähdäkseni ongelma ei ollutkaan relaatiomallissa eikä SQL:ssä (tietenkään), vaan henkilösidonnaisuudessa ja tietysti perinteisten tietokantojen ylläpitokustannuksissa. Tästä syystä vallankumous olisi pitänyt olla NoSQL:n sijaan nimeltään NoDBA. Nyt pahimmillaan tiedonhallinnan ja ohjelmistotekemisen huonot puolet yhdistyvät; eli korkeat ylläpitokustannukset ja henkilösidonnaisuus. Tässä on nähdäkseni ainekset jopa manattuun ”elävään kuolleeseen” kierteeseen.

Uusi vallankumous: Software-Defined Operational Analytics

Perinteisesti tietovarasto- ja analytiikkatekemisen pino koostuu räätälöidystä kehitys-/testaus-/käyttöönottomallista sekä erillisistä työkaluista ja ohjelmistoista (Kuva 1.). Tällaisesta mallista puuttuu koko pinon läpileikkaava automaatio, eri työkaluihin viedään muutokset erillisillä malleilla ja työ tapahtuu erillisissä työkaluissa.

Pystyäksemme keskittymään hankkeissa liiketoimintahyödyn tuottamiseen, meidän tulee yhdistää parhaimmat puolet pilviteknologioista, tietovarasto- ja analytiikkatekemisestä sekä ohjelmistotuotannosta.

Eli pilviteknologioista tuttu ns. software-defined-näkemys, ohjelmistotekemisen parhaat käytänteet sekä tiedonhallinnan periaatteet mahdollistavat ainutlaatuisen Data DevOps -toimittamisen mallin. Tässä mallissa tulee ottaa hallintaan koko tietovarasto- ja analytiikkatekemisen pino.

Kuva 1. Perinteinen tietovarastotekemisen pino (ei läpileikkaavaa automaatiota).

Automaatiossa on keskityttävä yleisimpien tehtävien ja ominaisuuksien tukemiseen jokaisella pinon tasolla (Kuva 2.), niin että 85% työstä tulee katetuksi ja tuloksena on optimoitu ympäristö tietovarasto- ja analytiikkakehittämiseen, -toimittamiseen ja ajoympäristön hallintaan. Tätä me kutsumme Software-Defined Operational Analytics:iksi (ohjelmiston määrittelemä operatiivinen analytiikka). Software-defined-käsite on tuttu pilviarkkitehtuureista, kuten software-defined storage (hajautetut ohjelmistojen hallitsemat tiedostojärjestelmät, kuten Hadoop Distributed File System ja AWS S3 Object Storage) ja software-defined networks (tietoverkkojen virtualisointi, SDN/NFV).

Kuva 2. Solitan Agile Data Engine -pinon läpileikkaava ratkaisu mahdollistaa Data DevOpsin.

Kun käytämme tätä samaa käsitettä software-defined, viittaamme tietovarasto- ja analytiikkakehittämisen eri automaatioalueisiin (Kuva 3.). Solitan Agile Data Engine ohjelmisto vastaa näihin automaation alueisiin, ja se onkin jo saanut hyvää – jopa kirotun hyvää – palautetta niin asiakkailta kuin käyttäjiltäkin. Kaikilla on oikeus automaatioon!

Kuva 3. Operatiivisen analytiikan automaation alueet.

Onko teidän tietovarasto- ja analytiikkaympäristönne elävä kuollut, eli kuin zombi? Jos näin on, niin anna meidän auttaa. Meillä on ratkaisu, joka puhaltaa sen uuteen elämään. Lue lisää täältä.

Harri Kallio työskentelee Solitan Cloud and Analytics -liiketoiminnankehityksessä. Hän johtaa Agile Data Engine -ohjelmistokehitystä. Hänellä on 12 vuoden kokemus ohjelmistotuotekehityksestä logistiikan teollisen internetin sekä televerkkojen monitoroinnin ja analytiikan aloilta. Harri puhuu SQL:ää aamupalalla, performanssiarkkitehtuureista unissaan ja konsepteista hereillä ollessaan. Hän on kahden tyttären ylpeä isä.