Data Architectuur
Onze man in Silicon Valley Laatst bijgewerkt: 20 augustus 2018

Om inspiratie op te doen voor mijn artikelen en presentaties bezoek ik regelmatig leveranciers in de San Francisco Bay Area. De plek waar ontzettend veel software wordt ontwikkeld op het gebied van big data, BI en data science. Tijdens gesprekken met de CTO of hoofdarchitect discussieer ik over de architectuur, de sterke en zwakke eigenschappen en de toekomst van de producten. Deze nieuwe ontwikkelingen en inspirerende gesprekken deel ik graag via deze live blog.

13 AUG – Dremio Corporation


Het eerste bedrijf dat ik op mijn trip in augustus bezocht, is gevestigd in Mountain View. Deze stad ligt in het hart van Silicon Valley en is de thuisbasis van veel grote softwarebedrijven, waarvan Google waarschijnlijk de bekendste is. Het is ook de stad waar veel startups gevestigd zijn, waaronder Dremio Corporation, het onderwerp van deze blog. Het hoofdkantoor ligt in de schaduw van de Google gebouwen, nog geen twee kilometer van de Google campus.

De CEO van Dremio, Tomer Shiran, is geen nieuwkomer. Hij was onder meer de architect van Apache Drill, een populair SQL-on-Hadoop product. Drill valt op door het kunnen bevragen van Hadoop files en andere gegevensbronnen zonder dat het vooraf een structuurdefinitie nodig heeft. Drill probeert de structuur af te leiden door het lezen van de gegevens zelf. Deze technologie is ook meegenomen in hun nieuwe product Dremio.

In 2015 vertrok Tomer bij MapR om Dremio te ontwikkelen samen met de huidige CTO Jacques Nadeau. Dremio is ongeveer één jaar geleden uit stealth-mode gekomen en toen verscheen de eerste versie op de markt.
Dremio is lastig te positioneren. Het bevat een belangrijke datavirtualisatie-component, het ondersteunt datapreparatie-mogelijkheden en is ontwikkeld rond een datacatalog-component. Bij Dremio zelf twijfelen ze ook nog over hoe ze dit product het beste kunnen categoriseren en houden het momenteel op een, in mijn ogen niet sterke classificatie, data-as-a-service platform.

In een tweet heb ik het weleens datavirtualisatie voor business users genoemd. De datapreparatie-mogelijkheden maken het eenvoudig voor niet-technische gebruikers om gegevensbronnen te ontsluiten en te koppelen. Gebruikers hoeven niet gelijk met SQL aan de slag, zoals bij de meeste andere datavirtualisatie-producten.

Dremio doet zelf niet de datavisualiatie. Dremio laat dat over aan BI tools, zoals Tableau en QlikSense. Deze producten gebruiken Dremio om gegevens uit Hadoop direct te benaderen. Gegevens hoeven niet eerst vanuit Hadoop naar data warehouses en data marts gekopieerd te worden en voorbewerkt te worden. Dremio heeft de snelheid om die gegevens live op te halen, ook als het om enorme hoeveelheden gaat. In feite biedt Dremio self-service BI mogelijkheden op datalakes en andere grote gegevensomgevingen.

Deze snelheid wordt voor een groot deel ontleend aan het gebruik van Apache Arrow. Op de Dremio website wordt deze technologie als volgt gedefinieerd: “Apache Arrow is a cross-platform standard for columnar data for in-memory processing. You can think of Arrow as the in-memory counterpart to popular on-disk formats like Apache Parquet and Apache ORC”.

Technologieën zoals Spark en TensorFlow maken er ook gebruik van. Apache Arrow kent al zo’n 200.000 downloads per maand.
Voor een volgende versie van Dremio wordt er gewerkt aan het open source initiatief genaamd Gandiva. Gandiva kan op een bepaalde manier vergeleken worden met JDBC en ODBC. Bij de twee laatstgenoemde worden de gegevens vanuit een bron naar een aanroepende applicatie altijd serieel verzonden, ofwel de rijen worden één voor één verstuurd. Als de bron parallel gegevens kan verwerken en de applicatie ook, dan is dit een serieuze bottleneck. Met Gandiva kunnen bron en applicatie parallel gegevens uitwisselen. Vooral technologieën die gegevens kolom-georiënteerd verwerken hebben hier veel baat bij.

Ondanks dat Dremio lastig te positioneren is, is het zeker de moeite waard om te bestuderen. Mocht je bovendien ooit de kans krijgen om een gesprek met Tomer Shiran te voeren, dan moet je dat zeker doen. Een inspirerende persoonlijkheid met een enorme technische bagage.

14 AUG – Tibco


Nu het stof is opgetrokken, is duidelijk hoe het ervoor staat met de Tibco datavirtualisatie server (TDV). De historie is waarschijnlijk bekend. In 2001 werd Composite Software opgericht in San Mateo, Californië. Initieel was het doel een product te ontwikkelen waarmee dataservices snel gebouwd konden worden. Dat doel werd al vroeg bijgesteld en het resultaat was een krachtig datavirtualisatie product: Composite Information Server. Na twaalf jaar werd het bedrijf gekocht door Cisco. Voor velen een onverwachte koper. Wat moest zo’n netwerkbedrijf met een datavirtualisatie server? Vier jaar later, in oktober 2017, werd het product verkocht aan Tibco Software. Nagenoeg het gehele ontwikkel- en marketingteam verhuisden mee.

