przez wiele firm, nawet tych dla których duże dane mają krytyczne znaczenie.
Na krótką metę takie podejście może ujść płazem, jednak w miarę wzrostu klastra chaos staję się być trudny do opanowania, klaster zaczyna przypominać stajnię Augiasza, a sam Sherlock Holmes nie jest w stanie rozwikłać zagadki, gdzie znajduje się poszukiwany zbiór danych i kto z niego korzysta.
Nawet jednak, gdy zdasz sobie sprawę z istnienia problemu, możesz nie dostrzec, że skuteczne rozwiązania znajdują się tak blisko. W czasie prezentacji, opowiemy o tym jak uprościliśmy zarządzanie danymi i procesami w klastrze Hadoop za pomocą pożytecznych, choć póki co jeszcze mniej znanych, narzędzi open-source. Przyjdź i przekonaj się jak Apache Falcon, HCatalog i kilka prostych technik pomogą Ci w utrzymaniu porządku na klastrze i sprawnym poruszaniu się wśród ogromu danych, procesów i związków między nimi.

kryjących się w danych. Czy jednak wyniki nie prowadzą nas czasami na manowce? Przemek Maciołek opowie jak efektywnie modelować typowe procesy biznesowe za pomocą R i jak omijać niektóre pułapki.

przetwarzania danych Apache TEZ - architektura, API, porównanie z podejściem w pradygmacie MapReduce. Będzie to również studium przypadku mało oczywistego zastosowania mechanizmu sesyjnego w TEZ.

automatyczna konfiguracja na przykładzie Cisco UCS. Serwery wirtualne: automatyczna instalacja serwerów RHEL. Automatyczna konfiguracja systemów na przykładzie BMC BladeLogic. Instalacja Hadoop z użyciem Ambari - Hortonworks HDP. Monitoring: integracja z wewnętrznymi systemami - od Nagios do OP. Bezpieczeństwo: wdrożenie Kerberosa oraz LDAP z użyciem IdM/IPA. Plany rozwojowe: integracja z Active Directory oraz komentarz na temat Rangera (centralne miejsce zarządzania uprawnieniami).

leading to suboptimal analytic outputs. Even when this data is available to countless users, traditional systems limit them to querying small volumes of data in order to return the results in a timely matter. What are key challenges here - (1) Limited data accessible to the people that need it, (2) Long time to value, and (3) Compliance and privacy concerns when you add more users and more diverse data.

An EDH allows organizations to bring together multiple data sources in one common location unlocking the ability to query against large volumes of disparate data. This includes not only SQL queries but also simple search and 3rd party BI platforms. With an EDH, analysts are now able to discover net-new data sets to include in analyses, perform large scale queries, and in turn, discover innovative analytics that drive a more predictable business.

uzupełniając ecosystem silników wzorowanych na MapReduce i Spark. Jest równie szybki jak silniki działające w pamięci systemu, a jednocześnie równie niezawodny jak Hadoop. Kompatybilność z systemem Hadoop (działa na YARN, odczytuje dane z HDFS i HBase i obsługuje włączanie istniejących funkcjonalności Hadoop map i reduce do programów Flink). Flink z perspektywy użytkownika: API i najbardziej interesujące wzorce projektowe stojące za Flinkiem. Zarys planów rozwojowych Flinka.

Wiele projektów Hadoopowych zostaje wstrzymanych czy ograniczonych w skali z uwagi na braki po stronie bezpieczeństwa. Tymczasem wcale nie musi tak być - Hadoop może być bezpieczny! W trakcie prezentacji studium przypadku - jak wdrożyć politykę bezpieczeństwa zgodną z najbardziej restrekcyjnymi wymogami. Aspekty bezpieczeństwa - otoczenie, dostęp, szyfrowanie.

danych oraz architektury w Grupie Wirtualna Polska.
Wykorzystanie technologii: Flume, Kafka, Hadoop, Hbase, Sqoop, Mahout i tak dalej.
Wkład tych technologii w budowę „martu danych” do analityki biznesowej. Format danych do efektywnego modelowania.

adresuje te zagadnienie Założenia i wysokopoziomowa architektura silnika analitycznego LASR Analytics Server, który dzięki wykorzystaniu rozproszonego środowiska obliczeniowego (klastera Hadoop) i modelu in-memory pozwala na zmierzenie się z wyzwaniami obliczeniowymi złożonych algorytmów analitycznych, gdy mamy mało czasu i dużo danych. W jaki sposób LASR współpracuje z Hadoop. Jak jego zalety mogą wykorzystać zarówno programiści Hadoop, Data Scientists, jak i osoby dla których Hadoop jest tylko workiem z danymi. Przykłady na żywo.

mapę aktywności społeczności naukowej, korzystając z kilku prostych algorytmów uczenia maszynowego. Co się może w tej sytuacji udać, a co zaskoczyć? Jak dobrze podejść do podobnych zadań? Odpowiedzi na te pytania zdobyte w trakcie rozwoju projektu "COmmon Map of ACademia" (COMAC).

przynieść firmie wartość dodaną. Potrzebujesz jednak do tego właściwych narzędzi. Tradycyjne narzędzia analityczne ogólnego zastosowania jak Hive, Pig czy generalnie MapReduce nie są odpowiednie do wizualnej analizy zależności poprzez wykresy. Na przestrzeni ostatnich lat wprowadzono na rynek szereg narzędzi służących konkretnie do tego rodzaju analiz. Przyjrzymy się łączącemu je wszystkie ogólnemu paradygmatowi programowania i możliwości jego wykorzystania w prezentacji analiz opartych na wykresach.

