Pour le bulletin de cette semaine, je vous propose les sujets suivants :
Migration 30 Petabytes sur Hadoop pour Facebook
Dans les architectures distribuées de stockage de données, une nouvelle fait le buzz cette semaine. Quand Facebook décide de déplacer ses datacenters, évidement, il y a de l'octet qui se promène. Victime de son trafic, l'ancien datacenter prévu initialement pour 10 PB a atteint dernièrement les 30 PB (avec pas moins de 10 PB généré en une seule année), soit quelques 30 000 000 Go!
Hadoop est le célèbre framework d'Apache pour la gestion de filesystem distribué. Il est utilisé par Facebook pour la gestion interne d'analyse ainsi que les produits additionnels (comme Facebook Ad Network), avec Hive pour la gestion d'un datawarehouse.
Voilà un potentiel sujet pour un prochain challenge USI: comment déplacer 30 PB de filesystem avec une contrainte d'exploitation du système en 24/7, et quelques millions d'utilisateurs de connectés ? (avis aux amateurs de défis !)
Côté infrastructure, 1200 serveurs 8-coeurs ainsi que 800 serveurs 16-coeurs avec chacun 12 To de disque et 32 Go de RAM.
Pour répondre à cette problématiques, les ingénieurs optent pour la solution du basculement total de l'ancien cluster vers le nouveau. Transporter un tel volume de données n'est pas instantané. L'équipe a du développer un système de réplication des changements en continue de l'ancien cluster vers le nouveau, tant que le basculement n'était pas effectué.
L'ajout d'un plugin sur Hive permet d'écrire tous ses changements sources dans un fichier d'audit. Le système de réplication est branché sur ce fichier et reproduit en continu les changements sur le nouveau noeud. Ce système n'est pas sans rappelé le mécanisme Change Data Capture d'Oracle !
Ensuite, l'équipe s'enferme dans une war-room, tire à la courte-paille quel ops devra lancer la commande fatidique, et stoppe l'ancien cluster. Je vous laisse imaginer la petite émotion lorsque le bouton Enter du clavier est pressée. Une fois le tour de magie effectué, et le sanity check passé, un changement de DNS ensuite permettra de rentre le système stable, et le stress des équipes redescendre face à la réussite d'un projet aussi colossal !
Ceci est par ailleurs une excellente publicité faite à Hadoop et Hive pour l'intégration dans le monde de l'entreprise.
A titre de comparaison, le nouvel accélérateur à particules du CERN, le LHC bat des records de collisions. Ses chiffres pourtant prodigieux n'arrivent que difficilement à la hauteur des volumétries de Facebook. Avec plus de 10 000 milliard de collision par an, et plus 1 Mo de données par collision, on atteint la barre des 10 Po par an. Cependant, on ne mesure pas l'octet à la valeur qu'il peut représenter.
Java 7
Ca y est, après une longue attente, Java 7 est sorti la semaine passée, le 28 juillet pour être exact. C'est sous la forme d'OpenJDK, le pendant open-source de l'ancien JDK fermé de Sun qui était jusqu'aux versions 6 l'implémentation de référence, que s'effectue cette sortie.
Nous vous avons tenu au courant assez régulièrement de l'avancement des travaux donc nous ne reviendrons pas en long, large et travers sur tout ce qu'apporte cette version et sur sa gestation pas toujours facile. Alors bien sûr, certains regretteront l'absence des expressions lambda et du projet Jigsaw (modularité) reportés à Java 8, mais ne boudons pas notre plaisir et profitons:
Mais comme toute nouveauté, cette nouvelle version du JDK apporte aussi son lot de douleurs. Apache l'a compris avec un bug sur les projets d'indexation et de recherche Lucene et Solr. Après mise à jour vers le JDK 7, des indexes se sont corrompus et des JVM sont tombées par dizaines avec l'erreur la plus connue des étudiants qui commence en langage C: SIGSEGV ou Segmentation Fault !
Les erreurs se portent sur une partie identifiée du projet, l'algorithme Porter Stemming pour l'optimisation de son moteur de recherche dans la langue de Shakespeare. La réponse apportée par l'équipe d'Apache ne s'est pas fait attendre. Après un premier problème d'optimisation des boucles, des effets de bords des nouvelles locales dans le JDK ou encore avec DataInput.readVInt(). Le premier fix est d'utiliser le paramètre de VM *XX:-UseLoopPredicate.*
Pour Solr, le problème venait principalement du fait que la bonne exécution des tests était dépendantes de l'ordre dans lequel ils étaient écrits. Comme quoi, les principes de réalisations des tests unitaires ne sont pas vains !
Il n'en faut pas moins pour que la blogosphère ne s'enflamme en quelques temps, dans des invectives contre JDK 7 et Apache, à tort. En effet, le problème vient plus d'un bug d'implémentation de HotSpot plutôt que des JSR en elle-mêmes. Le conseil est donc d'utiliser le workaround pour les projets Solr et Lucene, et d'attendre le bug fix d'Oracle. Oracle tente de rassurer les foules par ce billet: les corrections de bug des JVM sont en cours.
Adam Messinger Talks to InfoQ About Java 7 and 8
Following on from last week's release of Java 7, InfoQ spoke to Adam Messinger, Vice President of Development in the Fusion Middleware group at Oracle, to get more information about the release and Oracle's plan for Java 8.
Java Programming Language Enhancements
Enhancements in JDK 7
Java7 Hotspot Loop Bug Details
After Java7's GA release last week, an issue was discovered with one of the optimisations enabled by default with the new JIT. Although originally identified by a use-case in the Lucene search indexer, the problem may be more widespread in other codebases as well.
This prompted a number of alarmist articles, such as "Don't use Java 7 for anything" which implied that all loops were problematic. In fact, although there is a valid bug (in which loops may be incorrectly unrolled or cause SIGSEGV crashes), this optimisation bug has been present since Java 6 if either the -XX:+OptimizeStringConcat or -XX:+AggressiveOpts optimisations are enabled.
In fact, the problem only occurs with specific loops (those which uses conditions which may be mutated by the loop body), as noted in the fix. The problem doesn't occur when running in -Xint (in interpreted mode) but does occur when -server mode, which most server-side applications are likely to use.
JRuby and Java 7: What to Expect
Java 7 has landed, with a modest set of new features and a few major improvements as well. What can you expect from JRuby running on Java 7?
What's In Java 7 The biggest changes in Java 7 are not related to the Java language at all. Sure, there's the "project coin" enhancements to the Java language, which add some exception-handling shortcuts, new literals for numbers, arrays, hashes, the oftrequested "strings in switch" support, and a few other things. But they're modest incremental changes; the real revolution is at the JVM and JDK level.
Invokedynamic
The most important change in Java 7 is the incorporation of a new bytecode -- invokedynamic -- and an API for building chains of "method handles" to back that bytecode up.
GPU Computing with OpenCL
In the past, processor vendors have increased performance by increasing CPU clock rates, but an upper limit is being reached due to factors such as the settling time of CPU circuitry and the dissipation of waste heat. Performance can still be improved by adding additional processors — dual and quad core machines are now becoming commonplace, but adding more than a handful of cores is cost-prohibitive on commodity hardware.
Additional processing power can be achieved by utilizing the GPU of video cards that allow general purpose computing. As far back as 2001, consumer-grade graphics cards from NVidia allowed part of the rendering pipeline to be customized via user-written code, and since then GPUs have advanced to where more general computation is possible. GPU computing is now used in areas such as science, engineering, cryptography, and computer graphics.
As a GPU is designed to execute the same operations on each item of work (such as a pixel of an image, or an element of an array), it can be conceptualized as a large SPMD (Single Program, Multiple Data) processor array supporting data-parallel applications. Applications most suited to this programming model are ones where there is little dependency between the data items in the computation, such as vector addition or image processing. Computations that are task, rather than data, driven, may not benefit as much.
New Feature of JUnit: Rules
I am always surprised how many unknown feature hide in a supposedly simple library. Todays example is JUnit. When inspecting the newest version (4.7) I noted an annotation I hadn't noticed before: @Rule. WTF? I am looking at a testing framework and not at a rules engine, am I? So naturally I tried to find out what it is good for, and since not to much documentation is available my little research resulted in this blog post. Enjoy.
Rules in JUnit 4.9
One of the most useful innovations in the JUnit realm have been Rules. I wrote about Rules here [4]. And I wrote about use cases for JUnit Rules here [5]. Rules are great. And with JUnit 4.9 they get even better.
You can think of Rules as a way to encapsulate setup and teardown of a test in one class instead of two methods. But Rules are also a way to modify the way to execute your tests.
You can run tests a dozen time instead of once. Or in twenty different threads. Interestingly there were only Rules for single tests. So if you want to stick with the comparison with setup and teardown, aka @Before and @After there wasn't a @BeforeClass and @AfterClass equivalent in Rules.
Synchronized vs Lock performance
There are a number of articles on whether synchronized or Locks are faster. There appear to be opinions in favour of either option. In this article I attempt to show how you can achieve different views depending on how you benchmark the two approaches. I have included AtomicInteger to see how a volatile field compares.
- la migration de FaceBook avec 30PB (30 Peta Byte) à déplacer.
- Quelques articles sur le JDK 7 : les nouveautés, les bugs, et les autres langages : JRuby et JDK 7.
- Un article sur OpenCL : comment utiliser la puissance des processeurs graphiques pour faire du calcul.
- JUnit et les règles : dans la version 4.7.
- Les performances des verrou et des synchronizations.
Migration 30 Petabytes sur Hadoop pour Facebook
Dans les architectures distribuées de stockage de données, une nouvelle fait le buzz cette semaine. Quand Facebook décide de déplacer ses datacenters, évidement, il y a de l'octet qui se promène. Victime de son trafic, l'ancien datacenter prévu initialement pour 10 PB a atteint dernièrement les 30 PB (avec pas moins de 10 PB généré en une seule année), soit quelques 30 000 000 Go!
Hadoop est le célèbre framework d'Apache pour la gestion de filesystem distribué. Il est utilisé par Facebook pour la gestion interne d'analyse ainsi que les produits additionnels (comme Facebook Ad Network), avec Hive pour la gestion d'un datawarehouse.
Voilà un potentiel sujet pour un prochain challenge USI: comment déplacer 30 PB de filesystem avec une contrainte d'exploitation du système en 24/7, et quelques millions d'utilisateurs de connectés ? (avis aux amateurs de défis !)
Côté infrastructure, 1200 serveurs 8-coeurs ainsi que 800 serveurs 16-coeurs avec chacun 12 To de disque et 32 Go de RAM.
Pour répondre à cette problématiques, les ingénieurs optent pour la solution du basculement total de l'ancien cluster vers le nouveau. Transporter un tel volume de données n'est pas instantané. L'équipe a du développer un système de réplication des changements en continue de l'ancien cluster vers le nouveau, tant que le basculement n'était pas effectué.
L'ajout d'un plugin sur Hive permet d'écrire tous ses changements sources dans un fichier d'audit. Le système de réplication est branché sur ce fichier et reproduit en continu les changements sur le nouveau noeud. Ce système n'est pas sans rappelé le mécanisme Change Data Capture d'Oracle !
Ensuite, l'équipe s'enferme dans une war-room, tire à la courte-paille quel ops devra lancer la commande fatidique, et stoppe l'ancien cluster. Je vous laisse imaginer la petite émotion lorsque le bouton Enter du clavier est pressée. Une fois le tour de magie effectué, et le sanity check passé, un changement de DNS ensuite permettra de rentre le système stable, et le stress des équipes redescendre face à la réussite d'un projet aussi colossal !
Ceci est par ailleurs une excellente publicité faite à Hadoop et Hive pour l'intégration dans le monde de l'entreprise.
A titre de comparaison, le nouvel accélérateur à particules du CERN, le LHC bat des records de collisions. Ses chiffres pourtant prodigieux n'arrivent que difficilement à la hauteur des volumétries de Facebook. Avec plus de 10 000 milliard de collision par an, et plus 1 Mo de données par collision, on atteint la barre des 10 Po par an. Cependant, on ne mesure pas l'octet à la valeur qu'il peut représenter.
Java 7
Ca y est, après une longue attente, Java 7 est sorti la semaine passée, le 28 juillet pour être exact. C'est sous la forme d'OpenJDK, le pendant open-source de l'ancien JDK fermé de Sun qui était jusqu'aux versions 6 l'implémentation de référence, que s'effectue cette sortie.
Nous vous avons tenu au courant assez régulièrement de l'avancement des travaux donc nous ne reviendrons pas en long, large et travers sur tout ce qu'apporte cette version et sur sa gestation pas toujours facile. Alors bien sûr, certains regretteront l'absence des expressions lambda et du projet Jigsaw (modularité) reportés à Java 8, mais ne boudons pas notre plaisir et profitons:
- du fork/join
- la fermeture automatique des ressources auto-closables
- du support des Strings dans les switch
- du support du symbole underscore '_' dans les nombres comme séparateur, pour une meilleure lisibilité
- du multi-catch d'exceptions
- de l'opérateur diamant apportant une meilleure inférence de type sur la création d'instances génériques
- de Nio 2 (que nous vous avons récemment présenté) et de ses améliorations sur les E/S: l'ajout des Path du service Watchable ainsi que le support des symlinks pour le filesystem, mais aussi de nombreux apports sur les E/S asynchrones et les sockets non bloquants.
- invokedynamic, qui devrait accélérer les langages dynamiques qui l'utiliseront
Mais comme toute nouveauté, cette nouvelle version du JDK apporte aussi son lot de douleurs. Apache l'a compris avec un bug sur les projets d'indexation et de recherche Lucene et Solr. Après mise à jour vers le JDK 7, des indexes se sont corrompus et des JVM sont tombées par dizaines avec l'erreur la plus connue des étudiants qui commence en langage C: SIGSEGV ou Segmentation Fault !
Les erreurs se portent sur une partie identifiée du projet, l'algorithme Porter Stemming pour l'optimisation de son moteur de recherche dans la langue de Shakespeare. La réponse apportée par l'équipe d'Apache ne s'est pas fait attendre. Après un premier problème d'optimisation des boucles, des effets de bords des nouvelles locales dans le JDK ou encore avec DataInput.readVInt(). Le premier fix est d'utiliser le paramètre de VM *XX:-UseLoopPredicate.*
Pour Solr, le problème venait principalement du fait que la bonne exécution des tests était dépendantes de l'ordre dans lequel ils étaient écrits. Comme quoi, les principes de réalisations des tests unitaires ne sont pas vains !
Il n'en faut pas moins pour que la blogosphère ne s'enflamme en quelques temps, dans des invectives contre JDK 7 et Apache, à tort. En effet, le problème vient plus d'un bug d'implémentation de HotSpot plutôt que des JSR en elle-mêmes. Le conseil est donc d'utiliser le workaround pour les projets Solr et Lucene, et d'attendre le bug fix d'Oracle. Oracle tente de rassurer les foules par ce billet: les corrections de bug des JVM sont en cours.
Adam Messinger Talks to InfoQ About Java 7 and 8
Following on from last week's release of Java 7, InfoQ spoke to Adam Messinger, Vice President of Development in the Fusion Middleware group at Oracle, to get more information about the release and Oracle's plan for Java 8.
Java Programming Language Enhancements
Enhancements in JDK 7
Java7 Hotspot Loop Bug Details
After Java7's GA release last week, an issue was discovered with one of the optimisations enabled by default with the new JIT. Although originally identified by a use-case in the Lucene search indexer, the problem may be more widespread in other codebases as well.
This prompted a number of alarmist articles, such as "Don't use Java 7 for anything" which implied that all loops were problematic. In fact, although there is a valid bug (in which loops may be incorrectly unrolled or cause SIGSEGV crashes), this optimisation bug has been present since Java 6 if either the -XX:+OptimizeStringConcat or -XX:+AggressiveOpts optimisations are enabled.
In fact, the problem only occurs with specific loops (those which uses conditions which may be mutated by the loop body), as noted in the fix. The problem doesn't occur when running in -Xint (in interpreted mode) but does occur when -server mode, which most server-side applications are likely to use.
JRuby and Java 7: What to Expect
Java 7 has landed, with a modest set of new features and a few major improvements as well. What can you expect from JRuby running on Java 7?
What's In Java 7 The biggest changes in Java 7 are not related to the Java language at all. Sure, there's the "project coin" enhancements to the Java language, which add some exception-handling shortcuts, new literals for numbers, arrays, hashes, the oftrequested "strings in switch" support, and a few other things. But they're modest incremental changes; the real revolution is at the JVM and JDK level.
Invokedynamic
The most important change in Java 7 is the incorporation of a new bytecode -- invokedynamic -- and an API for building chains of "method handles" to back that bytecode up.
GPU Computing with OpenCL
In the past, processor vendors have increased performance by increasing CPU clock rates, but an upper limit is being reached due to factors such as the settling time of CPU circuitry and the dissipation of waste heat. Performance can still be improved by adding additional processors — dual and quad core machines are now becoming commonplace, but adding more than a handful of cores is cost-prohibitive on commodity hardware.
Additional processing power can be achieved by utilizing the GPU of video cards that allow general purpose computing. As far back as 2001, consumer-grade graphics cards from NVidia allowed part of the rendering pipeline to be customized via user-written code, and since then GPUs have advanced to where more general computation is possible. GPU computing is now used in areas such as science, engineering, cryptography, and computer graphics.
As a GPU is designed to execute the same operations on each item of work (such as a pixel of an image, or an element of an array), it can be conceptualized as a large SPMD (Single Program, Multiple Data) processor array supporting data-parallel applications. Applications most suited to this programming model are ones where there is little dependency between the data items in the computation, such as vector addition or image processing. Computations that are task, rather than data, driven, may not benefit as much.
New Feature of JUnit: Rules
I am always surprised how many unknown feature hide in a supposedly simple library. Todays example is JUnit. When inspecting the newest version (4.7) I noted an annotation I hadn't noticed before: @Rule. WTF? I am looking at a testing framework and not at a rules engine, am I? So naturally I tried to find out what it is good for, and since not to much documentation is available my little research resulted in this blog post. Enjoy.
Rules in JUnit 4.9
One of the most useful innovations in the JUnit realm have been Rules. I wrote about Rules here [4]. And I wrote about use cases for JUnit Rules here [5]. Rules are great. And with JUnit 4.9 they get even better.
You can think of Rules as a way to encapsulate setup and teardown of a test in one class instead of two methods. But Rules are also a way to modify the way to execute your tests.
You can run tests a dozen time instead of once. Or in twenty different threads. Interestingly there were only Rules for single tests. So if you want to stick with the comparison with setup and teardown, aka @Before and @After there wasn't a @BeforeClass and @AfterClass equivalent in Rules.
Synchronized vs Lock performance
There are a number of articles on whether synchronized or Locks are faster. There appear to be opinions in favour of either option. In this article I attempt to show how you can achieve different views depending on how you benchmark the two approaches. I have included AtomicInteger to see how a volatile field compares.
Aucun commentaire:
Enregistrer un commentaire