IT Blog

  Hey folks! If you are a beginner with stream processing with Spark, or even if you have used it multiple times but want to get a better understanding of spark structured streaming, then this article is for you! Before discussing processing stream data in Spark, let’s first understand what stream data processing is and how does it vary from batch data processing? If you are already familiar with these concepts, please skip ahead. Stream data processing Processing of data as and when it comes to make near real time decisions. For example, Fraud detection as and when it happens, detection of an erroneous server by analyzing the error rate, etc. How does stream processing differ from batch processing? Batch data processing is processing of data accumulated over a period of time. These are the normal flows/jobs that you have running say at daily, weekly, or twice a day frequency. No matter when the data comes, it will always be processed at fixed defined intervals. Another difference ...

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 N...

  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...