Cisco bleek geen goed thuis voor dit product. De vraag was of Tibco dit wel zou zijn. Vandaar dat ik graag voor een gesprek langsging op het hoofdkantoor in Palo Alto. Palo Alto is een stad waar hippiebands als de Grateful Dead zijn begonnen. Het grenst aan de beroemde Stanford University en veel softwarebedrijven zijn er ooit begonnen, waaronder Facebook, Google, Hewlett Packard, Paypal, Pinterest en VMware.

Na een lang gesprek met engineers en product marketeers van TDV is mijn conclusie dat, een half jaar na de overname, Tibco een prima thuis lijkt te zijn.

Uiteraard is in het afgelopen jaar het product doorontwikkeld, maar door de overname zat daar wel enige tijd de handrem op. Bijvoorbeeld, parallel processing, waar Cisco al een tijd over sprak, zal waarschijnlijk pas de tweede helft van 2018 beschikbaar komen. Dit soort vertragingen zien we vaak bij overnames.

De belangrijkste vraag was of Tibco het product zou laten “verdwijnen” als module binnen andere producten. Het zou dan geen stand alone product meer zijn. Daar lijkt het momenteel geheel niet op. Het lijkt alsof Tibco dezelfde aanpak gaat volgen met TDV als met veel andere producten. Het wordt een op zichzelf staand product dat met allerlei niet-Tibco producten kan samenwerken. Tibco zal er wel voor zorgen dat de connectie met de eigen producten van topkwaliteit is. Er is bijvoorbeeld nu al gewerkt aan het verbeteren van de interfaces tussen TDV en Spotfire, Statistica en Jaspersoft.

Er zal ook een synergetisch effect optreden. Zo heeft bijvoorbeeld een Tibco ontwikkelaar van de datagrid-technologie ActiveSpaces een koppeling gecreëerd met TDV. Hierdoor kan TDV gebruik maken van de kracht en snelheid van deze datagrid-technologie. De TDV ontwikkelgroep hoeft dus zelf niet meer alles te ontwikkelen. Persoonlijk zie ik graag directe interfaces ontstaan met Tibco’s master data management product en hun streaming database technologie, StreamBase.

De roadmap voor de komende maanden ziet er niet spectaculair uit, maar bevat wel veel verbeteringen. Onder andere de lijst van ondersteunde gegevensbronnen wordt uitgebreid, TDV zal op het gebied van cloud-ondersteuning sterk verbeterd worden en de query optimizer wordt versterkt met nieuwe technieken om sneller gegevens te benaderen. Hierbij zullen ook AI-technieken ingezet gaan worden.

Waar Tibco veel van verwacht zijn de cross-sell mogelijkheden. Het bedrijf heeft al veel bestaande klanten, waarvan sommigen al tientallen jaren klant zijn. Vooral cross-sell mogelijkheden met Spotfire en de andere BI-achtige tools zijn veelbelovend.

Kortom, TDV is terug en neemt in de datavirtualisatiemarkt weer een sterke plek in.

15 AUG – Arcadia Data


Het derde bezoek bracht mij naar een andere stad in de San Francisco Bay Area: San Mateo. Een wat gezichtsloze stad gelegen tussen Silicon Valley en San Francisco in. Er is niet veel over te vertellen. Zelfs op het gebied van muziek heeft San Mateo weinig artiesten voortgebracht. Na lang zoeken vond ik Merl Saunders. Hij heeft samen met de voorman van de Grateful Dead, Jerry Garcia, albums gemaakt. Een andere muzikant is gitarist Neal Schon die op de eerste albums van Carlos Santana mee speelde. Oh ja, en als je heel diep zoekt, country zanger Keith Carradine, de halfbroer van “Kung Fu” David Carradine, is ook in San Mateo geboren.

Ik bezocht daar Arcadia Data, leverancier van een BI-tool. Ongeveer anderhalf jaar geleden heb ik ze ook al bezocht. Toen vroeg ik hen waarom een bedrijf nog een BI-tool wilde ontwikkelen terwijl er al zoveel bestaan en wat hun unique selling point was. Een beetje beter of een beetje anders dan Qlik of Tableau is niet voldoende om in deze overvolle markt een acceptabel marktaandeel te veroveren. Anderhalf jaar geleden kreeg ik geen glashelder antwoord, deze keer wel.

Mijn twee gesprekspartners bij dit bezoek waren twee oudgedienden: Dale Kim, senior director products, en Steve Wooledge, VP marketing. Beiden hebben gewerkt bij leveranciers als MapD en Teradata en hebben veel ervaring met software voor grote en zware omgevingen.

