Devops for Growth

Easy Batch is a framework that aims at simplifying batch processing with Java. It was specifically designed for simple, single-task ETL jobs. Writing batch applications requires a lot of boilerplate code: reading, writing, filtering, parsing and validating data, logging, reporting to name a few.. The idea is to free you from these tedious tasks and let you focus on your batch application's logic.

How does it work?

Easy Batch jobs are simple processing pipelines. Records are read in sequence from a data source, processed in pipeline and written in batches to a data sink:

The framework provides the Record and Batch APIs to abstract data format and process records in a consistent way regardless of the data source/sink type.

Let's see a quick example. Suppose you have the following tweets.csv file:

id,user,message 1,foo,hello 2,bar,@foo hi!

and you want to transform these tweets to XML format. Here is how you can do that with Easy Batch:

Path inputFile = Paths.get("tweets.csv"); Path outputFile = Paths.get("tweets.xml"); Job job = new JobBuilder<String, String>() .reader(new FlatFileRecordReader(inputFile)) .filter(new HeaderRecordFilter<>()) .mapper(new DelimitedRecordMapper<>(Tweet.class, "id", "user", "message")) .marshaller(new XmlRecordMarshaller<>(Tweet.class)) .writer(new FileRecordWriter(outputFile)) .batchSize(10) .build(); JobExecutor jobExecutor = new JobExecutor(); JobReport report = jobExecutor.execute(job); jobExecutor.shutdown();

This example creates a job that:

• reads records one by one from the input file tweets.csv
• filters the header record
• maps each record to an instance of the Tweet bean
• marshals the tweet to XML format
• and finally writes XML records in batches of 10 to the output file tweets.xml

At the end of execution, you get a report with statistics and metrics about the job run (Execution time, number of errors, etc). All the boilerplate code of resources I/O, iterating through the data source, filtering and parsing records, mapping data to the domain object Tweet, writing output and reporting is handled by Easy Batch. Your code becomes declarative, intuitive, easy to read, understand, test and maintain.

Comment créer son format pivot ?

Plusieurs démarches sont possibles pour créer son modèle de formats pivot.

La démarche « top-down »

La démarche « top-down consiste à conceptualiser l’existant métier. Elle préconise de construire ces formats pivot à partir de la sémantique métier de l’entreprise. A partir de ces formats pivot, dans les systèmes, on modifie les traitements et les structures pour qu’elles tiennent compte des ces nouveaux formats, qui peuvent être loin de la réalité technique.
L’intérêt de cette méthodologie est qu’elle permet de mieux s’aligner aux besoins métiers, et donc de mieux répondre aux nouveaux challenges de l’entreprise. Elle permet aussi de profiter pleinement des mutualisations de formats pivot, qui sous-entend la mutualisation de services, et donc une architecture SOA optimisée. La contrainte est qu’elle demande une somme de travail considérable (besoin de cartographier tout le métier du SI pour ensuite le décliner sur les couches basses de développement), et peut induire un coût certain de refonte d’une partie du SI.

La démarche « bottom-up »

La démarche « bottom-up » re-conceptualise l’existant technique. Elle guide le concepteur vers une rétro-conception de l’existant technique, à partir des formats manipulés dans les applications, pour en déduire des formats pivot.
Son gain principal est de réutiliser l’existant, et donc de capitaliser et de gagner du temps sur les développements. De plus, dans le cas de Systèmes d’Informations dans laquelle une application centrale manipule des données avec plusieurs autres systèmes, en partant de données échangées par cette application, on dispose d’un format unitaire cohérent et surtout exhaustif. L’inconvénient de cette démarche est qu’on ne s’aligne pas sur le métier de l’entreprise, il y a donc un risque de césure entre les besoins que peut exprimer la direction métier et les réponses que peut lui apporter la DOSI.

La démarche « meet in the middle »

Cette démarche préconise de mener en parallèle un chantier « Top Down » et un chantier « Bottom Up ». Une fois ces deux chantiers en phase finale, l’objectif est de trouver une passerelle entre ces deux résultats et donc entre les formats pivot orientés métier et les formats pivot orientés techniques. Elle présente les avantages des deux premières méthodes : alignement parfait sur le métier et réutilisation de l’existant. Son principal inconvénient est le risque d’effet « tunnel » qu’elle engendre : attendre la fin des deux chantiers pour construire des formats pivot alternatifs entre une approche métier et une approche technique. Le risque principal est que durant le temps de construction de la passerelle, les besoins métier ou plus vraisemblablement les formats pivot techniques aient changé : les formats pivot alternatifs deviennent alors obsolètes.

La démarche « middle-out »

Cette démarche préconise de commencer à mi-chemin (« middle »)  entre le métier et la direction opérationnelle du SI (DOSI), c’est-à-dire à partir d’un vocabulaire commun aux gens du métier et aux informaticiens. Elle s’attaque au problème principal des projets informatiques actuels : la compréhension des problématiques métier côté IT, et vice-versa. Les deux parties trouvent un consensus par l’intermédiaire d’une base d’entités composants-entités métiers nécessaires, à partir duquel découleront les entités haut niveau côté métier (domaines sémantiques, classes sémantiques…), et les entités bas niveau côté DOSI (objets de type Data Transfert Objects).
Cette démarche peut être complémentaire à la mise en place progressive d’une architecture SOA.
Personnellement, je préfère les deux dernières démarches qui allient pragmatisme et efficacité. La meilleure méthode parmi ces deux dernières est à mon avis de privilégier l’une ou l’autre approche selon les cartes en main de l’entreprise sur ce projet :

• Disponibilités du métier ;
• Degré de compréhension entre la DOSI et le métier ;
• Temps et nombre de ressources allouées à la tâche d’urbanisation…

Comme dans beaucoup de situations, il faut simplement faire preuve de bon sens…

Illustration

 

Edit: I had completely forgotten that there is a relatively new area of the industry around “data engineering” to support data scientists and analysts. ETL to data engineers is more like bash scripts to most coders. It ought to work well just once or maybe periodically but generally doesn't require much effort. Data engineers help get huge amounts of data around their companies and will use Python or SQL or whatever gets the job done.

There's also a completely different scale of “batch” jobs which is where tools like Spark, Flink, and MapReduce come in. These tools can also be used for significantly more complex processing and analysis in addition to just moving data around.