Barak Obama remercie le Big Data

http://www.journaldunet.com/ebusiness/expert/53760/la-victoire-d-obama—cas-d-etude-concret-d-utilisation-des-big-data.shtml

Extrait:

Quel a donc été l’enseignement majeur de ces élections au plan digital ? L’usage massif des réseaux sociaux ? L’utilisation des dispositifs digitaux en mobilité ? L’interrelation du digital avec « la vraie vie » ? La géolocalisation ? La plupart de ces leviers ont déjà prouvé leur efficacité lors des élections de 2008 notamment en matière de crowdfunding, de buzz et de viralité.
Avec un minimum de recul, il est clair que cette élection a inauguré l’An Un du retraitement de masse de données numériques interconnectées; à savoir l’apparition de la Big Data ** comme levier l’action majeur… appliqué à des élections.

Partager :

Ne vous trompez pas de révolution

Un article bien intéressant sur la Big Data.

Extrait:

Au-delà du choix d’un outil ou d’une technologie nouvelle, la réflexion sur la place de la Data Science dans l’entreprise lui permet en effet de questionner ses pratiques, ses données et ses méthodes :

• Quels sont les processus sur lesquels une analyse fine de l’information permettrait d’être plus efficace (conception produit, marketing produit, relation client, vente en ligne, production opérationnelle, chaîne logistique, maintenance industrielle, gestion du risque financier, pilotage de la marge…) ?

• Quelles sont les données disponibles dans les systèmes d’information de l’entreprise, qui permettraient de répondre plus efficacement aux questions que se posent les pilotes de ces processus, et quelle est la nature de ces données (volume, qualité, variété…) ? À l’inverse, quelles sont les données non stockées dans les systèmes d’information, et qui permettraient pourtant d’enrichir fortement l’analyse métier (données de logs web, données issues de capteurs industriels…) ?

• Quelles sont les méthodes de traitement de l’information (analyse statistique, analyse numérique, intelligence artificielle, machine learning…) qui permettraient effectivement de transformer ces données en des réponses concrètes et opérationnelles aux questions posées par les pilotes de processus ?

IBM InfoSphere BigInsights

IBM InfoSphere BigInsights brings the power of Hadoop to the enterprise.

http://www-01.ibm.com/software/data/infosphere/biginsights/

Big data : comment l’intégrer à votre stratégie ?

Chronique de Jean-Baptiste Ceccaldi
Président, Sentelis

14/03/13 15:49
Big data : comment l’intégrer à votre stratégie ?

Avec l’explosion des usages internet et mobiles (réseaux sociaux, nouveaux services profilés…), l’arrivée de terminaux et boitiers de communication intelligents dans tous les aspects de la vie quotidienne et du monde industriel, la masse de données brutes s’est considérablement accrue.

Si la croissance exponentielle des informations ne date pas d’hier, les problèmes les plus ardus pour en tirer une réelle valeur ajoutée pour l’entreprise se concentrent autour de la vélocité (ex : leur vitesse de production), les critères de corrélation, la variabilité dans la qualité, l’hétérogénéité des structures, les cycles de vie et fréquences différentes, des contraintes sécurités et des exigences légales spécifiques…
Ce véritable tsunami, appelé « Big Data » remet au premier plan la sempiternelle problématique de gestion et d’exploitation de l’information dans les entreprises.

Le Big Data, c’est quoi ?

Le « Big Data » est un assemblage de technologies, de pratiques, processus et services qui doivent être mis en cohérence et coordonnés, gage de réussite et de rentabilité des investissements à consentir. Il ne se résume donc pas à une technologie, et n’est pas non plus un produit sur une étagère.
L’entreprise doit donc agir avec discipline et prendre la pleine mesure aussi bien en termes de gouvernance, de produits (c’est-à-dire de pratiques, méthodes et outils) que d’offres de services pour en permettre le déploiement efficacement des usages coté métier, c’est-à-dire en tirer des applications concrètes qui créent une performance pour l’entreprise, c’est à dire un avantage concurrentiel.
A ce propos, les premières initiatives « Big Data » exigent d’identifier un premier ensemble d’usages, qui serviront à construire une fondation industrielle transverse à l’entreprise. Une tâche non sans difficulté, qui nécessite une approche spécifique dirigée vers un seul objectif : délivrer la promesse du « Big Data » de transformer les masses de données brutes en stratégies gagnantes.

