[00:01] Apache Airflow in a most simple and intuitive language. Apache Airflow is a engineering. And if you go to any job portal, you will find tons of job. On their website, they say that it's a platform that will allow you to
[00:15] programmatically author, schedule, and monitor workflows. But, what does that example. Let's assume you're working in a finance company as a data engineer, and you are given this task to extract the stocks information using some API or
[00:30] extracting information such as ticker, price, book value, etc. Then, you are doing transformation, where you are calculating a new column price to book, which is price to book ratio. You are removing invalid records,
[00:45] right? For PB ratio, this doesn't have book value, so you probably want to remove it. You're doing some currency conversion. Reliance is a Indian stock, rest of it dollar, so you're doing rupee to dollar conversion and so on. And
[00:58] eventually, you want to load that data in Snowflake. Snowflake contains huge volume of data. So, daily you are loading these prices, and you are doing this computation nightly. Okay, your manager said that every day at night, we
[01:12] need to do this computation. So, what you can do is you can write simple Python code, okay? Extract, transform, and load functions, and then you can call them in sequence. It's a simple file called etl.py, which will perform
[01:26] these three tasks in a sequence. And then, using Unix cron job, you can set up a nightly schedule. You can say, "Okay, daily at 2:00 a.m. in night, please run this file." Now, this approach is straightforward, it works
[01:39] good, but there are a couple of issues. First, let's say there is an exception in extract, okay? Let's say the website or the API from where you are extracting the stocks data is down for a few minutes, only for a few minutes it is
[01:54] down. And when you're running this at 2:00 a.m., this will fail. And let's say remaining things will also fail, right? So, there is no inbuilt retry logic or failure handling. Now, if you're a smart programmer, you'll argue that, "So what?
[02:09] I can code up my retry logic. I can have a for loop, I can have three retries, and if there is an exception, I will again." And it will work. Let's say if
[02:21] the temporarily this API or let's say website is down, then after waiting for 10 seconds, it will uh come up. This works fine, but this approach is very manual, repetitive. And you must add this to every function where there is a
[02:36] chance of failure. So, it's not very scalable. Second problem is there is lack of visibility and monitoring. What if this script fails? In that case, you have to set up all the monitoring and logging on your own using some external
[02:49] tools. You have to go to the Unix machine where this is running, and you logs. I used to do this a lot at Bloomberg. Uh so, this is not a great approach in terms of visibility and monitoring. So, at Bloomberg, we used to
[03:05] have all these external monitoring tools uh to capture the failures and success, etc. Another thing you want out of this is what if you can represent this uh
[03:17] particular data pipeline in form of a DAG? So, DAG means directed acyclic graph. Directed means the data is going into one direction, right? So, there is a direction to it. Acyclic means there is no cycle. It's not like, "Okay, you
[03:32] are doing transform, load, and again you're going back to transform." There's no cycle to it. And graph means, if you know computer science fundamentals, this uh structure is called graph, okay? So, what if you can represent this workflow,
[03:47] this pipeline as a directed acyclic graph with retry and all other features, This thing you can't get in your plain Python script. So, there is no
[03:59] saying that transform depends on extract. And by the way, this is a very simple graph. You can actually have a complex graph. You can have even more complex graph than this, okay? You have multiple steps, some branching logic,
[04:13] some things you are processing in parallel. Now, if you do this in Python, it is not very intuitive, it is complex, and you can't get this kind of visualization as well. So, Airflow tries to solve all
[04:27] these problems. In Airflow, you will import DAG. So, you'll say, "From Airflow import DAG." And then, with DAG, you will give a name to your pipeline. So, this is called a DAG ID.
[04:40] Start date actually. From this date, this pipeline will run every day at 2:00 a.m., right? So, this is a cron syntax. So, schedule is set. And then,
[04:52] you will specify your three tasks, okay? So, first task is extract function. So, extract function, you will put it in this Python operator. You call it task Then, transform function. You call it
[05:04] task T2. Then, load function. You call it task T3. And you simply run this pipeline. You will say T1, T2, T3. It will execute these three things in a sequence. Now, the beauty of this kind of programming is it's very declarative,
[05:19] right? Here, you can say, "Okay, retries is three." And it will automatically do retry. Tomorrow, you want to change retries to five, let's say. And it will do that. You want to specify retry delay? You can specify it. It's like you
[05:33] file here, and you are just changing bunch of parameters. So, this way the possibility of introducing bugs will reduce. And also, the code is readable, very much extensible. Once this code is written, you can visualize this DAG in
[05:49] Airflow UI, okay? So, this is the Airflow user interface. And if you go to this DAGs, you will be able to see your pipeline. My pipeline ID is etl_pipeline. So, see here I am able to see it.
[06:03] is the DAG ID. And you can see the schedule here, next run, latest run. See, you all See all this information here. And then, the way, when you go to this, see you will be able to see all the runs, right?
[06:20] trigger it manually. See, if you want to trigger Usually in production, you don't trigger it manually, but just in case I'm just showing you. Uh it will be usually run on that nightly schedule, okay? Now, let's say at night 2:00 a.m.
[06:33] is running. See, this is running now. So, when you click on it, you will be able to see the status of your process in a nice UI. See, now it is saying success. See, all these three steps, you are able to see
[06:46] how much time it took, like 8 seconds here. You're able to see what are the sub steps, uh how much time each of the sub steps took, okay? If there were any failures, if there were any retries, you'll be able to see all the
[06:59] information. You can also see the logs. See, you're you are seeing logs for extract, you can see the logs for transform, load. It makes debugging so much easier, it makes tracking of your pipeline runs so much easy.
[07:15] You can also click on this particular icon and visualize your DAG. So, just to summarize the differences between your plain Python approach versus Airflow. See, Python script with cron job is very easy to set up. Airflow will require
[07:29] some setup of Docker and all that. But, once that is set up, you reap a lot of benefits. First one is you get nice web UI for your monitoring and observability. You also get uh retries and alerts built in in a declarative
[07:44] and alerts built in in a declarative way. Dependencies are visualized through DAG graph. Then, it is scalable. Apache Airflow is scalable because it uses distributed computing, and then there are distributed workers, okay? Whereas
[07:58] computing, you have to do multi-threading and all of that on your own. Then, there is extensibility because Apache Airflow has many integrations. See, we saw that Python operator, right? Similarly, let's say
[08:12] ADLS, uh it has a lot of integration in terms of those operators. And it is best suited for production-grade multi-step
[08:24] pipelines, okay? Uh and in the industry, usually your pipelines will be complex, uh and for that, Apache Airflow is more suitable. That's it, folks. I hope you have some understanding of Airflow now. [Music]
[08:40] [Music] Okay.