Skip to main content

Khác nhau giữa các chế độ triển khai giữa Local, Standalone và YARN trong Spark

Trong Apache Spark, có ba chế độ triển khai chính: Local, Standalone và YARN. Dưới đây là sự khác biệt giữa chúng:

  • Chế độ triển khai Local:
    • Chế độ triển khai Local là chế độ đơn giản nhất và được sử dụng cho môi trường phát triển và kiểm thử.
    • Khi chạy trong chế độ Local, Spark sẽ chạy trên một máy tính duy nhất bằng cách sử dụng tất cả các luồng CPU có sẵn trên máy đó.
    • Đây là chế độ phù hợp cho các tác vụ nhỏ và không yêu cầu phân tán dữ liệu.
  • Chế độ triển khai Standalone:
    • Chế độ triển khai Standalone cho phép bạn triển khai một cụm Spark độc lập bao gồm nhiều máy tính.
    • Trong chế độ này, một máy tính được chọn làm "Spark Master" và các máy tính khác được kết nối với Spark Master như là "Spark Workers".
    • Spark Master quản lý việc phân phối công việc và quản lý tài nguyên giữa các Spark Workers.
    • Chế độ Standalone phù hợp cho triển khai Spark trên các cụm máy tính riêng lẻ mà không có hệ thống quản lý cụm chuyên dụng.
  • Chế độ triển khai YARN:
    • YARN (Yet Another Resource Negotiator) là một hệ thống quản lý cụm phân tán của Apache Hadoop, được sử dụng để quản lý tài nguyên trong môi trường phân tán.
    • Chế độ triển khai YARN cho phép bạn triển khai Spark trên cụm YARN đã tồn tại, sử dụng các tài nguyên quản lý bởi YARN.
    • Spark sẽ là một ứng dụng YARN và sẽ gửi yêu cầu tài nguyên tới YARN ResourceManager để thực hiện các tác vụ tính toán.
    • Chế độ triển khai YARN phù hợp cho việc tích hợp Spark với hệ sinh thái Hadoop và triển khai Spark trên các cụm dữ liệu lớn.
    • Tùy thuộc vào yêu cầu và môi trường triển khai, bạn có thể chọn chế độ triển khai phù hợp với nhu cầu của mình.
Tham khảo video:



Labels:

Comments

Post a Comment

Popular posts from this blog

6 Rules of Thumb for MongoDB Schema Design

“I have lots of experience with SQL and normalized databases, but I’m just a beginner with MongoDB. How do I model a one-to-N relationship?” This is one of the more common questions I get from users attending MongoDB office hours. I don’t have a short answer to this question, because there isn’t just one way, there’s a whole rainbow’s worth of ways. MongoDB has a rich and nuanced vocabulary for expressing what, in SQL, gets flattened into the term “One-to-N.” Let me take you on a tour of your choices in modeling One-to-N relationships. There’s so much to talk about here, In this post, I’ll talk about the three basic ways to model One-to-N relationships. I’ll also cover more sophisticated schema designs, including denormalization and two-way referencing. And I’ll review the entire rainbow of choices, and give you some suggestions for choosing among the thousands (really, thousands) of choices that you may consider when modeling a single One-to-N relationship. Jump the end of the post ...
Post a Comment
Read more

How to add your Conda environment to your jupyter notebook in just 4 steps

 In this article I am going to detail the steps, to add the Conda environment to your Jupyter notebook. Step 1: Create a Conda environment. conda create --name firstEnv once you have created the environment you will see, output after you create your environment. Step 2: Activate the environment using the command as shown in the console. After you activate it, you can install any package you need in this environment. For example, I am going to install Tensorflow in this environment. The command to do so, conda install -c conda-forge tensorflow Step 3: Now you have successfully installed Tensorflow. Congratulations!! Now comes the step to set this conda environment on your jupyter notebook, to do so please install ipykernel. conda install -c anaconda ipykernel After installing this, just type, python -m ipykernel install --user --name=firstEnv Using the above command, I will now have this conda environment in my Jupyter notebook. Step 4: Just check your Jupyter Notebook, to se...
Post a Comment
Read more

Bet you didn’t know this about Airflow!

  We are living in the Airflow era. Almost all of us started our scheduling journey with cronjobs and the transition to a workflow scheduler like Airflow has given us better handling with complex inter-dependent pipelines, UI based scheduling, retry mechanism, alerts & what not! AWS also recently announced managed  airflow  workflows. These are truly exciting times and today, Airflow has really changed the scheduling landscape, with scheduling configuration as a code. Let’s dig deeper. Now, coming to a use case where I really dug down in airflow capabilities. For the below use case, all the references to  task  are for  airflow tasks . The Use case The above DAG consists of the following operations: Start an AWS EMR cluster : EMR is an AWS based big data environment. To understand the use case we don’t need to deep dive into how AWS EMR works. But if you want to, you can read more about it  here . Airflow task_id for this operation:  EMR_start...
Post a Comment
Read more