Le champ des usages potentiels est immense : nouveaux services basés sur une connaissance fine des comportements, identification de prospects, émergence de tendances, détection d’action illicite, anticipation des problèmes et dérives, fiabilisation des prévisions de ventes, optimisation des chaînes d’approvisionnement, marketing digital temps réel intégrant la géolocalisation, etc.
Quels enjeux pour la direction métier et la DSI ?

Coté métier, l’enjeu clé du « Big Data » consiste donc à gagner la bataille des données en étant meilleur que ses concurrents dans leurs usages (innovation, fidélité et satisfaction client…).
Coté DSI, il s’agit de mettre à disposition les moyens nécessaires à leur capture, leur intégration dans le système d’information, leur analyse en masse et leur exploitation. Le tout, à moindre coût.
Et pour la DSI, l’heure n’est plus à l’attentisme. Pour s’en convaincre, il suffit d’observer l’expansion et la démocratisation sur le marché des solutions « Big Data », dont le marketing cible directement, pour certaines, les acteurs métiers ainsi que les témoignages croissants de premières références probantes dans tous les secteurs d’activité.
La DSI doit commencer à apporter des réponses concrètes aux métiers et impérativement adresser le sujet pro-activement, avec le souci d’enrichir son offre, de services à valeur métier tout en masquant les aspects technologiques.
Les différentes approches : “Data-at-rest” versus “Data-in-motion”

Le « Big Data » promeut, pour les données ne nécessitant pas une analyse temps réel, la constitution d’un « Data Lake », espace de collecte, de stockage des « Data-at-rest » et de mise à disposition massive de données brutes sans organisation ou structuration à priori, matière première des travaux d’analyse pour rendre l’information actionnable.
C’est là une différence majeure avec l’approche décisionnelle classique basée sur le stockage de données structurées à la qualité optimale et qui de fait, ne fait pas sens dans l’univers du « Big Data ». Pour autant, cette approche reste complémentaire, mais en aval de la chaîne de valeur « Big Data » pour le stockage des données à valeur ajoutée qui en sont issues et que l’entreprise souhaite conserver pour une analyse ultérieure par exemple via les outils classiques de « Business intelligence ».
Les solutions de type « Apache Hadoop » sont basées sur cette logique de « Data Lake ». Les algorithmes type « MapReduce » popularisés par Google permettent quant à eux l’analyse en masse des données du « Data Lake ».
Pour les « data-in-motion » (ex : celles continuellement mises à jour comme les positions GPS) et à analyser en temps réel ou pour lesquelles le volume est trop important ou encore pour lesquelles on ne sait quelle valeur ajoutée pourrait bien en être tirée, les technologies de « Stream computing » (ex : Complex Event Processing) visent à permettre l’analyse des « data streams » sans stockage préalable.
« Big Data as a service » : un passage obligé

La complexité et la disparité des composants techniques sous-jacents au « Big Data », ses caractéristiques hors normes, aussi bien sur la volumétrie des données, les capacités de calcul intensif et les exigences de réactivité militent fortement pour la mise en place d’une offre « SaaS » privée ou publique et plus vraisemblablement hybride pour tirer avantage d’un « cloud service » de type « Analytics-as-a-Service ».
Une telle approche sécurise les usages par une qualité de service contrôlée. Elle rend possible une utilisation agile en ‘bac à sable’ pour les analyses exploratoires, combinant simultanément les exigences de fraîcheur de données issues des systèmes de production, d’étanchéité des traitements potentiellement gourmands et de degrés de liberté nécessaires à une analyse itérative. Elle simplifie l’orientation « multi-tenante », multi usages que doit vitalement supporter le socle « Big Data ». Si la sécurité des données doit être adressée, c’est aussi et surtout le résultat de l’analyse qui doit l’être.
Big Data : une fondation transverse du SI au service des métiers