Buiten dat het allerlei prachtige en moderne visualisaties ondersteunt, heeft het product een aparte manier om big data bronnen te bevragen en te visualiseren. Elk BI-tool kan tegenwoordig big data bronnen zoals Hadoop bevragen; dit gebeurt meestal door data van Hadoop te kopiëren naar de memory van het BI-tool. Daarna worden de meeste vragen van de gebruikers beantwoord vanuit memory. Dit gaat heel snel, maar de meeste tools hebben wel de beperking dat niet alle big data ingelezen kan worden en dat er dus een beperkte hoeveelheid data geanalyseerd kan worden. Vaak moet big data daarom geaggregeerd worden voordat het geladen wordt en dus is analyse op het meest gedetailleerde niveau niet meer mogelijk.

Voor Arcadia Data geldt deze beperking niet. Het product bestaat uit twee modules, de visualization engine en de acceleration engine. Eerstgenoemde is de module die de gebruikers zien en gebruiken. Laatstgenoemde is verantwoordelijk voor het ophalen van de gegevens uit Hadoop. Nu bestaan er tegenwoordig veel producten die dat kunnen, denk alleen al aan alle SQL-on-Hadoop engines zoals Hive en Impala. Arcadia Data’s acceleration engine heeft twee technische voordelen. Ten eerste, de engine draait in het Hadoop cluster. Dichterbij de data kan eigenlijk niet. Dit versnelt de benadering van de gegevens aanzienlijk. Dit levert ook direct een extra security voordeel op. Als bepaalde Hadoop files worden beveiligd, neemt Arcadia Data dat direct over.

Het tweede technische voordeel is dat de acceleration engine werkt met wat ze noemen analytical views. Indien bepaalde geaggregeerde gegevens vaak opgevraagd worden, kan een analytical view gedefinieerd worden waarin deze gegevens al van tevoren uitgerekend zijn. Dit is een voorbeeld van een instructie om zo’n analytical view te definiëren:

create analytical view events_aview

stored as parquet

as (select   count(*), platform, sdk_version

    from     events   

    group by platform, sdk_version);

De inhoud van deze view wordt fysiek opgeslagen; in dit voorbeeld in een Hadoop file met een Parquet file formaat. De acceleration engine bepaalt bij elke query of een analytical view gebruikt kan worden of dat de oorspronkelijke Hadoop files benaderd moeten worden. In het eerste geval zal dit de verwerking van de query enorm versnellen. De acceleration engine beheert deze opgeslagen gegevens zelf. Voor de gebruikers is het fysiek opslaan van deze views volledig onzichtbaar. Analytical views zijn niet nuttig voor data scientists, omdat zij zelden dezelfde query afvuren.

Waarom hebben ze voor deze architectuur gekozen? Het product is ontwikkeld voor een bepaalde use case. Zij gaan ervan uit dat de rol van een op Hadoop-gebaseerd data lake steeds prominenter zal worden binnen organisaties. Het data lake zal niet meer alleen gebruikt worden door een klein groepje data scientists, maar door een grote groep traditionele business gebruikers. Deze laatste workload kunnen we betitelen als productie BI. Productie BI wordt gekenmerkt door veel gebruikers die dag in dag uit gegevens opvragen met vooraf gedefinieerde rapporten, dashboards en apps. Arcadia Data is dus primair ontwikkeld en geoptimaliseerd voor productie BI waarbij data in een data lake ligt opgeslagen. Het gaat hierbij om schaalbaarheid en snelle, stabiele performance.

Deze use case maakt het product tamelijk uniek. Veel BI-tools zijn ontwikkeld om veel gebruikers te ondersteunen op een klassiek SQL-gebaseerd datawarehouse of om een klein aantal data scientists te ondersteunen op een Hadoop-gebaseerd data lake. Arcadia Data heeft gekozen voor productie BI op een data lake.

Ten slotte, de visualisatiemodule ondersteunt sinds kort ook streaming. Met producten als Apache Kafka kunnen gegevens direct het product in gestreamd worden. Alle diagrammen op het scherm worden dan live bijgewerkt. Voor gebruikers die zero-latency data willen zien en die inzicht willen hebben in lopende bedrijfsprocessen, is dit een waardevolle aanvulling.

San Mateo mag dan misschien een wat saaie stad zijn, dat geldt zeker niet voor Arcadia Data’s product. Jammer dat het nog zo onbekend is in Europa.

16 AUG – Denodo


Toevallig dat nu de twee meest dominante datavirtualisatie leveranciers zich in Palo Alto bevinden: Denodo en Tibco. Dat hadden die hippies van de beruchte band Grateful Dead waarschijnlijk nooit bedacht toen ze daar redelijk onder invloed nieuwe nummers aan het componeren waren. Anders hadden ze vast wel een nummer over datavirtualisatie geschreven.

Dit bezoek ging niet over het product in het algemeen, het ging ook niet over de visie of over de interne architectuur. Ik wilde een deep dive in een van de onderdelen van het product, namelijk de data catalog. Pablo Alvarez, global director of product marketing, was bereid om mij door dit product te leiden.

