salut  
 
je suis sur un projet perso depuis quelques temps et je viens de tomber sur un article parlant des data scientists
en wiki : https://fr.wikipedia.org/wiki/Science_des_donn%C3%A9es
ça ressemble un peu à ce que je compte faire en fait
par contre je n'ai pas certaines compétences, du style traitement du signal
 
donc avis aux amateurs  
 
ce projet a vocation à être en open source et freeware (les dons paypal seront possibles évidemment)
c# (service, winform et webform) et dispo sur le plus de bdd possibles
 
 - donc principalement de la configuration de requêtes via le winform ou webform
 - des stats à intégrer ensuite
 - et des tâches à effectuer
    - sur ce point je reprend la même chose que mscrm avec les callouts, c'est à dire appeler des dll développées par l'utilisateur et appelées par le service, ou des webservices
    - ou alors un ensemble de tâches prédéfinies avec paramètres et ordonnancées par l'utilisateur

Pas compris l'objectif concret de ton projet, ni la question s'il y en a une .

Développer des outils de data mining et/ou de big data, c'est chaud. En général, avant de partir sur ce genre de projet, c'est bien de faire un état de l'art et de tester le produits existants pour voir les points forts (idées à reprendre) et ce qui manque.
 
Dans le domaine, Apache est très actif : https://projects.apache.org/projects.html?category
 
Pour les SGBD, désormais, on part plutôt sur du NoSql. Et comme chaque système est très spécifique, ça sera pas de la tarte de faire un logiciel capable d'être efficace avec plusieurs de ces BD En général, la généricité a un coût tant en complexité du code que du temps d'exécution. Or, le facteur temps est un point clé du data mining / big data
 
Petite remarque : je suis pas sûr que partir sur des technos MS (donc OS Windows) soit le bon choix Des OS Unix sont généralement bien plus adaptés pour ce type de traitement lourd. En tout cas, j'ai pas trouvé trace d'un seul produit sur Windows dans ce bouquin : http://www.amazon.fr/Big-Data-Mach [...] 100720740/

salut
 
totalrecall, j'ai mal du m'exprimer en fait
le projet concerne ce que dit rufo en fait, data mining et/sur big data
la question c'est s'il y a des gens qui veulent y participer
 
 
rufo, j'en suis conscient, ça va me demander pas mal de boulot et de recherche
il va falloir que je regarde ce que fait apache dans ce domaine comme tu me l'indiques (mais si c'est apache ça veut dire qu'ils font déjà un truc gratuit dans ce domaine ?)
pour ce qui est du fait de développer sur unix ou linux, ça me rebute un peu, de plus la plupart des temps de réponses seront du au fait du sql, donc des bdd analysées
pour ce qui est du fait d'utiliser noSql en fait ça ne me semble pas approprié pour le produit, vu qu'il analyse des bdds, l'utilisateur en a donc forcément de dispo pour héberger les données de l'appli
pour l'instant je ne compte pas faire de machine learning (peut être ensuite)
pour le fait d'être efficace sur plusieurs bdd, normalement je ne vois pas d'inconvénient, je suis en train de me faire un gda multi bdd (pour l'instant j'ai prévu sqlserver, oracle, mysql et postgresql)
il faudra aussi que je fasse la récupération de données xml par fichiers et webservices
pour l'instant je compte prendre en compte seulement des données facilement exploitables (bdd et xml)
 
 
sinon, ce projet m'est venu à l'esprit car je développe plusieurs appli perso en ce moment
 - un log et lanceur d'alertes -> définition des disques et répertoires à analyser, bdd aussi avec différentes choses à contrôler selon les tables/champs définis, et évidemment actions à effectuer définies selon le type d'alerte
 - un analyseur de log d'un jeu vidéo, là c'est plutôt apparenté à du big data, environ 800meg de fichier texte pour une année par joueur (en comptant 50k utilisateurs potentiels sur 400k)
   - mon serveur web est en arizona et ma bdd à lyon (donc par tcp/ip), les temps de réponses ne sont pas trop dégeu
   - le tout à importer en bdd et évidemment éviter les doublons (une partie des logs sont communes à chaque joueur), pour l'instant j'en suis à 82 sec pour 1.7million de lignes analysées et importées (moins d'import évidemment en considérant les doublons)
   - sur ce truc je fais des statistiques classiques
   - là je commence à faire de la reconnaissance d'évennements sur un temps non défini selon les champs date (par exemple isoler une partie de chasse sans que l'utilisateur ne me donne la date de début et de fin),
    c'est à dire pouvoir regrouper des données par lot et les dissocier pour statistiques
   - à partir d'un webservice externe (autre site), je vais récupérer des informations sur les items pour pouvoir faire des stats de dommage selon mob et arme utilisée (dans le log on ne sait pas quelle arme est utilisée en fait, seulement le nombre de dmg)
   - à partir des stats (si assez de données sur une stratification précise), je vais ensuite pouvoir faire des stats prédictives sur cette stratification
 
voilou, j'espère avoir été plus clair que dans le premier post

