Amazon tramite EMR ci permette di creare un cluster Hadoop e pagare per il tempo che questo è utilizzato. Per questa motivazione gli scripts Apache Pig vengono posizionati su S3 (Simple Storage Service) e questo viene configurato a runtime quando lanciamo un cluster Hadoop e indichiamo che deve essere installato anche Pig e invocato il nostro script.

Purtroppo online non sono presenti scripts PHP per la creazione e configurazione di questo cluster Hadoop con supporto Pig. Propongo quindi uno di quelli che utilizzo io per la produzione, quindi non sono presenti le richieste di debugging.

<?php

define('INPUT_FOLDER', 's3://your-input-bucket');
define('OUTPUT_FOLDER', 's3://your-output-bucket/hadoop/output');
define('SCRIPTS_FOLDER', 's3://your-output-bucket/hadoop/scripts');

$emr = new AmazonEMR(array('key' => 'your-key', 'secret' => 'your-secret'));
$emr->set_region(AmazonEMR::REGION_EU_W1);

//Use your glob spec.
$inputGlob = 'prefix-' . date('Y-m-d') . '*';
$outputFolderName = date('Y-m-d');

$response = $emr->run_job_flow('my-hadoop-job', array(
    'Ec2KeyName' => 'indexer',
    'HadoopVersion' => '0.20',
    'KeepJobFlowAliveWhenNoSteps' => 'false',
    'InstanceGroups' => array(
        array( // Group #1
            'InstanceCount' => 1,
            'InstanceRole' => 'MASTER',
            'InstanceType' => 'm1.small',
            'Market' => 'ON_DEMAND',
            'Name' => 'my-hadoop-cluster',
        )
    ),
    'Placement' => array(
        'AvailabilityZone' => 'eu-west-1a'
    )
), array(
    'Steps' => array(
        new CFStepConfig(array(
            'Name' => 'Install Pig',
            'ActionOnFailure' => 'TERMINATE_JOB_FLOW',
            'HadoopJarStep' => CFHadoopStep::install_pig()
        )),
        new CFStepConfig(array(
            'Name' => 'Run Pig Script',
            'ActionOnFailure' => 'TERMINATE_JOB_FLOW',
            'HadoopJarStep' => CFHadoopStep::run_pig_script(
                SCRIPTS_FOLDER . '/my-script-log.pig',
                array(
                    'p',
                    'INPUT=' . INPUT_FOLDER . "/" . $inputGlob,
                    'p',
                    'OUTPUT=' . OUTPUT_FOLDER . "/" . $outputFolderName
                )
            );
        ))
    )
)
);

In questo script viene semplicemente configurato un bucket S3 da cui leggere i files (utilizza un glob basato sulle date e prefisso) ed un punto di uscita sempre su bucket S3 creando una cartella con la data del lancio dello script.

Avviando questo script viene creato il cluster su EMR ed avviato. Viene configurato il cluster tramite due step, il primo installa Apache Pig ed un secondo che avvia il nostro script residente su S3 a cui vengono passati due parametri INPUT ed OUTPUT che possono essere utilizzati dal nostro script Apache Pig per le operazioni di “Store” e di “Load”.

Originally submitted at O’Reilly

Dataflow Scripting with Hadoop

Programming Pig

Great book, clear and well written

Pros: Concise, Easy to understand, Well-written, Accurate

Best Uses: Novice, Intermediate

Describe Yourself: Developer

Very good, it covers a lot of Pig features from the beginning to advanced features.

(legalese)

Tutto quello che già sappiamo sulla configurazione di un server SOAP tramite Zend rimane comunque valido, per esempio la gestione obbligatoria dei commenti DocBlocks per permettere all’autodiscover di stabilire il tipo delle proprietà e quindi generare le giuste dichiarazioni dei tipi.

Vediamo subito come costruire il server:

<?php 

class Example_BaseController
    extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->_helper->layout()->disableLayout();
        $this->_helper->viewRenderer->setNoRender();

        if($_SERVER['REQUEST_METHOD'] == 'GET') {
            $autodiscover = new Zend_Soap_AutoDiscover('Zend_Soap_Wsdl_Strategy_ArrayOfTypeSequence');
            $autodiscover->setBindingStyle(array('style'=>'document'));
            $autodiscover->setOperationBodyStyle(array('use' => 'literal'));
            $autodiscover->setClass('MyService');
            $autodiscover->handle();
        } else {
            $soap = new Zend_Soap_Server("http://tr.local/example/base/?wsdl", array('cache_wsdl' => false));
            $soap->setClass('MyService');
            $soap->handle();
        }
    }
}

In questo esempio ho predisposto che la classe del servizio si chiama “MyService”. Ne pubblico un esempio di implementazione:

