Untitled - Syncsort

MAINFRAMES :
vaisseau mère des
Big Data
Comme chacun sait, les particuliers et les entreprises
génèrent chaque jour une quantité énorme de données :
2,5 milliards de trilliards d’octets pour être précis.1 Cela
signifie que 90 % des données mondiales d’aujourd’hui
n’ont été créées qu’au cours de ces deux dernières années.2
À l’ère des smartphones, de Facebook, de Twitter et
des formidables volumes de données (Big Data) qu’ils
engendrent, les mainframes (Big Iron) entrent rarement dans
le débat technologique. Pourtant, dans tous les secteurs
d’activité (finance, grande distribution, santé, assurances,
etc.), les plus grands groupes mondiaux génèrent encore la
majeure partie de leurs données via le mainframe. Pour ces
entreprises et de nombreuses autres, le mainframe est une
source vitale de Big Data qu’il est impossible d’ignorer.
Mainframes : source originelle des Big Data
En fait, les mainframes génèrent jusqu’à 80 % des données d’entreprises – de quoi faire figure de véritable vaisseau mère
des Big Data.3 Ils constituent également une source de données transactionnelles inestimables : tous les retraits aux
distributeurs automatiques jamais effectués, tous les vols réservés sur le système SABRE ont été traités sur mainframe.
Dans ces conditions, il va de soi que toute initiative d’analyse des Big Data devra prendre en compte les informations
générées sur ces grands systèmes. D’autant que ces informations y sont également souvent stockées. La mine de
données transactionnelles et autres qui résident sur les mainframes les rend tout simplement incontournables.
Ce guide vous explique comment relever les quatre plus grands défis de l’exploitation des données mainframe, et
comment offloader des charges batch coûteuses du mainframe vers la nouvelle plate-forme de choix pour l’analyse des
Big Data : Hadoop. Il vous aidera à identifier vos principales faiblesses en la matière et vous livrera des conseils avisés
pour concilier Big Iron et Big Data, avec à la clé une
évolutivité massive de vos données sur Hadoop.
LE MAINFRAME RESTE ROI
GÉNÉRALISATION
D’HADOOP :
LIBÉRER LES
INFORMATIONS
ENFOUIES DANS LES
DONNÉES MAINFRAME
Les premiers utilisateurs d’Hadoop — à savoir les sites
grand public comme Google, Facebook, Amazon et
Twitter — n’exploitaient aucun mainframe. Au cours
des dix prochaines années, à mesure que l’adoption
des technologies Big Data s’accélèrera dans les
grandes entreprises, les logiciels puissants offrant à
Hadoop un accès sécurisé aux vastes référentiels
de données mainframe joueront un rôle essentiel
dans l’exploitation des informations enfouies dans
toutes ces données.
•60 % de toutes les données
Internet sont stockées sur des
mainframes.4
•La plupart des mainframes
utilisent généralement 90 % de
la puissance CPU disponible. Ils
tolèrent des périodes prolongées
d’utilisation des CPU à 100 %,
grâce à la mise en attente et à
la priorisation des tâches sans
interruption des exécutions en
cours.5
•Le nombre de transactions traitées
quotidiennement sur IBM CICS est
supérieur au nombre de pages Web
servies.6
•La technologie mainframe
représente 25 % du chiffre
d’affaires d’IBM et plus de 40 %
de ses bénéfices.7
2
$
DIFFICULTÉS
D’ACCÈS AUX
BIG DATA
Les mainframes offrent une évolutivité et des performances
extrêmes – d’où leurs coûts. Des coûts qui vont bien
au-delà de l’achat de matériels. À l’exploitation, les
mainframes coûtent particulièrement cher en processeurs
et en stockage.
Examinons cela dans le détail.
Coûts processeurs
L’opportunité Hadoop
Contrairement aux autres plates-formes, les mainframes
sont facturés sur la base de la consommation CPU. Plus
vous utilisez votre mainframe, plus vous payez. Pour cela,
les mainframes se basent sur votre consommation en
MIPS (million d’instructions par seconde).8
Les coûts processeurs et de stockage constituent les
deux principales raisons pour lesquelles les entreprises
renoncent à l’analyse de leurs données mainframe. Les
architectures traditionnelles s’avèrent soit très coûteuses,
soit incapables d’effectuer des analyses intensives de
gros volumes de données.
Par exemple, une entreprise pesant 10 milliards de
dollars produira environ 3 700 MIPS sur sa plate-forme
principale.9 D’après le Gartner IT Key Metrics Data pour les
MIPS moyens et l’exploitation des serveurs physiques, le
coût annuel d’un MIPS s’élève à 4 445 $.10 Ainsi, un grand
groupe dépensera environ 16 millions de dollars par an, soit
presque 12 millions d’euros, rien que pour l’exploitation de
son mainframe. Ceci n’est qu’une estimation.
Coûts de stockage
Les mainframes utilisent des systèmes de stockage haute
capacité pour conserver de gros fichiers — les bases de
données peuvent facilement atteindre un téraoctet — et
y accéder extrêmement rapidement. Or, la performance
coûte cher. Les coûts de stockage mainframe peuvent ainsi
atteindre 100 000 $ par téraoctet. Dans de nombreux cas,
la sauvegarde de données mainframe s’effectue encore
sur des bandes, à l’aide de cartouches haute capacité qui
peuvent stocker jusqu’à 8,5 téraoctets de données non
compressées.
Hadoop propose une solution à ces deux problèmes en
migrant les données et certaines charges de traitement
— tri, filtre, copie, agrégation, etc. — du mainframe vers la
plate-forme Big Data. Cette rationalisation du stockage et
des processeurs coûteux permet aux entreprises de mieux
utiliser leurs capacités mainframe tout en garantissant un
meilleur respect des SLA et en réduisant significativement
leurs coûts.
Par conséquent, les entreprises sont très nombreuses à
adopter Hadoop pour intégrer leurs données mainframe
à leurs analyses Big Data. Hadoop leur propose, pour
la première fois, une approche capable de révéler tout
le potentiel des données mainframe de façon rapide,
évolutive et économique.
Grâce à Hadoop, vous associez désormais les
données transactionnelles détaillées des mainframes
aux données clickstream, journaux Web et autres
analyses des sentiments pour réaliser des analyses
autrefois impossibles. Le tout plus rapidement et plus
économiquement que jamais.
3
HADOOP :
l’essor des éléphants
Dès son lancement par Google sous forme de projet open source, Hadoop s’est rapidement imposé comme la plateforme de facto pour l’analyse des Big Data. Elle améliore les architectures de données existantes pour vous offrir deux
grands avantages :
•
Intégration facile et économique de très gros volumes de données mainframe dans les traitements et analyses Big
Data
•
Réduction des coûts grâce à l’offload des charges de traitement batch du mainframe vers
des plates-formes plus économiques
De nombreuses similitudes
Les traitements sur mainframe et sur Hadoop se rejoignent sur
de nombreux points.
•
Les deux plates-formes excellent dans le traitement batch,
avec une évolutivité et une fiabilité sans pareil.
•
Toutes deux dépendent fortement du tri. Dans le cas des
mainframes, jusqu’à 80 % des traitements batch impliquent
un tri. De la même façon, Hadoop a recours au tri des
données dans ses phases Map et Reduce.
•
Les deux plates-formes s’appuient sur un framework
fortement distribué pour traiter d’énormes volumes de
données.
Quelle est
l’ampleur de la
tâche Big Data ?
« Je cherche un moyen de
transférer les données de
11 000 opérations mainframe
quotidiennes vers mon data
warehouse, puis vers un cluster
Hadoop. »
— Directeur technique d’une
entreprise du Fortune 500
Combler le fossé (énorme)
entre Big Iron et Big Data
À l’évidence, il existe des différences entre Big Iron et Big Data.
L’offload des données mainframe et leur traitement dans Hadoop
n’est pas une mince affaire. Sans les bons outils, vous risquez de
freiner vos initiatives Big Data. Selon une étude récente, 44 %
des personnes interrogées considèrent le coût et les efforts
nécessaires à la transformation et au chargement des données
mainframe dans un data warehouse centralisé comme leur
problème nº1 de gestion des Big Data.11
Les programmeurs Hadoop ont donc besoin d’un moyen simple
d’accéder, de traduire et de migrer d’énormes volumes de
données mainframe vers les environnements Hadoop, et de les
rendre rapidement productives.
4
MAINFRAME ET HADOOP :
tous sur la même
longueur d’ondes
Pour de nombreuses entreprises, le meilleur moyen
de concilier le mainframe et Hadoop reste encore de
faire collaborer tout le monde dès le départ. Grâce à
une équipe transfonctionnelle composée d’adeptes
des deux plates-formes, vous pouvez clairement
définir les objectifs de votre projet, entendre les
inquiétudes des deux camps et vous épargner bien
des casse-tête. Vous avez donc toutes les raisons
de créer une équipe soudée de costume-cravate
(mainframe) et de baskets-sweatshirt (Hadoop).
Ce que vous devez savoir
Culturellement parlant, il ne fait aucun doute qu’un fossé
sépare les deux camps. Approches, préoccupations et
intérêts : ils divergent sur de nombreux points.
Pour les développeurs mainframe, les mots d’ordre sont
qualité, précision, fiabilité et sécurité. Rien de grave à
manquer un flux Twitter lorsque l’on sait que la disparition
d’une transaction financière peut vous coûter la prison. Du
côté des supporters d’Hadoop, l’utilisation et la disponibilité
immédiates priment. On met en production et on rentre à
la maison !
Ainsi, pour mener à bien un projet impliquant les deux
technologies, deux conditions s’appliquent :
•
•
Les adeptes d’Hadoop doivent comprendre le
fonctionnement des mainframes et les applications
qu’ils hébergent afin de mieux saisir les inquiétudes
des « costume-cravate » quant à la sécurité et aux
coûts.
Les inconditionnels du mainframe doivent pour leur
part cerner toutes les nouvelles possibilités d’Hadoop
en termes d’analyse et de sources de données.
Cette démarche leur permettra de comprendre
l’enthousiasme des « baskets-sweatshirt » pour l’agilité
de l’outil et sa connectivité étendue et sécurisée.
Syncsort : facteur de
cohésion des équipes
Heureusement, il existe des outils technologiques
qui vous permettent de rapprocher les deux
camps. En ce sens, Syncsort constitue un véritable
facteur de cohésion pour vos équipes. Syncsort
associe des décennies d’expertise mainframe
à des fonctionnalités Hadoop de pointe pour
vous offrir une approche simple et transparente
de l’exploitation de toutes vos données dans
Hadoop, y compris celles des mainframes.
Installées sur 50 % du parc Big Iron mondial, les
solutions Syncsort figurent parmi les logiciels
third-party les plus éprouvés sur mainframe.
Vous pouvez donc nous faire confiance. Nous
sommes également fortement implantés dans
la communauté Hadoop, comme en témoignent
nos contributions permanentes à l’évolution de
la plate-forme open source et les partenariats
étroits noués avec les principaux acteurs de cette
communauté.
5
ÉTAPE
1 :
résoudre les problèmes
d’intégration
Hadoop s’impose comme la plate-forme de choix pour l’analyse des Big Data.
Toutefois, elle n’offre pas de prise en charge native des mainframes.
Par conséquent, vous devez établir les connexions au mainframe par vous-même.
Une fois que vous y êtes parvenu, vos développeurs Java découvrent un tout
nouveau monde : traduction de données, copybooks COBOL, EBCDIC, « occurs
depending on », données décimales condensées, etc.
Impression vs. réalité
Malheureusement, le transfert de vos données mainframe
vers Hadoop s’avère bien plus complexe qu’il n’y paraît.
Vous pensez qu’il suffit de contacter l’équipe responsable
de la gestion de ces données, qui les chargera sur un
serveur FTP avant que les équipes Hadoop ne s’occupent
il arrive que les données clients se trouvent
dans une table et les commandes dans une
autre. Si vous le souhaitez, vous pouvez joindre
ces deux tables et agréger certaines de leurs
données en vue de bénéficier d’une meilleure
de les transférer vers HDFS ? Détrompez-vous !
vue d’ensemble. Vous devez ensuite copier les
données obtenues.
Vous êtes bien loin du compte. Le processus de migration
des données mainframe vers Hadoop suit un tout autre
scénario. Chaque fichier que vous souhaitez transférer
doit passer par les étapes suivantes :
1. Tout d’abord, vous devez identifier et sélectionner les
données à transférer. Cette tâche s’avère peu évidente
pour la plupart des développeurs Hadoop, élevés
aux interfaces graphiques. Les données mainframe
pourront se trouver dans plusieurs emplacements
(VSAM, bases de données, DB2 ou IMS), sous forme
de fichiers plats à longueur fixe ou variable. Il est donc
important de savoir comment accéder aux données.
2. Ensuite, vous devrez éventuellement prendre en
compte la compression SMS (Storage Management
Subsystem), qui se traduit en temps CPU.
3. Puis, vous aurez probablement besoin de préparer les
données. Cette préparation se divise elle-même en
deux parties :
•
•
Premièrement, vous filtrez les données pour en
extraire ce dont vous avez besoin. Par exemple,
il se peut que vous vouliez uniquement 50 % des
colonnes d’une table. Dans ce cas, vous devez
filtrer les colonnes souhaitées afin de réduire
votre consommation E/S.
Deuxièmement, vous effectuez un prétraitement
( jointures, tris, agrégations, etc.). Par exemple,
4. L’étape suivante consiste à traduire vos données.
Depuis toujours, le stockage sur mainframe s’est
avéré limité et coûteux. C’est pourquoi des formats
comme les décimales condensées ont vu le jour,
afin de stocker plus de données sur moins d’espace.
Par exemple, l’utilisation de données décimales
condensées pour le stockage de valeurs numériques
peut diviser par deux l’espace disque nécessaire sur
le mainframe. Bien que cette technique réduise les
besoins en stockage, elle ne permet pas de visualiser
les données et vous oblige à les convertir avant leur
chargement dans des cibles comme Hadoop.
5. Mais ce n’est pas tout. Afin de parfaitement comprendre
le sens des données, vous devrez vous familiariser
avec les copybooks COBOL. Sur le mainframe, les
métadonnées sont stockées dans des structures
obscures appelées copybooks COBOL, sortes de
plans complexes d’accès aux données sous-jacentes.
Les copybooks étant toujours conservés séparément
des données, il existe un risque de désynchronisation
entre données et métadonnées – si tant est que vous
parveniez à trouver les copybooks !
6. Une fois les données rationalisées au moyen du
copybook COBOL, vous pouvez enfin procéder au
transfert FTP et charger les fichiers dans Hadoop.
6
om
pres
s
filtrer/
reformater
io
n
Bases de
données, tables
et fichiers
déc
UN VÉRITABLE PARCOURS
DU COMBATTANT
sms
données
données
co
ré
gation
tr
i, joi
données
pie
sfer
an
r
tt
traduire/
comprendre :
t
nt
ure, ag
EBCDIC-ASCII et
copybooks COBOL
ftp
chargement
dans Hadoop
Attention aux autres embûches...
Aujourd’hui, l’extraction des données mainframe pour leur chargement dans Hadoop s’apparente à un véritable parcours
du combattant. Parmi les autres obstacles :
•
Consommation de temps CPU (augmentation des MIPS)
•
Problèmes de contrôle et gestion des données
•
Manque d’évolutivité pour respecter les fenêtres de traitement batch
•
Perturbation du fonctionnement du mainframe en production
En résumé, le temps, les coûts et les efforts nécessaires dissuadent de nombreuses entreprises d’utiliser les données
mainframe pour leurs analyses Big Data et autres.
7
QU’EST-CE QU’UN COPYBOOK COBOL ?
Dans le langage mainframe, un copybook correspond à une section de code écrite en COBOL
qu’il est possible de copier depuis un master et d’insérer dans différents programmes, ou en
différents endroits d’un même programme. Souvent, il sert à définir la structure physique des
données du programme, les morceaux de code procédural et les prototypes. Les copybooks
permettent de :
•
S’assurer que tout le monde utilise la même version d’une définition de la structure des
données ou d’un code procédural
•
Faciliter les références croisées là où les composants sont utilisés dans un système
•
Simplifier la modification des programmes en cas de besoin (une seule copie maître à
changer)
•
Réduire le besoin en codage des structures de données afin d’économiser du temps aux
programmeurs
Toutefois, pour des développeurs Hadoop peu aguerris à la programmation en COBOL pour
le mainframe, les copybooks peuvent s’avérer extrêmement déroutants.
-- extrait tiré de la page Wikipedia anglaise
Bonnes pratiques pour combler le fossé entre Big
Iron et Big Data
Toute solution destinée à accélérer l’accès, la traduction et le transfert des données mainframe dans Hadoop doit offrir
les fonctionnalités suivantes :
Connectivité
Chargement et traitement
•
•
Chargement direct dans HDFS
•
Offload des traitements batch
•
Transformations intégrées complètes pour une prise
en charge des flux de données et traitements batchs
complexes (p.ex. tri, agrégation, jointure, copie, filtre,
etc.), et bibliothèque de fonctions
•
Analyses complémentaires
Lecture des fichiers directement depuis le mainframe,
avec prise en charge des formats d’enregistrement
mainframe, y compris les formats fixe, variable,
variable avec descripteur de blocs et VSAM
•
Traduction des données à la volée, pour une
compréhension instantanée des données mainframe
lors de la conception des flux de données
•
Aucun logiciel nécessaire sur le mainframe
Traduction
•
Fonctions de transformation des données – décimales
condensées, EBCDIC/ASCII, enregistrements multiformats, etc. – sans codage
•
Prise en charge des copybooks COBOL
8
ÉTAPE
2 :
combler les écarts de compétences
Les compétences mainframe et Hadoop sont à la fois très rares
et très recherchées. Quant aux développeurs maîtrisant les
deux technologies, ils sont encore plus difficiles à trouver. Pour
prendre un peu de perspective, rappelons que la programmation
COBOL est apparue en 1959, tandis que la plate-forme Hadoop,
elle, n’a fait ses débuts que vers 2005, soit un grand écart de
plus de 40 ans !
C’est pourquoi les outils de transfert de données et de
développement de processus MapReduce imitant les opérations
batch du mainframe doivent requérir un minimum de formation
des collaborateurs déjà présents dans l’entreprise — et pas
uniquement les développeurs mainframe ou Hadoop ultraqualifiés. En effet, qu’il s’agisse de migrer les données vers
Hadoop pour des analyse Big Data ou pour l’offload de
traitements batchs, la plupart des départements informatiques
disposent de ressources très limitées dans ces deux domaines
de compétences.
Bonnes pratiques pour combler le fossé entre Big
Iron et Big Data
Comme nous l’avons souligné, rien que l’ingestion des données mainframe implique beaucoup de tâches et de codage
manuels. L’offload des données mainframes et des traitements batchs dans Hadoop obligent les entreprises à acquérir
un tout nouveau pool de compétences avancées en programmation. Or, ces compétences rares se paient cher. Dans ce
contexte, il est primordial de choisir un outil d’intégration de données complémentaire d’Hadoop et capable d’être utilisé
par toutes les compétences existantes dans votre entreprise.
Quelques bonnes pratiques :
•
Choisissez un outil doté d’une interface graphique qui permette aux développeurs Hadoop d’accéder, de traduire
et de charger des données mainframe dans HDFS sans intervention des programmeurs mainframe.
Les équipes IT ne devraient pas avoir à maîtriser Hive, Pig ou Java pour créer des processus MapReduce ; l’outil
devrait fournir des Mappers et Reducers clés en main. Cette fonctionnalité permet de réellement concilier le
mainframe et Hadoop en éliminant tout recours à la programmation COBOL, Hive, Pig ou encore Java.
•
Cherchez des outils intégrant des bibliothèques de modèles prédéfinis qui vous permettent d’offloader vos
données mainframe vers Hadoop et de répliquer facilement (dans Hadoop) les mêmes transformations de données
effectuées en COBOL et JCL sur le mainframe.
•
La réutilisabilité est essentielle ! Les fonctions de gestion des métadonnées en mode fichiers favorisent cette
réutilisation, pour un gain de productivité des développeurs et une simplification de la maintenance des systèmes.
•
Suivez visuellement les flux de données grâce aux métadonnées et à la traçabilité.
9
ÉTAPE
3 :
combler les failles
de sécurité
Les mainframes renferment certaines des données les
plus sensibles de l’entreprise. Dans les départements
informatiques, leur protection est prise très au sérieux.
Les dirigeants eux-mêmes sont conscients qu’en matière
de sécurité des données du mainframe, les entreprises
n’ont pas droit à l’erreur. Conclusion : si vous ne pouvez
garantir l’accès, le traitement et la diffusion sécurisés des
données, votre initiative Hadoop ne verra jamais le jour.
Mais ce n’est pas tout. Comme nous l’avons évoqué,
l’extraction des données du mainframe reste un processus
obscur, dans la mesure où il est impossible de connaître
la nature des données avant de les avoir récupérées. Bien
entendu, cette situation présente un important problème
de sécurité. L’extraction des données doit donc s’effectuer
de façon sécurisée afin de limiter l’accès aux seules
données autorisées, le tout via un dispositif de sécurité
qui s’intègre en toute transparence à l’environnement
mainframe.
On ne s’étonnera pas de voir les partisans du mainframe
s’alarmer face à la volonté de leurs homologues Hadoop
d’extraire des données du Big Iron.
Faiblesses de certains
outils
Certains outils d’extraction des données du mainframe
requièrent l’installation de logiciels non testés et non
éprouvés sur le mainframe. D’autres vous contraignent à
adopter leur propre modèle de sécurité et synchronisent
en permanence le vôtre avec le leur. Pour la plupart des
départements informatiques, aucune de ces approches ne
répond aux exigences.
Bonnes pratiques pour
combler le fossé entre
Big Iron et Big Data
Toute solution destinée à accélérer l’accès, la traduction et
le transfert des données mainframe vers Hadoop devrait
remplir plusieurs critères :
•
Rien à installer sur le mainframe
•
Prise en charge des protocoles Kerberos et LDAP
•
Extraction et chargement sécurisés des données
•
Exécution sécurisée des opérations
•
Sécurité au niveau des utilisateurs à l’aide d’un
protocole d’autorisation
Là encore, l’expérience et la confiance font toute la
différence. Votre solution de transfert des données
mainframe dans Hadoop devra reposer sur un logiciel
d’entreprise éprouvé, dont la réputation en matière de
sécurité n’est plus à faire.
Syncsort offre certains des logiciels
third-party les plus réputés et
éprouvés de la planète mainframe.
Aujourd’hui, Syncsort s’exécute sur 50 % de tous les mainframes. Si vous possédez un
mainframe, vous avez de grandes chances d’utiliser Syncsort. Sinon, pas de problème !
Grâce à DMX-h, vous pouvez exploiter toutes vos données sans installer de logiciel
supplémentaire sur votre mainframe — pas même un logiciel Syncsort.
10
ÉTAPE
4 :
réduire les écarts de coûts
Comme dans tous les projets informatiques et Big Data,
il existe bien évidemment un facteur coût. Les coûts de
gestion d’un téraoctet de données peuvent connaître des
variations importantes au sein d’une même entreprise :
•
Entre 20 000 $ et 100 000 $ par téraoctet dans un
environnement mainframe
•
Entre 15 000 $ et 80 000 $ par téraoctet dans un data
warehouse d’entreprise
•
Entre 250 $ et 2 000 $ par téraoctet dans Hadoop
Compte tenu des coûts très élevés des MIPS sur le
mainframe, la migration des données du Big Iron vers
Hadoop ne devrait entraîner aucune surconsommation
CPU mainframe pour le tri, le filtrage, la copie ou le
téléchargement. Sinon, à quoi bon économiser d’un côté
si c’est pour dépenser de l’autre ?
Bonnes pratiques pour combler le fossé entre Big
Iron et Big Data
Toute solution destinée à offloader les données mainframe et les charges de traitement vers Hadoop devrait vous
permettre de :
•
Réduire des coûts d’investissement (CapEx) et d’exploitation (OpEx) : votre entreprise devrait pouvoir réduire ses
CapEx et OpEx, d’abord en réduisant sa consommation CPU et E/S sur le mainframe, puis en optimisant l’efficacité
des ressources du cluster Hadoop. Ainsi, vous pourrez maximiser les débits par nœud du cluster et réduire les
besoins d’ajouter constamment de nouveaux nœuds.
•
Accélérer les processus MapReduce existants : votre solution devrait améliorer les performances et l’évolutivité
de votre traitement de données dans Hadoop. Dans l’idéal, les opérations MapReduce existantes devraient
également bénéficier de meilleures performances sans aucune modification. Ainsi, les opérations s’exécuteront
plus rapidement, augmentant la capacité du cluster à traiter davantage d’opérations dans la même fenêtre de
traitement.
•
Réduire les délais d’analyse : votre entreprise pourra accélérer et fiabiliser sa prise de décisions sur la base
d’analyses plus précises, grâce au traitement de volumes de Big Data plus importants dans des délais réduits et sur
les mêmes ressources.
11
SYNCSORT DMX-H :
plus rapide qu’un éléphant
à la charge
L’approche unique de Syncsort vous aide à libérer tout
le potentiel d’Hadoop au sein d’environnements Big
Data complexes. Elle favorise ainsi une adoption plus
large de la plate-forme dans toute l’entreprise. Grâce à
Syncsort DMX-h, votre entreprise peut capitaliser sur ses
compétences ETL existantes pour accélérer ses projets
Hadoop et traiter plus de données en moins de temps, tout
en réduisant ses coûts et sa consommation de ressources.
Offloadez vos données et
traitements mainframe
vers Hadoop !
Grands avantages de
Syncsort DMX-h
•
Réduction des coûts : bénéficiez d’une
connectivité directe entre Hadoop et
le mainframe, sans installer de logiciel
supplémentaire sur votre Big Iron. Offloadez
vos charges de traitement batch COBOL et
JCL vers Hadoop pour baisser vos coûts de
traitement mainframe (réduction de votre
consommation MIPS).
•
Évolutivité : offloadez vos données et vos
charges de traitement batch du mainframe
vers Hadoop et bénéficiez de l’évolutivité
massive inhérente à Hadoop.
Syncsort DMX-h offre une approche plus efficace de
l’exploitation de vos données mainframe et du transfert de
vos traitements batchs coûteux vers Hadoop :
•
Un seul et même outil pour connecter toutes vos
données à Hadoop
•
Connectivité zéro MIPS au mainframe
•
Intégration facile et traduction des données à la volée
•
Offload des traitements batch COBOL et JCL vers
Hadoop
•
Interface utilisateur graphique de développement,
test et dépannage des opérations MapReduce – sans
aucun codage
•
Performance : migrez vos données et
traitements mainframe vers Hadoop avec des
performances optimales par nœud.
•
Bibliothèque de modèles types adaptés aux principales
tâches ETL : jointures, change data capture (CDC),
agrégations de journaux Web, accès aux données
mainframe, etc.
•
Fiabilité : utilisez le logiciel third-party pour
mainframes le plus réputé du marché, doté de
technologies éprouvées qui vous garantissent
un résultat sans faute à tous les coups.
•
Fonctionnalités simplifiées de déploiement, suivi et
administration, y compris des fonctions complètes de
journalisation, ainsi qu’une intégration au JobTracker
d’Hadoop pour faciliter la consommation de journaux
•
Agilité : intégrez les données mainframe à
vos analyses Big Data pour permettre à votre
entreprise de fiabiliser et d’accélérer sa prise
de décisions.
•
Sécurité renforcée grâce à la prise en charge de
Kerberos et LDAP
•
Compétences : faites confiance à votre
équipe actuelle de développeurs Hadoop
pour développer de façon exponentielle les
capacités Big Data de votre entreprise.
12
ÉTUDE
DE CAS :
une grande banque américaine fait
décoller son projet Hadoop
Entreprise du S&P 500 dotée de 119 milliards de dollars d’actifs, ce grand établissement s’impose
comme le plus grand prestataire de services financiers complets des États-Unis. La banque
possède des clients dans 16 États et ses filiales lui assurent une présence sur le terrain via
environ 1 700 agences et plus de 2 000 distributeurs automatiques.
Dans l’impasse
Après une tentative de migration manuelle des données
mainframe vers Hadoop, l’équipe IT s’est trouvée au
pied du mur. Les développeurs venaient de passer des
mois à essayer de traiter par eux-mêmes les données
mainframe en Java. Ils avaient notamment consacré
plusieurs semaines à la lecture d’un copybook d’une
centaine de pages destiné à définir un seul fichier.
Hormis les nombreux copybooks longs et complexes, les
développeurs rencontraient d’autres difficultés :
•
•
Absence de logique applicative mainframe
correspondant au copybook et qui aurait permis de
trouver les erreurs de données
Dépendance de l’équipe Hadoop vis-à-vis de l’équipe
mainframe chargée de fournir les données
Syncsort leur facilite la
tâche
Syncsort DMX-h constituait le chaînon manquant
dont la banque avait besoin pour migrer ses données
mainframe dans Hadoop. Syncsort DMX-h a analysé
18 types d’enregistrements différents en toute simplicité,
en paramétrant graphiquement les règles « Redefine »
du copybook COBOL. Grâce à Syncsort DMX-h, l’équipe
Hadoop est parvenue à lire et convertir rapidement un
fichier à longueur variable et un fichier VSAM directement
depuis le mainframe, avant de les charger dans HDFS.
Temps total de développement avec Syncsort DMX-h :
moins de 4 heures pour les deux fichiers !
Autres avantages
•
Processus reposant sur de nombreuses tâches
manuelles mais très mal documenté
Grâce à Syncsort DMX-h, la banque a pu bénéficier
d’autres avantages importants :
•
Absence d’évolutivité de l’ensemble du projet, du fait
du manque d’experts maîtrisant à la fois Java et les
technologies mainframe
•
Plus de contrôle sur les délais de migration des
fichiers depuis le mainframe. Auparavant, l’équipe
Hadoop devait attendre que l’équipe mainframe
fournisse un fichier. Désormais, les experts Hadoop
peuvent extraire des fichiers en toute sécurité, chaque
fois qu’ils le souhaitent.
•
Malgré la réussite de son processus initial, la banque
a pensé qu’elle avait besoin d’une approche plus
pérenne, capable de s’étendre à l’ensemble de
son infrastructure informatique, tout en offrant une
meilleure documentation et en limitant l’écriture de
code et de scripts.
•
Les spécialistes mainframe qui ne maîtrisent pas Java
peuvent désormais créer des opérations de migration
pour les scénarios les plus complexes.
Au départ, la banque a passé des mois à créer du code
Java pour procéder à la migration. Elle est ainsi parvenue
à créer un programme destiné à traduire et à importer
80 % des fichiers mainframe et de bases de données.
Toutefois, face aux aspects les plus complexes de son
projet mainframe-Hadoop, le département informatique
s’est rendu compte qu’il ne pouvait gérer des fichiers
mainframe sans la logique applicative mainframe
correspondant à leur copybook.
La banque a alors fait appel à Syncsort.
« Nous devions valider de très longs copybooks et les mettre en correspondance avec les données. Parce
que nos copybooks sont volumineux et complexes (formats Redefines imbriqués, Occurs et Occurs Depending
On imbriqués), ils exigeaient un travail manuel long et fastidieux. Il n’a fallu que quelques minutes à Syncsort
DMX-h pour valider les copybooks et afficher les erreurs dans les données. »
— Chef de projet dans une grande banque américaine
13
Optez dès aujourd’hui pour
Syncsort DMX-h
Syncsort DMX-h fait de l’analyse des Big Data une réalité dans votre
entreprise. Non seulement la solution permet à votre département
informatique de traiter d’énormes volumes de données dans Hadoop,
mais elle constitue également un facteur de cohésion entre vos équipes
mainframes et Hadoop qui contribueront chacune efficacement à vos
initiatives stratégiques.
Pour une évolutivité massive de vos données
sur Hadoop, testez Syncsort DMX-h par vousmême !
Ou essayez Syncsort Ironcluster™ pour Amazon EMR !
Solution Hadoop ETL pour Amazon EMR, Syncsort Ironcluster vous offre tous les avantages
de DMX-h, avec en prime l’ergonomie et l’évolutivité uniques du Cloud Amazon.
Cet eBook vous a été
utile ? Faites-le
découvrir à d’autres !
Pour les entreprises appelées à gérer un flux constant de Big Data, Syncsort offre
une méthode plus intelligente de collecte et de traitement de volumes de données
en pleine explosion. Avec des milliers de déploiements à son actif sur les plus
grandes plates-formes, notamment les mainframes, Syncsort aide ses clients du
monde entier à repousser les limites architecturales des environnements Hadoop
et d’intégration de données pour obtenir de meilleurs résultats, plus rapidement,
avec moins de ressources et un TCO en baisse. Pour en savoir plus, rendez-vous sur
www.syncsort.fr.
NOTES :
Data Storage in the Era of Big Data, ViaWest, 31 janvier 2012
Source : IBM, cité dans Improving Decision Making in the World of Big Data, Christopher Frank, Forbes.com, 25 mars 2012
3
Encryption Meets the Mainframe, Gordon Rapkin, IBM Systems Magazine, septembre 2006
4
En 2005. Source : Introduction to the new mainframe: z/OS basics, IBM
5
Source : www.mainframesvilla.blogspot.com
6
Ibid.
7
Estimation de l’analyste A. M. Sacconaghi pour Sanford C. Bernstein, tel que cité dans I.B.M. Mainframe Evolves to Serve the Digital World, Steve
Lohr, The New York Times, 28 août 2012
8
Le nombre de MIPS (million d’instructions par seconde) est une mesure générale de la puissance de calcul et, partant, de la quantité d’opérations
qu’un plus gros ordinateur peut traiter. Sur les grands serveurs et mainframes, le MIPS permet de mesurer le coût du calcul : pour un montant donné,
plus le nombre de MIPS est élevé, plus le système est rentable.
9
Economics of Computing - The internal combustion Mainframe, Dr. Howard Rubin.
10
2010
11
Source : Mainframe Role in Big Data Strategy 2013, BMC Software.
12
Lorsque vous souhaitez récupérer au moins 80 % des données, il est éventuellement préférable de simplement toutes les transférer. Votre
consommation d’E/S sera certes plus élevée, mais vous économiserez sur la consommation CPU puisque vous ne filtrerez rien. Au final, il s’agit d’un
compromis entre SLA et coûts, car le filtrage sur le mainframe consomme plus de MIPS.
1
2
© 2014 Syncsort Incorporated. Tous droits réservés. Tous les noms de produits et marques cités appartiennent à leurs propriétaires respectifs.
DMXH-EB-002-1113FR