Samenvattend, de sterke punten van Denodo’s data catalog zijn:

  • Views kunnen gedocumenteerd worden; voor elke kolom en view kan een omschrijving ingevoerd worden.
  • Tags kunnen aan views toegekend worden; gebruikers kunnen zelf nieuwe tags definiëren.
  • Views kunnen geclassificeerd worden; gebruikers kunnen zelf nieuwe classificaties toevoegen.
  • Voor views kunnen property groups gedefinieerd worden.
  • Views kunnen gezocht worden op basis van omschrijvingen, tags, classificaties en property groups.
  • De module helpt ook bij het creëren van queries op de views. Als er relaties met andere views gedefinieerd zijn, kunnen deze gekoppelde views ook gebruikt worden bij het creëren van de queries.
  • Het gebruik van views kan ook geanalyseerd worden. Informatie over wie, hoe vaak en hoe de views gebruikt zijn is beschikbaar.
  • De data catalog gegevens worden niet in dezelfde database opgeslagen als waar alle runtime gegevens liggen opgeslagen. Dit zou een negatieve invloed kunnen hebben op de performance van de datavirtualisatie server. De data catalog kan opgeslagen worden in een SQL-database naar keuze.

Op elk product is wat aan te merken. Altijd zijn er wel features te bedenken die niet ondersteund worden, dus ook voor Denodo’s data catalog. Wat momenteel ontbreekt is de functionaliteit om een ontologie en/of thesaurus op te bouwen waarmee de zoekfunctie versterkt kan worden. Bijvoorbeeld, als we zoeken op het woord “product” is de data catalog niet slim genoeg om ook op het woord “artikel” te zoeken. Wel biedt het product een soort Google-achtige search mogelijkheid. Deze kan gebruikt worden om toch met iets meer vrijheid te zoeken. Een andere omissie is de mogelijkheid om vrij business objecten te definiëren, dus onafhankelijk van de views.

De data catalog is uiteraard nuttig voor ontwikkelaars om te kijken welke views er zijn en wat ze voorstellen. Maar naarmate datavirtualisatie steeds meer door business gebruikers gebruikt zal worden, zoals self-service BI users en data scientists, zal het belang van een goede data catalog alleen maar toenemen. Ik denk dat Denodo op de goede weg is met deze data catalog. De plannen voor de volgende versies klinken trouwens veelbelovend. Daarover wellicht later meer.

17 AUG – MapD


Het was tijd voor een rit naar San Francisco. Voorheen zaten daar nagenoeg geen softwarebedrijven. Tegenwoordig wel. Facebook heeft daar zelfs een nieuw hoofdkantoor laten bouwen. En wat voor een, het is veruit het hoogste gebouw in San Francisco en kan van kilometers ver al gezien worden. Zo hebben zich er de laatste tijd veel leveranciers gevestigd, waaronder Cloudera, Dropbox en Github, en ook steeds meer startups vestigen zich daar. San Francisco, the City, is “hot” als woonplaats, dus leveranciers vestigen zich daar omdat de engineers daar willen wonen.

Eén van deze startups is MapD, een nieuwe speler op de SQL databaseserver markt. Ze zijn gevestigd in het hart van San Francisco aan Market Street. Dus ik in de file naar San Francisco en met mij honderden Tesla’s.

MapD levert een platform bestaande uit drie componenten: Core (een SQL database engine die intensief gebruik maakt van GPUs), Immerse (een prachtig datavisualisatie product) en Render (verantwoordelijk voor het renderen van visualisatie door gebruik te maken van de kracht van GPUs). De componenten hebben elkaar niet nodig. De drie componenten kunnen afzonderlijk van elkaar aangeschaft worden.

MapD Core is een moderne, open source SQL database engine die er aan de buitenkant als een gewone SQL databaseserver uitziet. Maar schijn bedriegt, het geheim zit aan de binnenkant. MapD Core maakt gebruik van de parallelle processing mogelijkheden van GPUs (ofwel graphics cards). Data wordt het geheugen van de GPUs ingeladen en de SQL-instructies worden gecompileerd naar code die binnen de GPUs draait en parallel wordt uitgevoerd. Het product is gebouwd om zoveel mogelijk gebruik te maken van de parallelle processing mogelijkheden van de GPUs. Om een idee te geven, indien MapD op een server draait met bijvoorbeeld zes nVidia GPUs, dan kan MapD beschikken over meer dan 15.000 cores. De verwerking van SQL-queries wordt dan ook gedistribueerd over al die cores. Het effect hiervan is duidelijk: zeer snelle query performance. Benchmarks tonen inderdaad aan dat MapD factoren sneller is dan SQL-systemen die geen gebruik maken van GPUs. Als een klant hetzelfde niveau van parallellisatie wil bereiken op een Hadoop cluster dan moet er hard met de creditcard gewapperd worden.

De MapD Core database kan in batch geladen worden met gegevens uit een SQL-gebaseerd datawarehouse en ook vanuit Hadoop. Tevens kunnen gegevens live met bijvoorbeeld Kafka de database in gestreamd worden. Hiermee heeft de gebruiker zicht op wat er werkelijk op dat moment gebeurt. MapD is tevens uitgebreid met mogelijkheden om geografische en timeseries vraagstukken te beantwoorden.

De Render en Immerse componenten zijn verantwoordelijk voor de interactieve visualisatie. Wat speciaal is, is dat miljoenen gegevenspunten tegelijkertijd gevisualiseerd kunnen worden. Data kan tot op het laagste detailniveau getoond worden. Net als de Core component, rendert Render de complexe visualisaties in de GPUs. En dat is iets waar GPUs bijzonder snel in zijn, denk maar aan de visualisatiesnelheid van computerspellen.

