ITB Berlín - den třetí

bře 10 2019

Třetí den ITB nám s Honzou připadl oproti prvnímu a druhému dni o něco slabší, alespoň co se do zajímavosti přednášených témat týče. 

Přednáška Moritze von Petersdorff-Campen, CEO SuitePad.de, se zabývala spíše propagací z pohledu vlastníka hotelu. Postavil ji na tezi, že vždy existovala (a existuje) taková nabídka služeb, která přiměje běžného zákazníka nejít po nejnižší ceně. Jako příklad uváděl nasazení televizí do hotelových pokojů na sklonku čtyřicátých let v USA, nebo zavedení telefonů na pokoje v letech sedmdesátých. Podle Moritze mají nyní hotely příležitost získat konkurenční výhodu poskytnutím NetFlixu na pokoje pro své hosty.

Wolfgang Schmidt z Amadeus na sklonku své prezentace zmínil zajímavá doporučení pro hotely a provozovatele ubytování libovolné velikosti. Majitelé ubytovacích kapacit by měli:

  1. V první řadě dbát na kvalitní obsah (texty, videa, obrázky), který bude dostatečně reflektovat jejich konkurenční výhody. Tím minimalizují odchody potenciálních zájemců a dosáhnou vyšší efektivity.
  2. Investovat do IT odborníků, kteří se jim postarají o propojení s co nejširším spektrem online zprostředkovatelů ubytování a především o distribuci obsahu do jejich systémů. Tím zajistí, že se konkurenční výhody skutečně zobrazí co největšímu počtu potenciálních zákazníků.
  3. I za cenu zdražení rezervovat pro zprostředkovatelské systémy tučnější marže. Zde Wolfgang vychází z aktuální situace na trhu. Je velký počet zprostředkovatelů, kteří masivně digitalizují. Expertní systémy pak lidem nejvíce tlačí nabídky, na kterých má zprostředkovatel největší šanci vydělat. 

Rád bych ještě zmínil přednášku Big Data-Studie zur Konkurrenzanalyse von Destinationen, ve které se řekové Sandro Cuzzolin a Aris Ikkos pochlubili výsledky svého výzkumu. Zatímco naše WebMedea vidí hledanosti přes všechny obory v rámci ČR, tak tým Sandra a Arise se podíval na hledanost řeckých turistických destinací napříč celým světem. Získali tím seřazení zemí podle zájmu jejich obyvatel o dovolenou v Řecku. Dále to, které destinace frčí ve kterých zemích. Přidáním časové osy (výzkum provádějí několik let) získali loajalitu jednotlivých trhů k řeckým destinacím. V další fázi definovali největší zahraniční konkurenty (konkurenční oblasti) pro jednotlivé destinace a souběžně analyzovali i je. Jako dlouhodbě největší konkurent Řecka, co se turistiky týče vyšlo Španělsko. Nejkonkurenčnější destinací je pak Mallorca, která díky silnému brandu láká velký počet turistů nejen z USA. Autoři prezentovali ještě řadu dalších zajímavých souvislostí. Analýza bude sloužit řeckému turistickému průmyslu k efektivní propagaci jednotlivých destinací.

Slave roboti WebMedea

led 31 2019
V předchozím příspěvku jsem psal, že se naše slave aplikace na internetu chovají slušně. Co si pod tím představit? Ve WebMedea se na internet díváme jako na les. Les si žije svým životem, roste a mění se nezávisle na WebMedea. Ta jej pouze z každého jeho místa pozoruje. Jak? Naše infrastruktura představuje mraveniště rozesetá po lese. Slave aplikace pak představují mravenečky sbírající po lese kousíčky informací, které odnáši do mraveniště.
 

mravenci, PixaBay

Obr. 1: Roboti WebMedea jsou hodní mravenečci :), zdroj PixaBay

Za prvé, slave aplikace respektují robots.txt na webech. Pokud si autoři webu nepřejí, aby určité části webu procházeli roboti, naše slavy to respektují. Zkrátka mraveneček není dotěrný a nevleze do nory zvířátku, které si to nepřeje. 
 
Za druhé, slave aplikace poslouchají svého mastera, který je neposílá dvakrát na to samé místo dříve, než za určitou dobu. Z daného webu si tak slave odnese jen potřebné minimum informací, které předá masterovi (a ten registrům), a na web se vrátí až když je informaci nutné aktualizovat. Mravenečci jsou tedy organizovaní a neshlukují se opakovaně na jednom místě v lese a nepustoší ho.
 
Za třetí, slavy jsou šetrné ke službám Seznamu a Google, data si berou jednou za čas a v malých množstvích. Master aplikace vyhodnocují priority - o která data si kdy říci. Analogie: Mravenečci sbírají jehličí kolem stromů a nosí je do mraveniště.
 
