{"id":84416,"date":"2020-06-07T13:42:50","date_gmt":"2020-06-07T11:42:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez"},"modified":"2020-06-07T13:42:50","modified_gmt":"2020-06-07T11:42:50","slug":"formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","title":{"rendered":"Formatele fi\u0219ierelor \u00een big data: un scurt ghid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Formatele
\nDivinitate Meteorologic\u0103 de Remarin<\/i><\/a><\/noindex> <\/p>\n

Comanda Solu\u021bii Cloud Mail.ru<\/a><\/noindex> ofer\u0103 traducerea unui articol<\/a><\/noindex> inginerul Rahul Bhatia de la Clairvoyant despre ce formate de fi\u0219iere exist\u0103 \u00een big data, care sunt cele mai comune func\u021bii ale formatelor Hadoop \u0219i care format este cel mai potrivit.
\n<\/a><\/noindex><\/p>\n

De ce sunt necesare diferite formate de fi\u0219iere<\/h2>\n

\nO problem\u0103 serioas\u0103 \u00een performan\u021ba aplica\u021biilor care suport\u0103 HDFS, cum ar fi MapReduce \u0219i Spark, este timpul de c\u0103utare, citire \u0219i scriere a datelor. Aceste probleme sunt agravate de dificult\u0103\u021bile de gestionare a unor seturi mari de date, dac\u0103 nu avem un schem\u0103 fix\u0103, ci una evolutiv\u0103, sau exist\u0103 anumite restric\u021bii de stocare.<\/p>\n

Prelucrarea big data cre\u0219te sarcina asupra subsistemului de stocare - Hadoop stocheaz\u0103 date \u00een mod redundant pentru a asigura fiabilitatea. Pe l\u00e2ng\u0103 discuri, sunt suprasolicitate procesorul, re\u021beaua, sistemul de intrare-ie\u0219ire \u0219i a\u0219a mai departe. Pe m\u0103sur\u0103 ce volumul de date cre\u0219te, costul proces\u0103rii \u0219i stoc\u0103rii acestora se intensific\u0103.<\/p>\n

Diversele formate de fi\u0219iere \u00een Hadoop<\/a><\/noindex> sunt concepute pentru a rezolva exact aceste probleme. Alegerea unui format de fi\u0219ier adecvat poate aduce unele avantaje semnificative:<\/p>\n

    \n
  1. Timp de citire mai rapid.<\/li>\n
  2. Timp de scriere mai rapid.<\/li>\n
  3. Fi\u0219iere partajabile.<\/li>\n
  4. Suport pentru evolu\u021bia schemelor.<\/li>\n
  5. Suport extins pentru compresie.<\/li>\n<\/ol>\n

    \nUnele formate de fi\u0219iere sunt destinate uzului general, altele pentru variante mai specifice, iar unele sunt dezvoltate av\u00e2nd \u00een vedere caracteristici specifice ale datelor. Astfel, alegerea este \u00eentr-adev\u0103r destul de mare.<\/p>\n

    Formatul de fi\u0219ier Avro<\/h2>\n

    \nPentru serializarea datelor <\/i>este utilizat pe scar\u0103 larg\u0103 - acesta este un format de stocare a datelor bazat pe r\u00e2nduri<\/i>, adic\u0103 un format de tip r\u00e2nd \u00een Hadoop. Acesta stocheaz\u0103 schema \u00een format JSON, facilit\u00e2nd citirea \u0219i interpretarea acesteia de c\u0103tre orice program. Datele \u00een sine sunt stocate \u00eentr-un format binar, compact \u0219i eficient.<\/p>\n

    Sistemul de serializare Avro este neutr\u0103 la limbaj. Fi\u0219ierele pot fi prelucrate \u00een diferite limbaje, \u00een prezent fiind C, C++, C#, Java, Python \u0219i Ruby.<\/p>\n

    O caracteristic\u0103 cheie a Avro este suportul solid pentru scheme de date care se schimb\u0103 \u00een timp, adic\u0103 evolueaz\u0103. Avro \u00een\u021belege modific\u0103rile de schem\u0103 - eliminarea, ad\u0103ugarea sau modificarea c\u00e2mpurilor.<\/p>\n

    Avro suport\u0103 structurii de date diverse. De exemplu, se poate crea un \u00eenregistrare care con\u021bine un tablou, un tip enumerat \u0219i un sub-\u00eenregistrare.<\/p>\n

    \"Formatele
    \nAcest format este ideal pentru scrierea \u00een zona de aterizare (transitional) a lacului de date (    lac de date<\/a><\/noindex>, sau data lake \u2013 o colec\u021bie de instan\u021be pentru stocarea diferitelor tipuri de date \u00een completarea surselor de date). <\/p>\n

    A\u0219adar, pentru a scrie \u00een zona de landing a lacului de date, acest format este cel mai potrivit din urm\u0103toarele motive:<\/p>\n

      \n
    1. Datele din aceast\u0103 zon\u0103 sunt de obicei citite integral pentru procesare ulterioar\u0103 de c\u0103tre sistemele inferioare \u2013 iar formatul bazat pe \u0219iruri este mai eficient \u00een acest caz.<\/li>\n
    2. Sistemele inferioare pot extrage cu u\u0219urin\u021b\u0103 schemele tabelare din fi\u0219iere \u2013 nu este nevoie s\u0103 stocheze schemele separat \u00eentr-un depozit extern de metadate.<\/li>\n
    3. Orice modificare a schemei surs\u0103 este u\u0219or de gestionat (evolu\u021bia schemei).<\/li>\n<\/ol>\n

      <\/p>\n

      Formatul fi\u0219ierelor Parquet<\/h2>\n

      \nParquet este un format de fi\u0219ier open-source pentru Hadoop, care stocheaz\u0103 structuri de date imbricate \u00eentr-un format plat, coloan\u0103.<\/i>.<\/p>\n

      Comparativ cu abordarea tradi\u021bional\u0103 bazat\u0103 pe \u0219iruri, Parquet este mai eficient din punct de vedere al stoc\u0103rii \u0219i performan\u021bei.<\/p>\n

      Aceasta este deosebit de util\u0103 pentru interog\u0103rile care citesc anumite coloane dintr-un tabel larg (cu multe coloane). Datorit\u0103 formatului fi\u0219ierelor, sunt citite doar coloanele necesare, astfel \u00eenc\u00e2t intr\u0103rile \u0219i ie\u0219irile sunt reduse la minimum.<\/p>\n

      O mic\u0103 explica\u021bie suplimentar\u0103<\/strong>: pentru a \u00een\u021belege mai bine formatul fi\u0219ierului Parquet \u00een Hadoop, s\u0103 vedem ce \u00eenseamn\u0103 un format bazat pe coloane \u2013 adic\u0103 un format coloanal. \u00centr-un astfel de format, valorile de aceea\u0219i tip sunt stocate \u00eempreun\u0103 pentru fiecare coloan\u0103. <\/p>\n

      De exemplu<\/a><\/noindex>, \u00eenregistrarea include c\u00e2mpurile ID, Nume \u0219i Departament. \u00cen acest caz, toate valorile coloanei ID vor fi stocate \u00eempreun\u0103, la fel \u0219i valorile coloanei Nume \u0219i a\u0219a mai departe. Tabelul va ar\u0103ta aproximativ a\u0219a:<\/p>\n

      ID<\/strong>
      \nName<\/strong>
      \nDepartament<\/strong><\/p>\n

      1
      \nemp1
      \nd1<\/p>\n

      2
      \nemp2
      \nd2<\/p>\n

      3
      \nemp3
      \nd3<\/p>\n

      \n\u00cen formatul pe \u0219iruri, datele vor fi stocate astfel:<\/p>\n

      1
      \nemp1
      \nd1
      \n2
      \nemp2
      \nd2
      \n3
      \nemp3
      \nd3<\/p>\n

      \n\u00cen formatul coloanei, acelea\u0219i date vor fi stocate astfel:<\/p>\n

      1
      \n2
      \n3
      \nemp1
      \nemp2
      \nemp3
      \nd1
      \nd2
      \nd3<\/p>\n

      \nFormatul coloan\u0103 este mai eficient c\u00e2nd trebuie s\u0103 interoghezi mai multe coloane dintr-un tabel. Acesta va citi doar coloanele necesare pentru c\u0103 sunt adiacente. Astfel, opera\u021biunile de intrare-ie\u0219ire sunt reduse la minimum.<\/p>\n

      De exemplu, ai nevoie doar de coloana NUME. \u00cen formatul pe \u0219iruri<\/a><\/noindex> fiecare \u00eenregistrare din setul de date trebuie s\u0103 fie \u00eenc\u0103rcat\u0103, analizat\u0103 pe c\u00e2mpuri \u0219i apoi datele NUME extrase. Formatul coloanei permite accesarea direct\u0103 a coloanei Nume, deoarece toate valorile pentru aceast\u0103 coloan\u0103 sunt stocate \u00eempreun\u0103. Nu va fi necesar\u0103 scanarea \u00eentregii \u00eenregistr\u0103ri.<\/p>\n

      Astfel, formatul columnar \u00eembun\u0103t\u0103\u021be\u0219te performan\u021ba interog\u0103rilor, deoarece timpul de c\u0103utare pentru a accesa coloanele dorite este mai scurt, reduc\u00e2nd num\u0103rul opera\u021biunilor de intrare-ie\u0219ire, deoarece doar coloanele necesare sunt citite.<\/p>\n

      Una dintre caracteristicile unice Parquet<\/a><\/noindex> const\u0103 \u00een faptul c\u0103 \u00een acest format poate stoca date cu structuri \u00eennesterate.<\/i>Aceasta \u00eenseamn\u0103 c\u0103 \u00een fi\u0219ierul Parquet, chiar \u0219i c\u00e2mpurile \u00eennesterate pot fi citite separat, f\u0103r\u0103 a fi necesar\u0103 citirea tuturor c\u00e2mpurilor din structura \u00eennesterat\u0103. Pentru a stoca structuri \u00eennesterate, Parquet folose\u0219te un algoritm de fragmentare \u0219i asamblare.<\/p>\n

      \"Formatele
      \nPentru a \u00een\u021belege formatul fi\u0219ierului Parquet \u00een Hadoop, este necesar s\u0103 cunoa\u0219te\u021bi urm\u0103torii termeni:<\/p>\n

        \n
      1. Grup de r\u00e2nduri<\/strong> (row group): o diviziune logic\u0103 orizontal\u0103 a datelor \u00een r\u00e2nduri. Grupul de r\u00e2nduri const\u0103 dintr-un fragment al fiec\u0103rei coloane din setul de date.<\/li>\n
      2. Fragment de coloan\u0103<\/strong> (column chunk): un fragment al unei coloane specifice. Aceste fragmente de coloane tr\u0103iesc \u00eentr-un grup de r\u00e2nduri specific \u0219i vor fi garantat adiacente \u00een fi\u0219ier.<\/li>\n
      3. Pagina<\/strong> (page): fragmentele de coloane sunt \u00eemp\u0103r\u021bite \u00een pagini, scrise una dup\u0103 alta. Paginile au un header comun, astfel c\u0103 la citire se pot s\u0103ri cele inutile.<\/li>\n<\/ol>\n

        \n\"Formatele
        \nAici, headerul con\u021bine pur \u0219i simplu un num\u0103r magic PAR1<\/i> (4 octe\u021bi), care identific\u0103 fi\u0219ierul ca fiind de format Parquet.<\/p>\n

        \u00cen footer este scris urm\u0103toarele:<\/p>\n

          \n
        1. Metadatele fi\u0219ierului, care con\u021bin coordonatele de start ale metadatelor fiec\u0103rei coloane. La citire, trebuie mai \u00eent\u00e2i s\u0103 se citeasc\u0103 metadatele fi\u0219ierului pentru a g\u0103si toate fragmentele de coloane relevante. Apoi, fragmentele de coloane ar trebui citite secven\u021bial. De asemenea, metadatele includ versiunea formatului, schema \u0219i orice alte perechi cheie-valoare suplimentare.<\/li>\n
        2. Lungimea metadatelor (4 octe\u021bi).<\/li>\n
        3. Num\u0103rul magic PAR1<\/i> (4 octe\u021bi).<\/li>\n<\/ol>\n

          <\/p>\n

          Formatul fi\u0219ierelor ORC<\/h2>\n

          \nFormatul fi\u0219ierelor optimizat pe r\u00e2nd \u0219i coloan\u0103<\/i> (Optimized Row Columnar, ORC<\/a><\/noindex>) ofer\u0103 un mod foarte eficient de stocare a datelor \u0219i a fost dezvoltat pentru a dep\u0103\u0219i limit\u0103rile altor formate. Stocheaz\u0103 datele \u00eentr-o form\u0103 perfect compact\u0103, permi\u021b\u00e2nd s\u0103ri peste detalii inutile \u2014 f\u0103r\u0103 a necesita construirea de indec\u0219i mari, complec\u0219i sau gestiona\u021bi manual. <\/p>\n

          Avantajele formatului ORC:<\/p>\n

            \n
          1. Un fi\u0219ier la ie\u0219irea fiec\u0103rei sarcini, ceea ce reduce \u00eenc\u0103rc\u0103tura pe NameNode (nodul de nume).<\/li>\n
          2. Suport pentru tipurile de date Hive, inclusiv DateTime, tipuri de date zecimale \u0219i complexe (struct, list\u0103, map\u0103 \u0219i uniune).<\/li>\n
          3. Citirea simultan\u0103 a aceluia\u0219i fi\u0219ier de c\u0103tre diferite procese RecordReader.<\/li>\n
          4. Capacitatea de a diviza fi\u0219iere f\u0103r\u0103 a scana pentru marcaje.<\/li>\n
          5. Evaluarea aloc\u0103rii maxime posibile a memoriei heap pentru procesele de citire\/scriere, conform informa\u021biilor din footer-ul fi\u0219ierului.<\/li>\n
          6. Metadatele sunt stocate \u00een format binar de serializare Protocol Buffers, care permite ad\u0103ugarea \u0219i eliminarea c\u00e2mpurilor.<\/li>\n<\/ol>\n

            \n\"Formatele
            \nORC stocheaz\u0103 colec\u021bii de r\u00e2nduri \u00eentr-un singur fi\u0219ier, iar datele de tip r\u00e2nd din cadrul colec\u021biei sunt stocate \u00een format columnar.<\/p>\n

            Fi\u0219ierul ORC stocheaz\u0103 grupuri de r\u00e2nduri denumite dungi (stripes) \u0219i informa\u021bii auxiliare \u00een footer-ul fi\u0219ierului. Postscriptul de la sf\u00e2r\u0219itul fi\u0219ierului con\u021bine parametrii de comprimare \u0219i dimensiunea footer-ului comprimat.<\/p>\n

            Prin default, dimensiunea unei dungi este de 250 MB. Datorit\u0103 dimensiunii mari a dungilor, citirea din HDFS se efectueaz\u0103 mai eficient: \u00een blocuri mari \u0219i continue.<\/p>\n

            \u00cen footer-ul fi\u0219ierului este listat\u0103 o list\u0103 de dungi din fi\u0219ier, num\u0103rul de r\u00e2nduri pe dung\u0103 \u0219i tipul de date pentru fiecare coloan\u0103. De asemenea, sunt \u00eenregistrate valorile rezultate count, min, max \u0219i sum pentru fiecare coloan\u0103.<\/p>\n

            Footer-ul dungi con\u021bine un catalog al loca\u021biilor fluxului.<\/p>\n

            Datele de tip r\u00e2nd sunt folosite la scanarea tabelilor.<\/p>\n

            Datele de index includ valorile minime \u0219i maxime pentru fiecare coloan\u0103 \u0219i pozi\u021biile r\u00e2ndurilor din fiecare coloan\u0103. Indicele ORC este utilizat doar pentru selectarea dungilor \u0219i grupurilor de r\u00e2nduri, nu pentru r\u0103spunsurile la interog\u0103ri.<\/p>\n

            Compara\u021bia \u00eentre diferite formate de fi\u0219iere<\/h2>\n

            <\/p>\n

            Avro comparativ cu Parquet<\/h3>\n

            <\/p>\n

              \n
            1. Avro este un format de stocare pe baza r\u00e2ndurilor, \u00een timp ce Parquet stocheaz\u0103 datele pe baza coloanelor.<\/li>\n
            2. Parquet este mai potrivit pentru interog\u0103rile analitice, adic\u0103 opera\u021biunile de citire \u0219i interogare a datelor sunt mult mai eficiente dec\u00e2t cele de scriere.<\/li>\n
            3. Opera\u021biunile de scriere \u00een Avro se realizeaz\u0103 mai eficient dec\u00e2t \u00een Parquet.<\/li>\n
            4. Avro func\u021bioneaz\u0103 mai bine cu evolu\u021bia schemelor. Parquet suport\u0103 doar ad\u0103ugarea de scheme, \u00een timp ce Avro implementeaz\u0103 o evolu\u021bie multifunc\u021bional\u0103, adic\u0103 ad\u0103ugarea sau modificarea coloanelor.<\/li>\n
            5. Parquet este ideal pentru interogarea unui subansamblu de coloane \u00eentr-un tabel multi-coloan\u0103. Avro este potrivit pentru opera\u021biunile ETL, unde solicit\u0103m toate coloanele.<\/li>\n<\/ol>\n

              <\/p>\n

              ORC comparativ cu Parquet<\/h3>\n

              <\/p>\n

                \n
              1. Parquet stocheaz\u0103 mai bine datele imbricate.<\/li>\n
              2. ORC este mai adaptat pentru \u00eempingerea predicatelor (predicate pushdown).<\/li>\n
              3. ORC suport\u0103 propriet\u0103\u021bi ACID.<\/li>\n
              4. ORC comprim\u0103 mai bine datele.<\/li>\n<\/ol>\n

                \nWhat else to read on the topic<\/strong>:<\/p>\n

                  \n
                1. Analiza big data \u00een cloud: cum pot companiile s\u0103 devin\u0103 orientate pe date.<\/a><\/noindex>.<\/li>\n
                2. Un ghid modest pentru schemele de baze de date.<\/a><\/noindex>.<\/li>\n
                3. Canalul nostru Telegram despre transformarea digital\u0103.<\/a><\/noindex>. \n<\/li>\n<\/ol>\n

                  Sursa: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

                  Weather Deity by Remarin \u041a\u043e\u043c\u0430\u043d\u0434\u0430 Mail.ru Cloud Solutions \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430 \u0420\u0430\u0445\u0443\u043b\u0430 \u0411\u0445\u0430\u0442\u0438\u0438 \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Clairvoyant \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u0435\u0441\u0442\u044c \u0444\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0434\u0430\u043d\u043d\u044b\u0445, \u043a\u0430\u043a\u0438\u0435 \u0441\u0430\u043c\u044b\u0435 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u043d\u044b\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u0444\u043e\u0440\u043c\u0430\u0442\u043e\u0432 Hadoop \u0438 \u043a\u0430\u043a\u043e\u0439 \u0444\u043e\u0440\u043c\u0430\u0442 \u043b\u0443\u0447\u0448\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u0417\u0430\u0447\u0435\u043c \u043d\u0443\u0436\u043d\u044b \u0440\u0430\u0437\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0421\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435 \u0443\u0437\u043a\u043e\u0435 \u043c\u0435\u0441\u0442\u043e \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 HDFS, \u0442\u0430\u043a\u0438\u0445 \u043a\u0430\u043a MapReduce \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84417,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84416","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Formate de fi\u0219iere \u00een big data: un ghid pe scurt | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\u0424\u043e\u0440\u043c\u0430\u0442\u044b \u0444\u0430\u0439\u043b\u043e\u0432 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0434\u0430\u043d\u043d\u044b\u0445: \u043a\u0440\u0430\u0442\u043a\u0438\u0439 \u043b\u0438\u043a\u0431\u0435\u0437 | ProHoster","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","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-06-07T11:42:50+00:00","article:modified_time":"2020-06-07T11:42:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84416","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 14:58:40","updated":"2022-09-28 08:24:46","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/84416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=84416"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/84416\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/84417"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=84416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=84416"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=84416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}