Ondanks dat MapD voor een redelijk breed scala aan use cases ontwikkeld is, richten ze zich momenteel sterk op een specifieke use case: operational analytics. Bij deze vorm van analytics willen gebruikers live een operationele situatie bestuderen; kijken wat er gebeurt en waarom het gebeurt. Dit kan zijn omdat er een probleem of uitdaging is ontstaan waarop zo snel mogelijk gereageerd moet worden. Het kan ook zijn dat met operational analytics getracht wordt een mogelijk probleem te voorkomen. Operational analytics gaat dus niet over het monitoren van processen met bijvoorbeeld dashboards ontwikkeld met Business Objects, Tableau of Qlik. Het gaat ook niet over data science-achtige vormen van analytics waarbij we proberen nieuwe statistische modellen te ontwikkelen.

Volgens MapD is het ondersteunen van big data ook een essentiële eigenschap van operational analytics. Sommige processen van telefoonmaatschappijen, online gaming bedrijven, financiële instituten, industriële omgevingen, genereren massale hoeveelheden gegevens. Bij operational analytics wordt ervan uitgegaan dat er geen tijd is om gegevens eerst te kopiëren, bijvoorbeeld vanuit Hadoop naar een data warehouse, en vervolgens ingedikt te kopiëren naar een datamart. Tools die operational analytics ondersteunen moeten in staat zijn elke big data bron direct te benaderen en gegevens op het laagste detailniveau te kunnen verwerken.

Een andere eis is instant response. Het heeft geen zin operationele analytics uit te voeren als de analyse minutenlang duurt, terwijl een reactie misschien binnen enkele seconden vereist is.

Samenvattend, operational analytics is instant response, big data en analytics. En dit is waar MapD zich op richt. Indien uw organisatie geïnteresseerd is in operational analytics, doe uzelf dan een plezier en kijk naar enkele van de demo’s op hun website. Ondertussen probeer ik weer heelhuids San Francisco uit te komen en alle Tesla’s en zelfrijdende auto’s te ontwijken.

20 AUG – Elastic


Er zijn zoveel verschillende database-technologieën, je kunt ze niet allemaal kennen. Een product dat ik wel ken maar alleen globaal kan positioneren, is ElasticSearch. De naam verraadt het al, het is een search-based databaseserver. Het was tijd om eens met ze te gaan praten om meer te weten te komen over hun platform.

Op weg dan maar weer naar Mountain View. Op zich wel geestig om als Nederlander ElasticSearch in Silicon Valley te bezoeken, omdat het product een Nederlandse achtergrond heeft: ElasticSearch BV was in 2012 opgericht.

Het bedrijf Elastic, zoals ze sinds 2015 heten, levert enkele open source producten waarvan er twee het gezicht bepalen: ElasticSearch en Kibana. Eerstgenoemde is de databaseserver en Kibana is het BI tool.

Met het onderwerp search heb ik wel ervaring. Lang, lang geleden, toen ik bij Control Data werkte, heb ik een tijd support gegeven op een search engine genaamd Basis. Ik meen dat het een Canadees product was, maar dat kan ik fout hebben. Uiteraard leek de performance van dat product niet op wat producten als ElasticSearch tegenwoordig presteren. Het was een ander tijdperk, maar de principes van search zijn redelijk hetzelfde gebleven.

Gegevens worden in ElasticSearch niet in platte tabellen maar bij elkaar opgeslagen. Is enigszins vergelijkbaar met veel andere NoSQL-producten, zoals MongoDB en Cassandra. Kortweg, data die logisch bij elkaar hoort, wordt samen opgeslagen. Alle gegevenswaarden, gestructureerd en ongestructureerd (wat heb ik toch een hekel aan dat woord), kunnen geïndexeerd worden. Bij zoekopdrachten worden deze indexen benaderd. Lijsten met synoniemen kunnen gedefinieerd worden om de zoekopdracht sterker te maken. Als bijvoorbeeld een gebruiker zoekt op het woord appartement, wordt er op basis van de synoniemenlijst ook gezocht op het woord flat. Tevens ondersteunt ElasticSearch woordverbuigingen. Bijvoorbeeld, bij het zoeken op een meervoudsvorm van een woord, wordt ook de enkelvoudsvorm gevonden. Om eerlijk te zijn, dat ondersteunde Basis ook allemaal al. De kracht van ElasticSearch is de schaalbaarheid. Het is ontwikkeld om een grote, parallelle hardware architectuur volledig te benutten. Het effect is dat zeer grote hoeveelheden gegevens snel verwerkt kunnen worden. Helaas ondersteunt het product geen ontologieën en thesauri.

Na de eerste twintig minuten in het gesprek had ik wel het gevoel dat er aardig wat overeenkomsten met MarkLogic zijn. Toen ik dat meldde, was hun reactie dat zij dat product eigenlijk nooit tegenkomen. Vreemd. Na enig debat kwamen we tot de volgende theorie: ElasticSearch lijkt vooral gebruikt te worden door organisaties die een sterk open source beleid hebben, terwijl dat voor de MarkLogic klanten minder geldt.

