Posts

Tři P můžou znamenat cokoliv, v tomto případě jsou to: lidé (people), procesy a politiky a v těchto kategoriích si můžeme klást následující otázky:

People:

• Kdo je business vlastníkem služeb?
• Kdo používá naše služby?
• Kdo je za služby techn(olog)icky zodpovědný?

Procesy:

• Které procesy definují politiky?
• Jaké business procesy závisí na našich službách?
• Je zde proces pro životní cyklus služeb?

Politiky

• Jaké politiky jsou pro naše služby definované?
• Jak jsou politiky aplikované během design a runtime fáze?

Tyto otázky bychom měli mít do určité míry zodpovězené. S jejich tvorbou a udržováním by nám měl  pomoci vhodný nástroj.

3 části politiky

Politika se skládá ze tří částí:

• tvrzení (policy assertion),
• vlastníka (policy owner)
• a prosazení/vynucení (policy enforcement).

Tvrzení známe i z jiných IT domén, např. unit testy. Tvrzení by mělo být měřitelné a mělo by mít disjunktní odpověď pravdivé/nepravdivé (true/false). Vlastník politiky je jasný - je za politiku zodpovědný, udržuje ji atd.

Prosazování politiky může probíhat dvěma způsoby. Buď technologicky, nějakým automatizovaným nástrojem, nebo pomocí review. Obojí opět známe odjinud, např. automatizovaná statická analýza zdrojového kódu vs. “ruční” review.

3 oblasti podpory SOA governance

Nástroj pro SOA governance by nám měl pomoci ve třech oblastech:

• Vytváření a správa politik.
• Aplikování těchto politik v design fázi.
• Aplikování těchto politik v runtime fázi.

V případě prvních dvou bodů pomůže repository, kde se dají politiky a služby zaregistrovat. V případě služeb (design fáze) bude ještě potřeba o nich udržovat metadata. Pro runtime fázi bude potřeba nějaký monitorovací nástroj, v SOA se běžně používají řešení, která spadají do kategorie Business Activity Monitor (BAM).

Příklady politik

Aby jsme si pod politikami představili něco konkrétního, uvedu pár příkladů.

Design-time politiky:

• Nevytváříme duplicitní služby. Tohle bývá těžký, nápomocná může být impact analýza. Služba se většinou v čase mění, přibývají nové funkčnosti a využití a tak časem může dojít i k rozštěpení služby na dvě. Při změnách v čase je potřeba mít neustále na paměti zpětnou kompatibilitu kontraktu služby.
• Technologická standardizace. Velkou část za nás řeší zvolená SOA platforma, ale některé věci je potřeba definovat politikou. Např. interní služby používají REST, externí služby jedou přes WS-*.
• Validace zpráv. Celkem jasný. Problém bývá validaci vůbec zapnout.

Runtime politiky:

• Dostupnout služby 24x7. Služba buď běží, nebo neběží. Tohle souvisí se Service Level Agreement (SLA).
• Služby používají zabezpečený kanál. HTTPS atd.
• Služby jsou “sebe-popisné” (self-describing). Tohle může být i součástí design fáze. V runtime je to myšleno tak, že po deploymentu je služba použitelná i bez dodatečné dokumentace.

Co dál?

Tak. To je momentálně asi všechno, co k tomu můžu obecně napsat, aniž bych zmiňoval konkrétní nástroj. Jestli se nám nějaký podaří na projektu rozjet, tak nějaký článeček určitě přibude.

Jak se nám tak rozrůstá aktuální projekt (a postupuje k nasazování na další prostředí), vyvstala nám potřeba branchovat zdrojový kód. V Perforce (P4) se dá jednak klasicky branchovat, nebo se dají používat streamy. Protože streamy poskytují pro správu kódu daleko větší komfort, vybrali jsme si právě tento způsob.

Prozatím jsem byl pouhým uživatelem Perforce (P4). Používám ho už na druhém projektu a začínám mu přicházet na chuť :-)  Chtěl jsem si něco nastudovat ohledně streamů, které asi začneme brzy používat, ale protože nemám na projektu administrátorský práva, který jsou pro založene stream depotu potřeba, nainstaloval jsem si P4 lokálně. O streamech určitě napíšu někdy příště, nyní něco k jednoduché instalaci.