Permettre aux différents métiers de tirer la quintessence des « Big Data » via les justes regroupements et recoupements ne peut être envisagé sans la mutualisation des initiatives à l’échelle de l’entreprise pour constituer un dispositif pérenne, industriel et économiquement viable : un socle transverse « Big Data » au service des usages métiers.

Ce socle doit :
* porter les principes d’association et corrélation de données hétérogènes fondamentales au « Big Data » et susceptibles de révéler les tendances implicites recherchées par les métiers,
* mutualiser les investissements technologiques : « appliances Big Data » de stockage et/ou d’analyse telles que celles de Teradata, IBM (Netezza) ou EMC2 (Greenplum) ; solutions de « Stream Computing » comme celles d’IBM (Big Data Analytics) ou d’Oracle (CEP Engine) ; solutions logicielles d’analyse massive type SAS (Business Analytics); solution de base de données en mémoire comme SAP (HANA) ou encore les nœuds des architectures de traitement massivement distribué de type « data grids » et « clusters Hadoop »,
* garantir la qualité de service aux utilisateurs et coordonner les besoins concurrents de ressources par une gestion globale multi-usages. Une responsabilité qui passe notamment par un pilotage et une régulation fine des capacités d’infrastructure de stockage et d’analyse. Sur ces aspects, les offres du ‘Cloud’ (Amazon Web Services, Opera Solutions, 1010data, IBM SmartCloud Enterprise…) et les distributeurs Open Source (MapR, Cloudera, Hurence, …) sont impérativement à considérer pour garantir le meilleur mix efficacité opérationnelle – efficacité économique.
Le socle « Big Data » doit être construit de façon incrémentale selon une feuille de route qui garantit dans la durée la cohérence du mix gouvernance-services-produits (au sens technologies, méthodes mais aussi modèles de données et d’analyses) en cohérence avec le déploiement des usages, leur maintien en condition opérationnelle notamment lors des montées de version du socle.
Ses évolutions, son exploitation, et plus globalement sa gouvernance long terme doit se faire via la mise en place d’une organisation dédiée intégrant des ressources expertes sur le sujet, et ce, même si les solutions du marché progressent pour rendre le « Big Data » plus accessible et plus simple aux non-spécialistes.
Cette « Big Data Team » en responsabilité du socle « Big Data » et de l’offre de services associée doit être distincte des équipes utilisatrices du socle, de ses usagers: alors qu’elle a pour responsabilité la construction et la gestion de la chaîne analytique, les équipes utilisatrices quant à elles construisent et gèrent les analyses elles-mêmes.

* Les équipes utilisatrices doivent pouvoir être autonomes tout en étant accompagnées d’un support et d’une expertise de l’équipe socle, nécessairement pluridisciplinaire : des « Data scientists » spécialisés en ingénierie statistique et traitement de l’information, sensibilisés aux enjeux du « Big Data », et capables d’accompagner les interlocuteurs métier,
* des experts en conception, développement et administration de composants implémentés sur les technologies innovantes : Hadoop et MapReduce, bases de données NoSQL et orientées colonnes, plateforme analytique « R »…
* des architectes garantissant la cohérence de l’infrastructure applicative et technique et des pratiques d’ingénierie d’une plate-forme fortement hétérogène en rupture avec l’existant (boitiers logiciels et matériels, outils de pilotage spécialisés, stockage et traitement distribués sur « commodity hardware », connectivité à faible latence…)
Big Data = Big Challenge = Big Opportunity

