W projekcie Apache Hadoop opracowano oprogramowanie typu open source do niezawodnego, skalowalnego przetwarzania rozproszonego.
„Hadoop” zazwyczaj odnosi się do oprogramowania w projekcie, które implementuje platformę analizy danych mapreduce, a także rozproszony system plików (HDFS), który ją stanowi. Od wersji 0.23 Hadoop posiada autonomiczny menedżer zasobów: yarn. Ten menedżer zasobów ułatwia korzystanie z innych modułów oprócz silnika MapReduce, takich jak: Ambari, internetowe narzędzie do udostępniania, zarządzania i monitorowania klastrów Apache Hadoop, które obejmuje obsługę Hadoop HDFS, Hadoop MapReduce, Hive, HCatalog, HBase, ZooKeeper, Oozie, Pig i Sqoop. Ambari zapewnia również pulpit nawigacyjny do przeglądania stanu klastrów, takich jak mapy cieplne i możliwość wizualnego przeglądania aplikacji MapReduce, Pig i Hive wraz z funkcjami do diagnozowania ich charakterystyk wydajności w przyjazny dla użytkownika sposób:
Avro, system serializacji danych oparty na schematach JSON.
Cassandra, replikowany, odporny na awarie, zdecentralizowany i skalowalny system bazy danych.
Chukwa: System gromadzenia danych do zarządzania dużymi systemami rozproszonymi.
HBase, skalowalna, rozproszona baza danych, która obsługuje ustrukturyzowane przechowywanie danych dla dużych tabel.
Hive, infrastruktura hurtowni danych, która zapewnia podsumowanie danych i zapytania ad hoc.
Mahout, biblioteka algorytmów uczenia maszynowego zgodnych z paradygmatem M / R.
Pig, platforma / język programowania do tworzenia zadań równoległych
Storm, system przetwarzania w czasie rzeczywistym i przetwarzania strumieniowego
ZooKeeper, system koordynujący rozproszone węzły, podobny do Google Chubby
Oozie, system planowania przepływu pracy do zarządzania zadaniami Apache Hadoop.
Spark, szybki i ogólny silnik do przetwarzania danych na dużą skalę.
Flink, szybki i niezawodny silnik przetwarzania danych na dużą skalę.
PYTANIA:
Jaka jest różnica między Hadoop a noSQL?
Słyszałem o wielu narzędziach / strukturach pomagających ludziom w przetwarzaniu ich danych (środowisko dużych zbiorów danych). Jeden nazywa się Hadoop, a drugi to koncepcja noSQL. Jaka jest różnica w punkcie przetwarzania? Czy się uzupełniają?
ODPOWIEDZI:
NoSQL to sposób na przechowywanie danych, które nie wymagają żadnej relacji. Kluczem jest prostota konstrukcji i możliwość skalowania w poziomie, jednym ze sposobów przechowywania danych jest: projektowanie par wartości. To nadaje się do przetwarzania podobnego do Hadoop. Korzystanie z bazy danych NoSQL naprawdę zależy od typu problemu, który występuje.
Hadoop to system przeznaczony do przechowywania i przetwarzania ogromnych ilości danych. Jest to rozproszony system plików dfs. Powodem tego jest to, że jego konstrukcja jest tak ważna, że zakłada założenie, że awarie sprzętu są powszechne, tworząc w ten sposób wiele kopii tej samej informacji i rozprowadzając ją na wielu maszynach i stojakach, więc jeśli ktoś się zepsuje, nie ma problemu, my mam jeszcze dwie kopie. Oto świetny link do Hadoop również z wikipedii, zobaczysz, że moim zdaniem jest to nie tylko przechowywanie, ale także przetwarzanie: Hadoop
Można przenosić algorytmy zmniejszania mapy napisane dla MongoDB Hadoop później?
W naszej firmie mamy bazę danych MongoDB zawierającą wiele nieustrukturyzowanych danych, na których musimy uruchamiać algorytmy zmniejszania mapy w celu generowania raportów i innych analiz. Mamy do wyboru dwa podejścia do wdrożenia wymaganych analiz:
- Jednym z podejść jest wyodrębnienie danych z MongoDB do klastra Hadoop i wykonanie analizy całkowicie na platformie Hadoop. Wymaga to jednak znacznych inwestycji w przygotowanie platformy (oprogramowania i sprzętu) oraz wykształcenie zespołu do pracy z Hadoop i pisania zadań zmniejszania mapy.
- Innym podejściem jest po prostu włożenie wysiłku w zaprojektowanie algorytmów zmniejszania mapy i uruchomienie algorytmów w funkcjach zmniejszania mapy MongoDB. W ten sposób możemy stworzyć początkowy prototyp końcowego systemu, który może generować raporty. Wiem, że funkcje redukcji map MongoDB są znacznie wolniejsze w porównaniu do Hadoop, ale obecnie dane nie są tak duże, że czyni to jeszcze wąskim gardłem, przynajmniej nie przez następne sześć miesięcy.
Pytanie polega na tym, że korzystając z drugiego podejścia i pisząc algorytmy dla MongoDB, można je później przenieść do Hadoop przy niewielkiej potrzebie modyfikacji i przeprojektowaniu algorytmu? MongoDB obsługuje tylko JavaScript, ale różnice w języku programowania są łatwe do opanowania. Czy istnieją jednak fundamentalne różnice w modelu MongoDB i Hadoop z redukcją mapy, który może zmusić nas do przeprojektowania algorytmów w celu przeniesienia do Hadoop?
ODPOWIEDŹ:
Jeśli wykonasz prototyp używając tylko mongo, na pewno będzie zadanie tłumaczenia. Kiedy uruchomisz zadanie MapReduce na mongodb, ma ono wbudowane źródło danych i strukturę. Kiedy ostatecznie przekonwertujesz na hadoop, twoje struktury danych mogą nie wyglądać tak samo. Możesz wykorzystać złącze mongodb-hadoop, aby uzyskać dostęp do danych mongo bezpośrednio z poziomu hadoop, ale nie będzie to tak proste, jak mogłoby się wydawać. Czas, aby dowiedzieć się, jak dokładnie przeprowadzić konwersję w najbardziej optymalny sposób, raz łatwiej będzie uzasadnić ,że masz prototyp na miejscu, IMO. Podczas gdy będziesz musiał przetłumaczyć funkcje mapreduce, podstawowy pseudokod powinien mieć zastosowanie do obu systemów. W MongoDB nie znajdziesz niczego, co można zrobić przy użyciu Javy lub które jest znacznie bardziej skomplikowane w Javie.
Możesz używać algorytmów zmniejszania mapy w Hadoop bez programowania ich w Javie. Nazywa się to streamingiem i działa jak potokowanie Linux. Jeśli uważasz, że możesz przenieść swoje funkcje do odczytu i zapisu na terminalu, powinno działać dobrze. Oto przykładowy wpis na blogu, który pokazuje, jak korzystać z funkcji zmniejszania mapy napisanych w Pythonie w Hadoop.
Możesz także utworzyć połączenie MongoDB-Hadoop
Czy Amazon RedShift zastępuje Hadoop dla danych ~ 1XTB?
Hadoop i jego ekosystem są bardzo popularne. Jednak w praktyce, gdy wiele zestawów danych znajduje się w zakresie terabajtów, nie jest rozsądniej używać Amazon RedShift do odpytywania dużych zestawów danych, zamiast spędzać czas i wysiłek na budowie klastra Hadoop? W jaki sposób Amazon Redshift wypada w porównaniu z Hadoop pod względem złożoności konfiguracji, kosztów i wydajności?
Różnią się znacznie pod wieloma względami i nie sądzę, że Redshift zastąpi Hadoop. –Function. Na Redshift nie można uruchamiać niczego innego niż SQL. Co najważniejsze, nie można uruchamiać żadnych niestandardowych funkcji w Redshift. W Hadoop możesz, używając wielu języków (Java, Python, Ruby … nazywasz to). Na przykład NLP w Hadoop jest łatwe, podczas gdy w Redshift jest mniej lub bardziej niemożliwe. To znaczy. istnieje wiele rzeczy, które możesz zrobić w Hadoop, ale nie w Redshift. To chyba najważniejsza różnica. -Wykonanie zapytania o profil wydajności w trybie Redshift jest w większości przypadków znacznie wydajniejsze niż w Hadoop. Jednak ta wydajność pochodzi z indeksowania, które jest wykonywane, gdy dane są ładowane do Redshift (używam tutaj terminu indeksowanie bardzo luźno). Dlatego świetnie jest, jeśli załadujesz dane raz i wykonasz wiele zapytań, ale jeśli chcesz na przykład wykonać tylko jedno zapytanie, możesz stracić ogólną wydajność.
Które rozwiązanie wygrywa pod względem kosztów, zależy od sytuacji (np. wydajności), ale prawdopodobnie potrzebujesz sporo zapytań, aby uczynić go tańszym niż Hadoop (a dokładniej elastyczna redukcja mapy Amazon). Na przykład, jeśli wykonujesz OLAP, jest bardzo prawdopodobne, że Redshift wychodzi taniej. Jeśli wykonujesz codzienne partie ETL, bardziej prawdopodobne jest, że Hadoop będzie tańszy. Powiedziawszy to, zastąpiliśmy część naszej ETL, która została wykonana w Hive to Redshift, i to było całkiem wspaniałym doświadczeniem; głównie ze względu na łatwość rozwoju. Silnik zapytań Redshift jest oparty na PostgreSQL i jest bardzo dojrzały w porównaniu do Hive. Jego właściwości ACID ułatwiają uzasadnienie, a szybszy czas reakcji pozwala na przeprowadzenie większej liczby testów. To świetne narzędzie, ale nie zastąpi Hadoop.
EDYCJA: Jeśli chodzi o złożoność konfiguracji, powiedziałbym nawet, że dzięki Hadoop jest łatwiej, jeśli używasz EMR AWS. Ich narzędzia są tak dojrzałe, że uruchomienie zadania Hadoop jest absurdalnie proste. Narzędzia i mechanizmy związane z działaniem Redshift nie są jeszcze tak dojrzałe. Na przykład Redshift nie jest w stanie poradzić sobie z ładowaniem podtrzymującym, dlatego musisz wymyślić coś, co zamieni to w partię ładunków, co może zwiększyć złożoność twojego ETL.
Obecny limit rozmiaru dla Amazon Redshift to 128 węzłów lub 2 PB skompresowanych danych. Może być około 6PB nieskompresowany, chociaż przebieg różni się dla kompresji. Zawsze możesz nas poinformować, jeśli potrzebujesz więcej.
Osobiście nie sądzę, że tak trudno jest skonfigurować klaster hadoop, ale wiem, że czasem jest to bolesne, gdy zaczynasz. Ograniczenia rozmiaru HDFS znacznie przekraczają TB (czy miałeś na myśli eksabajt?). Jeśli się nie mylę, skaluje się do yottabajtów lub innego pomiaru, dla którego nawet nie znam tego słowa. Cokolwiek to jest, jest naprawdę duże. Narzędzia takie jak Redshift mają swoje miejsce, ale zawsze martwię się o rozwiązania specyficzne dla dostawcy. Moją główną troską jest zawsze „co mam zrobić, gdy jestem niezadowolony z ich usług?” – Mogę przejść do wyszukiwarki Google i przenieść swoją analizę do paradygmatu lub przejść do hadoop i przenieść tę samą pracę do tego systemu. Tak czy inaczej, będę musiał nauczyć się czegoś nowego i dużo pracy przy tłumaczeniu. Biorąc to pod uwagę, miło jest móc przesłać zestaw danych i szybko rozpocząć pracę – szczególnie, jeśli to, co robię, ma krótki cykl życia. Amazon wykonał dobrą robotę, rozwiązując problem bezpieczeństwa danych. Jeśli chcesz uniknąć hadoopa, zawsze będzie alternatywa. Ale praca z tym nie jest wcale taka trudna.
Jakie są przypadki użycia dla Apache Spark vs. Hadoop?
Z Hadoop 2.0 i YARN Hadoop prawdopodobnie nie jest już związany tylko rozwiązaniami zmniejszającymi mapę. Z tym postępem, jakie są przypadki użycia Apache Spark vs Hadoop, biorąc pod uwagę, że oba siedzą na szczycie HDFS? Przeczytałem dokumentację wprowadzającą do Spark, ale jestem ciekawy, czy ktoś napotkał problem, który był bardziej wydajny i łatwiejszy do rozwiązania w przypadku Spark w porównaniu do Hadoop.
Hadoop oznacza HDFS, YARN, MapReduce i wiele innych rzeczy. Czy masz na myśli Spark vs MapReduce? Ponieważ Spark działa na / z Hadoop, co jest raczej celem. Głównym powodem używania Spark jest szybkość, a wynika to z faktu, że jego wykonanie może przechowywać dane w pamięci między etapami, a nie zawsze utrzymywać HDFS po mapie lub zmniejszeniu. Ta zaleta jest bardzo wyraźna w przypadku obliczeń iteracyjnych, które mają dziesiątki etapów, z których każdy dotyka tych samych danych. Tutaj rzeczy mogą być „100x” szybsze. W przypadku prostych, jednoprzebiegowych zadań podobnych do ETL, dla których zaprojektowano MapReduce, generalnie nie jest to szybsze. Innym powodem używania Spark jest jego ładniejszy język wysokiego poziomu w porównaniu do MapReduce. Zapewnia funkcjonalny widok podobny do programowania, który naśladuje Scalę, co jest o wiele ładniejsze niż pisanie kodu MapReduce. (Chociaż musisz albo użyć Scali, albo zaadaptować nieznacznie rozwinięte API Java lub Python dla Spark). Crunch and Cascading już teraz zapewniają podobną abstrakcję na MapReduce, ale wciąż jest to obszar, w którym Spark jest miły. Wreszcie Spark ma jeszcze młode, ale obiecujące podprojekty dla ML, analizy wykresów i streamingu, które ujawniają podobny, spójny API. Z MapReduce musiałbyś w tym celu zwrócić się do kilku innych projektów (Mahout, Giraph, Storm). Miło jest mieć go w jednym opakowaniu, choć jeszcze nie jest „wypiekany”. Dlaczego nie używałbyś Spark? parafrazując siebie:
* Spark to przede wszystkim Scala z przeniesionymi interfejsami API Java; MapReduce może być bardziej przyjazny i bardziej natywny dla programistów Java
* Obecnie istnieje więcej wiedzy MapReduce niż Spark
* Do zadań równoległych do danych, jednoprzebiegowych, podobnych do ETL zaprojektowano MapReduce,
* MapReduce jest lżejszy w porównaniu do odpowiednika Spark
Spark jest dość dojrzały, podobnie jak YARN, ale Spark-on-YARN jest wciąż całkiem nowy. Oba mogą nie być jeszcze optymalnie zintegrowane. Na przykład do niedawna nie sądzę, aby Spark mógł poprosić YARN o przydziały na podstawie liczby rdzeni? Oznacza to, że MapReduce może być łatwiejszy do zrozumienia, zarządzania i dostrojenia
Przetwarzanie danych przechowywanych w Redshift
Obecnie używamy Redshift jako hurtowni danych, z czego jesteśmy bardzo zadowoleni. Mamy jednak teraz obowiązek uczenia maszynowego na podstawie danych w naszym magazynie. Biorąc pod uwagę ilość danych, najlepiej byłoby wykonać obliczenia w tym samym miejscu, co dane, zamiast je przesuwać, ale nie wydaje się możliwe dzięki Redshift. Patrzyłem na MADlib, ale nie jest to opcja, ponieważ Redshift nie obsługuje UDF (czego wymaga MADlib). Obecnie zastanawiam się nad przeniesieniem danych do EMR i przetwarzaniem ich za pomocą biblioteki uczenia maszynowego Apache Spark (a może H20, Mahout lub cokolwiek innego). Więc moje pytania to:
- czy jest lepszy sposób?
- Jeśli nie, jak mam udostępnić dane Sparkowi? Do tej pory zidentyfikowałem następujące opcje: użyj Sqoop, aby załadować go do HDFS, użyj DBInputFormat, zrób eksport Redshift do S3 i każ Sparkowi pobrać go stamtąd. Jakie są zalety / wady dla tych różnych podejść (i innych) podczas korzystania ze Spark?
Pamiętaj, że jest to nauka wsadowa offline, ale chcielibyśmy móc to zrobić tak szybko, jak to możliwe, abyśmy mogli szybko iterować eksperymenty.
Nowa usługa Amazon Machine Learning Service może działać dla Ciebie. Działa bezpośrednio z Redshift i może być dobrym sposobem na rozpoczęcie. Jeśli chcesz przetwarzać za pomocą EMR, możesz użyć polecenia UNLOAD Redshift, aby wyładować dane na S3. Spark na EMR może następnie uzyskać do niego bezpośredni dostęp bez konieczności wciągania go do HDFS.