Od zaměstnanců Techopedia, 25. ledna 2017
Take away : Host Eric Kavanagh diskutuje s výpočetní pamětí a SAP HANA s hosty Dr. Robinem Bloorem, Dezem Blanchfieldem a Billem Ellisem IDERA.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Eric Kavanagh: Dobře, dámy a pánové. Dobrý den, vítejte znovu. Je to čtyři hodiny východního času ve středu a posledních pár let, což znamená, že je čas znovu pro Hot Technologies. Ano, jmenuji se Eric Kavanagh, budu vaším hostitelem pro dnešní konverzaci.
A lidi, dnes budeme mluvit o některých skvělých věcech. Budeme se ponořit do světa paměti, přesný název zní „Do budoucnosti: An-Ramp pro výpočet In-Memory.“ V dnešní době je to všechno vztek a z dobrého důvodu, hlavně proto, že paměť je mnohem rychlejší než spoléhání se na rotující disky. Výzvou však je, že musíte přepsat mnoho softwaru. Protože dnešní software, většina z toho, byl napsán s ohledem na disk a to opravdu mění architekturu aplikace. Pokud aplikaci navrhnete tak, aby čekala na spřádací disk, děláte věci jinak, než pokud máte veškerou sílu technologie v paměti.
Je tu opravdu vaše místo, zasáhla mě na Twitteru, @eric_kavanagh. Vždy se snažím sledovat a také retweet kdykoli mě někdo zmiňuje.
Jak jsem řekl, dnes mluvíme o paměti, konkrétně o SAP HANA. Váš minulý rok jste opravdu strávili poznáváním komunity SAP opravdu dobře a musím říct, že je to fascinující prostředí. Klobouk před lidem, kteří provozují tuto operaci a jsou na frontách, protože SAP je neuvěřitelně dobrá operace. To, v čem jsou opravdu dobří, dělá podnikání. Jsou samozřejmě také skvělí v technologii a do společnosti HANA opravdu vložili velkou investici. Ve skutečnosti si pamatuji - asi před šesti nebo sedmi lety - že jsme vlastně dělali nějakou práci pro americké letectvo, a dostali jsme někoho ze společnosti SAP, aby přišel a brzy se podíval na svět HANA a co bylo plánováno. A přinejmenším, lidé v SAP Labs vynaložili hodně času a úsilí na pochopení toho, jak vybudovat tuto architekturu, která je zcela jiná, opět od tradičních prostředí, protože máte všechno v paměti. Mluví se tedy o transakčních i analytických transakcích na stejných datech v paměti, na rozdíl od tradičního způsobu, který je vytáhl, vložte je do krychle, například ji tam analyzujte, versus transakční, což se děje úplně jiným způsobem.
Toto je zajímavý prostor a my se vlastně dozvíme od jiného dodavatele, IDERY, trošku o tom, jak to všechno bude fungovat, a o čem to vlastně je on-rampa. Takže, uslyšíme dr. Robina Bloora, našeho vlastního hlavního analytika zde ve Skupině Bloor; Dez Blanchfield, náš datový vědec a poté dobrý přítel Bill Ellis z IDERA. Takže, s tím, dám klíče od Dr. Robina Bloorovi, který to vezme.
Dr. Robin Bloor: Jo, jak Eric říkal, čas, kdy jsme se poprvé seznámili s SAP HANA, byl zpátky před mnoha lety. Ale bylo to velmi zajímavé, ten konkrétní čas byl velmi zajímavý. Setkali jsme se s jednou nebo dvěma společnostmi, které tak či onak nabízely technologii v paměti. Bylo zcela jasné, že do paměti přijde. A opravdu to nebylo, dokud se SAP nevstal a náhle nespustil HANA. Když jsem viděl SAP dělat to, byl to šok. Bylo to, jako by to byl šok, protože jsem očekával, že to přijde odkudkoli. Čekal jsem, že to bude, víš, Microsoft nebo Oracle nebo IBM nebo někdo takový. Myšlenka, že to SAP dělá, byla pro mě opravdu velmi překvapivá. Předpokládám, že by to nemělo být, protože SAP je jedním ze strategických prodejců a do značné míry, víte, všechno velké, co se v oboru děje, pochází od jednoho z nich.
Každopádně, celý bod o paměti, myslím, uvědomili jsme si, zvykli jsme si o tom mluvit, že jakmile vlastně jdete do paměti - nejde o vkládání dat do paměti, jde o závazek k myšlenka, že paměťová vrstva je systémovým záznamem - jakmile migrujete systémový záznam do paměti, disk se stane předávacím médiem jednoho druhu a stane se jinou věcí. A já si myslel, že to bylo velmi vzrušující, když se to začalo. Opravdu, je to u rotujícího disku. Spinningový disk bude brzy existovat pouze v muzeích. Nejsem si jistý, jak brzy to bude, ale v podstatě je pevný disk nyní na Mooreově zákonné křivce, je to už desetkrát rychlejší než rotující rez, jak tomu nyní říkají, a docela brzy to bude ještě rychlejší a pak to znamená, že případy použití pro disk se stávají stále méně.
A kuriózní skutečnost, tradiční DBMS, ve skutečnosti bylo pro spřádací disk vytvořeno mnoho tradičního softwaru, předpokládalo to spřádací disk. Měl nejrůznější schopnosti na fyzické úrovni, které byly pečlivě naprogramovány, aby bylo možné využít rotující disk a umožnit co nejrychlejší načítání dat. A to vše je odplaveno. Prostě mizí, víš? A pak to bylo očividně velmi - nevím, lukrativní, předpokládám, že to bude nakonec - otevření pro databázi v paměti, která se pokusila obsadit pozici, kterou mají velké databáze, Oracle a Microsoft, SQL Server a IBM DB2, zabíral v prostoru v paměti a bylo velmi zajímavé sledovat, jak přicházejí a dělají to.
Pojďme mluvit o paměťové kaskádě; stojí to za zmínku. Je to také důvod, proč jsem to zmínil, důvod, proč jsem to hodil, byl prostě proto, aby všichni věděli, když tady mluvím o paměti, všechny ty vrstvy, o kterých mluvím, jsou ve skutečnosti pamětí. Ale najednou si uvědomíte, když se na to podíváte, je to hierarchický obchod, není to jen paměť. A proto platí téměř všechno, co jsme se dozvěděli dávno a dávno o hierarchickém úložišti. A to také znamená, že každá databáze v paměti musí procházet svou cestou, někteří ji prostě procházejí po samotné RAM, víte. A to se stále zvětšuje, zvětšuje a zvětšuje a nyní se měří v megabajtech. Ale máte L1 cache, která je stokrát rychlejší než paměť, L2 cache 30krát rychlejší než paměť a L3 cache asi 10krát rychlejší než paměť. Takže, víte, existuje spousta technologií - dobře, velké množství technologií - přijalo strategii používání těchto mezipaměti jako druhu úložného prostoru na cestě k provádění věcí, zejména databázové technologie. Takže, víte, to je jeden vliv.
Pak se objevil 3D XPoint a IBM PCM. A je to téměř rychlost RAM, což je v podstatě to, co se oba tito prodejci chlubí. Případy použití jsou pravděpodobně odlišné. Včasné experimentování s tím ještě není dokončeno. Nevíme, jak to ovlivní využití paměti RAM a technologii databáze v paměti. Pak máte RAM versus SSD. V současné době je RAM asi 300krát rychlejší, ale samozřejmě, že násobek klesá. A SSD versus disk, který je asi 10krát rychlejší, pokud tomu rozumím. Takže to je taková situace, jakou máte. Je to hierarchický obchod. Když se na to podíváme jiným způsobem, vzpomínka je samozřejmě úplně jiná. Horní diagram tedy ukazuje dvě aplikace, z nichž obě možná přistupují k databázi, ale určitě přistupují k datům o rotující rezi. A způsob, jakým ve skutečnosti věci procházíte sítí, v závislosti na tom, jaké závislosti jsou kolem, je ETL. To znamená, že, jak víte, data přecházejí do spřádající se rzi a poté se uvolní spřádající se rez, aby se dostali kamkoli, a aby se dostali kamkoli, vrátili se do spřádající se rzi, což jsou tři pohyby. A mějte na paměti, že paměť může být stoktisíckrát rychlejší než rotující disk a určitě si uvědomujete, že když vezmete data a uložíte je do paměti, je celá věc opravdu jiná.
Možná jste si mysleli, co by se stalo, na tom, co je na obrazovce právě tady, možná byste si mysleli, že tak či onak, ETL by ve skutečnosti prostě šlo z dat k datům v paměti. Ale ve skutečnosti by to nemohlo udělat; ve skutečnosti můžete mít tu pravou situaci, kdy dvě aplikace mohou skutečně vypálit stejnou paměť. Tuto paměť vám určitě může nabídnout databáze v paměti, pokud máte uzamčení a všechno ostatní kolem něj organizováno. To tedy nemění pouze rychlost věcí, ale také to, jak vlastně konfigurujete aplikace a celé datové toky.
Je to obrovský druh dopadu. Takže paměť je rušivá, že? A měli bychom to získat z toho, co jsem řekl. Zpracování v paměti v současné době urychlovač, ale stane se normou. Bude použito, bude aplikováno podle hodnoty aplikace, a proto je velmi, velmi zajímavé, že SAP ve skutečnosti vyjde s verzí svého ERP softwaru, který je v paměti. A vylepšení latence až o tři řády jsou zcela možné a ve skutečnosti dokonce více, než je možné, v závislosti na tom, jak to děláte. Dostáváte se tedy do paměti obrovská zlepšení rychlosti. A výsledek, SAP HANA S / 4 - který vydali, myslím, že lidé říkají, že je stále uvolňován, ale určitě byl vydán minulý rok - je to změna hry vzhledem k zákaznické základně SAP. Myslím, že tam je 10 000 společností, které používají SAP ERP, a skoro všechny z nich jsou velké společnosti, víte. Takže myšlenka, že všichni mají motivaci jít do paměti a používat své základní, protože ERP je téměř vždy základními aplikacemi, které podniky provozují, je to jen obrovský měnič her a bude to velmi zajímavé. Ale samozřejmě, že vše zní velmi dobře, ale musí být nakonfigurováno inteligentně a musí být dobře monitorováno. Není to tak jednoduché, jak to zní.
Po tom, co jsem řekl, si myslím, že míč předám, kdo je ten chlap? Oh, australský chlap, Dez Blanchfield.
Dez Blanchfield: Velmi vtipné. Robin Bloor, vždycky tvrdě jednat. Díky, že jsi mě dneska dostal. Takže velké téma, ale vzrušující. Takže jsem si vybral obrázek, který často vymýšlím, když přemýšlím o moderních datových jezerech a podnikových datových skladech a mých malých drahokamech dat. Takže tady mám toto krásné jezero obklopené horami a vlnami, které vycházejí, a vlny se shazují nad těmito kameny. To je druh, jak si dnes psychicky představuji, jak to vypadá uvnitř velkého datového jezera. Vlny jsou dávkové úlohy a analytika v reálném čase je hozena na data, jsou to skály. A když o tom přemýšlím jako o fyzickém jezeře, tak mi to přinese buzení, že, jak víte, rozsah datových skladů, které nyní stavíme, důvod, proč jsme přišli s tímto ražením a termínem datové jezero je to, že jsou velmi velké a jsou velmi hluboké, a občas v nich můžete mít bouře. A když to uděláme, vždy musíte vyřešit, co vytváří bouři.
Takže v tématu této věci se mi zdá, že toto volání sirény pro výpočet v paměti je opravdu velmi silné a z dobrého důvodu. Přináší tolik významných komerčních a technických výhod. To je diskuse na pár hodin v jiný den. Ale obecný posun k výpočtu v paměti, nejprve se chci zabývat tím, jak jsme se sem dostali a co to umožňuje, protože to, jaksi, nastavuje základy toho, kde mohou některé výzvy spočívat jako první a co musíme vědět, a přemýšlet o tom, že v našem světě přecházíme od tradičního starého rotujícího disku, který uchovává data a je stránkován na a mimo disk a do paměti a z paměti a do CPU, až nyní odstraňujeme téměř jednu z těchto celých vrstev, je točící se disk. Protože si pamatujte, že v počátečních dnech výpočetní jsme se architektonicky dlouho nepřesunuli z mainframe nebo středního světa o tom, co jsme původně považovali za jádro paměti a úložiště bicích.
Jak řekl Dr. Robin Bloor, přístup, který jsme použili k přesunu dat kolem počítačové architektury, se po nějakou dobu, po několik desetiletí, dramaticky nezměnil. Pokud přemýšlíte o skutečnosti, že víte, moderní výpočetní technika byla asi všude kolem, pokud uděláte milost hříčku, asi 60-lichých let, víte, šest desetiletí a více a je to v tom smyslu, že můžete koupit krabici z police, jak to bylo. Přechod k nové architektuře se skutečně projevil v mé mysli, když jsme se přesunuli z myšlení kolem mainframes a midrange a architektur jádra paměti a bicích úložišť, k statečným nebo superpočítačům, zejména jako Seymour Cray, kde se věci jako crossbar backplanes se stala věcí. Namísto toho, abyste měli pouze jednu trasu pro přesun dat přes základní desku nebo základní desku, jak se to dnes říká. A inline paměť, víte, v těchto dnech lidé opravdu nemyslí na to, co to ve skutečnosti znamená, když říkají DIMM a SIMM. Ale SIMM je jediná inline paměť a DIMM je duální inline paměť a my jsme od té doby složitější a existují tu desítky různých typů paměti pro různé věci: některé pro video, jiné pouze pro obecné aplikace, jiné vestavěné do procesorů.
Takže došlo k tomuto velkému posunu k novému způsobu ukládání a přístupu k datům. Chystáme se projít stejným posunem v jiné celé generaci, ale ne tolik v samotném hardwaru, ale v přijetí hardwaru v obchodní logice a v datové logické vrstvě, a je to další velký posun paradigmatu v mé mysli. .
Ale jen stručně, jak jsme se sem dostali. Hardwarová technologie se zlepšila a dramaticky se zlepšila. Šli jsme od CPU a myšlenka jádra byla docela moderní koncept. Bereme to za samozřejmé, že naše telefony mají dvě nebo čtyři jádra a naše počítače mají dvě nebo čtyři nebo dokonce osm jader na ploše a osm a 12 a více na, víte, 16 a 32 dokonce na serverové platformě . Ale je to vlastně docela moderní věc, že jádra se stala schopností uvnitř CPU a že jsme šli z 32-bit na 64-bit. Tam se stalo několik velkých věcí: dostali jsme vyšší rychlosti hodin na více jádrech, takže jsme mohli dělat věci paralelně a každé z těchto jader mohlo běžet více vláken. Najednou jsme mohli spouštět spoustu věcí na stejných datech současně. Šedesát čtyři bitové rozestupy adres nám poskytly až dva terabajty RAM, což je fenomenální koncept, ale teď je to věc. Tyto vícepásmové architektury zadní desky, víte, základní desky, kdysi jste mohli dělat věci pouze jedním směrem: dozadu a dopředu. A stejně jako ve dnech s výpočetní technikou Cray a některými superpočítačovými designy té doby, nyní ve stolních počítačích a běžných off-the-shelf, jakýchkoli stolních počítačích typu rack-mount, protože opravdu většina moderních Počítače nyní prošly obdobím mainframe, midrange, micro desktops a my jsme je převedli zpět na servery.
A spousta těchto schopností superpočítače, konstrukce superpočítače, se dostala do běžných běžných komponent. Víte, v těchto dnech je myšlenka vzít si velmi levné PC s připojením na stojany a umístit je do stojanů po stovkách, ne-li tisících, a spustit na nich software s otevřeným zdrojovým kódem, jako je Linux, a nasadit na ně aplikace SAP HANA Víme, že to často považujeme za samozřejmost. Ale to je velmi nová vzrušující věc a přichází s její složitostí.
Software se také zlepšil, zejména správa paměti a rozdělení dat. Nebudu se zabývat mnoha podrobnostmi, ale pokud se podíváte na velký posun za posledních 15 let, nebo dokonce méně, jak se spravuje paměť, zejména data v RAM a jak se data v RAM rozdělují, takže, jak už naznačil Dr. Robin Bloor, víte, věci se mohou číst a psát současně, aniž by se navzájem ovlivňovaly, místo aby čekaly. Mnoho velmi výkonných funkcí, jako je komprese a šifrování na čipu. Šifrování se stává důležitější věcí a nemusíme to nutně dělat v softwaru, v RAM, v prostoru CPU, nyní, když se to vlastně děje na čipu nativně. To dramaticky urychluje věci. A distribuované ukládání a zpracování dat opět, věci, které jsme kdysi předpokládali, byly věci superpočítačů a paralelního zpracování, nyní to bereme jako samozřejmost v prostoru jako SAP HANA a Hadoop a Spark atd.
Celým bodem toho je tento vysoce výkonný výpočetní systém, schopnosti HPC přicházely do podniku a nyní podnik využívá výhody plynoucí z toho, že jde o nárůst výkonu a technologický prostor a technické výhody a komerční zisky, protože víte, zkrácený čas na hodnotu dramaticky klesá.
Ale já používám tento obrázek příběhu, který jsem četl před časem gentlemana, který postavil PC pouzdro z Lego, protože to vždycky přijde na mysl, když přemýšlím o některých z těchto věcí. A to je to, že to vypadá jako skvělý nápad v době, kdy jej začnete stavět, a pak se dostanete do poloviny a uvědomíte si, že je opravdu složité dát dohromady všechny kousky Lego dohromady a udělat solidní věc, dostatečně solidní vložit základní desku a tak dále, postaví skříň pro osobní počítač. A nakonec si uvědomíte, že všechny malé kousky nejsou slepeny správně, a musíte být trochu opatrní ohledně toho, které malé kousky držíte dohromady, aby bylo pevné. A je to velmi roztomilý nápad, ale je to buzení, když se dostanete do poloviny a uvědomíte si: „Hmm, možná bych si měl koupit pouzdro na PC s 300 $, ale teď to dokončím a z toho se něco naučím.“
Pro mě je to skvělá analogie toho, jaké to je stavět tyto velmi složité platformy, protože je vše v pořádku a dobré je postavit a skončit v prostředí, ve kterém máte směrovače a přepínače, servery a stojany. A máte dohromady CPU a RAM a operační systém. A dáte na to něco jako HANA pro distribuované zpracování v paměti, ukládání dat a správu dat. Navíc stavíte zásobník SAP, získáte funkce databáze a poté načtete svá data a obchodní logiku a začnete na ně aplikovat několik čtení a zápisů a dotazů atd. Musíte se držet na vrcholu I / O a musíte naplánovat věci a řídit pracovní vytížení a multitenancy atd. Tento zásobník se stává velmi složitým, velmi rychle. To je samo o sobě složitý zásobník, pokud je to jen na jednom počítači. Vynásobte tím, že u 16 nebo 32 strojů se stává velmi, velmi netriviální. Když vynásobíte až stovky a nakonec tisíce strojů, přejdete ze 100 terabajtů na petabajt, je to děsivý koncept a to jsou skutečnosti, se kterými se nyní zabýváme.
Takže nakonec skončíte s několika věcmi, které také pomohly změnit tento svět, a to znamená, že místo na disku se stalo směšně levným. Víte, jednou za čas byste utratili 380 až 400 tisíc dolarů na gigabajt pevného disku, když to byl masivní buben o velikosti - něco, co k jeho vyzvednutí potřeboval vysokozdvižný vozík. V dnešní době se jedná o jeden nebo dva centy na gigabajt volného místa na disku. A RAM udělal totéž. Tyto dvě křivky J v obou těchto grafech, mimochodem, jsou každý deset let, takže jinými slovy se díváme na dva bloky po 10 letech, 20 letech snižování cen. Ale já jsem je rozdělil na dvě J-křivky, protože nakonec se ten pravý právě stal tečkovanou čarou a vy jste nemohli vidět detail, takže jsem to zmenšil. Gigabajt RAM před 20 lety byl něco v řádu šesti a půl milionu dolarů. V těchto dnech, pokud platíte více než tři nebo čtyři dolary za gigabajt RAM za komoditní hardware, který je okraden.
Toto výrazné omezení cen v posledních dvou desetiletích znamenalo, že nyní se můžeme přesouvat z místa na disku a přímo do RAM, a to nejen na úrovni megabajtů, ale nyní na úrovni terabajtů a zacházet s RAM jako s diskem. Výzvou však bylo, že RAM byla nativně pomíjivá - to znamená něco, co trvá krátkou dobu - takže jsme museli přijít s způsoby, jak do tohoto prostoru poskytnout odolnost.
A tak si myslím, že výpočet v paměti není pro slabé srdce. Žonglování těchto velmi rozsáhlých dat v paměti a jejich zpracování je zajímavou výzvou; Jak jsem již naznačil, není to pro slabé srdce. Jedna věc, kterou jsme se z této zkušenosti dozvěděli při velkoobjemovém a vysokohustotním zpracování v paměti, je skutečnost, že složitost, kterou vytváříme, způsobuje riziko v mnoha oblastech.
Ale podívejme se na to z pohledu monitorování a reakce. Když myslíme na data, začíná to na disku, sedí v databázích na discích, tlačíme je nahoru do paměti. Jakmile je v paměti a distribuován a existují jeho kopie, můžeme použít spoustu kopií, a pokud dojde k jakýmkoli změnám, může se to projevit napříč na úrovni paměti, namísto toho, abychom museli zapínat a vypínat a přes backplane na dvě různé úrovně, jde dovnitř a ven z paměti. Skončili jsme s touto hyperscale hardwarovou platformou, která nám to umožňuje nyní. Když mluvíme o hyperscalingu, je to těžší na směšně hustých úrovních a paměti s velmi vysokou hustotou, s velmi vysokou hustotou počtu procesorů a jader a vláken. Nyní máme velmi komplexní síťové patologie, které to podporují, protože data se musí v určitém okamžiku pohybovat po síti, pokud jde o uzly a klastry.
Takže skončíme s redundancí poruch zařízení, která se stává problémem, a musíme monitorovat zařízení a jejich části. Do této platformy musíme zabudovat odolnou redundanci poruch dat a monitorovat ji. Musíme mít zabudovanou odolnost distribuované databáze, takže musíme sledovat databázovou platformu a zásobník uvnitř. Musíme sledovat rozvrhování distribuovaného zpracování, co se děje uvnitř některých procesů, až po dotazování a dotaz a cestu, kterou dotaz vyžaduje, a způsob, jakým je dotaz strukturován a prováděn. Jak to vypadá, udělal někdo VYBRAT * na „bla“ nebo to, že skutečně udělal velmi inteligentní a dobře strukturovaný dotaz, který jim přinese nominální, minimální množství dat procházející architekturou v zadní rovině? Máme více pracovních zátěží, více uživatelů a více skupin provozujících stejné nebo více pracovních zátěží a dávkových úloh a plánování v reálném čase. A máme tuhle směs dávkového zpracování a zpracování v reálném čase. Některé věci fungují pravidelně - hodinové, denní, týdenní nebo měsíční - jiné jsou na vyžádání. Někdo by tam mohl sedět s tabletem, který by chtěl udělat zprávu v reálném čase.
A znovu se dostáváme k celému bodu, že složitost, která v nich nastává, není nyní jen výzvou, je to docela děsivé. Prověřujeme tuto skutečnost, že jediný problém s výkonem, jen jeden výkonný problém sám o sobě, může mít dopad na celý ekosystém. A tak skončíme s touto velmi zábavnou výzvou zjistit, jak jsou dopady? A máme tu tuto výzvu, jsme reaktivní nebo aktivní? Sledujeme věc v reálném čase a vidíme, že se něco „třeskne“ a reaguje na to? Nebo jsme viděli nějakou formu trendu a zjistili jsme, že s ním musíme aktivně vstoupit? Protože klíčem je, že každý chce něco rychlého, levného a snadného. Nakonec však skončíme těmito scénáři, na které se rád odvolávám, a mou oblíbenou řadou hádanky Donalda Rumsfelda, která se podle mého názoru vztahuje na všechny tyto scénáře vysoké složitosti - a to je to, že jsme to znali, protože to je něco jsme navrhli a postavili a běží podle plánu. Známe neznámé v tom, že nevíme, kdo co běží, kdy a kde, pokud je to na vyžádání. A máme neznámé neznámé a to jsou věci, které musíme sledovat a kontrolovat. Protože realita je, všichni víme, že nemůžete zvládnout něco, co nemůžete měřit.
Chcete-li tedy mít správné nástroje a správnou schopnost sledovat naše plánování CPU, podívejte se na čekací doby a zjistěte, proč věci čekají ve frontách plánů v potrubí. Co se děje v paměti, jaký druh využití se provádí, jaký výkon se dostáváme z paměti? Jsou věci rozděleny správně, distribuují se, máme dostatek uzlů, které drží jejich kopie, aby zvládly pracovní vytížení, které se na ně hází? Co se děje s prováděním procesů mimo procesy operačního systému? Samotné úlohy běží, jednotlivé aplikace a démoni, kteří je podporují? Co se děje uvnitř těchto procesů, zejména strukturování dotazů a jak jsou tyto dotazy prováděny a kompilovány? A zdraví těchto procesů celou cestu ven v zásobníku? Znovu víte, že čekáte, je to správné plánování, je třeba čekat, kde to čeká, je to čekání na čtení paměti, I / O, CPU, I / O napříč sítí koncovému uživateli ?
A pak zpět k tomuto bodu, který jsem právě zmínil těsně předtím, než jsem se zabalil, a to je to, jak se k nim přibližujeme k vyřešení problému a době odezvy? Sledujeme v reálném čase a reagujeme na věci, což je nejméně ideální scénář, ale i tak je lepší, když to nevíme a necháme zavolat na linku technické podpory a řekneme, že se něco pokazilo a musíme to sledovat. ? Nebo to děláme proaktivně a díváme se na to, co přichází po hranici? Jinými slovy, vidíme, že máme nedostatek paměti a potřebujeme přidat další uzly? Děláme analýzu trendů, děláme plánování kapacit? A ve všech těchto skutečnostech sledujeme historické doby provádění a přemýšlíme o plánování kapacit, nebo to sledujeme v reálném čase a aktivně přeplánujeme a provádíme vyvažování zátěže? A jsme si vědomi zátěže, která je na prvním místě? Víme, kdo dělá co v našem klastru a proč?
Výpočty v paměti jsou velmi silné, ale s touto silou je to téměř jedna z těch věcí, jako je nabitá zbraň a hrajete s živou municí. Pokud si nejste opatrní, můžete se nakonec zastřelit do nohy. Tato síla výpočtu v paměti tedy znamená, že můžeme spouštět mnohem rychleji napříč velmi distribuovanými a diskrétními datovými sadami. Ale pak to vyžaduje vyšší poptávku od koncových uživatelů. Na tuto moc si zvyknou a chtějí to. Už neočekávají, že práce budou trvat týdny a zprávy se objeví v obyčejném starém papíru. A pod tím vším je každodenní údržba obepínána kolem oprav, aktualizací a upgradů. A pokud přemýšlíte o nepřetržitém zpracování s výpočtem v paměti, správě těchto dat, správě pracovních zátěží v celé paměti, je to všechno v paměti, technicky v efemérní platformě, pokud začneme používat opravy a aktualizace a upgrady v tam přichází celá řada dalších výzev v oblasti řízení a monitorování. Potřebujeme vědět, co můžeme převést do režimu offline, kdy jej můžeme upgradovat a kdy ho přivést zpět online. A to mě přivádí k mému poslednímu bodu a to znamená, že jak se v těchto systémech stále více a více komplikuje, není to nic, co by člověk mohl udělat jen tím, že saje palcem a zatáhne za ucho. Neexistují žádné, jakési, střevní pocitové přístupy. Opravdu potřebujeme vhodné nástroje pro správu a poskytování této vysoké úrovně výkonu v oblasti správy počítačů a dat.
A s tím na mysli předám našemu příteli z IDERA a uslyším, jak se k této výzvě přistupovali.
Bill Ellis: Velice vám děkuji. Sdílím obrazovku a tady jdeme. Je tedy opravdu ponižující uvažovat o všech technologiích a všech lidech, kteří před námi přišli, aby tyto věci dostupné v roce 2017 byly dostupné. Budeme mluvit o analýze pracovní zátěže pro SAP HANA - v zásadě řešení pro monitorování databáze: komplexní, bez agentů, poskytuje real-time a vytváří historii, takže můžete vidět, co se stalo v minulosti. SAP S / 4 HANA nabízí potenciál lepšího, rychlejšího a levnějšího. Neříkám, že je to levné, jen říkám, že je to levnější. Tradičně se stalo, že byste měli hlavní produkční instanci - pravděpodobně běžící na Oracle ve větším obchodě, potenciálně SQL Server - a pak byste použili tento ETL proces a měli byste více, druh verzí pravdy . A to je velmi drahé, protože jste platili za hardware, operační systém, licenci Oracle pro každé z těchto jednotlivých prostředí. A navíc musíte mít lidi, aby sladili jednu verzi pravdy s další verzí pravdy. A tak bylo toto vícenásobné zpracování ETL jen pomalé a velmi, velmi těžkopádné.
A tak HANA, v podstatě jedna instance HANA, může potenciálně nahradit všechny tyto ostatní instance. Je to levnější, protože je to jedna hardwarová platforma, jeden operační systém, namísto násobků. A tak S / 4 HANA opravdu mění všechno a vy se v podstatě díváte na vývoj SAP z R / 2 na R / 3, různé balíčky vylepšení. Nyní je starý systém k dispozici až do roku 2025, takže máte osm let, než budete skutečně nuceni migrovat. Ačkoli vidíme lidi, víte, dabbling jejich prsty na to, protože vědí, že to přichází, a nakonec, víte, ECC bude běžet na HANA, a tak byste měli být opravdu připraveni na to a pochopit technologii.
Jedna databáze, žádné procesy ETL, žádné kopie, které musí být sladěny. Takže znovu, rychlejší, lepší a levnější. HANA je v paměti. SAP dodává software, dodáváte hardware. Neexistují žádné agregované tabulky. Jednou z věcí, kterou oni, tak jako tak, navrhují, když o tom přemýšlíte, je, že se do toho nechcete dostat, jen si koupíme největší dostupný server. Naznačují, že vy, druh, správná velikost vaší krajiny SAP předem, a v podstatě říkají, nemigrujete data za 20 let. Myslím, že archivace je něco, co je v IT málo využíváno, napříč plošně, nejen v obchodech SAP. A další věc je, že SAP skutečně strávil spoustu času přepisováním svého nativního kódu, aby nepoužíval SELECT *. SELECT * vrací všechny sloupce z tabulky a je to zvláště drahé v sloupcové databázi. A tak to není dobrý nápad pro SAP HANA. Takže v obchodech, které mají mnoho přizpůsobení, mnoho přehledů, to budete hledat a budete chtít specifikovat názvy sloupců, jak postupujete při migraci všeho na HANA.
Rádi bychom říkali, že HANA není všelék. Stejně jako všechny databáze, všechny technologie, musí být monitorovány, a jak již bylo zmíněno, potřebujete čísla, abyste mohli spravovat přebytek, měření měřením. A jedna z věcí, o kterých v oblasti IDERA mluvím, je to, že každá obchodní transakce interaguje se systémem záznamu a v tomto případě to bude HANA. A tak se HANA stává základem pro provádění vašich transakcí SAP, zážitek koncového uživatele. A proto je důležité, aby byl provozován na nejvyšší rychlost. Stává se jediným bodem selhání a při rozhovoru s lidmi je to něco, co může vyústit v to, že máte koncového uživatele a možná používá tato data v reálném čase a mají dotaz ad hoc, který potenciálně není úplně že jo. Možná se nepřipojují ke stolům a vytvořili vnější spojení, partyzánský produkt a v podstatě spotřebovávají spoustu prostředků. Nyní to HANA nakonec uzná a zabije tu relaci. A tak je tu zásadní část naší architektury, která vám umožní skutečně zachytit to v historii, takže můžete vidět, co se stalo v minulosti, a rozpoznat tyto situace.
Pojďme se tedy podívat na analýzu pracovního vytížení systému SAP HANA. Toto je verze 1, proto vás velmi žádáme, abyste se k nám připojili na cestě, a to je produkt společnosti IDERA. Je to komplexní, ale přesto jednoduché. Real-time s trendy. Hostitelské zdraví, například zdraví. Sledujeme stavy čekání, dotazy SQL, spotřebitele paměti a služby. Takto vypadá GUI a hned vedle netopýra uvidíte, že je web povolený. Vlastně jsem toto řešení otevřel v reálném čase v mém systému. Existuje několik zásadních věcí, na které se chcete podívat. Rozdělili jsme se do různých pracovních prostorů. Nejdůležitější z nich je to, co se děje na úrovni hostitele z využití procesoru a využití paměti. Rozhodně se nechcete dostat do zaměnitelného nebo mlátícího hlediska. A pak se v podstatě propracováváte dolů na to, co se děje v trendech, od doby odezvy, uživatelů, příkazů SQL, to je to, co řídí aktivitu v systému.
Jedna z věcí s IDERA je, že víte, že nic se neděje v databázi, dokud nedojde k aktivitě. A ta aktivita jsou příkazy SQL, které pocházejí z aplikace. Měření příkazů SQL je tedy naprosto zásadní pro to, aby bylo možné zjistit příčinu. Pojďme tedy začít a vrtat dovnitř. Takže na úrovni hostitele se můžeme ve skutečnosti podívat na paměť, sledovat v čase, využití hostitelského CPU. Krok zpět, můžete se podívat na příkazy COBSQL. Nyní je jednou z věcí, které uvidíte na naší straně architektury, že tato informace je uložena mimo HANA, takže pokud se něco stane HANA, v podstatě zachycujeme informace až do situace, kdy je Bůh nedostupný . Můžeme také zachytit vše, co se v systému děje, abyste měli jasnou viditelnost. A jedna z věcí, kterou uděláme, je, že představíme příkazy SQL ve váženém pořadí. To tedy vezme v úvahu počet spuštění, a proto jde o agregovanou spotřebu zdrojů.
A tak se zde můžete dostat do jednotlivých metrik - kdy byl tento příkaz SQL proveden? A pak je spotřeba zdrojů do velké míry řízena realizačním plánem, a proto jsme schopni to průběžně zachytit. HANA je v paměti. Je to velmi paralelní. Na každé tabulce má primární indexy, které se některé obchody rozhodnou vytvořit sekundární index pro řešení určitých problémů s výkonem. A tak, druh, vědět, co se stalo s plánem provádění pro některé příkazy SQL, může být velmi cenné. Také se podíváme na služby, spotřebu paměti znovu, mapované v průběhu času. Architektura: jedná se o samostatné řešení, které si můžete stáhnout z našich webových stránek, a architektura je taková, že je povolena pro web.
Ke konkrétní instanci se můžete připojit více uživatelů. Můžete monitorovat místní instance SAP HANA. A v našem úložišti máme průběžnou čtyřtýdenní historii a je to samosprávné. Chcete-li to nasadit, je to poměrně jednoduché. Potřebujete Windows Server. Musíte si ji stáhnout. Většina serverů Windows bude mít integrovanou rozhraní .NET a je dodávána s licencí. A tak byste šli do průvodce instalací, který je řízen programem Setup.exe, a ve skutečnosti by se otevře obrazovka, licenční smlouva a jednoduše byste tento obrys přepracovali kliknutím na „Další“. A tak, kde byste chtěli, aby HANA být nainstalován? Další jsou vlastnosti databáze a toto bude vaše připojení k SAP HANA, takže se jedná o monitorování agenta HANA bez agentů. A pak v podstatě poskytneme náhled, to je port, na kterém ve výchozím nastavení komunikujeme. Klikněte na „Instalovat“ a v zásadě se spustí HANA a začnete budovat historii. Takže jen trochu informací o velikosti grafu. Můžeme sledovat až 45 instancí HANA a budete chtít použít tento druh, na posuvné stupnici, k určení počtu jader, paměti, místa na disku, které budete potřebovat. A to předpokládá, že máte úplnou čtyřtýdenní historii válcování.
Stejně jako rychlá rekapitulace se také díváme na stav serveru, stav instance, využití CPU / paměti. Co jsou to spotřebitelé paměti, jaké jsou ovladače aktivity, jaké jsou služby? Příkazy SQL jsou zásadní - jaké jsou stavy provádění? Ukažte mi plány provádění, kdy se věci provádějí, poskytují trendy? Toto vám poskytne real-time a historii toho, co se stalo. A jak jsem zmínil, protože naše historie je oddělená od HANA, chystáme se zachytit věci, které vypršely a byly vypuštěny z historie HANA. Abyste viděli skutečnou spotřebu prostředků ve vašem systému kvůli samostatné historii.
Jak jsem již zmínil, webové stránky IDERA v sekci Products to snadno najdete. Pokud to chcete vyzkoušet, určitě vás vítáme. Podívejte se, jak vám poskytuje informace a na tomto webu jsou další informace. Jakékoli zúčastněné strany jsou tedy více než šťastné. Nyní v portfoliových produktech nabízených společností IDERA existuje monitor transakcí SAP ECC, který se nazývá Precise for SAP. A to, co dělá, je - ať už používáte portál, nebo jen vyrovnávací ECC - skutečně zachytí transakci koncového uživatele od kliknutí na disk, až po příkaz SQL a ukáže vám, co se děje.
Teď vám ukážu jen jednu souhrnnou obrazovku. Z této souhrnné obrazovky chci mít několik s sebou. Je to doba odezvy na ose Y, čas na ose X plus den a v tomto zobrazení transakce vám ukážeme čas klienta, čas fronty, čas ABAP kódu, čas databáze. Můžeme zachytit ID koncových uživatelů, T-kódy a vy můžete skutečně filtrovat a zobrazovat servery prostřednictvím konkrétní transakce, kterou prošli. Mnoho obchodů tedy provozuje přední část krajiny pod VMware, takže můžete skutečně měřit, co se děje na každém ze serverů, a dostat se do velmi podrobné analýzy. Toto zobrazení transakcí tedy platí pro transakci koncového uživatele v celé šířce SAP. A najdete to na našem webu pod Products APM Tools a toto by bylo řešení SAP, které máme. Instalace je o něco složitější, takže se nejedná pouze o stažení a vyzkoušení, jako bychom měli pro HANA. To je něco, kde bychom společně pracovali na návrhu, realizaci a realizaci celkové transakce za vás.
Takže jen třetí rychlá rekapitulace, analýza pracovní zátěže pro SAP HANA, je komplexní, bez agentů, v reálném čase, nabízí historii. Nabízíme možnost stažení a vyzkoušení pro váš web.
Takže s tím půjdu čas zpět na Erica, Deze a Dr. Bloora.
Eric Kavanagh: Jo, možná Robin, nějaké otázky od tebe, a pak Dez po Robinovi?
Dr. Robin Bloor: Dobře. První věc, kterou bych rád řekl, je, že se mi opravdu líbí pohled na transakci, protože to je přesně to, co bych v této situaci chtěl. Odvedl jsem spoustu práce - dobře, je to už dávno - dělám sledování výkonu a to byla věc; v té době jsme neměli grafiku, ale to byla věc, kterou jsem chtěl především dělat. Aby jste se tak či onak mohli vstoupit do místa, kde se problém vyskytuje.
První otázka, kterou mám, je, víte, většina lidí implementuje S / 4 nějakým způsobem nebo jiným způsobem mimo krabici, víte. Když jste se zapojili do jakékoli implementace S / 4, zjistili jste, že je implementována dobře, nebo skončíte, víte, objevujete věci, které by mohly zákazníka přinutit znovu nakonfigurovat? Jak to všechno jde?
Bill Ellis: No, každý obchod je trochu jiný. A existují různé vzorce použití, existují různé zprávy. Pro weby, které mají hlášení ad hoc, mám na mysli, že se jedná o zástupný znak v systému. A tak je jednou z klíčových věcí začít měřit a zjistit, co je základní linie, co je normální pro konkrétní web, kde je dané místo, na základě jejich vzorců použití, zdůrazňující systém. A odtud proveďte úpravy. Optimalizace monitorování obvykle není jednorázová, je to skutečně běžná praxe, kdy monitorujete, vylaďujete, honujete, aby systém pro komunitu koncových uživatelů lépe sloužil k efektivnějšímu poskytování služeb podniku.
Dr. Robin Bloor: Dobře, takže když implementujete - myslím, vím, že na tuto otázku je obtížné odpovědět, protože se bude lišit v závislosti na velikosti implementace - ale kolik zdroje monitorovací schopnosti IDERA, kolik to spotřebuje ? Dělá to něco na ničem, nebo to prostě nezasahuje? Jak to funguje?
Bill Ellis: Ano, řekl bych, že režie je přibližně 1–3 procenta. Mnoho obchodů je velmi ochotno to obětovat, protože potenciálně budete moci koupit zpět, pokud jde o optimalizaci. Závisí to na vzorcích použití. Pokud provádíte celou krajinu, záleží to na jednotlivých sledovaných technologiích. Takže, druh, počet najetých kilometrů se liší, ale jak jsme už mluvili, je určitě lepší utratit trochu za to, co se děje, než jen slepě. Zejména by to bylo, víte, tady jsme v lednu a dostanete se do zpracování ročních období a shromažďujete data za 12 měsíců. Víte, to dělá výkon, dostávat zprávy regulačním organizacím, bankám, akcionářům, je naprosto zásadní v kritickém obchodním výkonu.
Dr. Robin Bloor: Správně. A z vašeho pohledu jen rychle, protože si myslím, že jste tam zapojeni s celou řadou webů SAP - jak velký je pohyb mezi zákaznickou základnou SAP směrem k S / 4? Chci říct, je to něco, co víš, že je tu nějaká lavina nadšených zákazníků, nebo je to jen stálý pramínek? Jak to vidíš?
Bill Ellis: Myslím, že před pár lety bych řekl, že to byla špička. Teď bych řekl, že lidé jsou tak trochu na kolena. Myslím, že, jak víte, vzhledem k harmonogramu budou lidé v příštích několika letech opravdu ponořeni do HANA. A tak sledování, transformace, víte, myslím, že většina zákazníků je tak nějak na křivce učení společně. A tak si myslím, že nejsme úplně v lavině, jak jste uvedli, ale myslím, že jsme na vrcholu velké transformace na HANA.
Dr. Robin Bloor: Dobře, takže pokud jde o weby, které jste viděli, které pro toto šly, přizpůsobují také HANA pro jiné aplikace, nebo jsou nějakým způsobem úplně spotřebovávány při vytváření tohoto věci fungují? Jaký je tam obrázek?
Bill Ellis: Ano, lidé často integrují SAP s jinými systémy, v závislosti na tom, jaké moduly atd., Takže je tu trochu. Opravdu nevidím lidi, kteří na HANA nasazují jiné aplikace. To je jistě možné. A tak je to více kolem krajiny kolem infrastruktury SAP.
Dr. Robin Bloor: Předpokládám, že bych vás měl raději předat Dezovi. Zabíjel jsem tvůj čas. Dez?
Dez Blanchfield: Děkuji. Ne, to je vše dobré. Dva velmi rychlé, jen aby se pokusili nastavit téma. SAP HANA je už několik let venku a lidé to měli možnost zvážit. Kdybyste nám měli dát hrubý odhad procenta lidí, kteří to provozují - protože tu běží spousta lidí - co si myslíte, že procento trhu, o kterém víte, je v současné době pryč od tradičních implementací SAP po SAP na HANA? Díváme se na 50/50, 30/70? Jaké, jaké procento trhu vidíte lidi, kteří přešli a učinili krok nyní, oproti lidu, kteří se jen drží a čekají na věci, které se mají zlepšit nebo zlepšit nebo změnit nebo cokoli tak může být?
Bill Ellis: Ano, ve skutečnosti bych dal z mého pohledu procento kolem 20 procent. SAP má tendenci být tradičními podniky. Lidé bývají velmi konzervativní, a tak jejich lidé táhnou nohy. Myslím, že to také záleží na tom, víte, zda jste SAP provozovali po dlouhou dobu, nebo jste typ SMB, který možná nedávno nasadil SAP? A tak existuje řada faktorů, ale celkově si nemyslím, že procento je 50/50. Řekl bych, že 50 procent je alespoň fušujících a má HANA někde v jejich datovém centru.
Dez Blanchfield: Zajímavý stánek s jídlem, který jste nám dali dříve, bylo to, že se jedná o hotový úspěch v jistém smyslu a že hodiny fyzicky a doslova tikají o čase přechodu. Myslíte si, že v tom procesu lidé uvažovali? Jaký je obecný smysl lidského porozumění, že se jedná o přechodný posun v platformě, není to jen možnost, stává se to výchozí?
A z pohledu SAPu jsem si jistý, že se posouvají tímto způsobem, protože ve výkonu existuje významná konkurenční výhoda, ale myslím, že také zápasí s kontrolou zpět z platformy místo toho, aby šlo o třetí - party party, nyní ji přivedou zpět na svou vlastní platformu. Myslíte si, že společnosti tuto zprávu skutečně dostaly? Myslíte si, že tomu lidé rozumějí a nyní se na to chystáte? Nebo je to stále něco jako nejasná věc, myslíte si, na trhu?
Bill Ellis: Nemyslím si, že SAP je stydlivý o komunikaci a lidé, kteří šli do SAPPHIRE, viděli HANA všude. Takže si myslím, že lidé jsou si dobře vědomi, ale lidská přirozenost je tím, čím je, víte, někteří lidé trochu přetahují nohy.
Dez Blanchfield: Protože si myslím, že důvod, proč jsem se ptal na tuto otázku, musíte mi odpustit, ale souhlasím. Myslím, že se nestyděli o komunikaci. Myslím, že signál vyšel v mnoha ohledech. A já s tebou souhlasím - nevím, že všichni ještě skočili. Víte, tradiční podnik, velmi velké podniky, které to provozují, jsou stále v mnoha ohledech, ne úplně táhnou za nohy, ale jen se snaží zápasit se složitostí posunu. Protože si myslím, že jedna věc, kterou váš nástroj a určitě vaše demonstrace dnes zdůraznila, a pro mě jeden klíčový krok s jídlem, který bych chtěl, aby všichni poslouchali a naladili dnes, aby se posadili a věnovali pozornost reflexi, je nástroj, který je podle mě tento proces zjednodušený. Myslím, že pod nimi jsou partneři velmi nervózních CIO a jejich týmy, kteří přemýšlejí: „Jak provedu přechod od tradičních RDBMS, systémů pro správu relačních databází, které známe po celá desetiletí, k úplně novému paradigmatu výpočetních a řízení úložiště v prostoru, který je stále relativně statečný? “ Ale v mnoha ohledech je to neznámé a existuje jen velmi málo lidí, kteří provedli tento posun v jiných oblastech, že to není tak, jako by měli jinou část podnikání, která již provedla přechod na výpočet v paměti. Takže, je to vše, nebo nic pohybovat v jejich mysli.
Takže jedna z věcí, které jsem z toho vzal více než cokoli jiného - zasáhnu vás otázkou za minutu - je ten strach, myslím, že je nyní v mnoha ohledech zmírněn a že před dneškem, Kdybych poslouchal CIO, tak bych si nějak pomyslel: „Jak se mi podaří udělat tento přechod? Jak zaručím stejnou schopnost, jakou máme na platformě pro správu relačních databází a dlouholeté zkušenosti s databázemi DBA, na novou platformu, v níž v současné době nemáme dovednosti? “Takže moje otázka je, že, myslíte, že lidé pochopili, že nástroje nyní existují s tím, co nabízíte, a že mohou, jaksi, zhluboka dýchat a povzdechnout si, že přechod není tak děsivý, jak by to mohlo být dříve. aby byl tento nástroj k dispozici? Myslíte si, že to lidé pochopili, nebo je to stále něco takového, že se prostě potýkají s přechodem na výpočetní a paměťové úložiště v paměti oproti starým kombinacím NVMe, flash a disku?
Bill Ellis: Jo, takže existuje nepochybně spousta technologií a nástrojů, které to graficky zobrazují, co se děje a je velmi snadné určit špičkové spotřebitele zdrojů. Chci říct, že to pomůže zjednodušit věci a pomůže technologickému personálu opravdu dobře zvládnout. Hej, budou vědět, co se děje, a budou schopni porozumět celé složitosti. Nástroje na trhu jsou tedy rozhodně užitečné, a proto nabízíme analýzu pracovní zátěže pro SAP HANA.
Dez Blanchfield: Jo, myslím, že skvělé na tom, co jste nám dnes ukázali, je to, že při sledování hardwarového kusu, kusu operačního systému, dokonce i sledování části pracovní zátěže pohybující se, jak jste řekl, myslím, nástroje byli tam už nějakou dobu. Trochu pro mě, zejména uvnitř typu HANA, je to, že jsme neměli nutně schopnost získat lupu a podívat se do ní a podívat se přímo na to, co váš nástroj dělá s tím, co se děje s dotazy a jak jsou být strukturován a kde je toto zatížení.
Díky nasazení, které jste dosud viděli, vzhledem k tomu, že jste doslova nejvíce autoritativní v tomto prostoru na své platformě na světě, některé z rychlých výher, které jste viděli - máte nějaké neoficiální znalosti, se kterými můžete sdílet nás kolem některých Eureka momentů, aha momentů, kde lidé nasadili sadu nástrojů IDERA, našli věci, které si prostě neuvědomili, byly na jejich platformách a výkonech, které měli. Máte nějaké skvělé neoficiální příklady toho, kde to lidé právě rozmístili, aniž byste věděli, co měli, a najednou odešli: „Páni, vlastně jsme nevěděli, že to tam je?“
Bill Ellis: Jo, takže velké omezení nativních nástrojů spočívá v tom, že pokud je dotaz na útěk zrušen, vypláchne informace, takže v podstatě nemáte historii. Tím, že ukládáme historii offline, jako runaway dotaz, budete mít historii, budete vědět, co se stalo, budete mít možnost vidět plán provedení atd. A to vám umožňuje, druh, pomoci komunitě koncových uživatelů v zásadě lépe pracovat, psát zprávy lépe atd. A tak historie je něco, co je opravdu příjemné mít. A jedna z věcí, které jsem chtěl ukázat, je, že se můžete podívat v reálném čase až do čtyř týdnů a pak se můžete snadno přiblížit na jakýkoli časový rámec zájmu a pak můžete odhalit základní řidičskou aktivitu. Jen to, že viditelnost, je něco, co je velmi užitečné vědět, jaké úzké hrdlo se objevilo.
Dez Blanchfield: Zmínil jste se o tom, že je to více uživatelů, jakmile je nasazen, a byl jsem docela ohromen skutečností, že v mnoha ohledech je bez agentů a účinně nulový. Je normální, že jediné nasazení vašeho nástroje bude potom k dispozici všem od střediska síťových operací v NOC a sleduje základní infrastrukturu podporující klastr až po aplikační a vývojový tým? Je to normou a nasadíte ji jednou a oni by to sdíleli, nebo očekáváte, že by lidé mohli mít instanci modelu při pohledu na různé části zásobníku? Jak to vypadá?
Bill Ellis: Takže základní tým bude mít obvykle velmi silný zájem o technologické základy toho, co se děje v SAP. Je zřejmé, že existuje několik týmů, které podporují celou krajinu. HANA kus je právě zaměřen na to. Jdu na výchozí tým SAP jako základní spotřebitele informací.
Dez Blanchfield: Správně. Udeří mě však, že pokud mám vývojový tým nebo ne jen na úrovni kódu, ale pokud mám tým vědců nebo analytiků, kteří tam provádějí analytickou práci na souborech dat, zejména vzhledem k tomu, že existuje významný tlak na to, aby věda o údajích byla nyní aplikována na všechno uvnitř organizací nyní, podle mého názoru - a opravte mě, pokud se mýlím - se mi zdá, že to bude také pro ně velmi zajímavé, protože v mnoha ohledech jeden o vážných věcech, které můžete udělat v prostředí datového skladu, je uvolnění datového vědce a umožní mu začít s ad hoc dotazy. Měli jste nějaké příklady toho, co se děje, když vás obchody zavěšovaly, a řekli: „Hodili jsme na to tým pro vědu o údajích, opravdu to bolí, co pro ně můžeme udělat v porovnání s tím, co děláme právě tradiční provozní monitorování a řízení? “Je to dokonce něco?
Bill Ellis: No, jo, trochu bych to otočil a omezil by mi odpověď, že když se podívám na výkon, uvědomuji si výkon při vývoji QA výroby, víte, čím dříve skladujete, tím méně problémů, méně překvapení máte. Takže absolutně.
Dez Blanchfield: V návaznosti na to mnoho nástrojů, se kterými jsem měl zkušenosti - a jsem si jistý, že Robin bude souhlasit - mnoho nástrojů zde, pokud máte velký RDBMS, potřebujete opravdu vysoké- kvalifikovaní, hluboce zkušení a zkušení DBA. Některé požadavky na infrastrukturu a platformu, které přicházejí s aplikací SAP HANA, protože jsou v současné době podporovány na konkrétních distribucích přizpůsobujících se konkrétnímu hardwaru a tak dále, podle mého nejlepšího vědomí. Víte, existují lidé s desetiletými zkušenostmi, kteří nejsou stejní. Vidím však, že to není nutně požadavek tohoto nástroje. Zdá se mi, že můžete svůj nástroj nasadit a dát mu nějaké docela nové tváře a okamžitě jim dát sílu najít věci, které se dobře nevykonávají. Je to tak, že existuje poměrně krátká křivka učení, která se s tímto krokem přizpůsobí a z jeho nasazení získá nějakou hodnotu? Víte, můj obecný smysl je, že nemusíte mít 20 let zkušeností s řízením nástroje, abyste mohli okamžitě vidět hodnotu. Souhlasíte, že tomu tak je?
Bill Ellis: Oh, absolutně a myslím si, že hodně úspěchů nasazení opravdu závisí na plánování a architektuře prostředí SAP HANA. A pak je nepochybně spousta složitosti, spousta technologie, na které je postavena, ale pak to prostě jde na sledování vzorců použití toho, co se děje. Takže, i když je složitější, svým způsobem je zabalený a poněkud zjednodušený. To je velmi chudé.
Dez Blanchfield: Jo, takže předtím, než se vrátím k Ericovi, protože vím, že má pár otázek, zejména od těch, které přicházejí přes otázky a odpovědi, které vypadaly zajímavě, a já ráda slyším odpověď. Tradiční cesta pro někoho - už jste zmínili, že to můžete získat, můžete si ji stáhnout a vyzkoušet. Můžete to zopakovat rychle pro lidové poslouchání buď dnes, nebo pro lidi, kteří by to mohli přehrát později? Jaké jsou rychlé dva nebo tři kroky, jak dostat ruce na kopii a nasadit ji a vyzkoušet ji ve svém prostředí, než si ji koupí? Jak to vypadá? Jaké jsou kroky k tomu?
Bill Ellis: Jo. Takže, IDERA.com a stačí přejít na Produkty a uvidíte Analýza pracovního vytížení pro SAP HANA. K dispozici je stránka ke stažení. Myslím, že vás požádají o nějaké kontaktní informace a produkt je pouze zabalen s licenčním klíčem, takže si ho můžete nainstalovat pomocí Setup.exe a jen se rozjet, myslím, velmi rychle.
Dez Blanchfield: Takže mohou jít na váš web, mohou si ho stáhnout. Pamatuji si, že jsem se na to díval před nějakou dobou a včera večer jsem se dvakrát zkontroloval, můžete si vyžádat demo, z paměti, kam vás někdo z vašeho týmu projde? Ale můžete si ji stáhnout zdarma a nasadit lokálně ve vašem vlastním prostředí, ve svém vlastním čase, že?
Bill Ellis: Ano.
Dez Blanchfield: Výborně. No, myslím, že více než cokoli jiného, to je asi to, co bych osobně doporučil lidem, aby udělali, že si vezmu kopii z webu, vezmou tam nějakou dokumentaci, protože vím, že je tam hodně dobrého obsahu, abych to udělal, a zkus to. Dejte to do svého prostředí a podívejte se, co najdete. Mám podezření, že jakmile se podíváte pod kapotu pomocí prostředí SAP HANA pomocí nástroje IDERA, najdete tam věci, o kterých jste nevěděli, že tam byly.
Podívej, děkuji ti za to a děkuji za čas jen za Q&A s Robinem a I. Ericem, půjdu ti zpátky, protože vím, že některé Q & A prošly také od našich účastníků.
Eric Kavanagh: Ano, tady opravdu rychlý. Jeden z účastníků zde tedy udělá opravdu dobrý komentář, jen když mluví o tom, jak se věci mění. V minulosti se paměť udusila, zpomalila se častým stránkováním, v současné době CPU udává příliš mnoho dat v paměti. Víte, existují problémy se sítí. Vždy to bude pohyblivý cíl, že? Co vidíte v těchto dnech jako trajektorii, pokud jde o to, kde budou úzká místa a kde budete muset soustředit svou pozornost?
Bill Ellis: Jo. Dokud měříte, je těžké to vědět. Jednou z věcí příkazů SQL je, že budou hnací silou spotřeby prostředků. A tak za okolností, že byste měli mít, například, velkou spotřebu paměti nebo spotřebu procesoru, budete schopni zjistit, jaká aktivita způsobila spotřebu zdrojů. Teď byste to nemuseli nutně chtít zabít, ale také byste si měli být vědomi toho, co se děje, jak často se to stává, atd. Jsme tak trochu nové, pokud jde o řešení celé sady nebo kuchařky odpovědí na různé okolnosti. A tak je to velká otázka a čas ukáže. S postupem času budeme mít více informací.
Eric Kavanagh: To je vše. No, vy jste ve velmi zajímavém prostoru. Myslím, že v nadcházejících měsících a příštích několika letech uvidíte spoustu aktivit, protože vím, že SAP, jak jste navrhl v našem volání s obsahem, poskytl lidem pěknou dlouhou rampu pro lidi, kteří provedli přechod. Haně. Ale tato rampa má konec a v určitém okamžiku budou muset lidé učinit některá vážná rozhodnutí, takže čím dříve, tím lépe, že?
Bill Ellis: Rozhodně.
Eric Kavanagh: Dobře lidi, jsme spálili další hodinu tady na Hot Technologies. Můžete najít informace online, insideanalysis.com, také techopedia.com. Zaměřte se na tento web a získejte spoustu zajímavých informací, včetně seznamu všech našich archivů těchto minulých webcastů. Ale lidi, velké poděkování všem vám tam, našim přátelům v IDERA, Robinovi a samozřejmě Dezovi. A příští týden vás dostihneme, lidi. Ještě jednou díky za váš čas a pozornost. Opatruj se. Ahoj.