Le « Big Data » recèle un potentiel énorme. Pour autant, si les choses avancent vite en termes de solution, en délivrer la promesse reste complexe. S’engager dans le « Big Data » nécessite d’acquérir une bonne compréhension du sujet, un juste choix des cas d’usage et le bon mix de gouvernance, d’offre de services aux métiers, de méthodes, de compétences et de technologies adaptées à l’ambition. Une condition sine qua non pour s’assurer que le retour sur investissement soit bien au rendez-vous.

Mais à quoi peuvent bien servir les normes SQL?

De temps en temps, on entend parler des normes SQL, mais dans la réalité, ces normes paraissent bien théorique voire inutiles.
Néanmoins, voici un exemple ou l’emploi des normes SQL peut permettre d’éviter des situations délicates.

Lors de l’utilisation des ETL, une pléthore de fonctions SQL peut être proposée. Ces fonctions lors de créations de mappings et de transfromations sont très utiles. Néanmoins, un grand nombre de celles-ci sont propriétaires.

En premier lieu, les fonctions propres à l’ETL, seront souvent implémentées par le serveur ETL et ne pourront en aucun cas être confiées au serveur de BDD. D’autres, seront traduites en fonctions BDD, les choix de traduction peuvent être corrects, mais aussi surprenants, voire pénalisants. Ils resteront propres à l’ETL et vous ne serez pas maitre de ceux-ci.

Ensuite, les fonctions propres à la BDD, peuvent être mises en oeuvre directement sur le serveur BDD; l’ETL soumettra une requête optimisée et efficace pour votre base. Ainsi, une commande peut récupérer des données agrégées depuis la base de données, alors que l’utilisation de fonctions d’agrégation preopres à l’ETL forcerait le rapatriment de toutes les données avant de faire l’agrégation.

Par contre, dans le cas de l’utilisation de fonctions SQL standards, un avantage supplémentaire peut être tiré. En cas de migration de base de données, l’ETL propose surement des drivers ODBC adaptés. Les fonctions utilisables sans opérations de maintenance sot les foctions propriétaire ETL et les fonctions standard SQL. Les fonctions propriétaires BDD sont à migrer.

Ainsi, le choix du type de fonction utilisées lors de l’implémentation sera déterminant pour les futures optimisations et migrations. Le plus maléable est de se conformer aux normes SQL.
Donc l’utilisation des normes peut être un atout lors de l’implémentation d’un process d’alimentation.

Related articles

• Du mauvais usage du TRUNCATE (aprevotleygonie.wordpress.com)

Partager :

Article sur l’architecture de données BI, bon pour remettre les bases à plat.

Sherry's BI Corner

I’ve done ETL design and development in both integration projects and in reporting environment.

In master data integration projects, it’s not hard to distinguish staging area from the target area. In the staging area, truncating tables with old data and loading new data is a pretty common practice. I’ have not seen any truncating tables in the target area. This is a good thing. It means that developers understand the role of staging, and understand that loading data into target area needs to be carefully designed, or “reconciled”, as a consultant called it. Depending on the business rules, we will end up either creating new records in the target, or updating existing records, or deleting obsolete records.

In the reporting environment, however, developers have very different attitude and very different understanding of staging VS. target.

This is a very typical architecture I’ve seen so far. The flaw in this design…

Voir l’article original 315 mots de plus

No SQL rime t-il avec No Future?

L’arrivée du terme No SQL dans le language informatique ‘hype’ a fait l’effet d’un électrochoc dans ma tête. Immaginez 15 Ans de réflexion, d’études, d’utilisation des languages SQL, SQL+, PL/SQL anéantis par le NoSQL. Ce nouveau concept mettra t-il à terre un language faisant référence depuis 1974?
Près de 40 ans d’informatique et de SGBDR réduits à néant, et rendu définitivement has been! La majorité des produits de reporting et des ETL seraient donc basés sur des principes néandertaliens, au bord de la disparition.

Fort de ces réflexions, je me suis renseigné; WIKIPEDIA est mon amie. Voici donc le lien vers la page faisant le point sur cette menace pour les métiers de la BI:
http://fr.wikipedia.org/wiki/NoSQL

