Making PrescriptionsPpersonal - Pharmacogenomics reports - Software in MedicineGDG Budapest
10 éven belül valóra válhatna az a még
kissé futurisztikusnak tűnő kép, hogy mindenkiről egy genetikai
polimorfizmus adattár áll rendelkezésre mondjuk a háziorvosnál
Making PrescriptionsPpersonal - Pharmacogenomics reports - Software in MedicineGDG Budapest
10 éven belül valóra válhatna az a még
kissé futurisztikusnak tűnő kép, hogy mindenkiről egy genetikai
polimorfizmus adattár áll rendelkezésre mondjuk a háziorvosnál
A webes alkalmazások készítése – de leginkább karbantartása – során kevés figyelmet fordítunk ezek sebességének optimalizálására, vagy lehet csak egyszerűen nem kapunk rá elég prioritást a folyamatosan érkező üzleti igények árnyékában. Hosszútávon, így egy olyan mély gödröt áshatunk, amiből nagyon nehéz kimászni. Az előadásban leginkább saját tapasztalatok alapján összegyűjtött megoldásokról fogok beszélni, hogy ezeket a problémákat hatékonyan lehessen kezelni, jobb esetben megelőzni.
A Pannon Egyetemen fejlesztett felhő alapú workflow rendszer (ORENBI) back-end oldali fejlesztése alapján a Műszaki Informatikai karon tartott tanszéki szeminárum során előadott prezentációnk. A prezentáció témája az alkalmazott technológiák és architektúrális valamint TDD módszereink bemutatása és tapasztalataink átadása.
III. Elmélet - Az ERP rendszerek implementációja 1..pptxSzabolcs Gulyás
III./a Theory: Implementation of ERP systems 1.
• The importance of project planning
• Types and pitfalls of education
• Planning and handover of customizations
III./b: Practice: Technology
• Management of resources
• Creating technology (finished product, semi-finished product)
A webes alkalmazások készítése – de leginkább karbantartása – során kevés figyelmet fordítunk ezek sebességének optimalizálására, vagy lehet csak egyszerűen nem kapunk rá elég prioritást a folyamatosan érkező üzleti igények árnyékában. Hosszútávon, így egy olyan mély gödröt áshatunk, amiből nagyon nehéz kimászni. Az előadásban leginkább saját tapasztalatok alapján összegyűjtött megoldásokról fogok beszélni, hogy ezeket a problémákat hatékonyan lehessen kezelni, jobb esetben megelőzni.
A Pannon Egyetemen fejlesztett felhő alapú workflow rendszer (ORENBI) back-end oldali fejlesztése alapján a Műszaki Informatikai karon tartott tanszéki szeminárum során előadott prezentációnk. A prezentáció témája az alkalmazott technológiák és architektúrális valamint TDD módszereink bemutatása és tapasztalataink átadása.
III. Elmélet - Az ERP rendszerek implementációja 1..pptxSzabolcs Gulyás
III./a Theory: Implementation of ERP systems 1.
• The importance of project planning
• Types and pitfalls of education
• Planning and handover of customizations
III./b: Practice: Technology
• Management of resources
• Creating technology (finished product, semi-finished product)
3. A ereje
Google I/O Extended Budapest 20143
• Többmiliárd keresés másodpercenként
• 6 milliárd órányi YouTube videó havonta
• 425 millió Gmail felhasználó
4. A infrastruktúrája
Google I/O Extended Budapest 20144
• Fejlett globális hálózat
> Sok ezer km optikai kábel
• Redundancia
> A világ minden pontján jelen van
• A számítástudomány élvonala
> Trendeket teremt a szoftveriparban
5. Középpontban a termék
Google I/O Extended Budapest 20145
• Nem kell rendszeradminisztrációval foglalkozni
• A Google vállalja a menedzsmentet
> Adatbázis adminisztráció
> Szerver konfiguráció
> Terhelés kiegyensúlyozás
• Fejlesztőeszközök ismerős környezetekhez
• Teljesítmény monitorozás és finomhangolás egy
egyszerű, összevont webes konzolon keresztül,
vagy parancssorról
6. Skálázhatóság
Google I/O Extended Budapest 20146
• Menedzselt szolgáltatások
> Automatikusan skálázódnak a felhasználók
számának növekedésével!
• Nyers szolgáltatások
> Gyorsan és egyszerűen lehet új erőforrásokat
beépíteni
> Költséghatékonyság: csak azért kell fizetni, amit
valóban használsz
> Akár több száz szerver néhány órára
9. App Engine
Google I/O Extended Budapest 20149
• Népszerű nyelvek és keretrendszerek
> Python, Java, PHP, Go
> Django, Flask, Spring, stb.
• A fejlesztő feladata a kód megírása (utópia)
• Különböző adattárolási lehetőségek
> Cloud SQL: hagyományos MySQL
> Datastore: sémátlan NoSQL adatbázis
> Cloud Storage: felhő alapú objektumtár
10. App Engine
Google I/O Extended Budapest 201410
• Beépített szolgáltatások
> Pl. Memcache
• Megszokott fejlesztőeszközök
> Eclipse, IntelliJ, Maven, Git, PyCharm, stb.
• Tesztelés a fejlesztő gépén
• Akár napi 7 milliárd kérés kiszolgálása
13. Compute Engine
Google I/O Extended Budapest 201413
• Nagyteljesítményű virtuális gépek
> A feladatnak megfelelő konfiguráció választható
> Linux VM-ek: jól konfiguráltak, biztonságosak
• Kihasználják a Google hálózati kapacitásait
> Komoly cluster-ek építhetők
• Adatközpontok USA-ban, Európában, Ázsiában
• A gépek indítása nagyon egyszerű
> RESTful API, parancssor, webes konzol
14. Árak
Google I/O Extended Budapest 201414
• Az App Engine ingyenes! (egy kvóta eléréséig)
• Valóban csak a használatért kell fizetni
• Compute Engine
> 1-16 mag, 2-100GB RAM, $0.07-$1.3/óra
> Memória és CPU aránya variálható
• Háttértár(100GB/hó): HDD $4, SSD $33
17. A Hadoop gyökerei
Google I/O Extended Budapest 201417
• Google publikációk
> 2003 - The Google File System
> 2004 - MapReduce: Simplified Data Processing on
Large Clusters
• A Yahoo! felkarolta, 2005-ben készült el
• Ma Apache License alatt áll
• 2012-től jelentős változások, új generáció
18. Mi az a Hadoop?
Google I/O Extended Budapest 201418
• Szűk értelemben 2 technológia együttműködése
> HDFS - Hadoop Distributed Filesystem
> YARN - Yet Another Resource Negotiator
(MapReduce v2 és még sok más)
• Nagy (tényleg!) méretű adatfeldolgozó clusterek
• Viszonylag olcsó, hétköznapi szervereken
• Tágabb értelemben egy egész ökoszisztéma
19. Célok - HDFS
Google I/O Extended Budapest 201419
• Több millió nagy file tárolása
> Akár egyenként több tíz GB
> Összességében akár PB nagyságrend
• Horizontális skálázódás
> RAID helyett JBOD modell
> Adat replikáció az alkalmazásrétegben
20. Célok - HDFS
Google I/O Extended Budapest 201420
• Nagy átbocsátóképességre optimalizált
> Előnyben a batch jellegű stream I/O a kis
késleltetésű, interaktív hozzáférésekkel szemben
• A gépek tönkremennek, főleg a lemezek
> Nem különleges eset, napi rutin
• Együttműködés a YARN-nal
> Helyben való feldolgozás
21. Célok - YARN
Google I/O Extended Budapest 201421
• Egyszerű fejlesztés elosztott környezetben
> Nincs socket programozás
> Nem kell foglalkozni szálakkal, szinkronizációval
> Semmi különös technikára nincs szükség óriási
mennyiségű adat kezeléséhez
• Skálázhatóság
> Állapotmentes taszkok, nem kommunikálnak
közvetlenül (share nothing system), bármely gépen
futhatnak
> Teljesen átlátszóan bővíthető a cluster
22. Célok - YARN
Google I/O Extended Budapest 201422
• Automatikus párhuzamosítás, terheléselosztás
> A fejlesztőnek elég a logikát megírnia
> A keretrendszer ott futtatja, ahol az adat van
• A hibák mindennaposak
> Hibás node-ok detektálása
> Taszkok automatikus újrafuttatása
> Egy taszk vagy teljesen lefut, vagy eldobjuk és
újrafuttatjuk
23. Google I/O Extended Budapest 201423
• Social media óriás
> Több mint 100 petabyte adat
> Több száz milliárd fotó
> Több száz millió új fotó naponta
• Facebook Messaging
> Hadoop áll mögötte
• Reportok készítése
> Fejlesztőknek, elemzőknek, termékmenedzsereknek,
reklámpartnereknek
24. Egy tipikus Hadoop cluster
Google I/O Extended Budapest 201424
• 100 node (5 rack)
• Tipikus node:
> 3 GHz-es dual hex core CPU
> 64-378 GB RAM
> 24-36 TB lemezterület (6-10 TB effektív tárterület)
• Az egész cluster:
> 6.4-37.8 TB RAM (RAM!!! Wow…)
> Akár 1 PB effektív tárterület
> A Facebook clustere nem tipikus…
25. De mit lehet ezzel kezdeni?
Google I/O Extended Budapest 201425
• TB-os nagyságrendű adatok feldolgozása
memóriában egyszerűen és hibatűrően
> Apache Spark, a MapReduce trónfosztója
> Java, Scala és Python
> Stream-feldolgozás, adatbányászat, gépi tanulás,
ETL, felderítő adatelemzés, gráf számítások, stb.
26. De mit lehet ezzel kezdeni?
Google I/O Extended Budapest 201426
• PB-os nagyságrendű adatok interaktív kezelése
> Cloudera Impala, az első valódi SQL-on-Hadoop
> Valóban gyors lekérdezési sebesség
> Analitikus lekérdezésekben gyilkos
> Adattárház Hadoop alapon
27. Hol jön képbe a Google Cloud?
Google I/O Extended Budapest 201427
• Durva becslés: minden TB kapacitás kb. $1000
• Egy valamirevaló Hadoop cluster komoly
befektetés már a fejlesztés elején
• Ne legyenek illúziók
> Hosszútávon a Cloud drágább, de a költség eloszlik
• A trükk
> Fejlesztés helyi, pszeudo-elosztott környezetben
> Teszteléshez cluster automatizált felépítése,
használata, majd lebontása: költségminimalizálás
28. Megoldandó problémák
Google I/O Extended Budapest 201428
• A Hadoop-ot alapvetően nem a Compute Engine
mögött álló infrastruktúrára optimalizálták
> Pl. RAID és egyéb alacsonyszintű háttértár
menedzsment szolgáltatások rontják a teljesítményt,
csökkentik a replikáció előnyeit
• A lebontás/felépítés problémás
> Fix IP címért fizetni kell
> A háttértárakat meg kell őrizni kikapcsolt állapotban
is, ez $4/100GB/hó költséget jelent
29. Összefoglalás
Google I/O Extended Budapest 201429
• Apache Hadoop és Google Cloud
> A fejlesztés korai szakaszában ideális
> Éles rendszereknél szuboptimális, vagy túl drága
> Fejlesztési ciklus
–Fejlesztés kis teljesítményű, lokális gépeken
–Cluster felépítése (10-15 perc, automatizált)
–Adatok betöltése (opcionális, időigényes lehet)
–Teszt futtatása valós környezetben
–Adatok törlése (opcionális)
–Cluster leállítása és lebontása (5-10 perc, automatizált)