{"id":92508,"date":"2020-08-28T07:42:10","date_gmt":"2020-08-28T05:42:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak"},"modified":"2020-08-28T07:42:10","modified_gmt":"2020-08-28T05:42:10","slug":"kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak","title":{"rendered":"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vi lever i en fantastisk tid, hvor man hurtigt og nemt kan koble flere f\u00e6rdige, \u00e5bne v\u00e6rkt\u00f8jer sammen, konfigurere dem med 'slukket sind' baseret p\u00e5 r\u00e5d fra stackoverflow, uden at g\u00e5 ind i 'mange bogstaver', og s\u00e6tte dem i kommerciel drift. Og n\u00e5r der er behov for at opdatere\/udvide, eller nogen tilf\u00e6ldigt genstarter et par maskiner \u2014 at indse, at der er begyndt en eller anden p\u00e5tr\u00e6ngende sk\u00f8r dr\u00f8m i virkeligheden, alt er pludselig blevet ugenkendeligt kompliceret, der er ingen vej tilbage, fremtiden er uklar og sikrere, i stedet for at programmere, at holde bier og lave ost.<\/p>\n<p>Ikke for ingenting, har mere erfarne kolleger med frodighed af bugs og derfor allerede gr\u00e5 h\u00e5r, n\u00e5r de betragter det usandsynligt hurtige deployment af stakke af 'containere' i 'terninger' p\u00e5 dusinvis af servere med 'moderne sprog' med indbygget st\u00f8tte til asynkron ikke-blokerende input-output \u2014 beskedent smiler. Og stille forts\u00e6tter de med at l\u00e6se 'man ps', fordyber sig indtil \u00f8jnene bl\u00f8der i kildekoden til 'nginx' og skriver-skriver-skriver enhedstest. Kollegerne ved, at det mest interessante vil komme senere, n\u00e5r 'alt dette' en nat bliver til noget uforudset ved nyt\u00e5r. Og kun en dyb forst\u00e5else af unix-naturen, den indl\u00e6rte TCP\/IP-tilstandstabel og grundl\u00e6ggende sorterings- og s\u00f8gealgoritmer kan hj\u00e6lpe dem med at genoplive systemet ved klokken tolv.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n\u00c5h, ja, lidt afveksling, men jeg h\u00e5ber, at jeg fik overbragt fornemmelsen af forventning.<br \/>\nI dag vil jeg dele vores erfaring med at implementere et praktisk og billigt stack til DataLake, der l\u00f8ser de fleste analytiske opgaver i virksomheden for helt forskellige afdelinger.<\/p>\n<p>For nogen tid siden inds\u00e5 vi, at virksomhederne i stigende grad har brug for resultatet af b\u00e5de produkt- og teknisk analyse (for ikke at n\u00e6vne kirseb\u00e6r p\u00e5 kagen i form af maskinl\u00e6ring), og for at forst\u00e5 trends og risici \u2014 er det n\u00f8dvendigt at indsamle og analysere flere og flere metrikker.<\/p>\n<h3>Grundl\u00e6ggende teknisk analyse i 'Bitrix24'<\/h3>\n<p>\nFor several years now, alongside the launch of the \"Bitrix24\" service, we have actively invested time and resources in creating a simple and reliable analytical platform that helps quickly identify problems in the infrastructure and plan the next steps. Naturally, it was preferable to use ready-made tools that were as simple and understandable as possible. As a result, we chose Nagios for monitoring and Munin for analytics and visualization. Now we have thousands of checks in Nagios, hundreds of graphs in Munin, and our colleagues use them daily and successfully. The metrics are clear, the graphs are understandable, the system has been running reliably for several years, and new tests and graphs are regularly added: when we introduce a new service, we add several tests and graphs. Safe travels.<\/p>\n<h3>Keeping a Finger on the Pulse - Advanced Technical Analytics<\/h3>\n<p>\nThe desire to receive information about issues \"as quickly as possible\" led us to actively experiment with simple and understandable tools\u2014Pinba and XHProf.<\/p>\n<p>Pinba sent us statistics about the speed of PHP web page components in UDP packets, allowing us to view a short list of issues in the MySQL storage (Pinba comes with its own MySQL engine for fast event analytics) in real-time and respond accordingly. Meanwhile, XHProf automatically allowed us to gather execution graphs of the slowest PHP pages from clients and analyze what might have caused this\u2014calmly, while enjoying tea or something stronger.<\/p>\n<p>Some time ago, our toolkit was supplemented with another quite simple and understandable engine based on the inverse indexing algorithm, excellently implemented in the legendary Lucene library\u2014Elastic\/Kibana. The simple idea of multi-threaded document recording into Lucene's inverted index based on log events and quick searches using faceted search turned out to be genuinely useful.<\/p>\n<p>Despite the rather technical appearance of visualizations in Kibana, with low-level concepts like \"bucket\" and a rediscovered language of the long-forgotten relational algebra\u2014this tool has helped us well in the following tasks:<\/p>\n<ul>\n<li>How many PHP errors did the Bitrix24 client have on portal p1 in the last hour, and what were they? To understand, forgive, and quickly fix.<\/li>\n<li>Hvor mange videoopkald blev der foretaget p\u00e5 portalerne i Tyskland i de sidste 24 timer, hvilken kvalitet havde de, og var der nogen problemer med kanalen\/netv\u00e6rket?<\/li>\n<li>Hvor godt fungerer systemfunktionaliteten (vores C-udvidelse til PHP), som blev kompileret fra kildekoden i den seneste opdatering af tjenesten og rullet ud til kunderne? Er der ikke nogen segfaults?<\/li>\n<li>Bliver kundedata gemt i PHP's hukommelse? Er der ikke nogen fejl med overskridelse af den allokerede hukommelse: \u00about of memory\u00bb? Find og neutraliser.<\/li>\n<\/ul>\n<p>\nHer er et konkret eksempel. P\u00e5 trods af grundig og flerlagstestning, opstod der en irriterende og uventet fejl hos kunden under et meget us\u00e6dvanligt scenarie med beskadigede inddata, alarmen gik, og processen med hurtig rettelse blev iv\u00e6rksat:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/8a802dba41b5d1a85c0dc41dfbf8b84e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerudover giver Kibana mulighed for at organisere advarsler for bestemte h\u00e6ndelser, og p\u00e5 kort tid blev v\u00e6rkt\u00f8jet taget i brug af dusinvis af medarbejdere fra forskellige afdelinger - fra support og udvikling til QA.<\/p>\n<p>Aktiviteten i enhver afdeling inden for virksomheden er blevet let at overv\u00e5ge og m\u00e5le - i stedet for manuel analyse af serverlogfiler, er det tilstr\u00e6kkeligt at ops\u00e6tte logparsing og deres sendelse til Elastic-klyngen \u00e9n gang for at nyde, for eksempel at betragte p\u00e5 Kibana-dashboardet, antallet af solgte tohovede katte, der blev printet p\u00e5 3D-printer i den sidste m\u00e5neds cyklus.<\/p>\n<h3>Grundl\u00e6ggende forretningsanalyse<\/h3>\n<p>\nAlle ved, at forretningsanalysen i virksomheder ofte starter med ekstremt aktiv brug af, ja, ja, Excel. Men vigtigst af alt, at den ikke slutter der. Det skader ikke at h\u00e6lde lidt olie p\u00e5 b\u00e5let med cloud-baseret Google Analytics - man v\u00e6nner sig hurtigt til det gode.<\/p>\n<p>I vores harmonisk udviklende virksomhed begyndte der at opst\u00e5 'profeter' for mere intensivt arbejde med st\u00f8rre data. Behovet for dybere og mere mangfoldige rapporter dukkede regelm\u00e6ssigt op, og takket v\u00e6re indsatsen fra folk fra forskellige afdelinger blev der for nogen tid siden organiseret en simpel og praktisk l\u00f8sning - en kobling mellem ClickHouse og PowerBI.<\/p>\n<p>I lang tid hjalp denne fleksible l\u00f8sning os meget, men gradvist kom der en forst\u00e5else af, at ClickHouse ikke er elastisk, og man kan ikke misbruge det.<\/p>\n<p>Det er vigtigt at forst\u00e5 godt, at ClickHouse, ligesom Druid, Vertica og Amazon RedShift (som er baseret p\u00e5 Postgres), er analytiske motorer, der er optimeret til ret praktisk analyse (summationer, aggregationer, minimum-maximum p\u00e5 kolonner og lidt join), da de er organiseret til effektiv opbevaring af kolonnerne i relationelle tabeller, i mods\u00e6tning til det velkendte MySQL og andre (row-oriented) databaser.<\/p>\n<p>I bund og grund er ClickHouse blot en mere rummelig \"database\", med ikke s\u00e5 praktisk punktvis inds\u00e6ttelse (det er s\u00e5dan, det er designet, alt er i orden), men med en behagelig analyse og en r\u00e6kke interessante kraftfulde funktioner til arbejde med data. Ja, man kan endda oprette et cluster \u2014 men du forst\u00e5r, at det ikke er helt korrekt at sl\u00e5 s\u00f8m i med et mikroskop, s\u00e5 vi begyndte at lede efter andre l\u00f8sninger.<\/p>\n<h3>Eftersp\u00f8rgslen efter Python og analytikere<\/h3>\n<p>\nI vores virksomhed er der mange udviklere, der skriver kode n\u00e6sten hver dag i 10-20 \u00e5r i PHP, JavaScript, C#, C\/C++, Java, Go, Rust, Python, Bash. Der er ogs\u00e5 mange erfarne systemadministratorer, der har overlevet mere end en fuldst\u00e6ndig us\u00e6dvanlig katastrofe, der ikke kan forklares med statistik (for eksempel n\u00e5r de fleste diske i raid-10 bliver \u00f8delagt ved et kraftigt lynnedslag). Under s\u00e5danne forhold var det l\u00e6nge uklart, hvad en \"analytiker i Python\" egentlig var. Python er ligesom PHP, blot med et lidt l\u00e6ngere navn og f\u00e6rre spor af stoffer, der \u00e6ndrer bevidstheden, i kildekoden til fortolkerens. Men efterh\u00e5nden, som der blev skabt flere og flere analytiske rapporter, blev erfarne udviklere mere og mere opm\u00e6rksomme p\u00e5 vigtigheden af sn\u00e6vre specialiseringer i v\u00e6rkt\u00f8jer som numpy, pandas, matplotlib, seaborn.<br \/>\nDen afg\u00f8rende rolle blev sandsynligvis spillet af pludselige besvimelser blandt medarbejderne ved kombinationen af ordene \"logistisk regression\" og demonstrationen af effektiv rapportbygning p\u00e5 store datam\u00e6ngder ved hj\u00e6lp af, ja, pyspark.<\/p>\n<p>Apache Spark, dets funktionelle paradigme, som passer perfekt til relationel algebra og dets muligheder, gjorde et s\u00e5 stort indtryk p\u00e5 udviklerne, der var vant til MySQL, at behovet for at forst\u00e6rke de erfarne analytikere blev klart som dagen.<\/p>\n<h3>Yderligere fors\u00f8g p\u00e5, at Apache Spark\/Hadoop kunne f\u00e5 succes og hvad der ikke gik helt efter planen<\/h3>\n<p>\nMen blev det hurtigt klart, at der \u00e5benbart var noget systematisk galt med Spark, eller at man blot skulle v\u00e6re bedre til at vaske h\u00e6nder. Hvis Hadoop\/MapReduce\/Lucene-stakken blev lavet af tilstr\u00e6kkeligt erfarne programm\u00f8rer, noget der er indlysende, hvis man ser n\u00e6rmere p\u00e5 Java-kildeteksterne eller Doug Cutting\u2019s id\u00e9er i Lucene, s\u00e5 er Spark pludselig skrevet i et meget omstridt sprog, Scala, som set fra en praktisk synsvinkel ikke rigtig er i udvikling. Regelm\u00e6ssige nedbrud af beregninger p\u00e5 Spark-klyngen p\u00e5 grund af den illogiske og ikke s\u00e6rlig gennemsigtige h\u00e5ndtering af hukommelse under reduce-operationer (mange n\u00f8gler ankommer pludselig) har givet det et ry som noget, der har potentiale til at vokse. Ydermere forv\u00e6rrede et stort antal m\u00e6rkelige \u00e5bne porte, midlertidige filer, der voksede p\u00e5 de mest uforst\u00e5elige steder, og adskillige jar-afh\u00e6ngigheder situationen \u2013 hvilket fremkaldte et velkendt og barndomsagtigt f\u00f8lelser blandt systemadministratorer: en frygtelig had (eller m\u00e5ske skulle man have v\u00e6ret bedre til at vaske h\u00e6nder med s\u00e6be).<\/p>\n<p>Vi har derfor \"overlevet\" flere interne analytiske projekter, der aktivt benytter Apache Spark (herunder Spark Streaming, Spark SQL) og Hadoop-\u00f8kosystemet (og meget andet). Selvom vi med tiden har l\u00e6rt at \"tilberede\" dette temmelig godt og overv\u00e5ge det, og \"det\" praktisk talt er holdt op med at falde pludseligt p\u00e5 grund af \u00e6ndringer i datakarakteren og ubalanceret j\u00e6vn hashing af RDD, voksede \u00f8nsket om at anvende et f\u00e6rdigt, opdateret og administreret system et eller andet sted i skyen bare st\u00e6rkere og st\u00e6rkere. Det var netop p\u00e5 dette tidspunkt, at vi fors\u00f8gte at bruge den f\u00e6rdige cloud-l\u00f8sning fra Amazon Web Services \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/ru\/emr\/\">EMR<\/a><\/noindex> og fors\u00f8gte derefter at l\u00f8se opgaverne p\u00e5 den. EMR er Amazons version af Apache Spark med ekstra software fra \u00f8kosystemet, omtrent som Cloudera\/Hortonworks-opstillingerne.<\/p>\n<h3>Et \"gummih\u00e5ndtering\" filopbevaringssystem til analytiske behov \u2013 en akut n\u00f8dvendighed<\/h3>\n<p>\nErfaringen med at \"tilberede\" Hadoop\/Spark med forskellige forbr\u00e6ndinger er ikke g\u00e5et tabt. Behovet for at skabe et enkelt, billigt og p\u00e5lideligt filopbevaringssystem er blevet mere og mere klart, et system der ville v\u00e6re modstandsdygtigt over for hardwarefejl, og hvor man kunne opbevare filer i forskellige formater fra forskellige systemer og udf\u00f8re effektive dataudtr\u00e6k til rapporter inden for rimelig tid.<\/p>\n<p>Det ville ogs\u00e5 v\u00e6re rart, hvis opdateringen af softwaren p\u00e5 denne platform ikke blev til et nyt\u00e5rsmareridt med at l\u00e6se 20-siders Java-tracebacks og analysere kilometerlange detaljerede logfiler fra klyngens Spark History Server ved hj\u00e6lp af en lup. Man \u00f8nsker et simpelt og gennemskueligt v\u00e6rkt\u00f8j, der ikke kr\u00e6ver, at man regelm\u00e6ssigt skal n\u00f8rde under motorhjelmen, hvis en standard MapReduce-foresp\u00f8rgsel oph\u00f8rer med at fungere, n\u00e5r reduktionsdataene fra en worker falder ud af hukommelsen p\u00e5 grund af et ikke s\u00e6rligt godt valgt partitioneringsalgoritme til de oprindelige data.<\/p>\n<h3>Er Amazon S3 en kandidat til DataLake?<\/h3>\n<p>\nErfaringen med Hadoop\/MapReduce har l\u00e6rt mig, at der er behov for en skalerbar og p\u00e5lidelig filsystem og skalerbare workere, der \"kommer\" t\u00e6ttere p\u00e5 dataene, s\u00e5 man ikke skal overf\u00f8re dataene gennem netv\u00e6rket. Workerne skal v\u00e6re i stand til at l\u00e6se data i forskellige formater, men helst ikke l\u00e6se un\u00f8dvendige oplysninger, og der b\u00f8r v\u00e6re en mulighed for at gemme data i formater, der er bekvemme for workerne.<\/p>\n<p><b>En gang til \u2013 den grundl\u00e6ggende id\u00e9.<\/b> Der er ikke lyst til at \"l\u00e6sse\" store data ind i en enkelt klyngeanalytisk motor, som alligevel f\u00f8r eller siden vil kv\u00e6les, og man bliver n\u00f8dt til at shard'ere det p\u00e5 en grim m\u00e5de. Man \u00f8nsker at gemme filer, bare filer, i et forst\u00e5eligt format og udf\u00f8re effektive analytiske foresp\u00f8rgsler med forskellige, men forst\u00e5elige v\u00e6rkt\u00f8jer. Og antal filer i forskellige formater vil stige. Og det er bedre at shard'e de oprindelige data end motoren. Vi har besluttet, at vi har brug for en udvidelsesvenlig og universel DataLake...<\/p>\n<p>Hvad hvis man gemmer filer i det velkendte og for mange kendte skalerbare sky-lager Amazon S3, uden at skulle forberede boller fra Hadoop selv?<\/p>\n<p>Klart, persondata \"m\u00e5 ikke\", men hvad med andre data, hvis man kan flytte dem derhen og \"effektivt k\u00f8re\" dem?<\/p>\n<h3>Den kluster-baserede big data-analytiske \u00f8kosystem Amazon Web Services \u2013 meget enkelt sagt<\/h3>\n<p>\nIf\u00f8lge vores erfaring med AWS har Apache Hadoop\/MapReduce l\u00e6nge v\u00e6ret aktivt brugt under forskellige former, for eksempel i service DataPipeline (jeg misundrer kollegerne, de har l\u00e6rt at forberede det korrekt). Her har vi indstillet backups fra forskellige tjenester fra tabellerne DynamoDB:<br \/>\n<img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/058dc54ed032a7bf3e9e129646202440.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg de udf\u00f8res regelm\u00e6ssigt p\u00e5 de indbyggede klynger af Hadoop\/MapReduce som ure i flere \u00e5r. \"Indstillet og glemt\":<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/a6569da8cafdb96c63250bb32bf51704.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDesuden kan man effektivt arbejde med datascience ved at ops\u00e6tte Jupiter-notebooks i skyen for analytikere og bruge dem til tr\u00e6ning og implementering af AI-modeller med AWS SageMaker. S\u00e5dan ser det ud hos os:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/c825d979c9278a8edf8e1e747ef6def8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg ja, man kan ops\u00e6tte en notebook i skyen til sig selv eller analytikeren og tilslutte den til et Hadoop\/Spark-kluster, beregne og s\u00e5 'lave rent':<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/73cea18c54d2a9ce8d0441463991808b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet er virkelig praktisk til enkelte analytiske projekter, og til nogle af dem har vi med succes brugt EMR-tjenesten til storstilede beregninger og analyser. Men hvad med et systeml\u00f8sning til DataLake, vil det v\u00e6re muligt? P\u00e5 dette tidspunkt var vi t\u00e6t p\u00e5 h\u00e5b og fortvivlelse og fortsatte s\u00f8gningen.<\/p>\n<h3>AWS Glue er en p\u00e6nt pakket version af Apache Spark 'p\u00e5 steroider'.<\/h3>\n<p>\nDet viste sig, at AWS har sin egen version af stakken 'Hive\/Pig\/Spark'. Hive's rolle, alts\u00e5 kataloget for filer og deres typer i DataLake, varetages af 'Data catalog'-tjenesten, som ikke skjuler sin kompatibilitet med Apache Hive-formatet. Her skal man tilf\u00f8je information om, hvor dine filer ligger, og i hvilket format de er. Data kan ikke kun v\u00e6re i s3, men ogs\u00e5 i databaser, men det er ikke emnet for dette indl\u00e6g. S\u00e5dan er DataLake-datakataloget organiseret hos os:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/adb45d09698fdacbf41c86bbadde8bb2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFilerne er registreret, perfekt. Hvis filer er blevet opdateret \u2014 starter vi enten manuel eller efter tidsplan crawlers, der opdaterer informationen fra s\u00f8en og gemmer den. Derefter kan dataene fra s\u00f8en behandles, og resultaterne kan eksporteres et sted hen. I det simpleste tilf\u00e6lde eksporterer vi ogs\u00e5 til s3. Data kan behandles hvor som helst, men det anbefales at konfigurere behandlingsprocessen p\u00e5 et Apache Spark-kluster med udvidede funktioner via AWS Glue API. Man kan i princippet tage den gamle gode og velkendte Python-kode med pyspark-biblioteket og indstille dens udf\u00f8relse p\u00e5 N noder i klustret af en bestemt kapacitet med overv\u00e5gning, uden at skulle rode i Hadoop's indre og sl\u00e6be docker-containerne rundt og l\u00f8se afh\u00e6ngighedskonflikter.<\/p>\n<p><b>Endnu en gang \u2014 en simpel id\u00e9.<\/b> Man skal ikke konfigurere Apache Spark, man skal blot skrive kode i Python til pyspark, teste den lokalt p\u00e5 skrivebordet og derefter k\u00f8re den p\u00e5 et stort kluster i skyen, ved at angive hvor de oprindelige data ligger, og hvor resultatet skal placeres. Nogle gange er det n\u00f8dvendigt og nyttigt, og s\u00e5dan er det konfigureret hos os:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/dc03181573bb3f5cfcc3a8760bc7e07b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerfor, hvis man skal beregne noget p\u00e5 Spark-klusteret med dataene i s3 \u2014 skriver vi Python\/pyspark-koden, tester den og sender den afsted til skyen.<\/p>\n<p>Hvad med orkestreringen? Hvad hvis opgaven falder ud og forsvinder? Ja, man foresl\u00e5r at lave en flot pipeline i stil med Apache Pig, og vi har endda pr\u00f8vet dem, men vi har besluttet at bruge vores dybt tilpassede orkestrering lavet i PHP og JavaScript (jeg forst\u00e5r, der kan opst\u00e5 kognitiv dissonans, men det virker, i \u00e5revis og uden fejl).<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/e00ed2047c5c6492e36fccc82e7278a3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Formatet for de gemte filer i s\u00f8en er n\u00f8glen til ydeevnen.<\/h3>\n<p>\nDet er meget, meget vigtigt at forst\u00e5 endnu to n\u00f8glepunkter. For at foresp\u00f8rgsler om datafiler i s\u00f8en kan udf\u00f8res s\u00e5 hurtigt som muligt, og ydeevnen ikke forringes ved tilf\u00f8jelse af nye oplysninger, skal man:<\/p>\n<ul>\n<li>Opbevare kolonnerne i filer separat (s\u00e5 man ikke skal l\u00e6se alle r\u00e6kker for at forst\u00e5, hvad der er i kolonnerne). Til dette har vi valgt parquet-formatet med komprimering.<\/li>\n<li>Det er meget vigtigt at shard'e filer i mapper i stil med: sprog, \u00e5r, m\u00e5ned, dag, uge. Motorer, der forst\u00e5r denne type sharding, vil kun kigge i de n\u00f8dvendige mapper i stedet for at skulle h\u00e5ndtere alle dataene p\u00e5 \u00e9n gang.<\/li>\n<\/ul>\n<p>\nI princippet l\u00e6gger man p\u00e5 denne m\u00e5de de oprindelige data ud p\u00e5 den mest effektive m\u00e5de til de analytiske motorer ovenover, som ogs\u00e5 kan tilg\u00e5 sharded mapper og kun l\u00e6se de n\u00f8dvendige kolonner fra filerne. Der er ingen grund til at \"indlejre\" data andre steder (for opbevaringen vil simpelthen briste) \u2014 l\u00e6g dem bare straks fornuftigt i filsystemet i det rigtige format. Selvf\u00f8lgelig b\u00f8r det v\u00e6re klart, at det ikke er s\u00e6rlig fornuftigt at gemme en k\u00e6mpe csv-fil i DataLake, som f\u00f8rst skal l\u00e6ses linje for linje af klyngen for at udtr\u00e6kke kolonnerne \u2014 overvej de to ovenst\u00e5ende punkter endnu en gang, hvis du stadig ikke forst\u00e5r, hvorfor alt dette er n\u00f8dvendigt.<\/p>\n<h3>AWS Athena \u2014 \"dj\u00e6velen\" fra tobaksd\u00e5sen.<\/h3>\n<p>\nOg her, mens vi opretter en s\u00f8, st\u00f8dte vi p\u00e5 Amazon Athena. Det viste sig pludselig, at ved omhyggeligt at organisere vores enorme logfiler i sharder-mapper i det rigtige (parquet) kolonneformat, kan man meget hurtigt lave yderst informative udtr\u00e6k og generere rapporter UDEN, uden en Apache Spark\/Glue-klynge.<\/p>\n<p>Motoren Athena, der arbejder med data i s3, er baseret p\u00e5 den legendariske <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/ru\/big-data\/what-is-presto\/\">Presto<\/a><\/noindex> \u2014 en repr\u00e6sentant for MPP (massive parallel processing) tilgangene til databehandling, der henter data, hvor de ligger, fra S3 og Hadoop til Cassandra og almindelige tekstfiler. Man skal bare bede Athena om at udf\u00f8re en SQL-foresp\u00f8rgsel, s\u00e5 \u201efungerer det hurtigt og af sig selv\u201c. Det er vigtigt at bem\u00e6rke, at Athena er \u201eintelligent\u201c, den g\u00e5r kun ind i de n\u00f8dvendige sharded mapper og l\u00e6ser kun de relevante kolonner i foresp\u00f8rgslen.<\/p>\n<p>Foresp\u00f8rgsler til Athena priss\u00e6ttes ogs\u00e5 interessant. Vi betaler for <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/ru\/athena\/pricing\/\">m\u00e6ngden af scannede data<\/a><\/noindex>. Det vil sige, det er ikke prisen pr. maskine i klyngen pr. minut, men\u2026 for de reelt scannede data, der er n\u00f8dvendige for at udf\u00f8re foresp\u00f8rgslen p\u00e5 100-500 maskiner.<\/p>\n<p>Og ved kun at anmode om de n\u00f8dvendige kolonner fra de korrekt sharded mapper, viste det sig, at Athena-tjenesten koster os kun et par hundrede dollars om m\u00e5neden. Det er jo fantastisk, n\u00e6sten gratis sammenlignet med analyse p\u00e5 klynger!<\/p>\n<p>Her er, hvordan vi sharder vores data i S3:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/00bd9ae48c1cd13f3c4f7d32692c9209.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSom et resultat af dette begyndte forskellige afdelinger i virksomheden, fra informationssikkerhed til analyse, hurtigt at lave foresp\u00f8rgsler til Athena og modtage nyttige svar fra \u201estore\u201c data for ret lange perioder: m\u00e5neder, halve \u00e5r osv.<\/p>\n<p>Men vi gik videre og begyndte at hente svar i skyen <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.aws.amazon.com\/athena\/latest\/ug\/connect-with-odbc.html\">gennem ODBC-driveren<\/a><\/noindex>: analytikeren skriver SQL-foresp\u00f8rgslen i det velkendte konsol, som p\u00e5 100-500 maskiner \u201efor en slik\u201c gennems\u00f8ger data i S3 og returnerer svaret normalt inden for f\u00e5 sekunder. Praktisk. Og hurtigt. Det er stadig sv\u00e6rt at tro.<\/p>\n<p>Som f\u00f8lge af beslutningen om at opbevare data i S3 i et effektivt kolonneformat med fornuftig sharding af data i mapper\u2026 har vi f\u00e5et et DataLake og en hurtig og billig analytisk motor \u2013 gratis. Og den er blevet meget popul\u00e6r i virksomheden, da den forst\u00e5r SQL og fungerer v\u00e6sentligt hurtigere end gennem opstart\/stoppelse\/konfiguration af klynger. \u201eOg hvis resultatet er det samme, hvorfor betale mere?\u201c<\/p>\n<p>En foresp\u00f8rgsel til Athena ser omtrent s\u00e5dan ud. Hvis \u00f8nskes, kan man naturligvis formulere en temmelig <noindex><a rel=\"nofollow\" href=\"https:\/\/prestodb.io\/docs\/0.172\/index.html\">komplekse og fler-sides SQL-foresp\u00f8rgsel<\/a><\/noindex>, men vi vil n\u00f8jes med en simpel gruppering. Lad os se, hvilke svarkoder kunden havde for et par uger siden i webserverens logfiler og sikre os, at der ikke er nogen fejl:<\/p>\n<p><img decoding=\"async\" alt=\"Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor netop p\u00e5 denne m\u00e5de\" src=\"\/wp-content\/uploads\/2020\/08\/30028991467b9e52f597faa617d374b5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Konklusioner<\/h3>\n<p>\nEfter at have gennemg\u00e5et en ikke s\u00e5 lang, men smertefuld vej, konstant vurderende risici, kompleksitet og omkostninger ved vedligeholdelse, fandt vi en l\u00f8sning til DataLake og analyse, som fortsat gl\u00e6der os b\u00e5de med hastighed og ejeromkostninger.<\/p>\n<p>Det viste sig, at det at bygge et effektivt, hurtigt og billigt DataLake til behovene i helt forskellige afdelinger i virksomheden er muligt selv for erfarne udviklere, der aldrig har arbejdet som arkitekter og ikke ved, hvordan man tegner firkanter med pile og kender 50 termer fra Hadoop-\u00f8kosystemet.<\/p>\n<p>I starten var hovedet fyldt med information om forskellige \u00e5bne og lukkede software-zoos og forst\u00e5elsen af det ansvar, man har over for fremtidige generationer. Begynd blot at opbygge dit DataLake med simple v\u00e6rkt\u00f8jer: nagios\/munin -&gt; elastic\/kibana -&gt; Hadoop\/Spark\/s3 \u2026, indsamle feedback og dybt forst\u00e5 de fysiske processer. Alt det komplekse og uklare skal du overlade til fjenderne og konkurrenterne.<\/p>\n<p>Hvis du ikke vil i skyen og kan lide at vedligeholde, opdatere og patch'e open source-projekter, kan du bygge et lignende setup lokalt p\u00e5 billige kontormaskiner med Hadoop og Presto ovenp\u00e5. Det vigtigste er ikke at stoppe, men at forts\u00e6tte fremad, regne, finde simple og klare l\u00f8sninger, og s\u00e5 vil det helt sikkert lykkes! Held og lykke til alle, og vi ses igen!<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/bitrix\/blog\/516374\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0436\u0438\u0432\u0435\u043c \u0432 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0438 \u043f\u0440\u043e\u0441\u0442\u043e \u0441\u043e\u0441\u0442\u044b\u043a\u043e\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0433\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0445 \u0441 \u00ab\u043e\u0442\u043a\u043b\u044e\u0447\u0435\u043d\u043d\u044b\u043c \u0441\u043e\u0437\u043d\u0430\u043d\u0438\u0435\u043c\u00bb \u043f\u043e \u0441\u043e\u0432\u0435\u0442\u0430\u043c stackoverflow, \u043d\u0435 \u0432\u043d\u0438\u043a\u0430\u044f \u0432 \u00ab\u043c\u043d\u043e\u0433\u043e\u0431\u0443\u043a\u0432\u00bb, \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432 \u043a\u043e\u043c\u043c\u0435\u0440\u0447\u0435\u0441\u043a\u0443\u044e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044e. \u0410 \u043a\u043e\u0433\u0434\u0430 \u043d\u0443\u0436\u043d\u043e \u0431\u0443\u0434\u0435\u0442 \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0442\u044c\u0441\u044f\/\u0440\u0430\u0441\u0448\u0438\u0440\u044f\u0442\u044c\u0441\u044f \u0438\u043b\u0438 \u043a\u0442\u043e-\u0442\u043e \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u043e \u043f\u0435\u0440\u0435\u0437\u0430\u0433\u0440\u0443\u0437\u0438\u0442 \u043f\u0430\u0440\u0443 \u043c\u0430\u0448\u0438\u043d \u2014 \u043e\u0441\u043e\u0437\u043d\u0430\u0442\u044c, \u0447\u0442\u043e \u043d\u0430\u0447\u0430\u043b\u0441\u044f \u043a\u0430\u043a\u043e\u0439-\u0442\u043e \u043d\u0430\u0432\u044f\u0437\u0447\u0438\u0432\u044b\u0439 \u0434\u0443\u0440\u043d\u043e\u0439 \u0441\u043e\u043d \u043d\u0430\u044f\u0432\u0443, \u0432\u0441\u0435 \u0440\u0435\u0437\u043a\u043e \u0443\u0441\u043b\u043e\u0436\u043d\u0438\u043b\u043e\u0441\u044c \u0434\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92509,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0436\u0438\u0432\u0435\u043c \u0432 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0438 \u043f\u0440\u043e\u0441\u0442\u043e \u0441\u043e\u0441\u0442\u044b\u043a\u043e\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0433\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0445 \u0441 \u00ab\u043e\u0442\u043a\u043b\u044e\u0447\u0435\u043d\u043d\u044b\u043c \u0441\u043e\u0437\u043d\u0430\u043d\u0438\u0435\u043c\u00bb \u043f\u043e \u0441\u043e\u0432\u0435\u0442\u0430\u043c stackoverflow, \u043d\u0435 \u0432\u043d\u0438\u043a\u0430\u044f \u0432 \u00ab\u043c\u043d\u043e\u0433\u043e\u0431\u0443\u043a\u0432\u00bb, \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u0430\u043b\u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0435 \u0438 \u043d\u0435\u0434\u043e\u0440\u043e\u0433\u043e\u0435 DataLake \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u0438\u043c\u0435\u043d\u043d\u043e \u0442\u0430\u043a | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0436\u0438\u0432\u0435\u043c \u0432 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0438 \u043f\u0440\u043e\u0441\u0442\u043e \u0441\u043e\u0441\u0442\u044b\u043a\u043e\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0433\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0445 \u0441 \u00ab\u043e\u0442\u043a\u043b\u044e\u0447\u0435\u043d\u043d\u044b\u043c \u0441\u043e\u0437\u043d\u0430\u043d\u0438\u0435\u043c\u00bb \u043f\u043e \u0441\u043e\u0432\u0435\u0442\u0430\u043c stackoverflow, \u043d\u0435 \u0432\u043d\u0438\u043a\u0430\u044f \u0432 \u00ab\u043c\u043d\u043e\u0433\u043e\u0431\u0443\u043a\u0432\u00bb, \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-28T05:42:10+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-28T05:42:10+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hvordan vi organiserede et h\u00f8jtydende og billigt DataLake, og hvorfor lige s\u00e5dan | ProHoster","description":"Vi lever i en fantastisk tid, hvor man hurtigt og nemt kan sammenkoble flere f\u00e6rdige open source v\u00e6rkt\u00f8jer, konfigurere dem med 'slukket sind' efter r\u00e5d fra stackoverflow uden at dykke ned i 'mange bogstaver', og s\u00e6tte dem i drift.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u0430\u043b\u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0435 \u0438 \u043d\u0435\u0434\u043e\u0440\u043e\u0433\u043e\u0435 DataLake \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u0438\u043c\u0435\u043d\u043d\u043e \u0442\u0430\u043a | ProHoster","og:description":"\u041c\u044b \u0436\u0438\u0432\u0435\u043c \u0432 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0438 \u043f\u0440\u043e\u0441\u0442\u043e \u0441\u043e\u0441\u0442\u044b\u043a\u043e\u0432\u0430\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0433\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u0432, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0445 \u0441 \u00ab\u043e\u0442\u043a\u043b\u044e\u0447\u0435\u043d\u043d\u044b\u043c \u0441\u043e\u0437\u043d\u0430\u043d\u0438\u0435\u043c\u00bb \u043f\u043e \u0441\u043e\u0432\u0435\u0442\u0430\u043c stackoverflow, \u043d\u0435 \u0432\u043d\u0438\u043a\u0430\u044f \u0432 \u00ab\u043c\u043d\u043e\u0433\u043e\u0431\u0443\u043a\u0432\u00bb, \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-organizovali-vysokoeffektivnoe-i-nedorogoe-datalake-i-pochemu-imenno-tak","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-28T05:42:10+00:00","article:modified_time":"2020-08-28T05:42:10+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92508","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:07:39","updated":"2022-10-01 09:50:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=92508"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/92509"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=92508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=92508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=92508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}