ODBC : qu’est-ce que c’est et comment l’utilise-t-on ?

Nous savons tous que nous sommes dans l’ère du Big Data en ce moment. En effet, tout le monde en parle et essaie d’intégrer cette notion au sein de leur business. Il existe plusieurs moyens de collecter les données. De même, il existe également plusieurs façons de le stocker. Mais lorsque l’on souhaite les synthétiser, il faut un outil tel qu’ODBC ou JDBC si l’on utilise Java.

La collecte, le traitement et la consommation de données à des fins décisionnelles sont au cœur de tous. En effet, vu l’augmentation monstrueuse du volume de données survenu depuis ces dernières décennies, on ne peut plus négliger les opportunités qu’offrent ces dernières. Comme nous l’avons mentionné dans notre chronique sur la définition du Big Data, ce terme est plus profond que ce que l’on croit. En effet, au-delà du fait que c’est un ensemble de technique et d’outils technologiques de traitement de données massives, c’est également un moyen révolutionnaire pour mieux aborder les défis auxquels fait face chaque secteur d’activité.

Mais avant de pouvoir aborder ces défis de manière plus efficace à l’aide du Big Data, il faut traiter les données issues de celui-ci. Cela passe par le fait de pouvoir réunir les informations que l’on a à disposition. Dans cet article, nous allons voir ce qu’est l’ODBC et comment on l’utilise.

ODBC : C’est quoi ?

Open Data base Connectivity (ODBC) est un protocole qui crée un réseau d’échange d’information entre différentes applications informatiques. Cet échange s’effectue par un processus unique dans le but de manipuler les bases de données fournies par les systèmes de gestion de base de données (SGBD). On retrouve plusieurs SGBD et chacun possède son mode de fonctionnement.

Il existe plusieurs types de bases de données tels que Microsoft Access, Filemaker et MySQL. Il est donc nécessaire d’avoir un moyen standard de transférer les données entre ces différents types de bases de données. C’est au vu de cela que Microsoft a créé en 1992 la norme ODBC. 

Une application compatible avec ODBC peut accéder à toutes les informations d’une base de données qui prend en charge ODBC, peu importe le SGBD utilisé.

Quelle est sa fonctionnalité ?

Dans l’ordinateur de l’utilisateur, l’ODBC comporte un registre de source de données. Grâce à l’interface graphique, l’utilisateur peut ajouter une base de données au registre.

Les applications informatiques de l’utilisateur, quant à elles, manipulent les différentes données présentes dans le registre grâce à l’interface de programmation.

Chaque système de gestion de base de données possède un pilote informatique. Il permet la manipulation de données en utilisant l’interface de programmation propre au système de gestion de base de données.

ODBC est une particularité pour une API de base de données. L’API ne dépend d’aucun système de gestion de base de données (SGBD) ou d’un système d’exploitation.

Les développeurs de pilote de chaque système de gestion de base de données (SGBD) ont implémenté les fonctions de l’API ODBC.  C’est grâce à ces fonctions que les applications accèdent aux données d’un SGBD. Le gestionnaire de pilote s’assure de la communication entre les applications et les pilotes. 

Pour quelle raison ODBC est-il créé ?

Au début, toutes les entreprises utilisaient un seul SGBD. Donc, les accès à la base de données ont été possibles via l’interface graphique du système ou via des applications créées spécialement pour fonctionner avec le système de gestion de base de base de données.

Mais au fil du temps, les entreprises commencent à acquérir différents SGBD. Cela est causé par l’augmentation du nombre d’ordinateurs. De ce fait, de plus en plus d’applications informatiques et des logiciels sont disponibles.

Ce qui a favorisé cette expansion est l’apparition de nouveaux matériels plus rapides et moins chers. Aussi, dans la période des années 80, l’utilisation des SGBDR a commencé à se généraliser.

Cette expansion a pris plus d’ampleur avec la venue des ordinateurs personnels, qui ont favorisé l’usage des bases de données.

Avec l’usage généralisé des SGBDR, une entreprise pouvait avoir plusieurs données réparties sur différents postes de travail, de serveur et des ordinateurs portables. Toutes ces différentes données sont stockées dans des bases de données différentes étaient incompatibles entre elles et accessibles par beaucoup d’outils différents.

L’un des grands défis est l’avènement informatique client-serveur. Beaucoup d’ordinateurs personnels ont été déployés sur les bureaux. Ce qui donne à la fois une interface graphique pour les données et d’autres outils nécessaires comme des feuilles de calcul et des générateurs de rapport. 