Ainsi, le concept est réellement nouveau, rien encore de bien précis. Le dinosaure du reporting a encore quelques temps devant lui, mais ce concept est à surveiller de près. Une révolution est peut-être en marche.

Related articles

• Going NoSQL with SQL (architects.dzone.com)
• NoSQL – Not only SQL (Introduction to Apache Cassandra) (clean-clouds.com)

Partager :

le Big Data à l’assaut des zones de confort technique

Le big data, son histoire, et les nouveaux horizons ouverts …

Du mauvais usage du TRUNCATE

En préambule, voici la définition du TRUNCATE SQL(WIKIPEDIA):

In SQL, the TRUNCATE TABLE statement is a Data Definition Language (DDL) operation that marks the extents of a table for deallocation (empty for reuse).
The result of this operation quickly removes all data from a table, typically bypassing a number of integrity enforcing mechanisms.
It was officially introduced in the SQL:2008 standard.

The TRUNCATE TABLE mytable statement is logically (though not physically) equivalent to the DELETE FROM mytable statement (without a WHERE clause).
The following characteristics distinguish TRUNCATE TABLE from DELETE:
*In the Oracle Database, TRUNCATE is implicitly preceded and followed by a commit operation. (This may also be the case in MySQL, when using a transactional storage engine.)
*Typically, TRUNCATE TABLE quickly deletes all records in a table by deallocating the data pages used by the table. This reduces the resource overhead of logging the deletions, as well as the number of locks acquired. Records removed this way cannot be restored in a rollback operation. Two notable exceptions to this rule are the implementations found in PostgreSQL and Microsoft SQL Server, both of which allow TRUNCATE TABLE statements to be committed or rolled back transactionally.
*You cannot specify a WHERE clause in a TRUNCATE TABLE statement—it is all or nothing.
*TRUNCATE TABLE cannot be used when a foreign key references the table to be truncated, since TRUNCATE TABLE statements do not fire triggers. This could result in inconsistent data because ON DELETE/ON UPDATE triggers would not fire.
*In some database systems, TRUNCATE TABLE resets the count of an Identity column back to the identity’s seed.
*In Microsoft SQL Server 2000 and beyond in full recovery mode, every change to the database is logged, so TRUNCATE TABLE statements can be used for tables involved in log shipping. [1]

Lors de l’utilisation des ETL, la création d’un mapping peut, si on veut opérer en annule et remplace, faire appel à un mécanisme de suppression des données.
Ce mécanisme proposé est souvent nommé TRUNCATE TABLE.
Les ETL Buisness Objects Data Integrator et Informatica power Center sont tous deux concernés par ma remarque.
Ces ETL font appel à la commande SQL DELETE, et non au TRUNCATE SQL.

Voici donc la définition du DELETE SQL (WIKIPEDIA):

In the database structured query language (SQL), the DELETE statement removes one or more records from a table.
A subset may be defined for deletion using a condition, otherwise all records are removed.
Some DBMSs, like MySQL, allow to delete rows from multiple tables with one DELETE statement (this is sometimes called multi-table DELETE).

Ainsi, lors de suppression de gros volumes de données, l’ETL peut prendre un temps non négligeable, long, beaucoup trop long, voire s’approchant de l’infini.
En effet, le DELETE SQL réalise le nettoyage de la table LIGNE PAR LIGNE, alors que le TERUNCATE SQL fait la même opération, mais globalement.
Dans ce cas, il est souvent plus malin de ne pas suivre la voie tracée par l’ETL, de stopper l’alimentation, et de changer son fusil d’épaule.
Ainsi, Buisness Objects Data Integrator propose en alternative un DROP and RECREATE vraiement efficace.
Il aussi est possible de créer et appeler un code SQL faisant l’opération, que ce soit du TRUNCATE SQL ou DROP and RECREATE.

Related articles

• Heavy updates and deletions within an onFlush event handler (stackoverflow.com)

Partager :

XL attaque la BI

La BI se met (enfin?) à la portée de tous