Comme je te le disais, les SGBDR en big data/data mining, c'est une voie sans issue, d'où le NoSQL
"82 sec pour 1.7million de lignes" -> ça le prouve. Avec une archi adaptée, tu serais à environ 1s à 2 de temps de traitement
 
Franchement, lis le bouquin que j'ai mis en lien dans mon post précédent car à tes propos, je pense que tu mets les pieds dans un domaine dont tu ne connais pas grand chose et qui est hautement technique.
 
Et oui, les produits d'Apache sont gratuits.
 
Edit : renseigne toi sur des produits comme le système de fichier HDFS, HBase, Hadoop ou l'algo MapReduce. Il faut en effet bien comprendre que le big data nécessite des archi bien particulières, les traditionnelles n'étant pas assez performantes ni adaptées pour faire du distribué, la seule solution pour dépasser la limitation du temps de traitement au vu du volume de données à traiter.

 
oui mais quasiment le tier des lignes doivent être importées avec un exists(selec) avant pour ne pas avoir de doublons, c'est ça qui prend du temps
mais avec les différents fichier de log, une ligne à 20151005 12h15 et 24sec peut se retrouver à 25 ou 23 sec dans un autre fichier de log
d'où le exists(select) avec un intervalle sur la date
 
et le simple fait de parser le gros fichier pour stats avant import prend 5-6sec
 
j'utilise sqlconnection et SqlBulkCopy pour insérer par lot en masse, donc les lignes normales sont insérées directe dans leur tables respectives
et pour les lignes qui peuvent doublonner, même chose, bulkinsert dans une table temporaire (pas une table créée à la volée hein)
et ensuite par proc stock je parse tout le lot préparé dans la table tempo pour les insérer ou non dans la vrai table
c'est ça qui prend du temps
 
il faudra que je lise le bouquin et me renseigne sur les technos dont tu m'as parlé
 
merci pour les précisions
 
[edit]
mais tu veux dire que ceux qui ont de très grosses bases n'utilisent pas les produits classiques ? sqlserver ou oracle ?
pourtant on peut les mettre en batterie de serveur normalement ?

Oui, le big data ne repose pas sur des systèmes de fichier genre NTFS Ext3, Ext3 et des SGBDR (BD relationnelles donc) mais sur des systèmes de fichier unix du genre HDFS et des BD de type NoSQL (des BD non relationnelles donc à base de clé/valeur). En NoSQL, tu as MongDB, Cassandra pour ne citer qu'eux. Le langage d'interrogation n'est pas du SQL mais les outils essayent d'y ressembler pour faciliter la prise en main.
 
Pour info, t'as des distrib unix faites spécifiquement pour du Big Data. Comme je te l'ai dit, le big data est vraiment un domaine très nouveau avec pleins de technos nouvelles, pas du tout en lien avec ce qui se fait depuis les années 80 (les SGBDR datent de cette époque grosso modo).
 
Vraiment, lis le bouquin que j'ai mis en lien : il fait un très bon tour d'horizon des concepts et des technos utilisées en big data. Il aborde le métier de data scientist et de la visualisation des données, mais aussi de leur préparation et nettoyage.
 
Au passage, passer des technos classiques au big data est peut-être un pas un peu violent. Tu peux peut-être déjà te mettre au décisionnel : tu connais bien des outils comme les ETL (extract, transform and load) ou un outil comme Pentaho (c'est un clone gratuit de BO) ?

salut
 
merci pour les précisions
 
clair, c'est même très violent à mon avis, si le sql ne sert plus à rien il va falloir apprendre pas mal de choses et j'imagine surtout les bonnes façons de faire
 
pour les ETL j'ai déjà utilisé talend il y a quelques années, c'était pour le bancaire :
 - eux n'étaient pas passé au big data par contre, tout en oracle et fichiers textes de transactions à importer
 - pourtant ils avaient vraiment beaucoup de données, c'était pour le traitement de toutes les transactions, équipe backoffice (je ne sais pas si ça porte le même nom dans les autres banques)
 
le truc que je veux faire ressemble un peu à du talend en fait, mais sans les chargements de données dans les tables clientes évidemment
 
je viens de télécharger mongoDB là, ils disent que c'est le plus utilisé sur wiki, je vais regarder comment ça fonctionne
j'espère que chaque bdd nosql n'a pas son propre language, visiblement cassandra a le sien déjà, le cql
j'espère qu'il y a des distrib linux spécifiques pour big data aussi, parce que unix est payant si je me souviens bien ?
mais bon ça ne m'empêchera pas déjà de tester, là j'ai pris mongoDB pour windows
 
mais bon, tout ça ne fait qu'ajouter de la complexité à ce que je veux faire
parce que je ne vais pas pouvoir me passer des bdd classiques à mon avis, il va falloir prendre en charge les deux types
en tout cas si une bdd nosql peut s'interroger en tcp/ip normalement je peux continuer en c#
 
le truc pas mal c'est que j'utilise du JSON depuis 5ans maintenant pour mon boulot (de ce que dis wiki mongoDB fonctionne en BSON) donc là je suis pas trop perdu