Chaque ordinateur portable et serveur héberge un SGBDR et grâce à leur puissance de calcul et leur emplacement, ils fournissent un accès aux données rapide et coordonnée.

Mais comment se passe la connexion de logiciel front-end à la base de données back-end ?

Les éditeurs de logiciels indépendants ont été confrontés à un problème semblable. Les développeurs de logiciel pour ordinateur personnel devaient créer des méthodes d’accès aux données pour chaque SGBD. 

Ce qui signifie qu’une grande quantité de ressources étaient réservées pour le développement et la maintenance des méthodes d’accès aux données. La capacité des applications à accéder aux données dans n’importe quel SGBD favorise la vente de cette dernière. 

Tous ceux dont les développeurs souhaitaient avoir c’était un moyen d’accès aux données dans tous les différents types de SGBD. 

Les ordinateurs centraux (serveurs) et les mini-ordinateurs ont besoin d’une méthode pour pouvoir fusionner les données de différents SGBD dans une seule application. Et les groupes d’ordinateurs personnels voulaient en plus de cela, une méthode pour pouvoir créer une application indépendante de tout SGBD.  En bref, les deux groupes voulaient un moyen interopérable d’accéder aux données. Ils avaient besoin d’une connectivité de base de données ouverte.

Architecture du pilote ODBC

Pilote basé sur des fichiers

Le pilote se comporte à la fois comme pilote et source de données lorsqu’il réussit à avoir un accès direct aux données physiques. Il gère à la fois les appels ODBC et les instructions SQL. Les développeurs de ce pilote sont contraints de créer leurs propres moteurs de base de données.

Pilote basé sur un SGBD

Lorsqu’on accède aux données physiques grâce à un moteur de base de données distinct, le pilote analyse uniquement les données ODBC. Les instructions SQL sont plutôt traitées par le moteur de base de données.

Architecture de réseau

Les configurations de fichier et de SGBD ODBC peuvent exister sur un même réseau.

Autre architecture de pilote

Le pilote se comporte comme un middleware lorsqu’il est utilisé pour différentes sources de données. Lorsque le pilote est installé sur un serveur, plusieurs clients peuvent le partager. 

L’utilité de l’ODBC

La grande question est : comment ODBC arrive-t-il à standardiser les accès aux bases de données ? Deux exigences architecturales se posent :

• Les applications doivent avoir accès à plusieurs SGBD grâce au même code source, et cela sans recompilation et sans reconnexion.
• Les applications doivent avoir la capacité d’accéder à plusieurs SGBD en même temps.

En plus de cela, la réalité du marché amène à pose une autre question :

• ODBC doit-il exposer quelle fonctionnalité du SGBD ? Seulement les fonctionnalités identiques à tous les SGBD ou toute fonctionnalité disponible dans n’importe quel SGBD ?

Voici comment ODBC procède pour résoudre tous ces problèmes :

ODBC est une interface au niveau de l’appel

ODBC définit une CLI standard dans l’objectif de résoudre le problème d’accès des applications à plusieurs SGBD en utilisant l’unique code source. Celui-ci comporte toutes les fonctions de spécialisation de CLI d’Open Group et ISO/IEC et donne en plus quelques fonctions fréquemment utilisées par les applications.

Chaque SGBD prenant en compte ODBC dispose d’une bibliothèque ou d’un pilote différent. Le pilote charge les fonctions dans l’API ODBC. Donc, pour utiliser un autre pilote, on n’a pas besoin de recompiler l’application. Elle charge simplement le nouveau pilote et fait appel aux fonctions que ce pilote comporte.

Pour un accès simultané à plusieurs SGBD, l’application charge plusieurs pilotes. Chaque système d’exploitation à son mode de prise en charge de pilote.  Comme exemple, sur le système d’exploitation Microsoft® Windows®, les pilotes sont des bibliothèques de liens dynamiques (DLL).

ODBC définit une grammaire standard

En plus d’une CLI standard, ODBC définit une syntaxe SQL standard. Cette syntaxe est principalement basée sur la spécification Open Group SQL CAE. La CLI et le SQL standard ont une petite différence. Cela réside au niveau des différences entre la syntaxe SQL requise par Embedded SQL (Open Group) et une CLI (ODBC).

