Le tunneling de données est le principal canal d'importation et d'exportation des données dans MaxCompute. Il inclut le Tunnel standard pour les opérations par lots et le Stream Tunnel pour les écritures en flux continu. Ces deux options sont disponibles avec des groupes de ressources partagés gratuits (à usage limité) et des groupes de ressources dédiés sur abonnement dans toutes les régions.
Utilisation
-
Commandes Tunnel
Exécutez les commandes Tunnel via le client MaxCompute (odpscmd) pour charger et télécharger des données. Cette méthode convient aux opérations manuelles ou aux workflows scriptés. Actuellement, seul odpscmd est pris en charge ; les autres outils clients ne sont pas encore disponibles.
-
Opérations par lots (Tunnel standard) :
Cette méthode permet le chargement et le téléchargement hors ligne de données par lots. Elle convient aux scénarios nécessitant le transfert de grands volumes de données en une seule fois, notamment le chargement et le téléchargement de données d'une table unique, ainsi que le téléchargement des résultats des instances de requête.
-
Opérations en flux continu (Stream Tunnel)
Cette approche écrit continuellement les données par micro-lots. Elle est adaptée aux scénarios exigeant une ingestion de données soutenue, tels que la collecte de journaux et l'ingestion de données en temps réel.
Limites du service de transmission de données
Limites des canaux de données par lots
-
Chargement de données par lots
Limites
Restrictions
Cycle de vie d'UploadSession
24 heures
Nombre de blocs écrits par UploadSession
20 000
Vitesse d'écriture par bloc
10 Mo/s
Volume de données par bloc
100 Go
Nombre d'UploadSessions créées par table
500 toutes les 5 minutes
Nombre de blocs écrits par table
500 toutes les 5 minutes
Nombre de validations d'UploadSession simultanées par table
32
Nombre de validations par table
75 toutes les 15 secondes
Nombre d'écritures de blocs simultanées
Limité par le nombre d'emplacements (slots) simultanés. Une écriture de bloc unique occupe un emplacement.
Écritures simultanées
MaxCompute garantit les écritures simultanées selon les propriétés ACID (atomicité, cohérence, isolation et durabilité). Pour plus d'informations sur la sémantique ACID, consultez Sémantique ACID.
-
Téléchargement de données par lots
Limites
Restrictions
Cycle de vie de DownloadSession
24 heures
Cycle de vie d'InstanceDownloadSession
24 heures, limité par la durée de vie de l'instance.
Nombre d'InstanceDownloadSessions créées par projet
200 toutes les 5 minutes
Nombre de DownloadSessions créées par table
200 toutes les 5 minutes
Vitesse par requête de téléchargement
10 Mo/s
Nombre de créations de DownloadSession simultanées
Limité par le nombre d'emplacements (slots) simultanés. La création d'une DownloadSession unique occupe un emplacement.
Nombre de créations d'InstanceDownloadSession simultanées
Limité par le nombre d'emplacements (slots) simultanés. La création d'une InstanceDownloadSession unique occupe un emplacement.
Nombre de requêtes de téléchargement simultanées
Limité par le nombre d'emplacements (slots) simultanés. Une requête de téléchargement de données unique occupe un emplacement.
-
Les données par lots prennent en charge la fonctionnalité upsert pour les tables Delta
Limites
Restrictions
Cycle de vie d'UpsertSession
24 heures
Vitesse d'écriture maximale pour une UpsertSession
Nombre de buckets dans la table ou la partition × 10 Mo/s.
Utilisation maximale du quota d'emplacements pour une UpsertSession
Nombre de buckets dans la table ou la partition.
Fréquence de validation d'UpsertSession
Vous ne pouvez valider les données vers chaque partition d'une table Delta qu'une seule fois par minute. Si l'intervalle de validation pour une partition est inférieur à 1 minute, le système renvoie le message d'erreur suivant :
ErrorCode=FlowExceeded, ErrorMessage=CommitUpsert QPS Quota exceeded.
Limites des canaux de données en flux continu
|
Limites |
Restrictions |
|
Vitesse d'écriture par emplacement |
10 Mo/s |
|
Nombre de partitions écrites simultanément par table |
64 |
|
Nombre maximal d'emplacements disponibles par partition |
32 |
|
Nombre de vidages (flushes) simultanés |
Limité par le nombre d'emplacements (slots) simultanés. Un vidage unique occupe un emplacement. |
Limites du chargement de données
-
La taille de chaque champ ne peut pas dépasser sa limite. Pour plus d'informations, consultez Versions des types de données.
La taille d'un champ STRING ne peut pas dépasser 8 Mo.
Lors d'un chargement, plusieurs enregistrements de données sont regroupés pour la transmission.
Limites réseau pour le service de transmission de données (groupes de ressources dédiés)
Seul l'accès VPC est pris en charge. L'accès par réseau public n'est pas pris en charge.
Seule la transmission de données au sein de la même région est prise en charge. La transmission de données interrégionale n'est pas prise en charge.
Les conditions réseau affectent considérablement les vitesses de chargement et de téléchargement du service de transmission de données. Les vitesses varient généralement entre 1 Mo/s et 20 Mo/s. Si la vitesse de chargement est trop lente, envisagez d'utiliser une méthode de chargement multithread.
Informations sur les groupes de ressources partagés du service de transmission de données
Le tableau suivant répertorie le nombre maximal d'emplacements (slots) disponibles par projet pour les ressources partagées gratuites dans différentes régions. Les valeurs sont exprimées en nombre d'emplacements.
|
Site |
Région |
Emplacements (nombre) |
|
Chine |
Chine (Hangzhou) |
300 |
|
Chine |
China East 1 Finance (Hangzhou) |
50 |
|
Chine |
Chine (Shanghai) |
600 |
|
Chine |
China East 2 Finance (Shanghai) |
50 |
|
Chine |
Chine (Pékin) |
300 |
|
Chine |
Chine (Pékin) Gov Cloud |
100 |
|
Chine |
Chine (Zhangjiakou) |
300 |
|
Chine |
Chine (Ulanqab) |
300 |
|
Chine |
Chine (Shenzhen) |
150 |
|
Chine |
China South 1 Finance (Shenzhen) |
50 |
|
Chine |
Chine (Chengdu) |
150 |
|
Chine |
Chine (Hong Kong) |
50 |
|
Asie-Pacifique |
Singapour (Singapour) |
100 |
|
Asie-Pacifique |
Malaisie (Kuala Lumpur) |
50 |
|
Asie-Pacifique |
Indonésie (Jakarta) |
50 |
|
Asie-Pacifique |
Japon (Tokyo) |
50 |
|
Europe et Amériques |
Allemagne (Francfort) |
50 |
|
Europe et Amériques |
États-Unis (Silicon Valley) |
100 |
|
Europe et Amériques |
États-Unis (Virginie) |
50 |
|
Europe et Amériques |
Royaume-Uni (Londres) |
50 |
|
Moyen-Orient et Inde |
Émirats arabes unis (Dubaï) |
50 |
Chaque opération du service de tunneling de données (telle que l'écriture d'un bloc, la création d'une session de téléchargement ou un vidage) occupe un emplacement. Lorsqu'une connexion reste inactive sans transfert de données pendant une période prolongée, le serveur la déconnecte automatiquement et libère l'emplacement occupé. Par conséquent, même si le nombre d'emplacements simultanés atteint la limite, les connexions inactives sont automatiquement récupérées après un certain délai sans intervention manuelle.
Codes d'état valides pour le service de transmission de données
|
Code d'état |
Nom du code d'état |
|
200 |
HTTP_OK |
|
201 |
HTTP_CREATED |
|
400 |
HTTP_BAD_REQUEST |
|
401 |
HTTP_UNAUTHORIZED |
|
403 |
HTTP_FORBIDDEN |
|
404 |
HTTP_NOT_FOUND |
|
405 |
HTTP_METHOD_NOT_ALLOWED |
|
409 |
HTTP_CONFLICT |
|
422 |
HTTP_UNPROCESSABLE_ENTITY |
|
429 |
HTTP_TOO_MANY_REQUESTS |
|
499 |
HTTP_CLIENT_CLOSED_REQUEST |
|
500 |
HTTP_INTERNAL_SERVER_ERROR |
|
502 |
HTTP_BAD_GATEWAY |
|
503 |
HTTP_SERVICE_UNAVAILABLE |
|
504 |
HTTP_GATEWAY_TIME_OUT |
-
Politique de nouvelle tentative pour les requêtes échouées
Après l'échec d'une requête, le client doit attendre un certain délai avant de réessayer.
Le temps d'attente pour les requêtes ayant échoué consécutivement doit augmenter de manière exponentielle, à partir d'un minimum de 1 seconde. Par exemple : 1 s, 2 s, 4 s, 8 s, 16 s, 32 s, etc.
-
Requêtes en double
L'URL est identique (URI et paramètres URI).
Les requêtes consécutives sont envoyées depuis la même adresse IP cliente.
-
Requêtes valides
Une requête qui renvoie un code d'état valide et respecte la politique de nouvelle tentative.
-
Requêtes non valides
Une requête qui renvoie un code d'état valide mais ne respecte pas la politique de nouvelle tentative.
RemarqueL'accord de niveau de service (SLA) ne couvre pas les requêtes non valides.
-
Requêtes d'attaque
Requêtes qui ne respectent pas la politique de nouvelle tentative pour les codes d'état de limitation 429 et 503.
Pour les requêtes d'attaque, le service isole l'adresse IP cliente, l'UID et le projet à l'origine de l'attaque. L'objet isolé ne peut plus accéder au service.
RemarqueLe SLA ne couvre pas les requêtes d'attaque.
FAQ
Quelles sont les causes courantes du ralentissement du service de transmission de données ?
En raison des limitations de l'architecture du service, le service MaxCompute Tunnel peut connaître une latence occasionnelle des requêtes dans les scénarios suivants. Par exemple, le temps nécessaire pour charger ou télécharger 10 Mo de données peut passer de quelques secondes à plusieurs minutes.
-
Épuisement des ressources partagées du service Tunnel (CPU ou bande passante réseau)
Durée : De quelques minutes à plusieurs heures.
Cela est inévitable en raison des limitations de l'architecture du service. Si vous avez besoin d'une grande stabilité, achetez une ressource Tunnel dédiée.
-
Instabilité du lien réseau entre le client et le service Tunnel (chargement ou téléchargement via réseau public)
Durée : Impossible à estimer.
La stabilité du réseau public ne peut pas être garantie. Si vous avez besoin d'une grande stabilité, utilisez le réseau interne Alibaba Cloud.
-
Épuisement des ressources du client (CPU ou bande passante réseau)
Durée : Impossible à estimer.
Évaluez les ressources physiques sur le client.
-
Logique inefficace du code client (par exemple, traitement de données de longue durée lors d'un chargement ou d'un téléchargement sur une connexion persistante)
Durée : Impossible à estimer.
Prenez en compte les performances de transmission des données lors de la conception du code.