Co rządzi w Polsce?
Spark podobno 10-100 razy szybszy od Hadoopa (dla dużych danych) i łatwiejszy do naumienia, łatwiej się prowadzi, ale mniej bezpieczny.
0
1
Nie jestem w stanie odpowiedzieć co rządzi ale Spark i Hadoop celują w troche inny target. Oba pozwalają pracować na dużych zbiorach danych, Spark jest często do obliczeń gdzie chcemy wyniki mieć powiedzmy w "czasie rzeczywistym" natomiast Hadoop służy do zadań które mogą być jednak liczone w dłuższym czasie np. okresowe raporty. Spark może trzymać w pamięci natomiast Hadoop zakłada rozproszenie danych i składowanie ich w file systemie, HDFS.
0
Spark też może zapisywać na HDFS. - Julian_ 2 minuty temu
No tak, ale cała idea sparka jest w tym że często operacje wykonuje się na tych samych danych które wyszły jako wyniki poprzedniej transformacji. głupie jest robienie czegoś takiego (dla tych samych danych):
HDFS -> pamięć -> HDFS -> pamięć -> ... > HDFS
Można poczytać sobie więcej w papierku tutaj, jest bardzo przystępny (co prawda to jest papierek od sparka 1, ale idea chyba się jakoś super nie zmieniła - jeśli tak to przepraszam): https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf
0
Julian_ napisał(a):
Co rządzi w Polsce?
Spark podobno 10-100 razy szybszy od Hadoopa (dla dużych danych) i łatwiejszy do naumienia, łatwiej się prowadzi, ale mniej bezpieczny.
W jakim sensie mniej bezpieczny?
Spark może trzymać w pamięci natomiast Hadoop zakłada rozproszenie danych i składowanie ich w file systemie, HDFS.
W Sparku kontrolujesz sobie co i ile siedzi w pamięci, a co na dysku. Zależnie od rodzaju problemu i od własnych preferencji możesz minimalizować zapis na dysk, ale możesz też zapisywać dane w każdym kroku.
Jedną z centralnych własności Sparka jest to, że operacje mogą być powtórzone jeśli jakiś węzeł padnie. Za dokumentacją:
https://spark.apache.org/docs/2.2.0/rdd-programming-guide.html#rdd-persistence
RDD Persistence
One of the most important capabilities in Spark is persisting (or caching) a dataset in memory across operations. When you persist an RDD, each node stores any partitions of it that it computes in memory and reuses them in other actions on that dataset (or datasets derived from it). This allows future actions to be much faster (often by more than 10x). Caching is a key tool for iterative algorithms and fast interactive use.You can mark an RDD to be persisted using the persist() or cache() methods on it. The first time it is computed in an action, it will be kept in memory on the nodes. Spark’s cache is fault-tolerant – if any partition of an RDD is lost, it will automatically be recomputed using the transformations that originally created it.
In addition, each persisted RDD can be stored using a different storage level, allowing you, for example, to persist the dataset on disk, persist it in memory but as serialized Java objects (to save space), replicate it across nodes. These levels are set by passing a StorageLevel object (Scala, Java, Python) to persist(). The cache() method is a shorthand for using the default storage level, which is StorageLevel.MEMORY_ONLY (store deserialized objects in memory). The full set of storage levels is:
(tabelka)
0
Wibowit napisał(a):
Julian_ napisał(a):
Co rządzi w Polsce?
Spark podobno 10-100 razy szybszy od Hadoopa (dla dużych danych) i łatwiejszy do naumienia, łatwiej się prowadzi, ale mniej bezpieczny.
W jakim sensie mniej bezpieczny?
Security
Apache Spark – Spark is little less secure in comparison to MapReduce because it supports the only authentication through shared secret password authentication.
Hadoop MapReduce – Apache Hadoop MapReduce is more secure because of Kerberos and it also supports Access Control Lists (ACLs) which are a traditional file permission model.
https://data-flair.training/blogs/apache-spark-vs-hadoop-mapreduce/
1
Eeee to o to chodzi. Moim zdaniem w praktyce to ma raczej małe znaczenie, bo i tak zwykle sam kontrolujesz całą własną infrastrukturę i możesz sobie poblokować co chcesz na milion różnych sposobów (np firewallem). Myślę, że gdyby to był poważny problem to już dawno Spark obsługiwałby co trzeba.
Poza tym porównanie pochodzi sprzed roku. Od tamtego czasu mogło się coś pozmieniać.
Jest też 3 miesiące młodsze porównanie na tej samej stronie:
https://data-flair.training/blogs/hadoop-vs-spark-vs-flink-comparison/
- Security
Hadoop: It supports Kerberos authentication, which is somewhat painful to manage. But, third party vendors have enabled organizations to leverage Active Directory Kerberos and LDAP for authentication.
Spark: Apache Spark’s security is a bit sparse by currently only supporting authentication via shared secret (password authentication). The security bonus that Spark can enjoy is that if you run Spark on HDFS, it can use HDFS ACLs and file-level permissions. Additionally, Spark can run on YARN to use Kerberos authentication.
0
Czy Spark czy Hadoop? To i to. Zazwyczaj ( w 80%) używamy Sparka na HDFS i tam znajdują się dane wczytywane.
A po co HBase?
To jest ten przypadek kiedy dane nie są na HDFS ale np. są dane streamowane, Takie dane trzeba szybko zapisywać więc kolumnowa baza danych jaką jest HBase. Na HDFS zapisujesz dane ale nie możesz się do nich dostać w prosty sposób (sam plik). Jest niby Hive ale on jest stosunkowo wolny (odczyt i zapis). HBase daje ci szybki zapis oraz odczyt (z danego segmentu - czyli mozna powiedzieć z danych tych samych kolumn).
0
Czy mniej bezpieczny?
Ogólnie w 99% klaster Hadoop jest odizolowany od sieci więc sprawa bezpieczeństwa jest drugorzędna.
Nie myśl o Hadoopie jako czymś super złożonym/zaawansowanym. Dla użytkownika końcowego to tak naprawdę zwykła hurtownia danych (tutaj nazywany data lake) która ma swoje reguły. Sparka używamy głównie do włożenia danych w szybki sposób lub do przetworzenia ich - ponieważ jeżeli zaczytamy je do pamięci dalsze transformacje są mniej kosztowne czasowo. To nie znaczy ze nie piszę się typowych akcji Hadoopowych (tradycyjny MapReduce) - otóż piszę się, bo nie wszystko musi być super szybkie i nie każdy klaster ma tyle pamięci.
1
Moim zdaniem Spark - nawet jeśli tak jak napisano powyżej, obydwa podejścia mogą się uzupełniać.
Po pierwsze od wersji 2 używa tej samej abstrakcji danych do przetwarzania danych batch i streaming (DataFrame), co znacznie ułatwia same projektowanie aplikacji i nauczenie się biblioteki/wdrożenie w projekt. Przy Hadoop Map/Reduce mam wrażenie, że pisanie przetwarzania danych w streamingu jest czymś mega trudnym (niemożliwym?).
Po drugie Spark jest bardziej otwarty na różne środowiska - od data engineer po data scientist co tłumaczy się przez używalne języki: Scala, Java, Python czy R. Odnośnie samego środowiska użytkowników - poprzednio programiści używający Scali lub Javy byli uprzywilejowani, bo ich kod z reguły wykonywał się szybciej. Ale po implementacji Project Tungstein (http://www.waitingforcode.com/apache-spark-sql/spark-project-tungsten/read) to się zmieniło. Kod przetwarzający dane w Javie, Scali czy Pythonie wykona się z taką samą szybkością (https://databricks.com/blog/2015/04/24/recent-performance-improvements-in-apache-spark-sql-python-dataframes-and-more.html). Przy użyciu modułu Spark SQL kod transformacje na danych są tłumaczone do Javy i kompilowane (przykład http://www.waitingforcode.com/apache-spark-sql/generated-code-spark-sql/read). Taka uniwersalność daje przewagę Spark, ponieważ Hadoop Map/Reduce w jest pod tym względem ograniczony do Javy.
Po trzecie społeczność. Po szybkich poszukiwaniach Spark wydaje się być łatwiej integrowalny z pozostałymi projektami Big Data open sourcowymi. Istnieją pluginy pozwalające wczytywać dane z Cassandry, Kafki, Elasticsearch czy MongoDB. Dodatkowo dzięki społeczności samo poznanie tematu wydaje się być łatwiejsze (posty na Databricks https://databricks.com/blog/category/engineering, GitBooki Jacka Laskowskiego https://www.gitbook.com/book/jaceklaskowski/mastering-apache-spark/details).
Złoty Rycerz napisał(a):
Sparka używamy głównie do włożenia danych w szybki sposób lub do przetworzenia ich - ponieważ jeżeli zaczytamy je do pamięci dalsze transformacje są mniej kosztowne czasowo. To nie znaczy ze nie piszę się typowych akcji Hadoopowych (tradycyjny MapReduce) - otóż piszę się, bo nie wszystko musi być super szybkie i nie każdy klaster ma tyle pamięci.
Odnośnie samej pamięci, to Spark nie ogranicza się do przetwarzania tylko i wyłącznie przy użyciu pamięci: https://databricks.com/blog/2014/10/10/spark-petabyte-sort.html https://stackoverflow.com/questions/44961602/how-spark-handle-data-larger-than-cluster-memory Także przynajmniej teoretycznie rozmiar klastra nie powinien być elementem blokującym. Choć prawda, że zapisując wszystko do plików korzyści wynikającego z szybszego przetwarzania będa mniejsze.
0
bartosz25 napisał(a):
Moim zdaniem Spark - nawet jeśli tak jak napisano powyżej, obydwa podejścia mogą się uzupełniać.
Po pierwsze od wersji 2 używa tej samej abstrakcji danych do przetwarzania danych batch i streaming (DataFrame), co znacznie ułatwia same projektowanie aplikacji i nauczenie się biblioteki/wdrożenie w projekt. Przy Hadoop Map/Reduce mam wrażenie, że pisanie przetwarzania danych w streamingu jest czymś mega trudnym (niemożliwym?).
Ja bym bardziej polecał Scale i dataset - to jest prawdziwa kobyła. Nie ogranicza do podejscia rdd lub dataframe - to tak naprawdę jedność w dataset'cie. Tylko dla Scala.
Po trzecie społeczność. Po szybkich poszukiwaniach Spark wydaje się być łatwiej integrowalny z pozostałymi projektami Big Data open sourcowymi. Istnieją pluginy pozwalające wczytywać dane z Cassandry, Kafki, Elasticsearch czy MongoDB. Dodatkowo dzięki społeczności samo poznanie tematu wydaje się być łatwiejsze (posty na Databricks https://databricks.com/blog/category/engineering, GitBooki Jacka Laskowskiego https://www.gitbook.com/book/jaceklaskowski/mastering-apache-spark/details).
Moim zdaniem kulą w płot. Apache Hadoop to tak naprawdę taki byt który nie istnieje. Jak chcesz mieć Hadoop'a to idziesz do Vendora który daje ci paczki za darmo (np. Hortonworks). Masz tam stack komponentów (security, integracja itp. itd.). Kafka jak najbardziej się integruje się z Hadoop'em. Elasticsearch jest niepotrzebny bo masz odpowiedniki typu Solr.
Złoty Rycerz napisał(a):
Sparka używamy głównie do włożenia danych w szybki sposób lub do przetworzenia ich - ponieważ jeżeli zaczytamy je do pamięci dalsze transformacje są mniej kosztowne czasowo. To nie znaczy ze nie piszę się typowych akcji Hadoopowych (tradycyjny MapReduce) - otóż piszę się, bo nie wszystko musi być super szybkie i nie każdy klaster ma tyle pamięci.
Odnośnie samej pamięci, to Spark nie ogranicza się do przetwarzania tylko i wyłącznie przy użyciu pamięci: https://databricks.com/blog/2014/10/10/spark-petabyte-sort.html https://stackoverflow.com/questions/44961602/how-spark-handle-data-larger-than-cluster-memory Także przynajmniej teoretycznie rozmiar klastra nie powinien być elementem blokującym. Choć prawda, że zapisując wszystko do plików korzyści wynikającego z szybszego przetwarzania będa mniejsze.
Naturalnie to prawda. Ale tracisz wtedy na prędkości. Jak masz duży zbiór danych i nie zalezy Ci zeby przetworzyć go szybko ale chcesz go jakoś logicznie składować to idziesz w stronę Hive'a. Tak naprawdę w tym momencie jest tak dużo silników SQL (i jego odpowiedniki jak HQL) on Hadoop ze głowa mała.
Reasumując Spark nie jest czymś co zastępuje Hadoop'a a co najwyżej z nim współgra. Zastosowanie Hadoop'a jest dużo szersze. Apache Spark nie jest też jedynym silnikiem do przetwarzania danych. Co więcej streaming danych w Sparku jest stosunkowo (jak na terminologie Big Data) powolny. Rozróniamy kilka real-time - najbliższy i najszybszy "near-real-time" to raczej domena Apache Storm, czy teraz popularnego Apache Flink (i rozwijającego się). Na każdy silnik masz konkretny use-case