Les applications ont la possibilité de soumettre des instructions grâce à une syntaxe spécifique à ODBC ou au SGBD. Si dans une instruction, la syntaxe ODBC diffère de la syntaxe du SGBD, le pilote se charge de convertir la syntaxe avant l’envoi à la source de donnée. On ne trouve pas généralement ces conversions, car la plupart des SGBD utilisent la syntaxe SQL standard.

ODBC fournit un gestionnaire de pilotes pour gérer l’accès simultané à plusieurs SGBD

Malgré que l’utilisation de pilote ait résolu le problème d’accès simultané à plusieurs SGBD, le code pour réaliser cela semble complexe. Les applications créées pour travailler avec tous les pilotes ne peuvent être connectées de manière statique à aucun pilote. Ils chargent plutôt les pilotes pendant l’exécution et font appel aux fonctions qu’ils contiennent via une table de pointeur de fonction. Elle devient de plus en plus complexe si l’application utilise plusieurs pilotes en même temps.

Alors, les applications auront une grande difficulté à le faire, c’est pourquoi ODBC propose une gestionnaire de pilote. Le gestionnaire comporte toutes les fonctions ODBC. De cette manière, les fonctions sont appelées par leur nom depuis le gestionnaire de pilote au lieu de passer par les pointeurs dans chaque pilote.

Pour faire appel à un pilote particulier, l’application demande une description de connexion de celui-ci qui va permettre d’identifier le pilote puis demande au gestionnaire de charger le pilote. Après le chargement du pilote, le gestionnaire stocke l’adresse de chaque fonction dans le pilote. Pour faire appel à une fonction ODBC dans le pilote, l’application lance un appel dans le gestionnaire de pilote et transmet le descripteur de connexion pour le pilote. Grâce à l’adresse, le gestionnaire de pilote identifie la fonction demandée.

ODBC expose un nombre important de fonctionnalités de SGBD mais ne nécessite pas de pilotes pour tous les prendre en charge

Ce ne serait pas utile si ODBC expose une fonctionnalité unique à tous les SGBD. D’ailleurs la diversité de tous les SGBD qui existe de nos jours est due à leur différence de fonctionnalité. Il serait difficile, voire impossible pour les pilotes, d’implémenter les fonctionnalités si ODBC rendait toutes ces fonctionnalités disponibles sur n’importe quel SGBD.

Par contre, ODBC donne un grand nombre de fonctionnalités plus que celle prise en charge par la plupart des SGBD. Mais les pilotes doivent seulement implémenter un sous-ensemble de ces fonctionnalités. Les fonctionnalités restantes sont implémentées par les pilotes seulement si elles sont prises en charge par le SGBD.

De cette manière, les applications peuvent être créées pour utiliser les fonctionnalités d’un seul SGBD telles que définies par le pilote de ce SGBD pour pouvoir utiliser les fonctionnalités que peuvent utiliser par tous les SGBD ou pour s’assurer de la prise en charge d’une fonctionnalité quelconque et réagir en conséquence.

L’avantage qu’apporte ODBC dans un environnement de Big Data

ODBC est vraiment utile dans le domaine financier, car il donne une méthode standard d’extraction de données de petite ou grande taille. Or, on remarque que les Data Lakes (une manière de stocker des données massives) stockent des données de grande taille à l’ordre de pétaoctets.

Le problème auquel font face les entreprises est au niveau de l’extraction quotidienne de quelque gigaoctet de données dans cette grande masse de données. La technologie ODBC vient dans ce cas aider à surmonter cette difficulté, elle est simple et moins coûteuse à mettre en place.

Cette facilité et le faible coût de réalisation de cette technologie sont plus importants que la gestion et l’administration des Data lakes qui semble trop complexe et coûteux. Plus de 44% des entreprises ont un Data Lake de plus 100 Térabits.

Avec l’intégration de nouveaux types de données tels que des données non structurées et tierces, le volume de données des entreprises explose. Par exemple, dans le e-commerce, on remarque l’utilisation des données météorologiques.

Le groupe financier comme Goldman Sachs traite plus de 700 Térabits de données et de plus 90 000 de jeux de données. Il traite des milliards et des milliards de données chaque jour avec une augmentation de 40% par an au carré.

Face à cette situation, on comprend mieux le dur travail à faire pour extraire des millions de lignes d’une base de données en quelque seconde pour en faire des rapports.

Il existe une autre API qui permet aussi aux applications côté client de pouvoir interroger la base de données : c’est le JDBC.

Chaque fournisseur d’un système de gestion de donnée fournit un pilote ODBC ou JDBC afin de permettre aux applications des clients d’accéder à la base de données.