do raportów finansowych, do naszego obecnego 900-węzłowego klastra w znaczący sposób wpływającego na wiele cech naszej aplikacji w jej aktualnym kształcie.
Dwaj członkowie zespołu Hadoopa w Spotify opowiedzą o porażkach, frustracjach i odebranych nauczkach, opisując przy tym architekturę Hadoopa/rozwiązania Big Data w Spotify i jej ewolucję na przestrzeni czasu. Wyjaśnimy, w jaki sposób i dlaczego wykorzystujemy szereg narzędzi (m.in. Apache Falcon i Apache Bigtop do testowania zmian; Apache Crunch, Scalding i Hive z Tez) w celu zbudowania kompleksowego rozwiązania i udostępnienia możliwości analitycznych (warto również wspomnieć o Snakebite i Luigi - dwóch narzędziach opracowanych wewnątrz firmy w celu rozwiązania często pojawiających się problemów).

Cross-Industry Standard Process for Data Mining (CRISP-DM). W trakcie prezentacji przedstawiona zostanie metodologia CRISP-DM oraz doświadczenia Ada Lab w pracy z nią

W jaki sposób optymalizować treści wyświetlane użytkownikom korzystając z danych w czasie rzeczywistym, przy ruchu przekraczającym 500 milionów wyświetleń dziennie i kiedy zamiast gotowego rozwiązania warto skupić się na własnym i zastąpić farmę serwerów jednym.

każdej łamigłówki, był to bardzo długi i nie zawsze idealnie działający proces - wielokrotnie gubiliśmy się w ślepych zaułkach i pozornych skrótach.
Kształt przechowywanych danych, w tym:
- struktura katalogu i jej wpływ na wydajność klastra Hadoop,
- istotność zadeklarowania schematu rekordu,
- wersjonowanie i aktualizacja rekordów, znane również pod nazwą zarządzania danymi historycznymi,
Proces kalkulacji:
- przyspiesz go, korzystając z odpowiednich struktur danych na każdym etapie,
- błędy są nieuniknione, więc łatwość powtórnej kalkulacji jest koniecznością,
- nieprawidłowe funkcjonowanie lub utrzymanie klastra wyzwala proces kalkulacji bez interwencji człowieka,
- projektuj z myślą o określonym przedziale czasowym, ale bądź również przygotowany na dane strumieniowe.
Bądź przykładem obywatelskiej postawy:
- niewielkie pliki i puste katalogi są źródłem problemów,
- dbaj o możliwie niewielkie rozmiary, stosując kompresję danych,
- szacuj popyt na zasoby YARN w oparciu o faktyczne potrzeby,
- pliki CSV są najmniej pożądane, ale nie są zabronione.

Niespodzianki w systemie Hadoop i gdzie się ich spodziewać. Doświadczenia z klasycznymi DBRMS-ami i aplikacjami jednoserwerowymi (w kontekście Hadoop narzucające się odpowiedzi są często błędne!):
- Zabijanie procesu Hive za pomocą prostego zapytania wybierającego,
- Ponowne próby, które przeciążają klaster,
- Niedeterministyczne miary wydajności MapReduce wykorzystujących te same dane,
- Ponowne wykorzystanie obiektów fazy redukcji MapReduce,
- Wydajność maszyny klienckiej może się czasem okazać wąskim gardłem.

Komentarz:
W przypadku każdego ze wspomnianych kłopotliwych aspektów przedstawię przykładowe rozwiązanie zastosowane lub przynajmniej ocenione w praktyce. Wspomniane wyżej problemy mogą się wydawać pesymistyczną i przytłaczającą wizją stosowania Hadoopa, ale to nieprawda. Praca z tym frameworkiem sprawia nam prawdziwą przyjemność, ale chciałbym opowiedzieć o ciemnej stronie implementacji technologii Big Data, ponieważ każdy prawdziwy sukces poprzedzają godziny ciężkiej pracy nad rozwiązaniem pojawiających się problemów. Będę przeszczęśliwy, jeśli przynajmniej części słuchaczy uda się uniknąć omówionych pułapek i z sukcesem wdrożyć ecosystem Hadoop.

zrozumienie historii ukrytej w oceanie liczb? Trzeba te liczby odpowiednio pokazać. Dobra wizualizacja danych prowadzi do istotnych odkryć, natomiast zła wizualizacja potrafi wyprowadzić na manowce. Zasady pozwalające na tworzenie dobrych prezentacji danych oraz praktyczne przykłady ich zastosowania.

otrzymywać informacje do podejmowania decyzji w jak najszybszym czasie, dlatego zdecydowaliśmy się przetwarzać strumień danych za pomocą Storm. Opowiemy Wam w jaki sposób zintegrowaliśmy się z istniejącymi rozwiązaniami oraz jakie informacje ułatwiają pracę redakcji i developerom, które ułatwiają im pracę każdego dnia.

Jakie problemy musieliśmy pokonać i jakie rozwiązania znaleźliśmy. Główne elementy składowe - Apache Spark, Hadoop z Cassandra i Elastic Search - i ich spoiwo, czyli funkcjonalny Scala Code.

za to bliski czasu rzeczywistego. Razem te dopełniające się systemy mogą być wykorzystane do stworzenia całej gamy produktów opartych na dużej ilości archiwalnych danych, jednocześnie uwzględniając nowe fakty w czasie rzeczywistym.
Studium przypadku jak zostało to zrobione w Base przy wykorzystaniu infrastruktury Amazona i jakie problemy udało się rozwiązać (a jakich nie) i które pułapki udało się im ominąć, a w które dali się złapać.