{"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\/fr\/blog\/administrirovanie\/formaty-fajlov-v-bolshih-dannyh-kratkij-likbez","title":{"rendered":"Formats de fichiers dans les grandes donn\u00e9es : un bref aper\u00e7u","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Formats
\nDivinit\u00e9 de la m\u00e9t\u00e9o par Remarin<\/i><\/a><\/noindex> <\/p>\n

Commande Mail.ru Cloud Solutions<\/a><\/noindex> propose de ses auteurs.<\/a><\/noindex> L'ing\u00e9nieur Rahul Bhatia de Clairvoyant discute des formats de fichiers dans les grandes donn\u00e9es, des fonctions les plus courantes des formats Hadoop et du format \u00e0 utiliser.
\n<\/a><\/noindex><\/p>\n

Pourquoi diff\u00e9rents formats de fichiers sont n\u00e9cessaires<\/h2>\n

\nUn goulot d'\u00e9tranglement significatif dans la performance des applications supportant HDFS, comme MapReduce et Spark, est le temps de recherche, de lecture et d'\u00e9criture des donn\u00e9es. Ces probl\u00e8mes sont amplifi\u00e9s par les difficult\u00e9s de gestion de grands ensembles de donn\u00e9es, surtout si nous n'avons pas un sch\u00e9ma fixe, mais plut\u00f4t un sch\u00e9ma \u00e9volutif ou s'il y a des limitations au stockage.<\/p>\n

Le traitement des grandes donn\u00e9es augmente la charge sur le sous-syst\u00e8me de stockage \u2014 Hadoop stocke les donn\u00e9es de fa\u00e7on redondante pour atteindre la tol\u00e9rance aux pannes. En plus des disques, le processeur, le r\u00e9seau, le syst\u00e8me d'entr\u00e9e-sortie, etc., subissent \u00e9galement une charge \u00e9lev\u00e9e. \u00c0 mesure que le volume des donn\u00e9es augmente, le co\u00fbt de leur traitement et stockage augmente \u00e9galement.<\/p>\n

Diff\u00e9rents formats de fichiers dans Hadoop<\/a><\/noindex> ont \u00e9t\u00e9 con\u00e7us pour r\u00e9soudre pr\u00e9cis\u00e9ment ces probl\u00e8mes. Le choix du bon format de fichier peut offrir des avantages substantiels :<\/p>\n

    \n
  1. Temps de lecture plus rapide.<\/li>\n
  2. Temps d'\u00e9criture plus rapide.<\/li>\n
  3. Fichiers partageables.<\/li>\n
  4. Support de l'\u00e9volution des sch\u00e9mas.<\/li>\n
  5. Support avanc\u00e9 de la compression.<\/li>\n<\/ol>\n

    \nCertains formats de fichiers sont destin\u00e9s \u00e0 un usage g\u00e9n\u00e9ral, d'autres \u00e0 des cas d'utilisation plus sp\u00e9cifiques, et certains sont d\u00e9velopp\u00e9s en tenant compte de caract\u00e9ristiques particuli\u00e8res des donn\u00e9es. Ainsi, le choix est en effet assez vaste.<\/p>\n

    Format de fichier Avro<\/h2>\n

    \nPour de s\u00e9rialisation de donn\u00e9es <\/i>utilise largement Avro \u2014 c'est un format de stockage de donn\u00e9es bas\u00e9 sur des lignes<\/i>, c'est-\u00e0-dire textuel, dans Hadoop. Il stocke le sch\u00e9ma au format JSON, facilitant sa lecture et son interpr\u00e9tation par n'importe quel programme. Les donn\u00e9es elles-m\u00eames sont enregistr\u00e9es dans un format binaire, compact et efficace.<\/p>\n

    Le syst\u00e8me de s\u00e9rialisation Avro est neutre par rapport aux langages. Les fichiers peuvent \u00eatre trait\u00e9s par diff\u00e9rents langages, notamment C, C++, C#, Java, Python et Ruby.<\/p>\n

    Une caract\u00e9ristique cl\u00e9 d'Avro est son support robuste des sch\u00e9mas de donn\u00e9es qui \u00e9voluent avec le temps, c'est-\u00e0-dire qui subissent des changements. Avro comprend les modifications de sch\u00e9ma \u2014 suppression, ajout ou modification de champs.<\/p>\n

    Avro prend en charge une vari\u00e9t\u00e9 de structures de donn\u00e9es. Par exemple, il est possible de cr\u00e9er un enregistrement contenant un tableau, un type \u00e9num\u00e9r\u00e9 et un sous-enregistrement.<\/p>\n

    \"Formats
    \nCe format est id\u00e9al pour l'\u00e9criture dans une zone de transition du data lake (lac de donn\u00e9es) (    lac de donn\u00e9es<\/a><\/noindex>, ou data lake \u2014 une collection d'instances pour stocker diff\u00e9rents types de donn\u00e9es en compl\u00e9ment des sources de donn\u00e9es elles-m\u00eames). <\/p>\n

    Ainsi, pour l'\u00e9criture dans la zone d'atterrissage du lac de donn\u00e9es, ce format convient le mieux pour les raisons suivantes :<\/p>\n

      \n
    1. Les donn\u00e9es de cette zone sont g\u00e9n\u00e9ralement lues dans leur int\u00e9gralit\u00e9 pour un traitement ult\u00e9rieur par les syst\u00e8mes en aval \u2014 et le format bas\u00e9 sur les lignes est dans ce cas plus efficace.<\/li>\n
    2. Les syst\u00e8mes en aval peuvent facilement extraire les sch\u00e9mas des tables \u00e0 partir des fichiers \u2014 il n'est pas n\u00e9cessaire de stocker les sch\u00e9mas s\u00e9par\u00e9ment dans un m\u00e9ta-stockage externe.<\/li>\n
    3. Tout changement dans le sch\u00e9ma source est facilement g\u00e9r\u00e9 (\u00e9volution du sch\u00e9ma).<\/li>\n<\/ol>\n

      <\/p>\n

      Format de fichiers Parquet<\/h2>\n

      \nParquet est un format de fichier open source pour Hadoop, qui stocke des structures de donn\u00e9es imbriqu\u00e9es au format colonne plat.<\/i>.<\/p>\n

      Compar\u00e9 \u00e0 l'approche traditionnelle bas\u00e9e sur les lignes, Parquet est plus efficace en termes de stockage et de performance.<\/p>\n

      Cela est particuli\u00e8rement utile pour les requ\u00eates qui lisent certaines colonnes d'une table large (avec de nombreuses colonnes). Gr\u00e2ce au format de fichiers, seules les colonnes n\u00e9cessaires sont lues, minimisant ainsi les entr\u00e9es\/sorties.<\/p>\n

      Une petite digression-explication<\/strong>: pour mieux comprendre le format de fichier Parquet dans Hadoop, examinons ce qu'est un format bas\u00e9 sur les colonnes \u2014 c'est-\u00e0-dire en colonnes. Dans ce format, des valeurs homog\u00e8nes de chaque colonne sont stock\u00e9es ensemble. <\/p>\n

      Par exemple<\/a><\/noindex>, l'enregistrement comprend les champs ID, Name et Department. Dans ce cas, toutes les valeurs de la colonne ID seront stock\u00e9es ensemble, tout comme les valeurs de la colonne Name, et ainsi de suite. La table aura un aspect approximatif :<\/p>\n

      ID<\/strong>
      \nNom<\/strong>
      \nDepartment<\/strong><\/p>\n

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

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

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

      \nDans le format ligne, les donn\u00e9es seraient enregistr\u00e9es comme suit :<\/p>\n

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

      \nDans le format de fichiers en colonne, les m\u00eames donn\u00e9es seraient enregistr\u00e9es ainsi :<\/p>\n

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

      \nLe format en colonnes est plus efficace lorsque vous devez interroger plusieurs colonnes d'une table. Il ne lira que les colonnes n\u00e9cessaires, car elles sont adjacentes. Ainsi, les op\u00e9rations d'entr\u00e9e\/sortie sont minimis\u00e9es.<\/p>\n

      Par exemple, vous n'avez besoin que de la colonne NAME. Dans le format ligne<\/a><\/noindex> , chaque enregistrement dans l'ensemble de donn\u00e9es doit \u00eatre charg\u00e9, analys\u00e9 par champs, puis les donn\u00e9es NAME extraites. Le format en colonnes permet d'acc\u00e9der directement \u00e0 la colonne Name, car toutes les valeurs pour cette colonne sont stock\u00e9es ensemble. Il n'est pas n\u00e9cessaire de balayer tout l'enregistrement.<\/p>\n

      Ainsi, le format colonne am\u00e9liore les performances des requ\u00eates, car il n\u00e9cessite moins de temps de recherche pour acc\u00e9der aux colonnes requises et r\u00e9duit le nombre d'op\u00e9rations d'entr\u00e9e-sortie, en ne lisant que les colonnes n\u00e9cessaires.<\/p>\n

      Une des caract\u00e9ristiques uniques Parquet<\/a><\/noindex> est qu'il peut stocker des donn\u00e9es avec des structures imbriqu\u00e9es<\/i>. Cela signifie que dans un fichier Parquet, m\u00eame les champs imbriqu\u00e9s peuvent \u00eatre lus s\u00e9par\u00e9ment sans avoir besoin de lire tous les champs dans la structure imbriqu\u00e9e. Pour le stockage de structures imbriqu\u00e9es, Parquet utilise un algorithme de d\u00e9chiquetage et d'assemblage.<\/p>\n

      \"Formats
      \nPour comprendre le format de fichier Parquet dans Hadoop, il est n\u00e9cessaire de conna\u00eetre les termes suivants :<\/p>\n

        \n
      1. Groupe de lignes<\/strong> (row group) : une division logique horizontale des donn\u00e9es en lignes. Un groupe de lignes se compose d'un fragment de chaque colonne dans un ensemble de donn\u00e9es.<\/li>\n
      2. Fragment de colonne<\/strong> (column chunk) : un fragment d'une colonne sp\u00e9cifique. Ces fragments de colonnes r\u00e9sident dans un groupe de lignes donn\u00e9 et seront toujours contigus dans le fichier.<\/li>\n
      3. Page<\/strong> (page) : les fragments de colonnes sont divis\u00e9s en pages, enregistr\u00e9es cons\u00e9cutivement. Les pages ont un en-t\u00eate commun, ce qui permet de sauter les lectures non n\u00e9cessaires.<\/li>\n<\/ol>\n

        \n\"Formats
        \nIci, l'en-t\u00eate contient simplement un nombre magique PAR1<\/i> (4 octets), qui identifie le fichier comme un fichier au format Parquet.<\/p>\n

        Dans le pied de page, il est \u00e9crit :<\/p>\n

          \n
        1. M\u00e9tadonn\u00e9es du fichier, qui contiennent les coordonn\u00e9es de d\u00e9marrage des m\u00e9tadonn\u00e9es de chaque colonne. Lors de la lecture, il est d'abord n\u00e9cessaire de lire les m\u00e9tadonn\u00e9es du fichier pour trouver tous les fragments de colonnes d'int\u00e9r\u00eat. Ensuite, les fragments de colonnes doivent \u00eatre lus de mani\u00e8re s\u00e9quentielle. Les m\u00e9tadonn\u00e9es incluent \u00e9galement la version du format, le sch\u00e9ma et d'\u00e9ventuelles paires cl\u00e9-valeur suppl\u00e9mentaires.<\/li>\n
        2. Longueur des m\u00e9tadonn\u00e9es (4 octets).<\/li>\n
        3. Nombre magique PAR1<\/i> (4 octets).<\/li>\n<\/ol>\n

          <\/p>\n

          Le format de fichiers ORC<\/h2>\n

          \nFormat de fichiers optimis\u00e9 en ligne-colonne<\/i> (Optimized Row Columnar, ORC<\/a><\/noindex>) propose un moyen tr\u00e8s efficace de stocker des donn\u00e9es et a \u00e9t\u00e9 con\u00e7u pour surmonter les limitations des autres formats. Il stocke les donn\u00e9es de mani\u00e8re parfaitement compacte, permettant de sauter les d\u00e9tails non n\u00e9cessaires - tout en ne n\u00e9cessitant pas de construire de grands index complexes ou maintenus manuellement. <\/p>\n

          Les avantages du format ORC :<\/p>\n

            \n
          1. Un fichier \u00e0 la sortie de chaque t\u00e2che, ce qui r\u00e9duit la charge sur le NameNode.<\/li>\n
          2. Support des types de donn\u00e9es Hive, y compris DateTime, les types d\u00e9cimaux et les types de donn\u00e9es complexes (struct, list, map et union).<\/li>\n
          3. Lecture simultan\u00e9e d'un m\u00eame fichier par diff\u00e9rents processus RecordReader.<\/li>\n
          4. Possibilit\u00e9 de diviser les fichiers sans scanner \u00e0 la recherche de marqueurs.<\/li>\n
          5. Estimation de l'allocation maximale possible de la m\u00e9moire heap pour les processus de lecture\/\u00e9criture en fonction des informations dans le pied de page du fichier.<\/li>\n
          6. Les m\u00e9tadonn\u00e9es sont stock\u00e9es dans un format binaire de s\u00e9rialisation Protocol Buffers, qui permet d'ajouter et de supprimer des champs.<\/li>\n<\/ol>\n

            \n\"Formats
            \nORC stocke des collections de lignes dans un seul fichier, et au sein de la collection, les donn\u00e9es de ligne sont stock\u00e9es au format colonne.<\/p>\n

            Le fichier ORC stocke des groupes de lignes appel\u00e9s bandes (stripes) ainsi que des informations compl\u00e9mentaires dans le pied de page du fichier. Le post-scriptum \u00e0 la fin du fichier contient les param\u00e8tres de compression et la taille du pied de page compress\u00e9.<\/p>\n

            Par d\u00e9faut, la taille d'une bande est de 250 Mo. Gr\u00e2ce \u00e0 des bandes de cette taille, la lecture depuis HDFS est effectu\u00e9e de mani\u00e8re plus efficace : en grands blocs continus.<\/p>\n

            Le pied de page du fichier contient une liste des bandes dans le fichier, le nombre de lignes par bande et le type de donn\u00e9es de chaque colonne. Il y a \u00e9galement la valeur r\u00e9sultante de count, min, max et sum pour chaque colonne.<\/p>\n

            Le pied de page de la bande contient un r\u00e9pertoire des emplacements de flux.<\/p>\n

            Les donn\u00e9es de ligne sont utilis\u00e9es lors de la recherche dans les tables.<\/p>\n

            Les donn\u00e9es d'index incluent les valeurs minimales et maximales pour chaque colonne et les positions des lignes dans chaque colonne. Les index ORC sont utilis\u00e9s uniquement pour s\u00e9lectionner des bandes et des groupes de lignes, et non pour r\u00e9pondre aux requ\u00eates.<\/p>\n

            Comparaison des diff\u00e9rents formats de fichiers<\/h2>\n

            <\/p>\n

            Avro par rapport \u00e0 Parquet<\/h3>\n

            <\/p>\n

              \n
            1. Avro est un format de stockage en ligne, tandis que Parquet stocke les donn\u00e9es au format colonne.<\/li>\n
            2. Parquet est mieux adapt\u00e9 aux requ\u00eates analytiques, c'est-\u00e0-dire que les op\u00e9rations de lecture et de requ\u00eate de donn\u00e9es sont beaucoup plus efficaces que l'\u00e9criture.<\/li>\n
            3. Les op\u00e9rations d'\u00e9criture dans Avro sont plus efficaces que dans Parquet.<\/li>\n
            4. Avro g\u00e8re plus m\u00fbrement l'\u00e9volution des sch\u00e9mas. Parquet ne prend en charge que l'ajout de sch\u00e9mas, tandis qu'Avro met en \u0153uvre une \u00e9volution multifonctionnelle, c'est-\u00e0-dire l'ajout ou la modification de colonnes.<\/li>\n
            5. Parquet est id\u00e9al pour interroger un sous-ensemble de colonnes dans une table \u00e0 plusieurs colonnes. Avro convient aux op\u00e9rations ETL o\u00f9 nous interrogeons toutes les colonnes.<\/li>\n<\/ol>\n

              <\/p>\n

              ORC par rapport \u00e0 Parquet<\/h3>\n

              <\/p>\n

                \n
              1. Parquet stocke mieux les donn\u00e9es imbriqu\u00e9es.<\/li>\n
              2. ORC est mieux adapt\u00e9 \u00e0 la pouss\u00e9e de pr\u00e9dicats (predicate pushdown).<\/li>\n
              3. ORC prend en charge les propri\u00e9t\u00e9s ACID.<\/li>\n
              4. ORC comprime mieux les donn\u00e9es.<\/li>\n<\/ol>\n

                \nSuggestions de lecture suppl\u00e9mentaires<\/strong>:<\/p>\n

                  \n
                1. Analyse des Big Data dans le cloud : comment les entreprises peuvent devenir ax\u00e9es sur les donn\u00e9es.<\/a><\/noindex>.<\/li>\n
                2. Guide humble sur les sch\u00e9mas de bases de donn\u00e9es.<\/a><\/noindex>.<\/li>\n
                3. Notre cha\u00eene Telegram sur la transformation num\u00e9rique.<\/a><\/noindex>. \n<\/li>\n<\/ol>\n

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