La technologie JDBC

Cette technologie est venue avec Java version 1.1 et permet d’accéder à des bases de données. Avec toutes les classes que le JDBC comporte, on peut créer des applications capables de se connecter au système de gestion de données.

L’API JDBC est conçue pour être indépendante de tout SGBD. Donc, un programme peut se connecter à n’importe quelle base de données en utilisant la même syntaxe. 

Les outils nécessaires pour utiliser JDBC

Le package java.sql regroupe toutes les classes de JDBC version 1.0 et à partir de sa version 1.1 les classes sont incluses plutôt dans le JDK. 

L’utilisation de JDBC pour se connecter à une base de données nécessite un pilote conforme à cette base ou on veut se connecter dessus. Grâce au JDK, Sun met à disposition un pilote qui donne accès à la base de données via ODBC. Ce pilote donne une dépendance de JDBC vis-à-vis des bases de données.

Les types de pilotes JDBC

On a quatre types de pilotes JDBC :

• Le premier type est JDBC-ODBC bridge. L’utilisation du pont JDBC-ODBC va de pair avec ODBC et le pilote de la base à accéder. Cette fonctionnalité marche très bien sous Windows. 
• Le deuxième type est un driver développé en Java qui fait un appel d’API native de la base de données.  Les ordres JDBC sont convertis par ce driver pour faire un appel direct des API de la base de données grâce à un pilote natif sur le client. Ce driver oblige à l’utilisation de code natif sur le client.
• Le troisième type est un driver développer en java et qui utilise un middleware. Ce driver est basé sur un protocole de réseau propriétaire bien défini pour une base de données. Grâce à ce protocole réseau, le serveur dédié reçoit des messages et interagit avec la base de données.   
• Le quatrième type estun driver Java utilisant le protocole natif de la base de données. Ce driver fait un appel direct au SGBD via le réseau. Il est venu avec l’éditeur de la base de données.

Pour utiliser les drivers (souvent sous forme de fichier jar), il faut ajouter son chemin au classpath.

La présentation de la classe de l’API JDBC

L’ensemble des classes JDBC sont dans le package java.sql. Pour utiliser toutes les classes, il faut les importer en tapant :

import java.sql.*;

On distingue quatre classes importantes :

• DriverManager : Cette classe charge et configure le driver de la base de données ;
• Connection : elle se charge de la connexion et de l’authentification à la base de données ;
• Statement : contient la requête SQL et la transmet à la base de données ;
• ResultSet : Parcourir toute l’information réenvoyée par la base de données.

La connexion à une base de données

Pour interroger une base de données via ODBC, il faut au préalable charger le pilote JDBC-ODBC.

Big Data : Gestion des données avec Apache Hive

Maintenant, nous allons voir comment se passe la gestion des données dans le domaine du Big Data. Nous allons commencer par l’utilisation d’ODBC avec Apache Hive.

Qu’est-ce qu’Apache Hive ?

Il s’agit d’un datawarehouse pour Hadoop. Il a été créé d’abord par Facebook et finit par devenir un projet Apache Open Source. Hive n’est pas comme une base de données relationnelle ni comme un datawarehouse classique. C’est un système qui garde des métadonnées décrivant les données stockées dans HDFS. La base de données que Hive utilise est appelée metastore (Derby par défaut) pour s’assurer de la persistance des métadonnées. Une table Hive est composée :

• D’un schéma stocké dans le metastore ;
• De données stockées dans HDFS. 

Grâce à la donnée de metastore, Hive se comporte comme un système de gestion de base de données et interroge les tables de données avec son langage HiveQL.

Les requêtes HiveQL sont traduites par Hive en job MapReduce ou Tez. Cela permet aux analystes qui n’ont pas une bonne connaissance en programmation de jobs de pouvoir écrire facilement les requêtes HiveQL.

Hive supporte la syntaxe standard SQL :

INSERT INTO
SELECT 
FROM … JOIN …. ON
WHERE 
GROUP BY
HAVING
ORDER BY
LIMIT

De même que les commandes de définitions :

CREATE / ALTER / DROP TABLE / DATABASE

Nous avons évoqué cette architecture dans un article que nous avons publié sur Hive, et notamment sur Pig. Mais dans celui-ci, nous allons nous concentrer sur l’utilisation d’ODBC avec elle.

Le pilote ODBC Hive