We hadden ook een interessante discussie over de vraag of ElasticSearch een proprietary product is. Businessdictionary.com definieert proprietary software als “Computer programs that are exclusive property of their developers or publishers.” Omdat ElasticSearch open source is, is het dus vanuit dat perspectief niet proprietary. Wat natuurlijk wel proprietary is, is ElasticSearch’s API. Dit is geen standaard. Er is maar één product dat deze API ondersteunt. Als een klant ElasticSearch wil vervangen door een ander product, moeten de applicaties fors herschreven worden om de andere API aan te kunnen roepen. Dus misschien is de code dan wel niet proprietary, maar een klant zit toch vast aan dat product. Een migratie is een serieuze onderneming.

In ieder geval heb ik nu een completer en gedetailleerder beeld van ElasticSearch. Zoals zoveel nieuwe database-technologieën is het ontwikkeld voor een bepaalde use case en als dat overeenkomt met de use case van de klant, dan is dit een prima product.

 

21 AUG – MemSQL


MemSQL is waarschijnlijk niet de bekendste SQL databaseserver. Toch bestaat het product al sinds 2013 en is recentelijk al versie 6.5 uitgebracht. MemSQL is geen open source databaseserver, geen product dat gebruik maakt van Spark of Hadoop, en het is geen specialistische analytical SQL databaseserver. Nee, het lijkt een gewone SQL databaseserver. Aan de buitenkant zal u niet veel speciaals zien.

Waarom dan toch op bezoek in San Francisco bij deze leverancier? De reden is simpel, MemSQL lijkt dan misschien van buiten een gewone SQL databaseserver, van binnen is het een technisch hoogstandje. Het heeft een zeer moderne interne architectuur. Er worden bijvoorbeeld twee soorten tabellen ondersteund: rij-georiënteerde in-memory tabellen voor transactieverwerking en kolom-georiënteerde fysiek opgeslagen tabellen voor analytics. Het heeft een volledig gesharde architectuur. Voor concurrency control wordt multi-version concurrency control ondersteund en dus niet locking. Hierdoor ondersteunt het ook timetravelling. Met queries kan gevraagd worden hoe de data er een tijd geleden uitzag. Het product ondersteunt stored procured en stored functions, een JSON datatype, multi-tenancy, en de lijst gaat door. Het product is niet 100% carefree, maar de praktijk wijst uit dat het relatief weinig tijd van een DBA vraagt.

De snelheid is fenomenaal. Bijvoorbeeld, in een benchmark hebben ze recentelijk laten zien dat ze 1000 miljard rijen kunnen scannen in 1 seconde. Niet slecht. Ik denk dat veel organisaties dit niet halen met hun huidige SQL-product en ook niet met hun Hadoop-cluster.

MemSQL is een vertegenwoordiger van een nieuwe generatie general purpose SQL databaseservers. Om de zware big data systemen te kunnen ondersteunen, hebben we eerst een groep specialistische SQL databaseservers gehad. Zo is SnowflakeDB bijvoorbeeld een meer query-georiënteerd product, terwijl VoltDB een meer transactie-georiënteerde databaseserver is. Ze moesten die keuze om te specialiseren maken om te kunnen voldoen aan de zware eisen van big data systemen. MemSQL is ontwikkeld om beide workloads te ondersteunen en deze zelfs te combineren. Net als dat Oracle en SQL Server general-purpose databaseservers waren en zijn, is MemSQL dat ook, maar nu voor big data systemen.

De klanten die momenteel MemSQL gebruiken, zijn organisaties die het gebruiken als vervanging voor Oracle of SQL Server, omdat ze meer vermogen nodig hebben dan die producten kunnen leveren, én organisaties die het gebruiken voor de ontwikkeling van nieuwe IT-systemen waarvan ze bij voorbaat weten dat het met de bestaande producten niet gaat lukken.

De term die voor dit soort databaseservers gebruikt wordt, is sinds kort translytical, een combinatie van de woorden transacties en analytics. De naam MemSQL  komt van in-memory SQL processing en dat doet sommigen vermoeden dat het product voornamelijk geschikt is voor analyse, rapportage en queries. Dat is dus niet het geval.

Het feit dat dit gelukt is bij MemSQL, betekent misschien dat andere leveranciers het ook moeten kunnen. De vraag is hoe de leveranciers van de eerste generatie SQL databaseservers hier op gaan reageren. Kunnen zij hun producten intern volledig aanpassen? Of gaan ze dit oplossen door MemSQL of een vergelijkbaar product te kopen? IBM heeft door de jaren heen al heel wat database producten gekocht, denk aan Ralph Kimball’s RedBrick, Informix en Netezza. Zij zijn hier duidelijk niet vies van. Ook Microsoft heeft ingekocht. Bijvoorbeeld, SQL Server is ooit gekocht van Sybase en ze hebben DATAllegro gekocht, waar ogenschijnlijk niets mee gedaan is. Microsoft Analysis Service hebben ze gekocht van Panorama. Waarschijnlijk allemaal onder het mom van beter goed gekocht dan slecht geïmiteerd.