<?php
class MyService
{
    /**
     * @param string $name
     * @return MyObj
    public function getFromMyMethod($name)
    {
        $o = new MyObj();
        $o->name = "hello";

        return $o;
    }
}

<?php
class MyObj
{
    /**
     * @var string $name
     */
    public $name;
}

Come possiamo vedere non è molto complesso realizzare il server. Le modifiche necessarie sono solo relative al BindingStyle ed al OperationBodyStyle che devono essere rispettivamente di tipo “document” ed utilizzare il “literal”. Un altra particolarità è il tipo di definizione per l’autodiscover che è un “ArrayOfTypeSequence”.

A questo punto è possibile generare il codice Java o C# sul WSDL generato dall’autodiscover Zend. Otterremo un servizio con un metodo “getFromMyMethod” che restituisce un oggetto “MyObj” contente una proprietà di tipo “string” con nome “name”.

Personalmente seguo un sistema di pubblicazione basato si sistemi di versioning, tipicamente utilizzo GIT ma spesso anche SVN. Rimane comunque un problema dover andare a gestire gli aggiornamenti quando si hanno diversi server in cluster. Per risolvere questo problema ho navigato diverse soluzioni, anche provando hooks di post commit, sia di GIT che di SVN ma spesso è necessario realizzare anche altre operazioni, quindi mi sono mosso verso i Rakefile per automatizzare procedure, oppure sui files Ant. Molto flessibili ed ottimi, forse Rake è anche più elegante rispetto agli Ant files. Manca però sempre qualcosa, soprattutto per quello che riguarda un primo deploy ed altri aspetti.

Mi sono quindi deciso ed ho iniziato a studiare da qualche tempo Capistrano che è realizzato in Ruby ed ha proprio come obiettivo l’automazione di processi remoti. Capistrano è un prodotto eccezionale, sono favorevolmente colpito ed ora dopo averlo messo in produzione per qualche tempo credo proprio di non poterne fare più a meno.

La prima domanda che mi sono posto dopo il lancio di DynamoDB è stata sul futuro di SimpleDB e subito sulle pagine di Amazon possiamo trovare una eloquente digressione sulle differenze, dove in pratica si evince che DynamoDB è realizzato per essere veloce e scalabile.

DynamoDB sembra essere un prodotto fantastico e da qualche giorno mi dedico allo studio delle sue funzionalità e la possibilità di integrarsi con i vari servizi di Amazon come S3 ed Elastic MapReduce.

Spero di avere il tempo presto di scrivere e mostrare qualche esempio sull’utilizzo di questa piattaforma che farà sicuramente parlare di se nel futuro.

Il componente è molto flessibile e configurabile, questo lo rende ottimo per l’inziezione delle dipendenze. In particolare il componente è diviso in diverse sezioni e può essere configurato in diverse modalità per potergli far dirigere l’iniezione delle dipendenze.

Il metodo più semplice e veloce è utilizzare la definizione forte dei tipi in modo che autonomamente possa capire quali oggetti andare ad iniettare per costruire tutte le dipendenze. Le parti non fortemente dichiarate, come stringhe e tipi  base (scalari), possono essere dichiarate nel configuratore e ottenere un risultato semplice e veloce.

Possiamo vedere un esempio molto chiaro proposto da Ralph Schindler (puoi controllare l’originale sull’account github di Ralph Schindler)

<?php

namespace MovieApp {

    class Lister implements FinderAwareInterface {
        public $finder;
        public function setFinder(Finder $finder){
            $this->finder = $finder;
        }
    }

    class Finder {
        public function findAllByName($name) {}
    }

    interface FinderAwareInterface {
        public function setFinder(Finder $finder);
    }
}

namespace {
    // bootstrap
    // ... start autoloader

    $di = new Zend\Di\Di;
    $lister = $di->get('MovieApp\Lister');

    // expression to test
    $works = ($lister->finder instanceof MovieApp\Finder);

    // display result
    echo (($works) ? 'It works!' : 'It DOES NOT work!');

}

L’applicazione esegue la “get” ed è compito del DiC andare a costruire tutte le dipendenze e restituire l’oggetto correttamente inizializzato.

La cosa che mi ha colpito subito di questo nuovo sistema è la possibilità di utilizzare la “Annotations” invece di utilizzare files XML oppure YAML per la generazione dei modelli. Questo mi rende molto contento in quanto non sono costretto a delegare le informazioni in files paralleli ma posso realizzare una mappatura manuale in modo veloce e mantenendo collegata l’informazione di come è strutturata la base sui modelli.

La direzione dei modelli non è quindi più collegata ad un utilizzo pesante dell’ereditarietà come nella release precedente ma tramite un “Entity Manager” che si occupa di giostrare i nostri modelli.

