Vo vnútri monolit ByteDance: Stroj poháňajúci inteligentnejšie a rýchlejšie informačné kanály s obsahom

```html Autori: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Univerzita Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Budovanie škálovateľného systému odporúčaní v reálnom čase je kľúčové pre mnohé podniky, ktoré sú poháňané časovo citlivou zákazníckou spätnou väzbou, ako je napríklad radenie krátkych videí alebo online reklamy. Napriek všadeprítomnému prijatiu produkčných deep learningových frameworkov ako TensorFlow alebo PyTorch, tieto všeobecné frameworky nedokážu uspokojiť obchodné požiadavky v scenároch odporúčaní z rôznych dôvodov: na jednej strane, ladenie systémov na základe statických parametrov a hustých výpočtov pre odporúčanie s dynamickými a riedkymi vlastnosťami je škodlivé pre kvalitu modelu; na druhej strane, takéto frameworky sú navrhnuté s úplne oddelenou fázou dávkového trénovania a fázou obsluhy, čo bráni modelu v interakcii so zákazníckou spätnou väzbou v reálnom čase. Tieto problémy nás prinútili znovu preskúmať tradičné prístupy a preskúmať radikálne odlišné návrhové rozhodnutia. V tomto článku predstavujeme 1, systém prispôsobený na online trénovanie. Náš návrh bol poháňaný pozorovaniami našich aplikačných pracovných záťaží a produkčného prostredia, ktoré odrážajú výrazný odklon od iných systémov odporúčaní. Naše príspevky sú mnohostranné: po prvé, vytvorili sme bezkolíznu tabuľku vkladaní s optimalizáciami, ako sú vkladania s expiráciou a filtrovaním frekvencie, aby sme znížili jej nároky na pamäť; po druhé, poskytujeme produkčnú architektúru online trénovania s vysokou odolnosťou voči chybám; napokon sme dokázali, že spoľahlivosť systému môže byť vymenená za učenie v reálnom čase. Monolith bol úspešne implementovaný v produkte BytePlus Recommend2. Monolith 1 ÚVOD Posledná dekáda zaznamenala boom podnikov poháňaných technikami odporúčaní. V snahe o lepšiu zákaznícku skúsenosť je dodávanie personalizovaného obsahu pre každého jednotlivého používateľa ako reakcia v reálnom čase bežným cieľom týchto obchodných aplikácií. Na tento účel sa informácie z najnovšej interakcie používateľa často používajú ako primárny vstup na trénovanie modelu, pretože by najlepšie zobrazovali portrét používateľa a predpovedali záujmy a budúce správanie používateľa. Deep learning dominoval modelom odporúčaní [ , , , , , ], pretože obrovské množstvo používateľských údajov je prirodzene vhodné pre masívne dátovo riadené neurónové modely. Avšak úsilie o využitie sily deep learningu v priemyselných systémoch odporúčaní neustále naráža na problémy vyplývajúce z jedinečných charakteristík údajov získaných z reálneho používateľského správania. Tieto údaje sa drasticky líšia od údajov použitých v konvenčných problémoch deep learningu, ako je modelovanie jazyka alebo počítačové videnie, v dvoch aspektoch: 5 6 10 12 20 21 (1) Vlastnosti sú väčšinou riedke, kategorické a dynamicky sa menia; (2) Podkladová distribúcia tréningových údajov je nestacionárna, tzv. Concept Drift [8]. Takéto rozdiely predstavujú jedinečné výzvy pre výskumníkov a inžinierov pracujúcich na systémoch odporúčaní. 1.1 Riedkosť a dynamika Údaje pre odporúčanie väčšinou obsahujú riedke kategorické vlastnosti, niektoré z nich sa vyskytujú s nízkou frekvenciou. Bežná prax mapovania na vysokorozmerný priestor vkladaní by viedla k sérii problémov: • Na rozdiel od jazykových modelov, kde je počet slovných častí obmedzený, počet používateľov a hodnotených položiek je o niekoľko rádov väčší. Takáto obrovská tabuľka vkladaní by sa sotva zmestila do pamäte jedného hostiteľa; • Horšie je, že sa očakáva, že veľkosť tabuľky vkladaní bude časom rásť, keď pribúda viac používateľov a položiek, zatiaľ čo frameworky ako [ , ] používajú husté premenné pevnej veľkosti na reprezentáciu tabuľky vkladaní. 1 17 V praxi mnohé systémy používajú nízko-kolízne hashovanie [ , ] na zníženie nárokov na pamäť a umožnenie rastu ID. To sa spolieha na príliš idealistický predpoklad, že ID v tabuľke vkladaní sú rovnomerne rozložené vo frekvencii a kolízie neovplyvňujú kvalitu modelu. Bohužiaľ, toto je zriedka pravda pre reálny systém odporúčaní, kde malá skupina používateľov alebo položiek má výrazne viac výskytov. S organickým rastom veľkosti tabuľky vkladaní sa zvyšuje pravdepodobnosť kolízie hashovacích kľúčov a vedie k zhoršeniu kvality modelu 3 6 [3]. Preto je pre produkčné systémy odporúčaní prirodzeným dopytom mať schopnosť zachytiť čo najviac vlastností vo svojich parametroch a tiež mať možnosť elasticky upravovať počet používateľov a položiek, ktoré si chcú viesť. 1.2 Nestacionárna distribúcia Vizuálne a lingvistické vzory sa vyvíjajú v časovej škále storočí, zatiaľ čo rovnaký používateľ so záujmom o jednu tému môže zmeniť svoj zápal v nasledujúcej minúte. V dôsledku toho je podkladová distribúcia údajov používateľa nestacionárna, fenomén bežne označovaný ako Concept Drift [8]. Intuitívne, informácie z nedávnejšej histórie môžu efektívnejšie prispieť k predpovedaniu zmeny v správaní používateľa. Na zmiernenie vplyvu Concept Driftu je potrebné aktualizovať obslužné modely z nových používateľských spätných väzieb čo najbližšie k reálnemu času, aby odrážali najnovší záujem používateľa. Vzhľadom na tieto rozdiely a na základe pozorovania problémov, ktoré vznikajú v našej produkcii, sme navrhli , rozsiahly systém odporúčaní na riešenie týchto bolestivých bodov. Vykonali sme rozsiahle experimenty na overenie a iteráciu nášho návrhu v produkčnom prostredí. Monolith dokáže: Monolith (1) Poskytnúť plnú expresívnu silu pre riedke vlastnosti návrhom bezkolíznej hashovacej tabuľky a dynamického mechanizmu na vylúčenie vlastností; (2) Vrátiť spätnú väzbu z obsluhy do tréningu v reálnom čase pomocou online tréningu. Tieto architektonické schopnosti umožňujú Monolithu konzistentne prekonať systémy, ktoré používajú hash-triky s kolíziami s približne podobným využitím pamäte, a dosiahnuť najmodernejšie online AUC bez nadmerného zaťaženia výpočtovej kapacity našich serverov. Zvyšok článku je organizovaný nasledovne. Najprv podrobne rozoberieme návrhové detaily, ako Monolith rieši existujúce problémy pomocou bezkolíznej hashovacej tabuľky a tréningu v reálnom čase v Sekcii 2. Experimenty a výsledky budú prezentované v Sekcii 3, spolu s produktovo testovanými závermi a niektorými diskusiami o kompromisoch medzi časovou citlivosťou, spoľahlivosťou a kvalitou modelu. Sekcia 4 sumarizuje súvisiace práce a porovnáva ich s Monolithom. Sekcia 5 uzatvára túto prácu. 2 NÁVRH Celková architektúra Monolithu vo všeobecnosti sleduje nastavenie TensorFlow distribuovaného Worker- arameter erver (Obrázok V architektúre Worker-PS sú stroje pridelené s rôznymi rolami; Worker stroje sú zodpovedné za vykonávanie výpočtov definovaných grafom a PS stroje uchovávajú parametre a aktualizujú ich podľa gradientov vypočítaných Workermi. P S 2). V modeloch odporúčaní sú parametre kategorizované do dvoch skupín: husté a riedke. Husté parametre sú váhy/premenné v hlbokej neurónovej sieti a riedke parametre sa týkajú tabuliek vkladaní, ktoré zodpovedajú riedkym vlastnostiam. V našom návrhu sú husté aj riedke parametre súčasťou TensorFlow Grafu a sú uložené na serveroch parametrov. Podobne ako TensorFlow Variable pre husté parametre, navrhli sme sadu vysoko efektívnych, bezkolíznych a flexibilných operácií HashTable pre riedke parametre. Ako doplnok k obmedzeniam TensorFlow vyplývajúcim z oddelenia tréningu a inferencie je elasticky škálovateľný online tréning Monolithu navrhnutý tak, aby efektívne synchronizoval parametre z tréningového PS do online obslužného PS v krátkych intervaloch, s garanciou robustnosti modelu poskytovanou mechanizmom tolerancie chýb. 2.1 Hash Tabuľka Prvý princíp v našom návrhu reprezentácie riedkych parametrov je vyhnúť sa stláčaniu informácií z rôznych ID do rovnakého vkladača pevnej veľkosti. Simulácia tabuľky vkladaní s dynamickou veľkosťou pomocou TensorFlow Variable z krabice nevyhnutne vedie k ID kolízii, ktorá sa zhoršuje s príchodom nových ID a rastom tabuľky. Preto sme namiesto budovania na Variable vyvinuli novú HashTable s kľúčom-hodnotou pre naše riedke parametre. Naša HashTable používa Cuckoo Hashmap [ ] pod kapotou, ktorá podporuje vkladanie nových kľúčov bez kolízie s existujúcimi. Cuckoo Hashing dosahuje v najhoršom prípade časovú zložitosť 𝑂 (1) pre vyhľadávanie a mazanie a očakávanú amortizovanú 𝑂 (1) čas pre vkladanie. Ako je znázornené na Obrázku udržiava dve tabuľky 𝑇0, 𝑇1 s rôznymi hashovacími funkciami ℎ0 (𝑥), ℎ1 (𝑥), a prvok by bol uložený v jednej z nich. Pri pokuse o vloženie prvku 16 3 𝐴 do 𝑇0 sa najprv pokúša umiestniť 𝐴 na ℎ0 (𝐴); Ak je ℎ0 (𝐴) obsadené iným prvkom 𝐵, vyhodí 𝐵 z 𝑇0 a pokúsi sa vložiť 𝐵 do 𝑇1 s rovnakou logikou. Tento proces sa bude opakovať, kým sa všetky prvky nestabilizujú, alebo sa vykoná prehashovanie, keď vkladanie narazí na cyklus. Zníženie nárokov na pamäť je tiež dôležitým aspektom nášho návrhu. Naívny prístup vkladania každého nového ID do HashTable rýchlo vyčerpá pamäť. Pozorovanie reálnych produkčných modelov viedlo k dvom záverom: (1) ID, ktoré sa vyskytujú len niekoľkokrát, majú obmedzený prínos k zlepšeniu kvality modelu. Dôležité pozorovanie je, že ID sú distribuované dlhým chvostom, kde populárne ID sa vyskytujú miliónkrát, zatiaľ čo nepopulárne sa vyskytujú najviac desaťkrát. Vkladania zodpovedajúce týmto zriedkavým ID sú podvyužité kvôli nedostatku tréningových údajov a model nebude schopný urobiť dobrý odhad na základe nich. Nakoniec tieto ID pravdepodobne neovplyvnia výsledok, takže kvalita modelu neutrpí odstránením týchto ID s nízkym počtom výskytov; (2) Zastaralé ID z dávnej histórie zriedka prispievajú k aktuálnemu modelu, pretože mnohé z nich sa nikdy nenavštívia. To môže byť spôsobené používateľom, ktorý už nie je aktívny, alebo krátkym videom, ktoré je zastarané. Ukladanie vkladaní pre tieto ID nemôže modelu nijako pomôcť, okrem zbytočného vyčerpávania pamäte nášho PS. Na základe týchto pozorovaní sme navrhli niekoľko heuristík na filtrovanie ID vlastností pre pamäťovo efektívnejšiu implementáciu HashTable: (1) ID sú filtrované pred prijatím do tabuliek vkladaní. Máme dve metódy filtrovania: najprv filtrujeme podľa ich výskytov pred ich vložením ako kľúče, kde prahová hodnota výskytov je nastaviteľný hyperparameter, ktorý sa líši pre každý model; okrem toho používame pravdepodobnostný filter, ktorý pomáha ďalej znižovať využitie pamäte; ![#Figure 4: Streaming Engine. Spätná väzba informácií z [Používateľ → Model Server → Tréningový Worker → Model Server → Používateľ] by trvala dlho pri použití cesty Batch Training, zatiaľ čo Online Training by slučku uzavrela okamžite.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID sú časované a nastavené tak, aby vypršala platnosť po nečinnosti po preddefinované časové obdobie. Čas vypršania platnosti je tiež nastaviteľný pre každú tabuľku vkladaní, aby umožnil rozlíšiť vlastnosti s rôznou citlivosťou na historické informácie. V našej implementácii je HashTable implementovaná ako operácia zdroja TensorFlow. Podobne ako Variable, aj vyhľadávania a aktualizácie sú implementované ako natívne operácie TensorFlow pre ľahšiu integráciu a lepšiu kompatibilitu. 2.2 Online tréning V Monolith je tréning rozdelený do dvoch fáz (Obrázok 1): (1) Fáza dávkového tréningu. Táto fáza funguje ako bežná tréningová slučka TensorFlow: V každom tréningovom kroku tréningový worker načíta jeden mini-dávku tréningových príkladov z úložiska, požiada o parametre z PS, vypočíta dopredný a spätný priechod a nakoniec odošle aktualizované parametre do tréningového PS. O niečo odlišne od iných bežných úloh deep learningu, náš dataset trénujeme iba jedenkrát. Dávkový tréning je užitočný na trénovanie historických údajov, keď upravujeme našu modelovú architektúru a pretrénujeme model; (2) Fáza online tréningu. Po nasadení modelu do online obsluhy tréning nekončí, ale vstupuje do fázy online tréningu. Namiesto čítania mini-dávkových príkladov z úložiska tréningový worker spracováva reálne údaje za chodu a aktualizuje tréningové PS. Tréningový PS periodicky synchronizuje svoje parametre s obslužným PS, čo sa okamžite prejaví na strane používateľa. Toto umožňuje nášmu modelu interaktívne sa prispôsobovať spätnej väzbe používateľa v reálnom čase. Monolith je postavený so schopnosťou bezproblémového prepínania medzi dávkovým tréningom a online tréningom. Toto je umožnené naším návrhom streamovacieho enginu, ako je znázornené na Obrázku 2.2.1 Streaming Engine. 4. V našom návrhu používame jednu frontu Kafka [ ] na zaznamenávanie akcií používateľov (napr. Kliknutie na položku alebo označenie položky páči sa mi atď.) a druhú frontu Kafka pre vlastnosti. Jadrom enginu je Flink [ ] streamovacia úloha pre online spojovač vlastností. Online spojovač spája vlastnosti s označeniami z akcií používateľov a produkuje tréningové príklady, ktoré sa potom zapisujú do fronty Kafka. Fronta pre tréningové príklady je konzumovaná online aj dávkovým tréningom: 13 4 Pre online tréning tréningový worker priamo číta údaje z fronty Kafka; Pre dávkový tréning úloha na sťahovanie dát najprv stiahne dáta do HDFS [ ]; Po nahromadení určitého množstva dát v HDFS tréningový worker získa dáta z HDFS a vykoná dávkový tréning. 18 Aktualizované parametre v tréningovom PS budú odoslané do obslužného PS podľa plánu synchronizácie parametrov. V reálnych aplikáciách sa záznamy o akciách používateľov a vlastnosti streamujú do online spojovača (Obrázok bez záruky poradí. Preto používame jedinečný kľúč pre každý požadok, aby sa akcia používateľa a vlastnosti mohli správne spárovať. 2.2.2 Online Joiner. 5) Oneskorenie akcie používateľa môže byť tiež problémom. Napríklad používateľ môže pred rozhodnutím kúpiť položku, ktorá mu bola predstavená pred dňami, stráviť niekoľko dní. To je výzva pre spojovač, pretože ak sa všetky vlastnosti uchovávajú v cache, jednoducho sa nezmestia do pamäte. V našom systéme sa používa úložisko kľúč-hodnota na disku na ukladanie vlastností, ktoré čakajú dlhšiu dobu. Keď dorazí záznam o akcii používateľa, najprv vyhľadá v pamäťovej cache a potom vyhľadá úložisko kľúč-hodnota v prípade chýbajúcej cache. Ďalším problémom, ktorý sa vyskytuje v reálnych aplikáciách, je, že distribúcia negatívnych a pozitívnych príkladov je vysoko nerovnomerná, pričom počet prvých môže byť rádovo vyšší ako počet druhých. Aby sa zabránilo tomu, že pozitívne príklady budú zahltené negatívnymi, bežnou stratégiou je negatívne vzorkovanie. To by určite zmenilo podkladovú distribúciu trénovaného modelu, pričom by ho upravilo smerom k vyššej pravdepodobnosti robenia pozitívnych predpovedí. Ako nápravu aplikujeme korekciu log-odds [ ] počas obsluhy, čím zabezpečíme, že online model je neskreslený odhad pôvodnej distribúcie. 19 Počas online tréningu tréningový cluster Monolith neustále prijíma dáta z online obslužného modulu a aktualizuje parametre na tréningovom PS. Kľúčovým krokom na umožnenie obslužnému PS profitovať z týchto novo natrénovaných parametrov je synchronizácia aktualizovaných parametrov modelu. V produkčnom prostredí sa stretávame s niekoľkými výzvami: 2.2.3 Synchronizácia parametrov. Modely na online obslužnom PS sa nesmú prestať obsluhovať počas aktualizácie. Naše modely v produkcii majú zvyčajne niekoľko terabajtov, a preto nahradenie všetkých parametrov chvíľu trvá. Bolo by neakceptovateľné zastaviť online PS z obsluhy modelu počas procesu nahradenia a aktualizácie sa musia vykonávať za chodu; Prenos multi-terabajtového modelu v celku z tréningového PS do online obslužného PS by predstavoval obrovský tlak na šírku pásma siete aj na pamäť na PS, pretože vyžaduje dvojnásobnú veľkosť modelu pamäte na prijatie nového prichádzajúceho modelu. Aby sa online tréning mohol škálovať na veľkosť nášho obchodného scenára, navrhli sme v Monolith inkrementálny, priebežný, periodický mechanizmus synchronizácie parametrov založený na niekoľkých pozorovaných charakteristikách našich modelov: (1) Riedke parametre dominujú vo veľkosti modelov odporúčaní; (2) Vzhľadom na krátke časové okno sa trénuje a aktualizuje iba malá podmnožina ID a ich vkladaní; (3) Husté premenné sa pohybujú oveľa pomalšie ako riedke vkladania. Je to preto, že v optimalizátoroch založených na momente akumulácia momentu pre husté premenné je zosilnená obrovskou veľkosťou tréningových údajov pre odporúčanie, zatiaľ čo iba niekoľko riedkych vkladaní dostáva aktualizácie v jednej dátovej dávke. (1) a (2) nám umožňujú využiť riedke aktualizácie naprieč všetkými ID vlastností. V Monolith udržiavame hashovaciu sadu dotknutých kľúčov, reprezentujúcich ID, ktorých vkladania boli trénované od poslednej synchronizácie parametrov. Posielame podmnožinu riedkych parametrov, ktorých kľúče sú v sade dotknutých kľúčov, s minútovým časovým intervalom z tréningového PS do online obslužného PS. Toto relatívne malé balenie inkrementálnej aktualizácie parametrov je ľahké prenosy cez sieť a nespôsobí prudký nárast pamäte počas synchronizácie. Využívame tiež (3) na ďalšie zníženie sieťovej prevádzky a využitia pamäte nastavením agresívnejšieho plánu synchronizácie pre riedke parametre, zatiaľ čo husté parametre aktualizujeme menej často. To nám môže priniesť situáciu, kde husté parametre, ktoré obsluhujeme, sú relatívne zastaranou verziou v porovnaní s riedkou časťou. Avšak takáto nekonzistencia môže byť tolerovaná z dôvodu uvedeného v (3), pretože nebol pozorovaný žiadny zjavný straty. 2.3 Odolnosť voči chybám Ako systém v produkcii je Monolith navrhnutý so schopnosťou obnoviť PS v prípade jeho zlyhania. Bežnou voľbou pre odolnosť voči chybám je periodicky snímať stav modelu a obnovovať sa z najnovšieho snímku pri detekcii zlyhania PS. Voľba frekvencie snímkovania má dva hlavné vplyvy: (1) Kvalita modelu. Intuitívne, kvalita modelu trpí menej stratou nedávnej histórie so zvýšenou frekvenciou snímkovania. (2) Výpočtová réžia. Snímkovať multi-terabajtový model nie je zadarmo. Vykazuje veľké objemy kopírovania pamäte a I/O disku. Ako kompromis medzi kvalitou modelu a výpočtovou réžiou, Monolith sníma všetky tréningové PS denne. Hoci PS stratí jeden deň aktualizácií v prípade zlyhania, zistili sme, že degradácia výkonu je tolerovateľná prostredníctvom našich experimentov. V nasledujúcej sekcii analyzujeme vplyv spoľahlivosti PS. 3 HODNOTENIE Pre lepšie pochopenie výhod a kompromisov prinášaných naším navrhnutým dizajnom sme uskutočnili niekoľko experimentov v produkčnej škále a A/B testovanie so živou obsluhou na vyhodnotenie a overenie Monolithu z rôznych hľadísk. Cieľom našich experimentov je odpovedať na nasledujúce otázky: (1) Ako veľmi môžeme profitovať z bezkolíznej HashTable? (2) Aký dôležitý je online tréning v reálnom čase? (3) Je návrh synchronizácie parametrov Monolithu dostatočne robustný v rozsiahlej produkčnej situácii? V tejto sekcii najprv predstavíme naše experimentálne nastavenia a potom podrobne prediskutujeme výsledky a naše zistenia. 3.1 Experimentálne nastavenie Ako je popísané v Sekcii tabuľky vkladaní v Monolith sú implementované ako bezkolízne HashTables. Na preukázanie nevyhnutnosti vyhýbania sa kolíziám v tabuľkách vkladaní a na kvantifikáciu ziskov z našej bezkolíznej implementácie sme vykonali dve skupiny experimentov na datasete Movielens a na našom internom produkčnom datasete: 3.1.1 Tabuľka vkladaní. 2.1, (1) Datasety ml-25m [ ]. Toto je štandardný verejný dataset pre hodnotenie filmov, obsahujúci 25 miliónov hodnotení, ktoré zahŕňajú približne 162 000 používateľov a 62 000 filmov. MovieLens 11 • . Pôvodné štítky sú hodnotenia od Predspracovanie štítkov 0.5 do 5.0, zatiaľ čo v produkcii naše úlohy väčšinou prijímajú binárne signály od používateľov. Aby sme lepšie simulovali naše produkčné modely, konvertujeme škálové štítky na binárne štítky tým, že považujeme skóre ≥ 3.5 za pozitívne vzorky a zvyšok za negatívne vzorky. • Model a metriky. Implementovali sme štandardný model DeepFM [9], bežne používaný modelový architektúra pre problémy odporúčaní. Skladá sa z FM komponentu a hustého komponentu (Obrázok 6). Predpovede sú hodnotené pomocou AUC [2], pretože toto je hlavné meranie pre reálne modely. • Kolízie vkladaní. Tento dataset obsahuje približne 160 tisíc ID používateľov a 60 tisíc ID filmov. Na porovnanie s bezkolíznou verziou implementácie tabuľky vkladaní sme vykonali ďalšiu skupinu experimentov, kde sú ID predzpracované pomocou MD5 hashovania a potom mapované na menší priestor ID. V dôsledku toho budú niektoré ID zdieľať svoje vkladanie s inými. Tabuľka 1 ukazuje podrobné štatistiky ID používateľov a filmov pred a po hashovaní. (2) . Interný dataset odporúčaní Experimenty sme tiež vykonali na modeli odporúčaní v produkčnom prostredí. Tento model vo všeobecnosti sleduje multi-tower architektúru, kde je každý tower zodpovedný za učenie sa predpovedať špecializovaný druh správania používateľa. Každý model má okolo 1000 tabuliek vkladaní a distribúcia veľkosti tabuliek vkladaní je veľmi nerovnomerná;