Vlákno názorů k článku Ledy se hýbají. Sedm úřadů spouští projekt otevřených dat od . . - ano, dávají od toho ruce pryč, důvod proč...
-
. . (neregistrovaný)
v tom máte pravdu, je to vysoce neefektivní a dost problematické, ale HW je levný, koupíš za pár milionů servery a jsi schopný zpracovávat několik PB dat, která jiná platforma ti to dá?
Řada jiných technologií je mnohem, mnohem lepších, ale v momentě kdy dojde k lámání chleba se škálováním či množstvím dat, vše si vyrazí zuby.
Google hadoop již opustil, teď jeho vývoj táhne zejména činský trh, kde na něm běží všechny tamní sociální sítě, stejně tak na něm jede Seznam, yandex, Avast.
Spark je občas šílenost, ale umí dobře škálovat streaming a spustíš v něm C kód a dají se v tom dělat zázraky.
Pokud se ti data na třídění vejdou na jeden server, najdeš tisíc možností jak je lépe rozstřídit, jakmile ale potřebuješ pro data deset serverů, již se ti možnosti v čem je třídit dost zúžují...
-
Ano, jsme z jineho prostredi. Nekteri lide platformy vymysleji a programuji, a druzi je pouzivaji. Pak jsou z toho obvykle ruzne pohledy na jednu vec :-) Vite, ja taky muzu pouzit pro vypocet grafovych struktur Hadoop, muzu ho dokonce pouzit pro obycejne trideni dat, ale pro tyto ulohy se ukazuje jako reseni neefektivni a s vyraznymi ztratami v radu desitek az stovek procent. Posledni dekompozice te zazracne platformy resi nektere z mnoha nedostatku, takze pak jde delat ad-hoc reseni nad vykuchanymi moduly. Toto jsou syrova fakta, ktera potvrdi jak pan Cutting tak i Cafarella, pokud budou uprimni. O narocnosti spravy Hadoop clusteru a sprave zdroju jiste take neco vite, zadny zazrak to neni, a duvod proc se to pouziva (odlehcene receno) je asi tak jako proc se pouzivaji MS Windows. Dalsi kdo by vam pri osobnim a uprimnem hovoru potvrdil jak je Hadoop "nestastny" jsou lide z Googlu, ale oficialne samozrejme nic nereknou, protoze v tom jsou penize za prodeje jejich reseni, ktere z Hadoopu delaji aspon (obcas) efektivni software. A takhle funguje korporatni svet.
-
fd (neregistrovaný)
Aha, vy navic neumite cist ... takze citace ...
http://wwwinfo.mfcr.cz/ares/ares_es.html.cz
"Vzhledem k charakteru aplikace ARES nenese Ministerstvo financí odpovědnost za aktuálnost a úplnost údajů...ani za nepřetržitý provoz...ani za korektnost a aktuálnost jimi zpřístupňovaných informací..."
Ovsem zakon vam stanovi povinost overovat, jen neni kde.
-
fd (neregistrovaný)
Ocividne melete a nevite o cem.
Pokud nekdo potrebuje overit existenci jedne firmy, tak na to nepotrebuje stahovat GB dat, staci mu API, ktereho se muze zeptat na prave tu jednu firmu a to mu trivialne vrati pouze udaje o ni.
Podstatne pro nej je, aby ta data byla aktualni. Nejaka komercni firma, ktera si ty GB dat postahuje a na tech rok starych datech bude poskytovat nejakou funcionalitu je mu knicemu.
A jestli chcete videt jako to fungovat rozhodne nema, tak se dete podivat na ty (konecne ...) verejna data o jizdnich radech. Ty oscanovana PDF si tam muzete volne postahovat.
-
. . (neregistrovaný)
očividně jsme úplně z jiného prostředí, Spark nad Hadoopem třeba používá polovina českých bank, mobilní operátoři, Facebook či třeba český Gooddata, stejně tak běží v CERNu. Ne všichni se spokojí s možnostmi teradaty či RDBMS. Proč myslíte, že se to nedá provozovat profesionálně? :)
-
. . (neregistrovaný)
ale přece o tom furianství jsou otevřená data a stejně tou myšlenkou jdu výzvy typu, vymyslete aplikaci, pošlete nám návrhy atd. atd.
Chci jasně oddělit samotná data a business logiku nad nimi, ať už jí dělá kdokoliv, klidně sám stát.
K efektivnímu řešení nevedou současné limity na stahování odevřených dat, kdy ani nejsem schopný data získat, aby nedošlo k zablokování celé sítě, to je postavené na hlavu.
Nárust dat bude pořád v určitých mezích, už teď není problém zpracovávat stovky TB za pár tisícovek měsíčně, tady se bavíme o GB.
-
Jste praktik a urcite byste se mel podilet na implementacich. Navrh je zase dobre prenechat lidem, kteri teto problematice rozumi a delaji ho s vidinou cile a ne svych subjektivnich pocitu. Furiantstvi typu "tuhle rundu platim ja" nebo "ja do toho ty servery dam" nepovede k efektivnimu reseni, ale k presnemu opaku, zejmena pri narustu dat. Nezlobte se, ale ja pro sebe tuto diskuzi koncim, protoze omyly nejlepe proveri cas. Ted je to na nem.
-
. . (neregistrovaný)
A co si tedy představuješ pod API k datům? V UK jsou také jen dostupné balíky dat, nikoliv rozhranní k nim.
Jakékoliv rozhranní omezuje práci s daty, toť vše co tvrdí a představa, že než budou nějaká data dostupná, musí se pro ně vytvořit API mě opravdu neláká.
Očividně ale mluvíme v naprosto jiných intencích, jsem z IT a věnuji se datům a práci s nimi profesionálněj pro nadnárodní klientelu.
-
. . (neregistrovaný)
jenže ověření (konzistenci, integritu a validitu) můžeš provést i nad datovými souboty a nepotřebuješ k tomu specializované rozhranní (aka API). V jiném příspěvku jsem uvedl příkad s distribucí linuxových aktualizací.
Kontrola identity pro stahování otevřených dat je nežádoucí, v tom případě už to nejsou otevřená data, ale spíše svobodný přístup k datům.
Já chci nechat práci s daty na komerčním sektoru, komunitě a nedávat to státu, když to neumí a nezvládá, zbytečně se pak taková data zamknout do jednoúčelových aplikací, rozhraní.
-
. . (neregistrovaný)
no protože stát nemá takové lidi, aby mu to navrhli, oni ti lidi ani nejsou v velkých českých firmách.
Mně rozhranní pro práci s daty nedává smysl, jediné co mi dává smysl je bezbariérová dostupnost takových dat, nepotřebuji k tomu autorizaci, autentizaci či filtrování nebo vyhledávání.
Naopak podobné funkce nad takovými daty rád zdarma poskytnu, mám na to technologie i servery, jen potřebuji ty a data a nechci, aby stát vynakládal prostředky na něco víc než poskytnutí dat, stát je neflexibilní v jakékoliv změně a vše by funkčně zafixoval na několik let, toho se bojím.
Na škálování datových souborů nepotřebuji doktorád, máme tady otevřené ověřené technologie, třeba ty, které používají linuxové distribuce k aktualizacím. Proč zavádět API, které budu muset implementovat, které se už z přítomnosti nějaké business logiky bude hůře škálovat?
-
Nikoli, já jenom vím, že rozhraní omezuje uživatele na používání toho, co je v rozhraní implementováno, a uživatelé nemohou využít toho, k čemu sice za tím rozhraním existují zveřejnitelná data, ale přes to API k nim není přístup. Uváděl jsem jako příklad ty jízdní řády, pro které sice existuje rozhraní, které spoustě uživatelů stačí, ale třeba Google nebo Seznamu pro integraci do map je to rozhraní k ničemu, stejně jako je k ničemu někomu, kdo chce udělat off-line vyhledávání spojení do mobilu.
Ono by to totiž s tím API muselo fungovat tak, že si někdo pískne, že chce takové a takové API, a stát mu ho dodělá. Jenže proč by to dělal a platil stát – pro stát je daleko jednodušší zveřejnit ta data, a API ať už si udělá ten, kdo ho chce používat.
To, že je lepší poskytnout data, a ať si s nimi každý dělá, co chce, se ve světě ví už delší dobu, takže na nějaké rozsouzení časem není potřeba čekat, výsledek už se dávno ví. Teda pokud nemáte pocit, že ČR má nějaké „špecifiká“, kvůli kterým to tady bude jinak.
-
Urcite je zajimave si postavit z kremiku na vlastni zahradce vlastni procesor s vlastni instrukcni sadou, sehnat si do toho data, vsechno pripravit....a nakonec dojit k poznani, ze kdybyste pouzil Mash-up, tak jste mohl delat neco zajimavejsiho :-)
Vy stale mate predstavu rozhrani jako nejake vratnice, kde sedi neprijemny vratny, ktery vas chce vypakovat, a proto to chcete mit plne pod kontrolou. Jenze nektera data proste nedostanete, protoze dodavatel dat nezna vasi identitu. Ja spise preferuji API s moznosti overeni, plnym pristupem kamkoliv, klidne i s dumpem... ovsem zacit a skoncit na dumpovani DB ma z praktickeho/ekonomickeho pohledu nulovy efekt. S tim vy jiste souhlasit nebudete, takze to nechme rozsoudit cas. Piti pak plati ten, kdo se zmylil.
-
Pako (neregistrovaný)
V článku jsou vyjmenované agendy jejichž data by měla být otevřena. Jde jednoznačně o agendy kde dostupnost kompletních dat v dobře dokumentovaném formátu má pro veřejné použití větší smysl než jedno API nad nimi.
To pochopitelně neznamená že rozumně udělané API by svůj význam nemělo také.
-
Nekolik zakladnich postrehu.
Co je podle vas to "API", ze mu davate takove privlastky o skalovani a cene provozu? Proc by kancelar vladniho architekta nezvladla udelat vhodna API? Jiste tam nesedi jen neci kamaradi, ale lide s erudici a kvalitni odbornici. Nebo ne?
Mnoho vladnich systemu je, budme uprimni, black-box. Takovy bastl federovanych systemu rozetnete (za provozu) postavenim bran s API. Pak se firmy i obcane muzou misto podavani papirovych formularu spolehnout na strojova rozhrani a dokonce propojeni mezi urady bude moci byt konecne strojove a neduplicitni. Podle priorit a rozpoctu muzete nasledne eliminovat bastl, vylepsovat API, stepit ho na mensi casti, uvolnovat vic dat, atd. Tohle s opakovanymi importy/exporty datovych bobku nikdy nedosahnete. Nanejvys vytvorite komunitu lidi, kteri spolu mluvi "o datech statni spravy" a problematice importu/exportu.
Kdyz mate kolo, take vas nikdo nenuti jezdit jako pan Kreuziger, pokud se k tomu sam nerozhodnete. Proc by mel tedy poskytovatel dat plytvat vykonem? Nuti ho k tomu nekdo? Vim jaka je realita przneni vladnich zakazek. Osobne jsem videl system, ktery vydelava statu dost penez v radu miliard. Bezi na extremne drahem HW a SW, neskucne zprznenem hobby software nekde z Jizni Ameriky a pritom by to same utahl bezny notebook. Tuhle realitu znam, jenze clovek by nemel porad premyslet v intencich toho, ze stat umi jen veci pokazit kvuli spatnemu rizeni a klubum nejrozlicnejsich kamaradu. Dobrych techniku a architektu je v tehle zemi neskutecne dost.
-
Ty přestupy buď budou součástí těch dat, takže identifikátory zastávek budou sedět, nebo si je každý implementátor musí zajistit sám. A pak je správné, že si je každý může udělat sám, podle svých potřeb, a že není závislý na nějakém API, kde ty přestupy mohou být špatně.
To, že k sobě sety patří, zjistím podle nějakého identifikátoru, který to bude označovat. Třeba pokud se nebudou vydávat častěji než jednou denně, poznám to podle data vydání.
Ty požadavky na data vznikají proto, že nějaká rozhraní pro přístup k těm datům už existují, ale vždy přijde někdo, kdo by s těmi daty chtěl pracovat jiným způsobem, a to rozhraní mu nestačí – potřeboval by přístup k těm datům, nad kterými rozhraní pracuje. Když má ta data, může si to rozhraní klidně napsat sám – jediná nevýhoda je, že bude duplikovat práci, kterou už odvedl na tom rozhraní někdo jiný. Zatímco když máte jenom rozhraní, a potřebujete jiný přístup k datům, máte smůlu, to nijak neobejdete. Takže je to přesně naopak, než tvrdíte – potřeba je otevřít hlavně ta data, a to API k nim už pak může napsat kdokoli.
Nemusíte vymýšlet stovky reálných situací, vymyslete alespoň jednu.
-
. . (neregistrovaný)
Moc teorie. Dobře udělaných API je pomálu a často jsou hodně špatně škálovatelná a drahá na provoz. Házet někam soubory je levné a dá se to transparentně škálovat/cachovat.
Příklad praxe, pro jednu velkou českou firmu jsme dělali kontinuální akvizici dat od třetí strany (za měsíc cca 5TB nekomprimovaných dat) v proměnlivé struktuře. Na S3 kompatibilní uložiště jsme dostali každou hodinu změněné údaje (fieldy) proti poslednímu stavu (formát avro), každý údaj měl svoje sekvenční číslo, aby bylo možné ověřit konzistenci. Schéma bylo zpětně neměnné, pouze přibývaly nová pole, zpětnou projekci struktur jsme zajišťovali sami a nebylo to nijak obtížné.
Druhý příklad, pro jiného klienta jsme zajišťovali sběr dat z jeho uzlů po celém světě (cca 8PB měsíčně), data chodila v různých velikostech, v různých formátech a různě časově zarovnaná. Opět S3 kompatibiní uložiště, podle přípony a vnitřní struktury souboru jsme detekovali jednoduše jestli už formát známe nebo ne, znémé formáty jsme rovnou zpracovávali, ty neznáme zařazovali do fronty a čekali až odpovědný člověk vytvoří odpovídající job v Talend na zpracování takových dat.
Při poskytování velkých objemů dat nechceš na straně poskytovatele vynakládat žádný výpočetní výkon na filtrování a zpracování, ideálně chceš pouze vrátit soubor. S3 je také api, jen pracuje na úrovni celých souborů či bloků a ne na úrovní jednotlivých záznamů.
Vývoj a údržba klasického REST api je náročná, osobně jsem pro co nejmenší bariéru mezi daty a jejich získání, soubory někde na http/ftp mi vyhovují, hlavně ať jsou k dispozici. Pokud bude umožněn jejich mirroring, rád poskytnu pár serverů.
-
Budu se drzet vaseho prikladu, at se snaze posuneme k meritu veci. Kdo vam napriklad rekne, jak dlouho trva prestup z jedne zastavky do druhe, prip. kde ty zastavky lezi? Dalsi dump dat, ale ta vazba treba vyzaduje cisteni (identifikatory zastavek nemusi byt 1:1) a udelaji ji vsichni implementatori stejne? Bude vam k necemu vystup, kteremu nebudete na 100% verit?
A co kdyz budou oba datove sety dynamicke, jak zajistite, ze budete pouzivat takove, ktere k sobe "patri"? Jak zajistite, abyste uz nyni mohl pouzivat data, ktera jsou k dispozici, a zaroven, az nekdo prida dalsi vazby, vas software bezel bez zasahu dal?
Muzu vam vymyslet stovky realnych situaci, ze kterych vyvaznete jen s API, prip. necim blizkym LOD, kde by ovsem ale zase vznikly jine druhy potizi. Samozrejme, zadne API neni dokonale, ale lze ho verzovat, rozsirovat, dokumentovat - proste vyvijet a udrzovat. Kdyz odhlednete od trivialnich aplikaci, tak obycejne dumpy databazi tuhle vlastnost nemaji. Coz zaroven nepopira fakt, ze API vam ten dump muze vracet jako jednu z mnoha funkci...
-
Mohl byste uvést příklad takového API? Protože to API by stejně bylo jenom ke čtení. A já nějak nevidím výhodu v tom, že mi někdo předpřipraví určité funkce pro přístup k nějakým datům (a když nepřipraví funkci, kterou já potřebuju, mám smůlu), oproti stavu, kdy mi někdo poskytne rovnou ta data a já si nad nimi můžu dělat funkce, jaké mne napadne.
Třeba takové jízdní řády. Dnes je k nim přístup přes „API“ – někdo se rozhodl, že lidé budou potřebovat vyhledávat spojení, zobrazit odjezdy z jedné zastávky a zobrazit všechny spoje jedné linky. To umí webový IDOS, není to úplně API, ale to, co dělají webové formuláře, by mohlo dělat i nějaké API. Pokud chce někdo použít jiný algoritmus hledání spojení, jiné zacházení s přestupy, jiný výběr dopravních prostředků, nebo to kombinovat s jinými údaji (jiné jízdní řády, kombinace MHD + auto apod.), má smůlu, API mu to neumožní. A nebo nemusíte mít API, ale prostě dostanete ta data, nad kterými IDOS funguje. A s tím si můžete dělat cokoli, použít vlastní algoritmus, kombinovat s autem nebo jízdou na kole, udělat offline aplikaci. Není ta druhá varianta daleko lepší?
-
Cim dal vice pochybuji, ze jste nekdy nejaky velky system videl. Snapshot dat muze byt klidne jedinou z mnoha funkci API. O "zmrsenem API" postavenem na miru nebudu vubec polemizovat, ja zas videl rozpadly dum, a proto zacneme pouzivat zemljanky? Jak provazete systemy vladnich uradu? Jak zapojite do tvorby techto nadstaveb vic lidi, potazmo firem, kdyz to vladni agentury dlouhodobe nezvladaji? Musite to otevrit a necekat az se z bobku dat, polozenych na jednu hromadu, neco "samo" udela. Chapu, ze tvorit bobky dat je pracovne efektivni - je to snadne, je to hned a muzete se tvarit upracovane a pozitivne. Pro opravdovy informacni system a pro obcany to ma ovsem nulovy prinos.
-
. . (neregistrovaný)
také se stavím za to, že api je zbytečná komplikace a doufám, že nebude zavedeno.
Stáhnout si balíky dat k sobě a pustit se do analýzy je to pravé, teď chce jen, aby byl formát dokumentovaný a ustálený.
K řadě analýz stejně potřebuješ mít data ve svém SW a proč zbytečné používat API, které bys musel doprogramovat, když stačí zadat url a řada SW řešení jíž umí data získat.
-
Pako (neregistrovaný)
Naopak, zkušeností mám víc než bych možná chtěl. Rozdíl není mezi "API" a "dumpem dat", ale mezi tím jak jsou postavené. Nejednou jsem si nad zmršeným API postaveným na míru jednoúčelové aplikaci říkal že hrubý dump databáze, nad kterým bych si postavil vlastní dotazy, by byl podstatně - univerzálněji - použitelnější.
-
To nemusi byt chyba ani jednoho z nas. Zrejme jste velke systemy nikdy netvoril, a mozna ani zevnitr nevidel. Zkuste zvazit, co a jak pracne udelate s dumpem databaze Google Maps, a co dokazete udelat s jejich Google API. Kdyby vladni systemy mely otevrene API, tak to vyresi mnohe realne problemy. Misto toho se tady tvori bobky dat, ktere budou mylne vykladany jak je diky nim ceska statni sprava "otevrena".
-
Bohuzel, na tom vasem odkazu jsem nenasel zadny zajimavy datovy set. Jestli to ovsem spravne chapu, tak stat uvolnuje "nejaka" data v "nejake" nezavazne strukture. Na tom muze stavet leda blahovy nadsenec anebo student. Jako platce dani bych ocekaval, ze si nekdo odpovedny konecne vezme tuzku a papir a zajisti, aby se otevrelo API vsech statnich systemu. Zadouci data si pak pres API vytahne kdokoliv. Nebylo by to perspektivnejsi?
-
Bude to k tomu, že ta data může kdokoli vzít a zpracovat je jiným způsobem, než jak to dělá dnes stát. Podívejte se třeba na to, co s tím málem zveřejněných dat dělá datový tým Českého rozhlasu.