Ho reso disponibile su github i miei primi passi con questa seconda versione di Doctrine per approfondire l’argomento visto la notevole lista di funzionalità che sono state create dal team di sviluppo che lo rendono uno strumento molto appetibile!

Stillmaintained.com è un servizio utile per informare gli utilizzatori dei nostri prodotti opensource sullo stato del prodotto, ovvero se è ancora mantenuto (still mantained), non mantenuto ed in cerca di qualcuno che lo gestica, completamente non mantenuto etc etc.

Ho già attivato alcuni progetti per l’utilizzo di questa risorsa come Zend WordPress e PHP Diff che sono disponibili sul mio account github.

Ho analizzato ed utilizzato PHPUnderControl per la continuous integration in PHP ed ho iniziato a vedere anche Jenkins sempre per il PHP. Il primo ostacolo è sempre l’hosting del sistema di controllo e la continua e costante manutenzione che è necessaria su tutti i sistemi che porta via già il poco tempo a disposizione della giornata. Travis CI è una soluzione di Continuous Integration per prodotti completamente OpenSource con una connessione diretta su GitHUB.

La soluzione sviluppata dal team di Travis è semplice elegante e molto funzionale anche se ancora in Alpha state. Allego alcune screen-shot a questo articolo per farvi saggiare la bontà dello strumento.

Travis si configura con un semplice file YAML con un nome di default .travis.yml

Silex è traghettato agli sviluppatori, oltre che come codice sorgente, come pacchetto Phar, il nuovo gestore pacchetti di PHP, credo ispirato ai JAR (ma potrei sbagliarmi anche qui).

Il funzionamento base di Silex ruota intorno alle closures PHP introdotte nelle versioni di PHP 5.3 insieme ai namespaces. Un esempio introduttivo è veramente semplice ed include già una potenza e flessibilità incredibile…

<?php
require_once __DIR__.'/silex.phar';

$app = new Silex\Application();

$app->get('/hello/{name}', <strong>function ($name) use ($app) { return 'Hello '.$app->escape($name); }</strong>);

$app->run();

Dopo aver caricato il pacchetto viene creata l’applicazione e tramite il router viene insegnato all’applicazione che esiste una “strada” di nome “hello” che ha un parametro di nome “name” che viene gestito nella closure evidenziata.

Se proviamo a chiamare la strada indicata vedremo una pagina web composta semplicemente da “Hello” con un nome indicato nel parametro, quindi se chiamo “/hello/walter”  vedremo in uscita “Hello walter”. Esempio semplice ma già carico di significati e interessanti proprietà.

Le funzionalità sono veramente tante per Silex, come l’aggiunta di Twig come gestore template e altri providers per la gestione databases e tanto tanto altro come  una gestione in controllers per avvicinarsi ad un pattern MVC completo.

Vediamo ora un esempio più complicato di utilizzo di Silex con Twig ed un provider per incapsulare delle sezioni.

<?php
require_once __DIR__.'/silex.phar';

$app = new Silex\Application();

error_reporting(E_ALL);
ini_set('display_errors', 'On');

$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path'       => __DIR__.'/views',
    'twig.class_path' => __DIR__.'/vendor/twig/lib',
));

$app->get('/', function(){echo "Hello";});

$app['autoloader']->registerNamespace('Wdm', __DIR__);
$app->mount('/blog', new Wdm\HelloControllerProvider());

$app->get('/hello/{name}', function ($name) use ($app) {
    return $app['twig']->render('hello.twig', array(
        'name' => $name,
        'other' => array('eg' => 'walter-eg')
    ));
});

$app->run();

Vediamo che la direttiva “register” aggiunge un nuovo Service Provider, in questo caso Twig per la gestione dei templates. Successivamente viene introdotta l’HelloControllerProvider per la gestione della sezione chiamata “blog”.

Il Controller Provider è molto semplice e ne vediamo subito il contenuto

<?php
namespace Wdm;

use Silex\Application;
use Silex\ControllerProviderInterface;
use Silex\ControllerCollection;

class HelloControllerProvider implements ControllerProviderInterface
{
    public function connect(Application $app)
    {
        $controllers = new ControllerCollection();

        $controllers->get('/', function (Application $app) {
            return $app->redirect('/hello/wally');
        });
        $app->get('/blog/{name}', function ($name) use ($app) {
            return $app['twig']->render("blog/" . $name . '.twig', array(
                'name' => $name,
                'other' => array('eg' => 'walter-eg')
            ));
        });

        return $controllers;
    }
}

Silex è veramente flessibile e molto interessante, spero di poterlo introdurre presto nell’ambito dei progetti che incontro sulla strada…