Maar een product kan nog zo’n indrukwekkende lijst met prachtige features ondersteunen, the proof of the pudding is in the eating, zoals de Engelsen zeggen. Voorlopig laten de benchmarks zien dat MemSQL erg snel is voor beide workloads. En langzaamaan begint de markt het product te ontdekken. Afgelopen jaar is hun omzet met 200% gestegen en dat is geen slecht teken. Hun klantenlijst ziet er ook indrukwekkend uit. Is MemSQL de eerste vertegenwoordiger van de tweede generatie big data-ready, general purpose databaseservers? Stay tuned.

22 AUG – Snowflake computing


Voor het laatste leveranciersbezoek van deze trip moest ik weer naar het zuiden rijden, naar het saaie San Mateo, weer over highway 101. Ondertussen weet ik alle gaten en scheuren in die snelweg blind te omzeilen. Het doel is Snowflake Computing, een bedrijf dat heel veel aandacht krijgt en het erg goed doet. In de SQL-databaseserver markt is het waarschijnlijk een van de meest succesvolle jonge SQL databaseservers.

Ik ken Snowflake al relatief lang. Medio 2014 werd ik gebeld door een marketingdame van een bedrijf in Silicon Valley. De vraag was of ik geïnteresseerd zou zijn om bij hen langs te komen om het nieuwe product dat ze aan het ontwikkelen waren te bekijken. Ze wilde graag weten wat ik ervan vond. Op dat moment waren ze nog in stealth modus. Al had ik nog nooit van ze gehoord en kende ik de dame niet, ik ging toch op haar uitnodiging in. Na een lange vlucht kwam ik daar aan, werd vriendelijk ontvangen door die dame en naar een vergaderzaal geleid. Tot mijn verrassing zaten daar vier heren die ik al heel lang kende, allemaal zeer ervaren architecten van databaseservers. Allemaal met een goede reputatie. Ik wist direct dat dit product veel potentieel zou kunnen hebben. En dat bleek ook al snel toen ze de markt op gingen.

Bij aankomst bleek al snel dat ze gegroeid waren sinds het vorige bezoek. Toen hadden ze slechts één etage nodig om al hun werknemers te huizen. Nu waren er al drie etages nodig en waren er ontwikkelaars in een gebouw aan de overkant van de weg gehuisvest. Het gaat dus goed met ze.

Dit succesvolle product heeft een Nederlands tintje. Marcin Zukowski was een van de heren aan de tafel. Marcin kende ik nog van VectorWise. VectorWise was een spinoff van het CWI (Centrum voor Wiskunde en Informatica) in Leiden. Marcin was van 2003 tot en met  2008 verbonden aan het CWI. Daarna werd hij mede-oprichter en CEO van VectorWise. VectorWise is uiteindelijk aan Ingres (momenteel Actian genoemd) verkocht.

Mocht u SnowflakeDB niet kennen, het is een SQL databaseserver ontworpen en geoptimaliseerd om in de cloud te draaien. Er bestaat dus geen on-premise versie. Het is nagenoeg een carefree databaseserver, of wat sommigen nu noemen een self-driving databaseserver. Er is bijna geen DBA nodig om dit product in de lucht te houden. Het is echt een service. Het product is zeer elastisch. Het is erg gemakkelijk om het product meer resources te laten gebruiken als dat nodig is, maar het is ook net zo simpel om resource weer terug te geven. Bijvoorbeeld, als op een vrijdagmiddag de workload langzaamaan lichter wordt, kan deze met een simpele ingreep ingekrompen worden. Dit bespaart uiteraard geld.

Initieel was het product ontwikkeld voor AWS, maar langzaamaan wordt het steeds vollediger in het ondersteunen van Microsoft Azure.

Als product concurreert het met producten als Google BigQuery en Amazon Redshift. Alle drie zijn het SQL databaseservers met een specifieke use case: datawarehousing.

Dit artikel is helaas kort, omdat het meeste dat tijdens dit bezoek besproken is, allemaal onder NDA was. Ik denk dat ik wel mag melden dat er zeer interessante nieuwe features aankomen. En dit zijn geen kleine liflafjes maar zware uitbreidingen waar vooral grote omgevingen veel baat bij zullen hebben. Als alle features die besproken zijn inderdaad binnen een jaar beschikbaar zijn, dan zouden de concurrenten het weleens zwaar kunnen krijgen.

Klaar. Dit was het laatste bezoek van deze trip. Ik kon weer highway 101 op, terug naar San Francisco. Het was tijd om inkopen te doen. Het was tijd om te shoppen naar vinyl en CD’s, en daarvoor heeft de San Francisco Bay Area nog steeds fenomenale winkels, zoals Amoeba en Rasputin. Kijken of ze nog bijvoorbeeld Grateful Dead albums hebben? En denk nu niet dat die gasten allang geen muziek meer maken. De huidige zanger was in 2016 qua live concerten de bestverkopende zanger ter wereld, beter dan Beyonce en Justin Bieber.

23 AUG – Onze man terug in Laren


Na de CD-inkopen was het tijd om naar huis te gaan. De trip was begonnen met enkele lezingen die ik moest verzorgen op de TDWI conferentie in het Disney Hotel in Anaheim. Trouwens, het is altijd grappig om daar rond te lopen. De ene helft van de mensen is daar vanwege de conferentie en is business casual gekleed en de andere helft draagt een korte broek, Micky Mouse oren en ruikt naar zonnebrand.