Toto není samo sebou, zatímco WebMedea slave je mraveneček, existují aplikace, které se v lese chovají jako dřevorubci. Zadavatel řekne dřevorubci, co má natěžit, dřevorubec vezme sekeru a jde rubat. Rube hlava nehlava. Čím více lidí chce natěžit data, tím více dřevorubců nenávratně devastuje les. Ekonom i ajťák si snadno udělají obrázek o škálovatelnosti takové služby i její závislosti na okamžité dostupnosti plundrovaného lesa. :) 

Poolování linků ve WebMedea

led 27 2019
WebMedea je založena na microservices architektuře, rozprostřené přes vlastní síť dedikovaných a virtuálních serverů. Jak si ji nejlépe představit? Viděli jste film Na hraně zítřka s Tomem Cruisem na motivy knihy All You Need Is Kill? Tak mimozemská entita, proti které hlavní hrdina bojoval, odpovídá architektuře WebMedei. Omegy jsou dedikované servery s aplikacemi nazvanými registry, ty všechno ví - jsou napojeny přímo na Cassandru a opečovávány ve špičkových datových centrech. Alphy odpovídají uzlům s aplikací nazvanou master, která dokáže nezávisle pracovat na složitějších výpočtech a řídit armádu slavů. Chobotnaté vetřelčí Bety z filmu představují aplikace typu slave, nasazené na velkém množství virtuálních serverů po celé republice. Každý slave vidí jen svého mastera, dotazuje se ho pro úkoly a odvádí rutinní práci. Slave je úplně odstíněn od registrů, může být okamžitě nahrazen a znásoben. Nutno podotknout, že slave se na internetu chová slušně.
 
Jedním z nejvíce zatížených míst v systému jsou registry, které musí neustále poskytovat data pro byznysové analýzy master uzlů. Přičemž největší tok dat způsobuje více než miliarda hypertextových odkazů napříč všemi weby v ČR, které jsou neustále sbírány, ukládány a analyzovány. Původní implementace registrů byla založena na javovském Cassandra driveru od Datastax a knihovně Spring Boot a umožňovala následující workflow:
  1. Master se dotázal REST rozhraní registrové aplikace
  2. Registry aplikace sestavila požadovaný dotaz a poslala jej Cassandře
  3. Pomocí CassandraConverterRowCallback se z výsledkové sady vytvořily požadované objekty
  4. Objekty se zpracovaly (druhotné vyfiltrování, seřazení, či jiné předzpracování)
  5. REST rozhraní registrů vrátilo Masterovi serializované pole požadových objektů
  6. Master deserializoval objekty a provedl s nimi potřebné operace
Uvedené řešení fungovalo spolehlivě zhruba do začátku léta 2018. Mezitím přerostl počet evidovaných hyperlinků miliardu. Narostla také hustota linků v okolí jednotlivých webů. Při zpracování začalo docházet k enormnímu paměťovému zatížení a to zejména u registry aplikací.
 
Situaci jsme se rozhodli vyřešit poolováním objektů v registry a master aplikacích. Protože jsme neměli kontrolu nad instancováním tříd v CassandraConverterRowCallback a při deserializaci Sprint Boot, byli jsme nuceni tuto funkci přenechat poolu. Implementace poolu byla jednoduchá, bylo jen potřeba pamatovat na to, že si do něj souběžně chce šahat více vláken...
 
@Component
public class LinkPool {

  Deque<Link> links = new ConcurrentLinkedDeque<>();

  public void recycle(Collection<Link> links) {
    synchronized (this.links) {
      this.links.addAll(links);
    }
  }

  public void recycle(Link link) {
    synchronized (links) {
      this.links.add(link);
    }
  }

  public Link getLink(Row row) {
    Link link = null;
    synchronized(links) {
      while (link == null) {
        if (links.isEmpty()) {
          return new Link(row);
        }
        link = links.poll();
      }
    }
    return link.fromResultSetRow(row);
  }
}
Další optimalizací bylo snížení trafficu mezi registry a masterem. Byznys vrstvy pracují s linky na úrovni logických celků. Naše výpočetní algoritmy jsou založeny na principu procházení grafu do šířky. Tím pádem se systematicky přesouvají od jedné domény na druhou a zpracovávají jejich okolí. No a projít okolí domácích gigantů jakými jsou iDnes, nebo Firmy.cz vyžaduje přechroustat velké množství linků, ve kterých se zdrojové a cílové domény často opakují. Indexací duplicit při serializaci v registrech a opětovným zrekonstruováním linků při deserializaci v master aplikacích se nám v ideálním případě podařilo zmenšit traffic až o 50%.
 
Souběžně s optimalizací aplikace Marek vyčlenil master server Ares pouze k účelu analýz nad linky. Řešení se ukázalo být stabilní a neustále rostoucí databázi zvládáme bez velké zátěže vyhodnocovat.