{"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\/pt\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","title":{"rendered":"Formatos de arquivos em big data: uma breve introdu\u00e7\u00e3o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Formatos
\nDivindade do Tempo por Remarin<\/i><\/a><\/noindex> <\/p>\n

Time Solu\u00e7\u00f5es em Nuvem Mail.ru<\/a><\/noindex> oferece tradu\u00e7\u00e3o de artigo<\/a><\/noindex> do engenheiro Rahul Bhati da empresa Clairvoyant sobre os formatos de arquivos em Big Data, quais s\u00e3o as fun\u00e7\u00f5es mais comuns dos formatos Hadoop e qual formato \u00e9 o melhor para usar.
\n<\/a><\/noindex><\/p>\n

Por que existem diferentes formatos de arquivo<\/h2>\n

\nUm gargalo s\u00e9rio no desempenho de aplicativos que suportam HDFS, como MapReduce e Spark \u2014 \u00e9 o tempo de busca, leitura e grava\u00e7\u00e3o de dados. Esses problemas s\u00e3o agravados pelas dificuldades em gerenciar grandes conjuntos de dados quando temos um esquema n\u00e3o fixo, mas em evolu\u00e7\u00e3o, ou quando existem algumas limita\u00e7\u00f5es de armazenamento.<\/p>\n

O processamento de Big Data aumenta a carga no subsistema de armazenamento \u2014 o Hadoop armazena dados de forma redundante para garantir a resili\u00eancia. Al\u00e9m dos discos, a CPU, a rede, o sistema de entrada e sa\u00edda, e assim por diante, tamb\u00e9m s\u00e3o pressionados. \u00c0 medida que o volume de dados cresce, tamb\u00e9m aumenta o custo de seu processamento e armazenamento.<\/p>\n

Diferentes formatos de arquivos em Hadoop<\/a><\/noindex> foram criados para resolver exatamente esses problemas. A escolha do formato de arquivo adequado pode trazer algumas vantagens significativas:<\/p>\n

    \n
  1. Tempo de leitura mais r\u00e1pido.<\/li>\n
  2. Tempo de grava\u00e7\u00e3o mais r\u00e1pido.<\/li>\n
  3. Arquivos compartilh\u00e1veis.<\/li>\n
  4. Suporte \u00e0 evolu\u00e7\u00e3o de esquemas.<\/li>\n
  5. Suporte avan\u00e7ado para compress\u00e3o.<\/li>\n<\/ol>\n

    \nAlguns formatos de arquivo s\u00e3o projetados para uso geral, outros para op\u00e7\u00f5es mais espec\u00edficas, e alguns s\u00e3o desenvolvidos com caracter\u00edsticas espec\u00edficas dos dados em mente. Portanto, a escolha realmente \u00e9 bastante ampla.<\/p>\n

    Formato de arquivo Avro<\/h2>\n

    \nPara de serializa\u00e7\u00e3o de dados <\/i>\u00e9 amplamente utilizado \u2014 Avro \u00e9 um formato de armazenamento de dados baseado em linhas<\/i>, ou seja, no formato de linhas, no Hadoop. Ele armazena o esquema em formato JSON, facilitando a leitura e interpreta\u00e7\u00e3o por qualquer programa. Os pr\u00f3prios dados est\u00e3o em formato bin\u00e1rio, compacto e eficiente.<\/p>\n

    O sistema de serializa\u00e7\u00e3o Avro \u00e9 neutro em rela\u00e7\u00e3o \u00e0 linguagem. Os arquivos podem ser processados por diferentes linguagens, atualmente C, C++, C#, Java, Python e Ruby.<\/p>\n

    Uma caracter\u00edstica fundamental do Avro \u00e9 o suporte robusto para esquemas de dados que mudam com o tempo, ou seja, evoluem. O Avro reconhece altera\u00e7\u00f5es no esquema \u2014 remo\u00e7\u00e3o, adi\u00e7\u00e3o ou modifica\u00e7\u00e3o de campos.<\/p>\n

    O Avro suporta uma variedade de estruturas de dados. Por exemplo, \u00e9 poss\u00edvel criar um registro que contenha um array, um tipo enumerado e uma sub-record.<\/p>\n

    \"Formatos
    \nEste formato \u00e9 ideal para grava\u00e7\u00e3o na zona de landing (transi\u00e7\u00e3o) do lago de dados (    lago de dados<\/a><\/noindex>, ou data lake \u2014 uma cole\u00e7\u00e3o de inst\u00e2ncias para armazenar diferentes tipos de dados al\u00e9m das fontes de dados diretas). <\/p>\n

    Assim, para grava\u00e7\u00e3o na zona de landing do lago de dados, esse formato \u00e9 o mais adequado pelas seguintes raz\u00f5es:<\/p>\n

      \n
    1. Os dados dessa zona s\u00e3o geralmente lidos na \u00edntegra para posterior processamento por sistemas inferiores \u2014 e o formato baseado em linhas \u00e9 mais eficiente nesse caso.<\/li>\n
    2. Os sistemas inferiores podem facilmente extrair tabelas de esquema dos arquivos \u2014 n\u00e3o \u00e9 necess\u00e1rio armazenar os esquemas separadamente em um armazenamento meta externo.<\/li>\n
    3. Qualquer altera\u00e7\u00e3o na esquematiza\u00e7\u00e3o original \u00e9 facilmente tratada (evolu\u00e7\u00e3o do esquema).<\/li>\n<\/ol>\n

      <\/p>\n

      O formato de arquivos Parquet<\/h2>\n

      \nParquet \u00e9 um formato de arquivo open-source para Hadoop, que armazena estruturas de dados aninhadas em um formato de coluna plana<\/i>.<\/p>\n

      Em compara\u00e7\u00e3o com a abordagem tradicional baseada em linhas, o Parquet \u00e9 mais eficiente em termos de armazenamento e desempenho.<\/p>\n

      Isso \u00e9 especialmente \u00fatil para consultas que leem colunas espec\u00edficas de uma tabela ampla (com muitas colunas). Gra\u00e7as ao formato dos arquivos, apenas as colunas necess\u00e1rias s\u00e3o lidas, minimizando a entrada e sa\u00edda.<\/p>\n

      Uma pequena explica\u00e7\u00e3o introdut\u00f3ria<\/strong>: para entender melhor o formato de arquivo Parquet no Hadoop, vamos ver o que \u00e9 um formato baseado em colunas \u2014 ou seja, um formato columnar. Nesse tipo de formato, os valores de cada coluna do mesmo tipo s\u00e3o armazenados juntos. <\/p>\n

      Por exemplo<\/a><\/noindex>, a grava\u00e7\u00e3o inclui os campos ID, Nome e Departamento. Neste caso, todos os valores da coluna ID ser\u00e3o armazenados juntos, assim como os valores da coluna Nome e assim por diante. A tabela ficar\u00e1 aproximadamente assim:<\/p>\n

      ID<\/strong>
      \nNome<\/strong>
      \nDepartamento<\/strong><\/p>\n

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

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

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

      \nNo formato de linha, os dados ser\u00e3o armazenados da seguinte forma:<\/p>\n

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

      \nNo formato columnar, os mesmos dados ser\u00e3o armazenados assim:<\/p>\n

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

      \nO formato columnar \u00e9 mais eficiente quando voc\u00ea precisa consultar v\u00e1rias colunas de uma tabela. Ele ler\u00e1 apenas as colunas necess\u00e1rias, pois est\u00e3o pr\u00f3ximas umas das outras. Assim, as opera\u00e7\u00f5es de entrada e sa\u00edda s\u00e3o minimizadas.<\/p>\n

      Por exemplo, voc\u00ea s\u00f3 precisa da coluna NOME. No formato de linha<\/a><\/noindex> Cada registro em um conjunto de dados precisa ser carregado, analisado em campos e, em seguida, os dados NAME devem ser extra\u00eddos. O formato em colunas permite acessar diretamente a coluna Name, pois todos os valores para essa coluna est\u00e3o armazenados juntos. N\u00e3o \u00e9 necess\u00e1rio escanear todo o registro.<\/p>\n

      Assim, o formato em colunas melhora o desempenho das consultas, pois leva menos tempo para acessar as colunas desejadas, reduzindo o n\u00famero de opera\u00e7\u00f5es de entrada e sa\u00edda, uma vez que apenas as colunas necess\u00e1rias s\u00e3o lidas.<\/p>\n

      Uma das caracter\u00edsticas \u00fanicas do Parquet<\/a><\/noindex> \u00e9 que nesse formato ele pode armazenar dados com estruturas aninhadas<\/i>. Isso significa que em um arquivo Parquet at\u00e9 campos aninhados podem ser lidos separadamente, sem a necessidade de ler todos os campos na estrutura aninhada. Para armazenar estruturas aninhadas, o Parquet utiliza o algoritmo de fragmenta\u00e7\u00e3o e montagem (shredding and assembly).<\/p>\n

      \"Formatos
      \nPara entender o formato de arquivo Parquet no Hadoop, \u00e9 necess\u00e1rio conhecer os seguintes termos:<\/p>\n

        \n
      1. Grupo de linhas<\/strong> (row group): uma divis\u00e3o l\u00f3gica horizontal dos dados em linhas. Um grupo de linhas consiste em um fragmento de cada coluna no conjunto de dados.<\/li>\n
      2. Fragmento de coluna<\/strong> (column chunk): um fragmento de uma coluna espec\u00edfica. Esses fragmentos de colunas vivem em um determinado grupo de linhas e ser\u00e3o adjacentes no arquivo.<\/li>\n
      3. P\u00e1gina<\/strong> (page): fragmentos de colunas s\u00e3o divididos em p\u00e1ginas, gravadas uma ap\u00f3s a outra. As p\u00e1ginas t\u00eam um cabe\u00e7alho comum, ent\u00e3o ao ler, p\u00e1ginas desnecess\u00e1rias podem ser puladas.<\/li>\n<\/ol>\n

        \n\"Formatos
        \nAqui, o cabe\u00e7alho simplesmente cont\u00e9m um n\u00famero m\u00e1gico PAR1<\/i> (4 bytes), que identifica o arquivo como um arquivo no formato Parquet.<\/p>\n

        No rodap\u00e9 est\u00e1 escrito o seguinte:<\/p>\n

          \n
        1. Metadados do arquivo, que cont\u00eam as coordenadas iniciais dos metadados de cada coluna. Ao ler, primeiro \u00e9 necess\u00e1rio ler os metadados do arquivo para encontrar todos os fragmentos de colunas de interesse. Em seguida, os fragmentos de colunas devem ser lidos sequencialmente. Al\u00e9m disso, os metadados incluem a vers\u00e3o do formato, o esquema e quaisquer pares adicionais de chave-valor.<\/li>\n
        2. Comprimento dos metadados (4 bytes).<\/li>\n
        3. N\u00famero m\u00e1gico PAR1<\/i> (4 bytes).<\/li>\n<\/ol>\n

          <\/p>\n

          Formato de arquivos ORC<\/h2>\n

          \nFormato de arquivos otimizados em linha e coluna<\/i> (Optimized Row Columnar, ORC<\/a><\/noindex>) oferece um modo muito eficiente de armazenamento de dados e foi desenvolvido para superar as limita\u00e7\u00f5es de outros formatos. Armazena dados de forma perfeitamente compacta, permitindo pular detalhes desnecess\u00e1rios \u2014 enquanto n\u00e3o requer a constru\u00e7\u00e3o de \u00edndices grandes, complexos ou de manuten\u00e7\u00e3o manual. <\/p>\n

          Vantagens do formato ORC:<\/p>\n

            \n
          1. Um arquivo de sa\u00edda para cada tarefa, reduzindo a carga no NameNode (n\u00f3 de nomes).<\/li>\n
          2. Suporte a tipos de dados do Hive, incluindo DateTime, tipos decimais e tipos complexos (struct, list, map e union).<\/li>\n
          3. Leitura simult\u00e2nea do mesmo arquivo por diferentes processos RecordReader.<\/li>\n
          4. Possibilidade de dividir arquivos sem escanear em busca de marcadores.<\/li>\n
          5. Avalia\u00e7\u00e3o do m\u00e1ximo poss\u00edvel de aloca\u00e7\u00e3o de mem\u00f3ria heap para processos de leitura\/grava\u00e7\u00e3o com base nas informa\u00e7\u00f5es no rodap\u00e9 do arquivo.<\/li>\n
          6. Metadados s\u00e3o armazenados em um formato bin\u00e1rio de serializa\u00e7\u00e3o Protocol Buffers, que permite adicionar e remover campos.<\/li>\n<\/ol>\n

            \n\"Formatos
            \nORC armazena cole\u00e7\u00f5es de strings em um \u00fanico arquivo, enquanto os dados de string dentro da cole\u00e7\u00e3o s\u00e3o armazenados em formato colunar.<\/p>\n

            O arquivo ORC armazena grupos de strings, chamados de stripes, e informa\u00e7\u00f5es auxiliares no rodap\u00e9 do arquivo. O postscript no final do arquivo cont\u00e9m par\u00e2metros de compress\u00e3o e o tamanho do rodap\u00e9 comprimido.<\/p>\n

            Por padr\u00e3o, o tamanho da stripe \u00e9 de 250 MB. Gra\u00e7as a stripes desse tamanho, a leitura do HDFS \u00e9 realizada de forma mais eficiente: em blocos grandes e cont\u00ednuos.<\/p>\n

            No rodap\u00e9 do arquivo, \u00e9 gravada uma lista de stripes no arquivo, o n\u00famero de linhas por stripe e o tipo de dados de cada coluna. Tamb\u00e9m est\u00e3o gravados os valores resultantes de count, min, max e sum para cada coluna.<\/p>\n

            O rodap\u00e9 da stripe cont\u00e9m um diret\u00f3rio de localiza\u00e7\u00f5es de fluxo.<\/p>\n

            Os dados de string s\u00e3o usados durante a varredura de tabelas.<\/p>\n

            Os dados de \u00edndice incluem valores m\u00ednimos e m\u00e1ximos para cada coluna e as posi\u00e7\u00f5es das linhas em cada coluna. Os \u00edndices ORC s\u00e3o utilizados apenas para selecionar stripes e grupos de strings, n\u00e3o para responder a consultas.<\/p>\n

            Compara\u00e7\u00e3o entre diferentes formatos de arquivos<\/h2>\n

            <\/p>\n

            Avro versus Parquet<\/h3>\n

            <\/p>\n

              \n
            1. Avro \u00e9 um formato de armazenamento por linhas, enquanto o Parquet armazena dados por colunas.<\/li>\n
            2. Parquet \u00e9 mais adequado para consultas anal\u00edticas, isto \u00e9, opera\u00e7\u00f5es de leitura e consulta de dados s\u00e3o muito mais eficientes do que grava\u00e7\u00e3o.<\/li>\n
            3. Opera\u00e7\u00f5es de grava\u00e7\u00e3o em Avro s\u00e3o realizadas de forma mais eficiente do que em Parquet.<\/li>\n
            4. Avro trabalha de forma mais madura com a evolu\u00e7\u00e3o de esquemas. O Parquet suporta apenas a adi\u00e7\u00e3o de esquemas, enquanto o Avro implementa uma evolu\u00e7\u00e3o multifuncional, ou seja, a adi\u00e7\u00e3o ou modifica\u00e7\u00e3o de colunas.<\/li>\n
            5. Parquet \u00e9 ideal para consultar subconjuntos de colunas em uma tabela de m\u00faltiplas colunas. Avro \u00e9 adequado para opera\u00e7\u00f5es ETL, onde consultamos todas as colunas.<\/li>\n<\/ol>\n

              <\/p>\n

              ORC em compara\u00e7\u00e3o com Parquet<\/h3>\n

              <\/p>\n

                \n
              1. Parquet armazena melhor dados aninhados.<\/li>\n
              2. ORC \u00e9 mais adequado para empurr\u00e3o de prediados (predicate pushdown).<\/li>\n
              3. ORC suporta propriedades ACID.<\/li>\n
              4. ORC comprime melhor os dados.<\/li>\n<\/ol>\n

                \nO que mais ler sobre o assunto<\/strong>:<\/p>\n

                  \n
                1. An\u00e1lise de Big Data na nuvem: como as empresas se tornaram orientadas a dados<\/a><\/noindex>.<\/li>\n
                2. Um guia modesto sobre esquemas de bancos de dados<\/a><\/noindex>.<\/li>\n
                3. Nosso canal no Telegram sobre transforma\u00e7\u00e3o digital<\/a><\/noindex>. \n<\/li>\n<\/ol>\n

                  Fonte: 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\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\udd47Formatos de arquivos em big data: um breve guia | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/84416","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=84416"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84416\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/84417"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=84416"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=84416"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=84416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}