Le pilote Hive ODBC est un outil puissant qui implémente la norme API ODBC pour le système de gestion de base de données Hive. Il permet aux applications ODBC de communiquer de façon idéale avec Hive via une interface standard.

Logiciel requis

Pour que le pilote Hive ODBC normalement il faut les composants logiciels suivant : 

• Hive Server : C’est par ce service que les clients lancent à distance des commandes et requêtes Hive. Sans le Hive Server le pilote Hive ODBC ne peut effectuer l’ensemble des interactions de base de données.
• Apache Thrift : C’est un logiciel multilingue qui évolue et qui permet au pilote ODBC d’interagir avec le serveur Hive. Il faut suivre ce lien pour l’installation de Thrift. Le pilote Hive ODBC a été construit avec la version Thrift trunk r790732, mais la toute dernière version est aussi compatible. N’oubliez pas de noter le chemin d’installation de Thrift durant l’étape de génération de Thrift. Ces informations sont capitales pour la génération du client Hive.  Ce chemin sera appelé THRIFT_HOME.

Architecture du pilote

Pour bien comprendre le fonctionnement et l’architecture de Hive nous verrons étape par étape comment se passe l’exécution d’une requête Hive. Hive/Hadoop interagit selon les trois étapes suivantes :

1. Envois de la requête HiveQL : grâce à une interface web ou un client JDBC/ODBC, la requête est envoyée au serveur web.
2. Planification de la requête : Le pilote reçoit la requête ensuite la requête est compilée, optimisée et planifiée comme un job. 
3. Exécution du job : c’est sur le cluster Hadoop que le job est exécuté.

Première partie : la partie client

Il existe différentes manières de soumettre de requête au serveur Hive :

• Le client Hive CLI (Hive Commande Line Interface), il permet d’exécuter les commandes directement depuis le shell Hive ou d’écrire de commande Hive dans un fichier texte et de l’exécuter. Beeline remplace le client Hive,   car il n’est pas compatible avec Hiveserver2 et Beeline devient le nouveau client et interagit avec HiveServer2 via thrift ;
• Le client JDBC/ODBC ;
• Le client web.

Deuxième partie : la partie serveur

Appelé HiveServer2, c’est à ce niveau que se trouvent tous les pilotes.  Il se compose du metastore, du compilateur et de l’exécuteur.

HiveServer2 joue deux rôles : la gestion des requêtes concurrentes et la gestion de l’authentification client. HiveServer2 crée pour chaque connexion client un nouveau contexte d’exécution.

Troisième partie : Hadoop

Elle correspond à l’exécution du job sur cluster Hadoop. D’ailleurs, si vous souhaitez vous initier à cet écosystème, nous vous offrons cette formation gratuite pour vous aider.

Hive : Managed table et External table

Dans Hive, il y a une similitude entre Managed table et External table au sens RDBMS. La différence se trouve lors de la gestion des données d’une table supprimée.

Dans l’exemple qui suit, nous allons voir la création d’une managed table product ayant 5 colonnes en commande HiveQL :

hive > CREATE TABLE product (
productId INT,
productName STRING,
productCategory STRING,
valuationDate TIMESTAMP,
validTillDate TIMESTAMP) 
ROW FORMAT DELIMITED 
FIELDS TERMINATED BY ‘,’;

Création d’une External table

Il est possible de préciser l’emplacement de stockage de données dans HDFS en ajoutant le mot LOCATION lors de la création de la table comme ceci :

hive > CREATE EXTERNAL TABLE product-ext (
productId INT,
productName STRING,
productCategory STRING,
valuationDate TIMESTAMP,
validTillDate TIMESTAMP) 
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ‘,’
LOCATION ‘/user/BigDataLab/Hive_part1/products’ ;

Spark SQL

Avec son interface JDBC/ODBC ou de ligne de commande, Spark peut se comporter comme un moteur de requête. Dans ce cas de fonctionnement, les utilisateurs et les applications n’ont pas besoin de passer par un code pour interagir avec Spark SQL.

Exécution du serveur Thrift JDBC/ODBC

Le serveur Thrift JDBC/ODBC installé ici correspond à HiveServer2. À l’aide du script beeline venu avec Hive ou Spark on peut tester le serveur JDBC.

En tapant ce code dans le répertoire Spark on démarre le serveur JDBC :

./sbin/start-thriftserver.sh

Les bin/spark-submitoptions de ligne de commande et les bin/spark-submitoptions pour spécifier les propriétés Hive sont compatibles avec le script. L’adresse du serveur par défaut est localhost10000, mais on peut remplacer par une autre variable : 