Instalace Perforce Serveru

Instalace Perfoce Serveru (P4D) je velmi rychlá a jednoduchá. Popíšu instalaci pro vývojářské účely - do domovského adresáře. Pro "opravdový" nasazení by přibyly pouze dva kroky: vytvoření uživatele (a ev. skupiny), pod kterým P4D poběží a vytvoření root adresáře pro depot.

Instalaci zahájíme stažením serveru (P4D) a řádkového klienta (P4) z download stránky. Doporučuji stáhnou i grafického klienta (P4V).

1. Vytvoříme pracovní adresář (root depotu).
2. Zkopírujeme soubory p4d a p4 do $PATH a nastavíme spustitelný příznak.
3. Nastavíme proměnnou P4PORT, port na kterém P4D naslouchá. (P4PORT je důležitá i pro klienta a nastavuje se v ní host i port.)
4. Nastavíme proměnnou P4ROOT, root adresář depotu.
5. Spustíme server jako daemon příkazem p4d -d.
6. Server můžeme zastavit příkazem p4 admin stop.

Instalace P4D

Přidání souborů do depotu

Přidání souborů do depotu

P4 depot

Perforce (P4) je komerční version control system (VCS) se spoustou zajímavých vlastností. Jeho asi nejsilnější stránkou jsou vizuální nástroje na správu branchů/streamů a mergování souborů. Největším úskalím, na které může narazit vývojář se zkušeností s "běžnými" open source VCS nástroji àla SVN, je "trochu jiná" filozofie, se kterou Perfoce ke správě verzí přistupuje. Jednou takovou věcí je vytvoření ignore-listu souborů/adresářů, které nechceme komitovat do repository (depot v řeči P4).

Jako hlavní klient pro P4 je určen Perforce Visual Client (P4V), v aktuální verzi 2012.1, která ignore-list umí. Jelikož ale starší verze P4V klasický ignore-list, jak ho známe např. z CVS, SVN, Gitu apod., neumějí a vzhledem k tomu, že je P4 komerční (a tak se ve firmách/na projektech jen tak upgradovat nebude), nebude na škodu si říct, jak ignore-list "vyrobit" ve starších verzích. Následující popis je pro verzi 2011.1.

Ignorování souborů/adresářů se v P4V nastavuje na úrovni workspace a to pomocí mapování depotu (repository) na lokální workspace. Funguje to dobře, ale má to dvě nevýhody - jednak je potřeba ignorování nastavit pro každý workspace (kterých můžu mít víc, např. pro branchování) a jednak nejde ignorování sdílet mezi vývojáři, tj. nastavit je pouze jednou pro daný projekt. Pokud tedy máme tyto skutečnosti na paměti, můžeme se pustit do nastavení:

