We leven in een geweldige tijd waarin je snel en eenvoudig verschillende kant-en-klare open source-tools kunt koppelen, ze kunt instellen met je “bewustzijn uitgeschakeld” volgens het advies van Stackoverflow, zonder je te verdiepen in de “meerdere letters”, en te starten ze in commerciële exploitatie. En als je moet updaten/uitbreiden of als iemand per ongeluk een paar machines opnieuw opstart, realiseer je je dat er in werkelijkheid een soort obsessieve nare droom is begonnen, alles plotseling onherkenbaar ingewikkelder is geworden, er is geen weg meer terug, de toekomst is vaag en veiliger, in plaats van programmeren, bijen kweken en kaas maken.
Het is niet voor niets dat meer ervaren collega's, met hun hoofden bezaaid met bugs en daarom al grijs, nadenken over de ongelooflijk snelle implementatie van pakketten met "containers" in "kubussen" op tientallen servers in "modieuze talen" met ingebouwde ondersteuning voor asynchrone niet-blokkerende I/O, glimlach bescheiden. En ze blijven stilletjes "man ps" herlezen, verdiepen zich in de "nginx" -broncode tot hun ogen bloeden, en schrijven, schrijven, schrijven unit-tests. Collega's weten dat het interessantste zal gebeuren als ‘dit alles’ op een dag op oudejaarsavond op het spel wordt gezet. En zij zullen alleen maar geholpen worden door een diepgaand begrip van de aard van Unix, de uit het hoofd geleerde TCP/IP-statustabel en fundamentele sorteer-zoekalgoritmen. Om het systeem weer tot leven te brengen als het klokkenspel slaat.
Oh ja, ik was een beetje afgeleid, maar ik hoop dat ik de staat van verwachting heb kunnen overbrengen.
Vandaag wil ik onze ervaring delen met het inzetten van een handige en goedkope stack voor DataLake, die de meeste analytische taken in het bedrijf oplost voor totaal verschillende structurele divisies.
Enige tijd geleden kwamen we tot het inzicht dat bedrijven steeds meer behoefte hebben aan de vruchten van zowel product- als technische analyses (om nog maar te zwijgen van de kers op de taart in de vorm van machinaal leren) en om trends en risico's te begrijpen - we moeten gegevens verzamelen en analyseren steeds meer meetinstrumenten.
Basis technische analyses in Bitrix24
Enkele jaren geleden, gelijktijdig met de lancering van de Bitrix24-service, hebben we actief tijd en middelen geïnvesteerd in het creëren van een eenvoudig en betrouwbaar analytisch platform dat zou helpen snel problemen in de infrastructuur te zien en de volgende stap te plannen. Natuurlijk was het raadzaam om kant-en-klare hulpmiddelen te nemen die zo eenvoudig en begrijpelijk mogelijk waren. Als gevolg hiervan werd nagios gekozen voor monitoring en munin voor analyse en visualisatie. Nu hebben we duizenden cheques in nagios, honderden kaarten in munin, en onze collega's gebruiken ze elke dag met succes. De metrics zijn duidelijk, de grafieken zijn helder, het systeem werkt al enkele jaren betrouwbaar en er komen regelmatig nieuwe testen en grafieken bij: als we een nieuwe dienst in gebruik nemen, voegen we meerdere testen en grafieken toe. Succes.
Vinger aan de pols - Geavanceerde technische analyses
De wens om “zo snel mogelijk” informatie over problemen te ontvangen, leidde ons tot actieve experimenten met eenvoudige en begrijpelijke hulpmiddelen - pinba en xhprof.
Pinba stuurde ons statistieken in UDP-pakketten over de werkingssnelheid van delen van webpagina's in PHP, en we konden online in de MySQL-opslag (Pinba wordt geleverd met zijn eigen MySQL-engine voor snelle gebeurtenisanalyse) een korte lijst met problemen zien en hierop reageren hen. En met xhprof konden we automatisch grafieken verzamelen van de uitvoering van de langzaamste PHP-pagina's van klanten en analyseren wat daartoe zou kunnen leiden - rustig thee inschenken of iets sterkers.
Enige tijd geleden werd de toolkit aangevuld met een andere vrij eenvoudige en begrijpelijke engine, gebaseerd op het reverse indexing-algoritme, perfect geïmplementeerd in de legendarische Lucene-bibliotheek - Elastic/Kibana. Het eenvoudige idee van het multi-threaded opnemen van documenten in een inverse Lucene-index op basis van gebeurtenissen in de logboeken en een snelle doorzoeking er doorheen met behulp van facetverdeling bleek erg nuttig.
Ondanks de nogal technische verschijning van visualisaties in Kibana met laagdrempelige concepten als ‘emmer’ die ‘naar boven stroomt’ en de opnieuw uitgevonden taal van de nog niet geheel vergeten relationele algebra, begon de tool ons goed te helpen bij de volgende taken:
- Hoeveel PHP-fouten heeft de Bitrix24-client het afgelopen uur op de p1-portal gehad en welke? Begrijp, vergeef en corrigeer snel.
- Hoeveel videogesprekken zijn er de afgelopen 24 uur gevoerd op portalen in Duitsland, met welke kwaliteit, en waren er problemen met het kanaal/netwerk?
- Hoe goed werkt de systeemfunctionaliteit (onze C-extensie voor PHP), samengesteld vanuit de broncode in de laatste service-update en uitgerold naar klanten,? Zijn er segmentfouten?
- Passen klantgegevens in PHP-geheugen? Zijn er fouten bij het overschrijden van het geheugen dat aan processen is toegewezen: "onvoldoende geheugen"? Vind en neutraliseer.
Hier is een concreet voorbeeld. Ondanks grondige tests op meerdere niveaus ontving de klant, met een zeer afwijkende behuizing en beschadigde invoergegevens, een vervelende en onverwachte fout, er klonk een sirene en het proces om deze snel te repareren begon:
Bovendien kunt u met Kibana meldingen voor specifieke gebeurtenissen organiseren, en in korte tijd werd de tool in het bedrijf gebruikt door tientallen medewerkers van verschillende afdelingen - van technische ondersteuning en ontwikkeling tot QA.
De activiteit van elke afdeling binnen het bedrijf is gemakkelijk te volgen en te meten geworden - in plaats van de logboeken op servers handmatig te analyseren, hoeft u alleen maar één keer de logboeken te parseren en deze naar het elastische cluster te sturen, zodat u er bijvoorbeeld in de kibana over kunt nadenken. dashboard het aantal verkochte tweekoppige kittens afgedrukt op een 3D-printer voor de afgelopen maanmaand.
Basis bedrijfsanalyse
Iedereen weet dat bedrijfsanalyses in bedrijven vaak beginnen met extreem actief gebruik van, ja, Excel. Maar het belangrijkste is dat het daar niet bij blijft. Het cloudgebaseerde Google Analytics voegt ook olie op het vuur toe: je begint snel aan de goede dingen te wennen.
In ons zich harmonieus ontwikkelende bedrijf begonnen hier en daar ‘profeten’ te verschijnen van intensiever werken met grotere gegevens. De behoefte aan meer diepgaande en veelzijdige rapporten begon regelmatig te verschijnen, en door de inspanningen van jongens van verschillende afdelingen werd enige tijd geleden een eenvoudige en praktische oplossing georganiseerd: een combinatie van ClickHouse en PowerBI.
Lange tijd heeft deze flexibele oplossing veel geholpen, maar geleidelijk begon het besef te komen dat ClickHouse geen rubber is en niet op die manier bespot kan worden.
Hier is het belangrijk om goed te begrijpen dat ClickHouse, net als Druid, net als Vertica, net als Amazon RedShift (dat is gebaseerd op postgres), analytische motoren zijn die zijn geoptimaliseerd voor redelijk gemakkelijke analyses (sommen, aggregaties, minimum-maximum per kolom en een paar mogelijke joins ), omdat georganiseerd voor efficiënte opslag van kolommen met relationele tabellen, in tegenstelling tot MySQL en andere (rijgeoriënteerde) databases die ons bekend zijn.
In wezen is ClickHouse gewoon een ruimere "database", met niet erg handige punt-voor-punt invoeging (zo is het bedoeld, alles is in orde), maar prettige analyses en een reeks interessante krachtige functies voor het werken met gegevens. Ja, je kunt zelfs een cluster maken - maar je begrijpt dat het slaan van spijkers met een microscoop niet helemaal correct is en we gingen op zoek naar andere oplossingen.
Vraag naar Python en analisten
Ons bedrijf heeft veel ontwikkelaars die al 10-20 jaar bijna elke dag code schrijven in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Er zijn ook veel ervaren systeembeheerders die meer dan één absoluut ongelooflijke ramp hebben meegemaakt die niet past in de wetten van de statistiek (bijvoorbeeld wanneer de meerderheid van de schijven in een raid-10 wordt vernietigd door een sterke blikseminslag). In dergelijke omstandigheden was het lange tijd niet duidelijk wat een ‘python-analist’ was. Python lijkt op PHP, alleen is de naam iets langer en zitten er iets minder sporen van geestverruimende stoffen in de broncode van de tolk. Naarmate er echter steeds meer analytische rapporten werden gemaakt, begonnen ervaren ontwikkelaars steeds meer het belang van nauwe specialisatie in tools als numpy, pandas, matplotlib en seaborn te begrijpen.
De beslissende rol werd hoogstwaarschijnlijk gespeeld door het plotselinge flauwvallen van werknemers door de combinatie van de woorden 'logistische regressie' en de demonstratie van effectieve rapportage over grote gegevens met behulp van, ja, ja, pyspark.
Apache Spark, het functionele paradigma waarop relationele algebra perfect past, en de mogelijkheden ervan maakten zo'n indruk op ontwikkelaars die gewend waren aan MySQL dat de noodzaak om de gelederen met ervaren analisten te versterken duidelijk werd.
Verdere pogingen van Apache Spark/Hadoop om van de grond te komen en wat niet helemaal volgens het script verliep
Al snel werd echter duidelijk dat er systemisch iets niet helemaal klopte met Spark, of dat het simpelweg nodig was om je handen beter te wassen. Als de Hadoop/MapReduce/Lucene-stack is gemaakt door redelijk ervaren programmeurs, wat duidelijk wordt als je goed naar de broncode in Java of de ideeën van Doug Cutting in Lucene kijkt, dan is Spark plotseling geschreven in de exotische taal Scala, die vanuit praktisch oogpunt zeer controversieel en ontwikkelt zich momenteel niet. En de regelmatige daling van het aantal berekeningen op het Spark-cluster als gevolg van onlogisch en niet erg transparant werk met geheugentoewijzing voor minder bewerkingen (veel sleutels komen tegelijk aan) heeft er een halo omheen gecreëerd van iets dat ruimte heeft om te groeien. Bovendien werd de situatie verergerd door een groot aantal vreemde open poorten, tijdelijke bestanden die op de meest onbegrijpelijke plaatsen groeiden en een enorme hoeveelheid jar-afhankelijkheden - waardoor systeembeheerders één gevoel kregen dat al vanaf hun kindertijd bekend was: felle haat (of misschien ze moesten hun handen wassen met zeep).
Als gevolg hiervan hebben we verschillende interne analytische projecten ‘overleefd’ die actief gebruik maken van Apache Spark (waaronder Spark Streaming, Spark SQL) en het Hadoop-ecosysteem (enzovoorts). Ondanks het feit dat we in de loop van de tijd hebben geleerd ‘het’ vrij goed voor te bereiden en te monitoren, en dat ‘het’ vrijwel plotseling stopte met crashen als gevolg van veranderingen in de aard van de gegevens en de onbalans van uniforme RDD-hashing, de wens om iets te nemen dat al klaar is , ergens in de cloud bijgewerkt en beheerd, werd steeds sterker. Het was in deze tijd dat we probeerden de kant-en-klare cloud-assemblage van Amazon Web Services te gebruiken - en vervolgens probeerde ik er problemen mee op te lossen. EMR is Apache Spark, opgesteld door Amazon met aanvullende software uit het ecosysteem, net zoals Cloudera/Hortonworks bouwt.
Er is dringend behoefte aan rubberen bestandsopslag voor analyses
De ervaring van het “koken” van Hadoop/Spark met brandwonden aan verschillende delen van het lichaam was niet voor niets. De noodzaak om één enkele, goedkope en betrouwbare bestandsopslag te creëren die bestand zou zijn tegen hardwarefouten en waarin het mogelijk zou zijn om bestanden in verschillende formaten van verschillende systemen op te slaan en van deze gegevens efficiënte en tijdbesparende voorbeelden voor rapporten te maken, werd steeds groter. duidelijk.
Ik wilde ook dat het updaten van de software van dit platform geen nieuwjaarsnachtmerrie zou worden met het lezen van twintig pagina's tellende Java-traces en het analyseren van kilometerslange gedetailleerde logs van het cluster met behulp van Spark History Server en een vergrootglas met achtergrondverlichting. Ik wilde een eenvoudige en transparante tool hebben die niet regelmatig onder de motorkap hoefde te duiken als het standaard MapReduce-verzoek van de ontwikkelaar stopte met uitvoeren toen de reduce data worker geen geheugen meer had vanwege een niet erg goed gekozen brondatapartitioneringsalgoritme.
Is Amazon S3 een kandidaat voor DataLake?
Ervaring met Hadoop/MapReduce heeft ons geleerd dat we een schaalbaar, betrouwbaar bestandssysteem en schaalbare werkers daarbovenop nodig hebben, die dichter bij de gegevens ‘komen’ om de gegevens niet over het netwerk te sturen. Werknemers moeten gegevens in verschillende formaten kunnen lezen, maar bij voorkeur geen onnodige informatie lezen en gegevens vooraf kunnen opslaan in formaten die geschikt zijn voor werknemers.
Nogmaals het basisidee. Er is geen wens om big data in één enkele clusteranalyse-engine te ‘gieten’, die vroeg of laat zal stikken en je deze op een lelijke manier zult moeten verscheuren. Ik wil bestanden, alleen maar bestanden, in een begrijpelijk formaat opslaan en er effectieve analytische vragen op uitvoeren met behulp van verschillende maar begrijpelijke tools. En er zullen steeds meer bestanden in verschillende formaten zijn. En het is beter om niet de engine, maar de brongegevens te delen. We hebben een uitbreidbaar en universeel DataLake nodig, besloten we...
Wat als je bestanden opslaat in de bekende en bekende schaalbare cloudopslag Amazon S3, zonder dat je zelf je koteletten van Hadoop hoeft klaar te maken?
Het is duidelijk dat de persoonlijke gegevens ‘laag’ zijn, maar hoe zit het met andere gegevens als we deze naar buiten brengen en ‘effectief aansturen’?
Cluster-bigdata-analyse-ecosysteem van Amazon Web Services - in zeer eenvoudige bewoordingen
Afgaande op onze ervaring met AWS wordt Apache Hadoop/MapReduce daar al lange tijd actief gebruikt onder verschillende sauzen, bijvoorbeeld in de DataPipeline-service (ik ben jaloers op mijn collega's, zij hebben geleerd hoe ze het correct moesten bereiden). Hier stellen we back-ups in van verschillende services uit DynamoDB-tabellen:
En ze draaien al een aantal jaren regelmatig op ingebedde Hadoop/MapReduce-clusters als een uurwerk. "Stel het in en vergeet het":
U kunt zich ook effectief bezighouden met datasatanisme door Jupiter-laptops in de cloud op te zetten voor analisten en de AWS SageMaker-service te gebruiken om AI-modellen te trainen en in te zetten in de strijd. Zo ziet het er voor ons uit:
En ja, je kunt een laptop voor jezelf of een analist in de cloud pakken en deze aan een Hadoop/Spark-cluster koppelen, de berekeningen doen en dan alles vastpinnen:
Erg handig voor individuele analytische projecten en voor sommige hebben we de EMR-service met succes gebruikt voor grootschalige berekeningen en analyses. Hoe zit het met een systeemoplossing voor DataLake, zal deze werken? Op dit moment stonden we op de rand van hoop en wanhoop en zetten we de zoektocht voort.
AWS Glue - netjes verpakt Apache Spark op steroïden
Het bleek dat AWS zijn eigen versie van de “Hive/Pig/Spark”-stack heeft. De rol van Hive, d.w.z. De catalogus met bestanden en hun typen in DataLake wordt uitgevoerd door de "Data catalog" -service, die de compatibiliteit ervan met het Apache Hive-formaat niet verbergt. U moet aan deze service informatie toevoegen over waar uw bestanden zich bevinden en in welk formaat ze zijn. De gegevens kunnen niet alleen in s3 staan, maar ook in de database, maar dat is niet het onderwerp van dit bericht. Hier ziet u hoe onze DataLake-gegevensdirectory is georganiseerd:
De bestanden zijn geregistreerd, geweldig. Als de bestanden zijn bijgewerkt, starten we handmatig of volgens een schema crawlers, die de informatie over hen vanuit het meer bijwerken en opslaan. Vervolgens kunnen de gegevens uit het meer worden verwerkt en de resultaten ergens worden geüpload. In het eenvoudigste geval uploaden we ook naar s3. Gegevensverwerking kan overal worden uitgevoerd, maar er wordt aanbevolen dat u de verwerking op een Apache Spark-cluster configureert met behulp van geavanceerde mogelijkheden via de AWS Glue API. In feite kun je de goede oude en bekende Python-code gebruiken met behulp van de pyspark-bibliotheek en de uitvoering ervan configureren op N-knooppunten van een cluster met enige capaciteit met monitoring, zonder in het lef van Hadoop te graven en docker-moker-containers te slepen en afhankelijkheidsconflicten te elimineren .
Nogmaals, een eenvoudig idee. Het is niet nodig om Apache Spark te configureren, u hoeft alleen maar Python-code voor pyspark te schrijven, deze lokaal op uw desktop te testen en deze vervolgens op een groot cluster in de cloud uit te voeren, waarbij u specificeert waar de brongegevens zich bevinden en waar het resultaat moet worden geplaatst. Soms is dit nodig en nuttig, en zo hebben we het opgezet:
Dus als je iets moet berekenen op een Spark-cluster met behulp van gegevens in s3, schrijven we code in python/pyspark, testen het en veel succes in de cloud.
Hoe zit het met de orkestratie? Wat als de taak viel en verdween? Ja, er wordt voorgesteld om een mooie pipeline te maken in de Apache Pig-stijl en we hebben ze zelfs geprobeerd, maar voor nu hebben we besloten om onze diep aangepaste orkestratie in PHP en JavaScript te gebruiken (ik begrijp het, er is cognitieve dissonantie, maar het werkt, want jaar en zonder fouten).
Het formaat van de bestanden die in het meer zijn opgeslagen, is de sleutel tot prestaties
Het is heel erg belangrijk om nog twee belangrijke punten te begrijpen. Om ervoor te zorgen dat zoekopdrachten naar bestandsgegevens in het lake zo snel mogelijk worden uitgevoerd en de prestaties niet afnemen als er nieuwe informatie wordt toegevoegd, moet u:
- Bewaar kolommen met bestanden afzonderlijk (zodat u niet alle regels hoeft te lezen om te begrijpen wat er in de kolommen staat). Hiervoor hebben we het parketformaat met compressie genomen
- Het is erg belangrijk om bestanden op te delen in mappen zoals: taal, jaar, maand, dag, week. Engines die dit soort sharding begrijpen, kijken alleen naar de noodzakelijke mappen, zonder alle gegevens achter elkaar te doorzoeken.
Op deze manier deelt u in wezen de brongegevens in de meest efficiënte vorm in voor de analytische motoren die erbovenop hangen, die zelfs in gesharde mappen selectief alleen de noodzakelijke kolommen uit bestanden kunnen invoeren en lezen. U hoeft de gegevens nergens te "vullen" (de opslag zal gewoon barsten) - plaats ze gewoon onmiddellijk en verstandig in het juiste formaat in het bestandssysteem. Het mag hier uiteraard duidelijk zijn dat het opslaan van een enorm csv-bestand in DataLake, dat eerst regel voor regel door het cluster moet worden ingelezen om de kolommen te kunnen extraheren, niet erg aan te raden is. Denk nog eens na over de bovenstaande twee punten als het nog niet duidelijk is waarom dit allemaal gebeurt.
AWS Athena - de jack-in-the-box
En toen, tijdens het creëren van een meer, kwamen we op de een of andere manier per ongeluk Amazon Athena tegen. Opeens bleek dat door onze enorme logbestanden zorgvuldig in mapscherven in het juiste (parket)kolomformaat te rangschikken, je daar heel snel uiterst informatieve selecties uit kunt maken en rapporten kunt bouwen ZONDER, zonder Apache Spark/Glue-cluster.
De Athena-motor, aangedreven door data in s3, is gebaseerd op de legendarische - een vertegenwoordiger van de MPP-familie (massive parallel processing) van benaderingen van gegevensverwerking, waarbij gegevens worden meegenomen waar ze zich bevinden, van s3 en Hadoop tot Cassandra en gewone tekstbestanden. Je hoeft Athena alleen maar te vragen een SQL-query uit te voeren, en dan werkt alles “snel en automatisch.” Het is belangrijk op te merken dat Athena “slim” is, alleen naar de noodzakelijke gedeelde mappen gaat en alleen de kolommen leest die nodig zijn in het verzoek.
Ook de prijzen voor verzoeken aan Athena zijn interessant. Wij betalen voor . Die. niet voor het aantal machines in het cluster per minuut, maar... voor de gegevens die daadwerkelijk worden gescand op 100-500 machines, alleen de gegevens die nodig zijn om het verzoek te voltooien.
En door alleen de benodigde kolommen op te vragen uit correct gesharde mappen, bleek dat de Athena-service ons tientallen dollars per maand kost. Nou, geweldig, bijna gratis, vergeleken met analyses op clusters!
Trouwens, hier is hoe we onze gegevens delen in s3:
Als gevolg hiervan begonnen in korte tijd heel verschillende afdelingen in het bedrijf, van informatiebeveiliging tot analyse, actief verzoeken te doen aan Athena en snel, binnen enkele seconden, nuttige antwoorden te ontvangen van ‘big’ data over vrij lange perioden: maanden, een half jaar, enz. P.
Maar we gingen verder en begonnen naar de cloud te gaan voor antwoorden : een analist schrijft een SQL-query in een bekende console, die op 100-500 machines “voor centen” gegevens naar s3 verzendt en meestal binnen een paar seconden een antwoord retourneert. Comfortabel. En snel. Ik kan het nog steeds niet geloven.
Als gevolg hiervan, nadat we besloten hadden om gegevens op te slaan in s3, in een efficiënt kolomformaat en met een redelijke verdeling van gegevens in mappen... ontvingen we DataLake en een snelle en goedkope analytische engine - gratis. En hij werd erg populair in het bedrijf, omdat... begrijpt SQL en werkt ordes van grootte sneller dan door het starten/stoppen/instellen van clusters. “En als het resultaat hetzelfde is, waarom zou je dan meer betalen?”
Een verzoek aan Athene ziet er ongeveer zo uit. Indien gewenst kun je natuurlijk voldoende vormen , maar we zullen ons beperken tot eenvoudige groepering. Laten we eens kijken welke responscodes de client een paar weken geleden had in de webserverlogboeken en controleren of er geen fouten zijn:
Bevindingen
Na een niet te zeggen lang, maar pijnlijk pad te hebben doorlopen, waarbij we voortdurend de risico's, het niveau van complexiteit en de kosten van ondersteuning adequaat hebben beoordeeld, hebben we een oplossing voor DataLake en analytics gevonden die ons altijd tevreden stelt, zowel qua snelheid als qua eigendomskosten.
Het bleek dat het bouwen van een effectief, snel en goedkoop te bedienen DataLake voor de behoeften van compleet verschillende afdelingen van het bedrijf volledig binnen de mogelijkheden ligt van zelfs ervaren ontwikkelaars die nog nooit als architect hebben gewerkt en niet weten hoe ze vierkanten op vierkanten moeten tekenen met pijlen en ken 50 termen uit het Hadoop-ecosysteem.
Aan het begin van de reis bonkte mijn hoofd van de vele wilde dierentuinen van open en gesloten software en het begrip van de verantwoordelijkheidslast voor nakomelingen. Begin gewoon met het bouwen van uw DataLake met eenvoudige tools: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., waarbij u feedback verzamelt en de fysica van de processen die plaatsvinden diepgaand begrijpt. Alles complex en duister - geef het aan vijanden en concurrenten.
Als u niet naar de cloud wilt gaan en open-sourceprojecten graag wilt ondersteunen, updaten en patchen, kunt u lokaal een schema bouwen dat vergelijkbaar is met het onze, op goedkope kantoormachines met Hadoop en Presto erbovenop. Het belangrijkste is om niet te stoppen en vooruit te gaan, te tellen, naar eenvoudige en duidelijke oplossingen te zoeken, en alles zal zeker lukken! Veel succes allemaal en tot ziens!
Bron: www.habr.com