export HIVE_SERVER2_THRIFT_PORT=
export HIVE_SERVER2_THRIFT_BIND_HOST=
./sbin/start-thriftserver.sh \
  --master  \

Ou par les propriétés du système :

./sbin/start-thriftserver.sh \
  --hiveconf hive.server2.thrift.port= \
  --hiveconf hive.server2.thrift.bind.host= \
  --master 
  ...

  ...

Maintenant vous pouvez utiliser beeline pour lancer un test du serveur Thrift JDBC/ODBC :

./bin/beeline

Effectuez la connexion au serveur JDBC/ODBC en ligne de commande en exécutant : 

beeline> !connect jdbc:hive2://localhost:10000

Le serveur Thrift JDBC prend également en charge l’envoi de messages RPC d’épargne via le transport HTTP. Utilisez le paramètre suivant pour activer le mode HTTP en tant que propriété système ou dans un hive-site.xml fichier dans conf/:

hive.server2.transport.mode - Set this to value: http
hive.server2.thrift.http.port - HTTP port number to listen on; default is 10001
hive.server2.http.endpoint - HTTP endpoint; default is cliservice

Exécuter la CLI Spark SQL

La CLI Spark SQL est un outil très pratique pour lancer le service de métastore Hive en mode local et exécuter les requêtes entrées à partir de la ligne de commande. Gardez que la CLI Spark SQL ne peut pas interagir avec le serveur Thrift JDBC.

Pour lancer la CLI Spark SQL, exécutez la commande suivante dans le répertoire Spark :

./bin/spark-sql

La configuration de Hive se fait en plaçant vos fichiers hive-site.xml, core-site.xmlet hdfs-site.xmldans conf/. Vous pouvez ouvrir ./bin/spark-sql –help pour une liste complète de toutes les options disponibles.

Pour vous aider à mieux maitriser Spark pour la Data, nous avons créé une mini formation composée de cours vidéo et d’un livre numérique que vous pouvez télécharger.

Pilote ODBC Splunk

Les informations tirées des données machines peuvent être très importantes, mais la question est de savoir si vous êtes capable de rendre accessibles ces informations à vos utilisateurs ? 

ODBC Driver donne une connexion standard entre Splunk et les autres logiciels de traitement de données comme Microsoft Excel et Tableau Desktop. 

Donc il est possible d’avoir un accès à de données machines importantes et pouvoir les lier à d’autres données au sein de l’entreprise pour donner une bonne visibilité et de nouvelles informations.

Les avantages du pilote ODBC Splunk

• Une méthode de connexion standard à Splunk Enterprise ;
• Les utilisateurs ont un accès direct et sécurisé ;
• Faire le mixage de donnée machine avec les données structurelles dans le but d’avoir un meilleur contexte opérationnel.

Pourquoi utiliser Splunk ODBC Driver

Grâce à la norme ODBC, on peut récupérer des données depuis Splunk Enterprise en utilisant des applications ou logiciels de traitement de données.

Accès base sur le rôle

Grâce aux commandes d’accès définis par Splunk Enterprise, on peut prendre le contrôle d’accès aux données sensibles.

Isolement des données machines 

Avec les recherches sauvegarder dans Splunk Enterprise afin de lire les données machines pour qu’elles seules soient accessibles.

Intégrité des données machines

La lecture des données machines depuis Microsoft Excel ou Tableau Desktop ne peut être modifiée, changée ni supprimée, elle est en lecture seule.

Fonctionnement du pilote Splunk ODBC Driver

L’image suivant illustre le fonctionnement du pilote Splunk ODBC Driver :

La configuration 

Le pilote ODBC est compatible avec les systèmes d’exploitation de Microsoft Windows et Microsoft Visual C++ 2010 est requis pour le poste client sur lequel le pilote ODBC Splunk est exécuté.

En conclusion, ODBC est une technologie vraiment importante dans le Big Data, si le but est d’extraire de volume quotidien de données tout en conservant une meilleure interopérabilité. Sans interopérabilité, une entreprise ne peut pas avoir une vue d’ensemble de ses données et en exploiter au maximum. Vous avez vu le fonctionnement et l’utilisation de cette architecture tous le long de cet article. Maintenant, vous pouvez le mettre en pratique dans vos futurs projets Big Data.

Si vous souhaitez augmenter encore plus vos compétences dans ce domaine, nous vous invitons de télécharger cette formation sur la programmation Scala.