Tijdens zo’n conferentie praat je informeel met andere analisten, zoals Wayne Eckerson, Claudia Imhoff en Mark Madsen, en ook met de datawarehouse-architecten van allerlei soorten organisaties. Al die gesprekken vind ik altijd mateloos inspirerend. Het dwingt je over het vakgebied na te denken. Daarom dacht ik als afsluiting van deze live blog om een viertal gedachtenspinsels te delen die voortvloeien uit die gesprekken op de conferentie en met de leveranciers.

Wat is de toekomst van SQL in de wereld van big data?

Dat we big data systemen ontwikkelen is nu wel duidelijk. Maar toen we met big data begonnen waren de SQL-systemen er niet geschikt voor. Daarmee ontstond een kans voor leveranciers om technologie te ontwikkelen die er wel geschikt voor was, denk hierbij aan Hadoop en de NoSQL-producten. Wat we nu zien is dat SQL met een inhaalslag is begonnen. Er is een duidelijke tweede generatie SQL-systemen verschenen die wel big data ready zijn. MemSQL en SnowflakeDB zijn daar duidelijke voorbeelden van. Als deze trend blijft doorzetten zal dat zeker de NoSQL wereld pijn gaan doen. Uiteraard heeft NoSQL iets unieks te bieden, maar SQL zal een steeds grotere bedreiging gaan vormen.

Is het originele data lake concept gericht op data scientists wel wat we nodig hebben?

Was het niet een te haastig bedacht concept om voor data scientists een oplossing te ontwikkelen voor hun niet-aflatende honger naar data? Veel gesprekken met allerlei organisaties geven mij het gevoel dat we daar niet mee op het goede pad zitten. Zoals ik al in andere blogs en whitepapers heb proberen aan te geven, een logical, multi-purpose data lake is qua investering beter te verantwoorden. Ik geloof ook meer in een hybride data lake waar meerdere database technologieën worden ingezet. Voor veel toepassingen is het beter om gestructureerde brongegevens direct in een snel SQL-systeem te pompen en dan voor allerlei vormen, waaronder operational analytics, direct beschikbaar te maken. Voor ongestructureerde data zijn Hadoop en NoSQL misschien betere kandidaten. Maar om een dergelijke hybride oplossing makkelijk toegankelijk te maken voor allerlei soorten gebruikers, is een overkoepelende datavirtualisatielaag aan te bevelen.

Veel database technologieën zijn specialistisch van aard.

Database technologieën zijn goed voor een beperkt aantal use cases. De oudere generatie producten waren allemaal general purpose producten en geschikt voor een breed scala aan use cases. Omdat er steeds zwaardere systemen gebouwd moesten worden, systemen met meer gebruikers, meer gegevens, meer transacties, enzovoorts, lukte dat niet meer met general purpose systemen en werden we gedwongen te gaan werken met specialistische producten. Op zich is daar niets mis mee. De uitdaging voor een organisatie is dan wel om de eigen use cases van tevoren goed te definiëren en de producten in detail te bestuderen om te kijken of die use cases passen bij hun eigen use cases. En daar gaat momenteel veel mee fout. Te vaak worden de verhalen van de leveranciers te makkelijk geloofd en zit een organisatie met een product opgescheept dat niet past. Dit doet me altijd denken aan een scène van Monty Python waar twee huisvrouwen elkaar ontmoeten. De een sleept een viertaktmotor achter zich aan. De ander vraagt waarom ze die gekocht heeft. Het antwoord is omdat die in de aanbieding was. Zoals ik al aangaf in mijn vorige blogs komen de general purpose systemen er aan die wel big data ready zijn. En general purpose technologieën overwinnen meestal specialistische technologieën. Denk maar aan de specialistische ouderwetse telefoon versus de moderne mobiele telefoon.

Nieuwe producten & nieuwe technologieën

Ten vierde, het blijft mij verwonderen dat het nog steeds mogelijk is om in de BI-wereld nieuwe producten te ontwikkelen waar echt geheel nieuwe technologieën in verwerkt zijn. Toch knap dat er nog steeds ontwikkelaars zijn die voldoende out of the box kunnen denken. Ik heb wel het idee dat de meeste van die grensverleggende ideeën niet meer van de grote, bekende leveranciers komen. Het zijn bijna allemaal startups die ons verder brengen. Helaas worden regelmatig de succesvolle producten opgekocht door de grotere bedrijven. Vele van die producten sterven dan een langzame, stille dood. Het is soms alsof zo’n product in een zwart gat verdwijnt.

Hopelijk is het delen van de informatie uit deze inspirerende gesprekken met de leveranciers voor iedereen nuttig geweest. Wellicht is het voor herhaling vatbaar.

 

Een andere blog van Rick lezen? Bekijk ook Self Service Analytics en het grote BI-dilemma


Whitepaper
DOWNLOAD

Wat kunnen we voor jou betekenen?

Bel 035 - 53 94 490 of laat je gegevens achter en ik neem zo snel mogelijk contact met je op.