1. V menu View -> Workspaces, nebo ikona .
2. Kliknout pravým tlačítkem na daný worskpace -> Edit workspace <workspace>.
3. V sekci Workspace Mappings kliknout na View workspace mapping as a text.
4. Přidat řádky pro ignorování. Důležitý je znak mínus před rootem depotu (-//). Tři tečky (...) znamenají libovolnou hierarchii adresářů.

-//mw/.../SCA-INF/...  //<workspace>/mw/.../SCA-INF/...
-//mw/.../deploy/...   //<workspace>/mw/.../deploy/...
-//mw/.../classes/...  //<workspace>/mw/.../classes/...

Pokud si pohled překlikneme zpátky pomocí View workspace mapping as a tree, měli bychom vidět něco takového:

P4 workspace s ignorovanými adresáři

Měl jsem teď takovou dvoudenní chřipku... což je ideální čas, dohnat na internetu to, co normálně nestíhám, tedy videa, přednášky apod. Na Hadoop mám už políčeno cca rok, ale pořád jsem se k tomu nemohl nějak dostat. Shodou okolností jsem před pár dny narazil na stránky Big Data University, kde lidé z IBM mmj. nabízejí zdarma kurz Hadoop Fundamentals I.

Kurz je dobře udělaný (videa, přepisy textu, laby), není dlouhý (dá se zvládnout za den) a dá solidní přehled o technologiích kolem Hadoopu. Plus vše se dá vyzkoušet na VMware imagi, která je k dispozici na stránkách IBM. Byť to byl kurz krátký, byl velmi výživný, takže si sám pro sebe udělám takové jakési review, abych to pořádně vstřebal.

Co je to Hadoop?

Hadoop je framework vyvíjený pod křídly Apache Software Foundation (ASF), který umožňuje distribuované zpracování velkých data setů (Big Data).  Hadoop je založen na dvou stěžejních technologiích pocházejících od Googlu - distribuovaný filesystem Google File System (GoogleFS, GFS) a algoritmus MapReduce. Jelikož je GoogleFS proprietární, obsahuje Hadoop vlastní implementaci distribuovaného filesystemu - Hadoop Distributed File System (HDFS). Stejně tak má Hadoop vlastní implementaci MapReduce enginu nazvanou Hadoop MapReduce. Obě komponenty jsou napsané v Javě.

Hadoop Distributed File System (HDFS)

HDFS je distribuovaný filesystem, určený pro komoditní hardware (takže nepotřebuje drahé high-end servery), a který je provozovaný jako abstrakce nad nativním filesystemem. Pro ukládání souborů používá bloky o velikosti 64 MB (default), nebo 128 MB (recommended), které jsou replikovány na jednotlivé uzly Hadoop clusteru.

Replikace HDFS bloků

Jednotlivé uzly Hadoop clusteru jsou sdruženy do tzv. racků (racks), jejichž souhrn pak tvoří právě onen cluster. Rack je sdružení uzlů do logické jednotky. Pokud je potřeba síťová komunikace mezi jednotlivými uzly, je preferovaná komunikace v rámci jednoho racku. Naopak u replikace je vhodné, aby byla vytvořena do jiného racku (přesněji, jedna replika bloku je vytvořena v tomtéž racku a jedna je vytvořena v jiném).

Hadoop cluster

HDFS je založený na architektuře master/slave. Hadoop cluster obsahuje jediný master server - NameNode, který spravuje jmenný prostor a metadata filesystemu a také reguluje přístup klientů k souborům. Ostatní uzly v clusteru jsou typu DataNode a slouží k ukládání bloků dat, které pak vystavují klientům. DataNody periodicky reportují NameNodu seznam bloků, které jsou na nich uloženy.

HDFS uzly v Hadoop clusteru

HDFS commands

Pro práci s HDFS se používá podmnožina POSIX-like příkazů, jejich kompletní přehled (a reference) je na stránce Hadoop Shell Commands. Podobnou informaci můžeme dostat přímo z příkazové řádky některým z příkazů:

• hadoop fs
• hadoop fs -help
• hadoop fs -help <příkaz>

Nápověda Hadoop shellu

Obecný HDFS příkaz má tvar (důležitá je ta pomlčka před příkazem):

• hadoop fs -<příkaz>

Příklad použití HDFS příkazů je na následujícím obrázku. K tomu je potřeba poznamenat, že Hadoop přebírá uživatele a práva z hostujícího (unix) systému. Uživatel je tedy stejný jako výsledek příkazu whoami a skupiny jsou získány příkazem bash -c groups.

Příklad HDFS příkazů

V předšlém příkladu je nejprve uživatelem root vytvořen adresář /user/guido, následně je změněn vlastník adresáře na guido. Pak si již uživatel guido nakopíruje z lokálního filesystemu na HDFS soubor a zjistí jeho velikost.

Příště

V průběhu psaní se mi článek trochu rozrostl, takže jsem se rozhodl ho rozdělit do více částí. V té následující bych se chtěl věnovat Hadoop MapReduce a v ještě další (a zatím předpokládám, že závěrečné) bych chtěl probrat způsoby dotazování nad Hadoopem, tedy nástroje jako Pig, Hive a Jaql.