If you're working with data pipelines, you definitely need to give Apache Airflow a look.
This pure Python workflow framework is one of the most popular and capable out there.
You create your workflows by writing Python code using clever language operators,
and then you can monitor them and even debug them visually once you get them started.
So stop writing manual code or Cronjaw-based code to create data pipelines and check out Airflow.
And to do that, we have three great guests from the Airflow community.
Yarek Potik, Taxil Naik, and Leah Cole.
This is Talk Python to Me, episode 330, recorded August 5th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
And keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by us over at Talk Python Training.
And the transcripts are brought to you by Assembly AI.
Leah, Yarek, Axel, welcome to Talk Python to Me.
It's good to have you all here.
Thanks for having us.
Thank you.
Yeah.
It's really fun to be talking about Airflow.
These are the types of tools that I think they don't get that much awareness, but they're the kind of thing that can be the real backbone of a lot of teams, a lot of organizations, and so on.
So I think that'll be super fun to dive into.
And we'll all learn a lot.
And I suspect a lot of people listening will realize, oh, here's a whole class of tools.
I didn't even realize I should have considered to solve my problems.
But before we get down to that, let's start with your stories.
Leah, you go first.
How do you get into programming Python?
Python was the first language that I learned.
I do have a bachelor's in computer science.
And the school I went to, that is the language that Intro to CS is taught in.
I am so jealous.
My Intro to CS class was in Scheme, which is derivative of Lisp, which didn't seem that practical.
And then I was told I had to learn Fortran.
It would be the most useful language I'd ever learn.
Neither of which turned out to be true.
I wish I learned Python.
So thanks, Carlton College, Northfield, Minnesota, for giving me Python early.
And yes, I loved Python from the beginning.
You asked how I got into programming.
So I actually do have a parent in tech.
It is my dad.
And he tried to get me into programming a lot earlier.
And like a true teen, I said, absolutely not.
Because it was suggested by my dad.
It really wasn't until I got to school.
And I heard people say that Intro to CS was a fun elective.
For those only listening, that's totally in quotes, as I'm saying it, that I decided to take it.
And it turned out I really liked it.
And I decided to pivot from being a math major, which wasn't going very well, to being a computer science major.
Yeah, that's fantastic.
I was also a math major.
And I find the programming side, a lot of the same skill set you have to use.
Like the thinking through problem solving.
You have these constraints or axioms in math.
And you work from them.
But in math, you just come up with sort of like the next idea that is the next problem that is the next idea.
And in computers, you build stuff that people use.
Exactly.
And it's such a difference, I find.
It's puzzles is the programming.
And that was always the part of math that I liked.
I never liked the writing proofs or the theoretical side of things.
I just wanted to solve puzzles with logic and rules.
Yeah, fantastic.
Well, it sounds like you've landed in the right spot.
That's awesome.
I'm doing okay.
Jarek, how about you?
Yes, you talked about your first language.
So my first language in computer science during the studies was, I think, Delphi or Pascal.
I can't even remember that.
But actually, the first language I started programming in the real work was, listen to that, Kobol.
So I tend to joke that when I'm retiring, I will be very well paid five hours a week programmer of Kobol.
Because nobody else will know it.
You're going to keep the trucks delivering and the warehouses open.
Exactly.
Beautiful.
Just five hours a week.
Yeah, that's super cool job, I think.
But then Python is actually quite new in my portfolio, let's say, of languages.
I've learned it maybe six years ago.
And with my experience and years of working in CS, it's relatively late.
But I loved it from the first glance.
I used to work in like C, Java, C++, hundreds of other, a lot of other languages.
But Python was just super easy from the start and super nice tool and super, super friendly.
Like, I was, after years of programming in Java, I was like so much, oh, one line you can do what I would do in five pages of Java code.
Yeah.
That's cool.
And you can understand it as well.
Yes.
So, yeah.
I fell in love immediately.
And this is my absolutely favorite language right now.
Same here.
Axel?
Yeah.
For me, I did my bachelor's in electrical engineering.
So, didn't do anything over there.
But when I came in the UK to do my master's, we were taught R language and Java.
One fine day, we were ending the college in just a month or two.
And there was a presentation from someone in the university who was telling us how to use data science in the industry and everything.
They said, you should know Python.
And you're like, oh, but we were not taught Python.
And we are just one or two months away from doing our internships and everything.
And we don't know Python.
So, that's when I started looking into Python.
I got an internship.
And then I actually started learning more of Python.
So, this was 2016, I'm talking about.
And, yeah, since then it has been a wild, wild ride.
I have written a lot of Java, a lot of R.
But Python seems to be very easy to write, easy to understand.
Plus, the community behind it and the packages behind it are so vast that you can use it for anything.
And basically, yeah.
I saw a funny t-shirt once that said, I learned Python.
It was a great weekend.
Which I think is really funny, right?
Because on one hand, yeah, sure, you can go through.
And actually, the language is simple, especially if you know something else that's like Java or C++.
Oh, this is a breath of fresh air, right?
But on the other hand, I've been doing this for a long time, all day, every day.
And I'm still learning Python every day, right?
So, it's a really interesting juxtaposition of, like, you can learn the language really easily.
But then there's the standard library.
And then there's 300,000 PyPI packages.
Like, Airflow is just one of them.
And that's our whole topic today, right?
So, it's kind of both, right?
Yeah.
And the language keeps growing.
So, you've got to keep track of the cool new things that are released.
And things that are true in Python 2.7 are definitely not true today with Python 3.10.
It's grown a lot.
It definitely has.
And I saw that Airflow is not supporting the older versions of Python, basically, as they get deprecated.
So, yay for that, right?
Yeah, we have actually, you know, very, very strong rules following the Python release rules.
So, we've learned from what Python learned on the release schedule.
And we just follow it very, very closely with, like, how much we have when we support, when we stop, we support Python.
That makes a lot of sense.
Yeah, it's difficult to maintain compatibility between Python 2 and 3.
That's a lot of overhead.
Actually, we, yes.
I have nightmares about it, cherry picking all the stuff from the main branch to the old release branch and adding Python to support.
But Kaxil, you cannot complain.
I mean, we both, but Kaxil did that a lot.
And thanks to that, we've been several times top committers on Apache organization.
Like, there is a, like, this week, most commits made.
And that was us doing cherry picks between three version and two seven version.
And once, we made it both at the same time, top committers on Apache.
Fantastic.
I'm mad at GitHub.
The GitHub does not count commits on any other branch except main or master.
Oh, not fair, not fair.
We'll have to do our own visualizations.
Exactly.
Yeah, exactly.
All right.
Before we move on out of the live stream, Hawaii girl says Python is awesome, like all of us.
Yes, definitely.
Thanks for being here.
All right.
Well, let's start this at a slightly higher conversation than just Airflow.
So Airflow is one of these workflow management frameworks.
Whoever wants to take this, what is that?
Why do I need that?
When do I need that?
What are these tools, as I hinted at the beginning?
I want to walk through some of the history, though, like in 2014, 2015, where like data engineering
was not mainstream and everyone was just using Cron for scheduling their task.
And then there came Luigi, where people were using XML and those sort of languages to write
their tags workflows to make sure that the task runs on schedule.
Yeah.
So DAGs directed acyclic graphs?
Yes.
Okay.
Yeah.
Let's be very clear.
You cannot have a circle for tasks.
The dependencies cannot be that.
People have tried that.
It takes a long time to finish those.
Yes.
A little bit.
A long time.
Some of those decks are still running.
So it takes a long time for them to start sometimes, too.
But yeah, I think to complete the history part, people just got bored writing the XML syntax.
And it's difficult to understand.
Similar to what we were talking about, Java and Python.
Like Python is much easier to read, easier to understand.
There came Airflow.
Maxime wrote Airflow in his time at Airbnb and open sourced it to Apache Software Foundation.
And that had a sigh of relief for people working on Luigi and others as well.
Because then you could write your workflows in an easy to understand language that you're already very familiar with.
You don't need to write those XMLs.
And who loves writing XMLs, first of all?
And so it's easy to understand.
Just configuration as code.
And there was also, I think, a slight move towards everything as code.
Infrastructure as code with Terraform and Ansible and whatnot.
And Airflow was just a perfect tool for workflow as code or DAGs as code.
And since, I think, 2016 to 2018, Airflow's popularity has skyrocketed with the advent of, like, separate specialized data engineering field.
Previously, I think software engineers used to do everything.
But then people or companies also realized that it's a separate field.
It's a lot of work.
It's not, you can also just not include machine learning engineer and let him do everything.
It's a separate data engineer's job to write a pipeline, knows how to handle the data, and everything from start to start.
Let's realize that thousands of things, which, first of all, your Cron expressions or Cron alone cannot handle those.
The task dependencies, the SLAs and whatnot.
So I think that's when, with the advent of data engineering, people realizing the importance of data, Airflow's popularity gained massively between 2080,
which also, by the way, coincided with where Airflow became the top-level project in Apache Software Foundation.
Until then, Airflow was just an incubating project in ASF.
And then it became a top-level project.
And that was a big milestone for Airflow and the community.
I think data engineering is really interesting because a lot of people, when they think of,
well, what are the divisions of what you do with programming, you know, especially in Python?
Well, we've got, like, web programming, to some degree, UI programming,
and then we've got data science.
Sort of web and data science are the two, but there's this middle ground where I feel like
people kind of don't want to go there, or that's the data, right?
You want to make sure if you get a bunch of data and you feed it to your model,
your model is only as good as the data you get, right?
If you're trying to automate some ingest of data or warehousing reporting,
it's only as good as the reliability of the data coming in, the accuracy, right?
We've got things, was it great expectations and stuff like that for testing, actually testing
against the data, not the code that works with the data.
Yes.
And let me just add, because also Airflow is really an orchestrator.
So, like, I used to sing in the choir for many years.
And for me, this is really, like, this parallel between the conductor and the team playing.
We don't do stuff in Airflow.
Airflow doesn't do stuff.
It just tells others what to do.
And there's data processing stuff.
So, like, we don't know how, basically, we as data engineers, because, like, we are actually,
you know, data software engineers writing things for data engineers.
So, when we think about, like, this cross of this both, like, software engineer and data
engineer, so we don't know how to actually make a model, machine learning model.
Or we don't know machine learning.
We don't know how to, even we don't know how to do MapReduce, right?
I mean, if you want to process a lot of data, but we know what to do with the data when it
comes, who should do next, what, and what, how to pass it somewhere else.
And we can make it super complex to define or complex in terms of composed of many, many
different steps in different relations.
But Airflow makes it super easy to manage the whole thing so that it runs smoothly and you
can operate it and you don't, and you can deal with any problems that arise on the go.
So, Jarek, at this point, I want to expand on it real quick.
There's a very human aspect to the workflow orchestration that I think both you, both
Kexil and Jarek have touched on, which is that having a workflow orchestrator really enables
you to move from having, like, the data scientist in their silo working on this pipeline alone
to having a whole team of data scientists and data engineers working together.
Because you have really specialized folks who can work on building those models.
And that might not be the same group of people that's figuring out how to get the data from
A to B and making sure that it's healthy and is what the model and the data scientists are
expecting.
So I think it just enables a lot more collaboration and helps you have more specialists working together.
Yeah, it becomes that well-known, well-tested way to flow data down into the specialties that people need, right?
Exactly.
Talk Python To Me is partially supported by our training courses.
At Talk Python, we run a bunch of web apps and web APIs.
These power the training courses as well as the mobile apps on iOS and Android.
If I had to build these from scratch again today, there's no doubt which framework I would use.
It's FastAPI.
To me, FastAPI is the embodiment of modern Python and modern APIs.
You have beautiful usage of type annotations.
You have model binding and validation with Pydantic.
And you have first class, async, and await support.
If you're building or rebuilding a web app, you owe it to yourself to check out our course,
Modern APIs with FastAPI over at Talk Python Training.
It'll take you from curious to production with FastAPI.
To learn more and get started today, just visit talkpython.fm/FastAPI
or email us at sales at talkpython.fm.
One of the things you do in these types of frameworks is you build these tasks, right?
Give us an idea of what some of the tasks look like.
And you actually have a whole bunch of, would that be the integrations in there?
Or is that something different?
Provisors.
That's the name that we are using in Airfield too.
Yes.
So we have like more than 70 of those right now.
We do for 70 services we talk to, external services or databases or whatnot.
70 entities.
But within that, we have several hundreds of these so-called operators or sensors
or transfer operators, which perform the task.
And they're actually super easy.
It's just one method.
Execute.
That's it.
Right.
That's pretty much it.
Yeah.
There's the three things, the sensors, the operators, the transfers.
Like an example of a sensor might be waiting to see if an object is in S3 or in Google Cloud
storage.
And a transfer is moving something from A to B.
And an operator, those are the ones we probably have the most of, right?
Yak and Kaxel.
And that, it can be anything in a service.
I don't know, like starting running.
So I work in Google Cloud, so the operators I'm most familiar with are the Google ones.
So like spinning up a data cluster and then running a Spark job on it or running something
on a Kubernetes pod.
There, yeah.
If you can dream it, either there is an operator for it or you can write an operator for it.
Yeah.
When I started with Airflow back in 2017, we used Airflow for the same reason.
Like Airflow was designed for being a classic ETL tool or being an enabler of sorts.
So a lot of companies were migrating from on-premises to cloud.
We were doing a project in partnership with Google to move customers' data to cloud.
And we were using NiFi for data to be on GCS.
But from there, everything was orchestrated by Airflow.
So once the data lands in Google Cloud Storage, then there's classic ETL, that extract, transform,
load.
From GCS, it goes to BigQuery.
BigQuery does some manipulations and the data goes to like, there's a dashboard, a data studio
that shows a rich dashboard behind it.
And this is all managed by Airflow.
And it was so easy because we separated this using task and we were using all the hooks and
operators that Leah and Yarek were talking about, which was like GCS to GCS operator, move
the data from the landing area to staging.
So your landing area remains untouched.
So you can verify with your vendor that the data is as recent, even in futures.
And then there were BigQuery operator to run SQL query.
And then there are other operators for different GCS services.
So I think with Google, there was already a good amount of integrations back three, four
years back.
Similarly for Spark and other operators.
Yeah.
One of the things that stands out to me that might be really useful here is if something
goes wrong.
You know, you talked about the contrast being cron jobs or something like that.
And if something goes wrong with that, or you need to scale out across different machines
or whatever, and how do you get those timings right or other weird things?
So what's the mechanism for dealing with, you know, I'm going to get some data.
It drops in the cloud.
I'm going to pull it over.
But then maybe it's invalid data or something.
What's that look like?
So at least for Airflow, all the operators that were written previously or the idea behind
them were the task, a single operator or a single task should be idempotent.
So even if you run them multiple times, it should produce the same result.
So if a task for whatever reason fails, you could add more retries to it.
There's a retry parameter that the base class takes.
And you could say retries is four, retries is five, and Airflow will handle that for you.
So if a task fails, it will rerun it for that amount of time.
Right.
It could fail because the database server is down, or it could fail because it's never going
to work, right?
It could be either one.
Exactly.
And you want to be notified as well.
So then we had all those on failure callback, on success callback, those emails get sent out
saying the data didn't arrive at all or whatever the reason may be.
There is even more to that because we also have the mechanism of backfilling the data.
So even in this case, it's not like not a server failure, but your data has improved.
Because you've got a new metadata and you want to reprocess the data you've already processed
for like last week or only process part of the data because it takes a lot of time.
And you know that the data up to a certain point is good, but then you have to process just part
of your workflow of part of your DAG for the last week.
You can do that with Airflow.
So you can just tell, make a command, run a command, just reprocess me that data for
this period of time, starting from this task, because this is where we know we have to reprocess
the data because the data has been cleaned up, for example.
Right.
You don't have to detect it.
You don't have to copy it down.
You've changed it locally and you want it to get fixed.
I see.
Okay.
And the super cool thing there is that this can be done by one person who doesn't know
what those tasks are doing at all.
Like they are just all the language of how the tasks are written.
The specification is written in the way that anyone can do that.
And then this person operating can very safely just rerun parts of it and be sure that what
comes out at the end is just what they are expecting.
And if you have like hundreds and thousands of that's written by, you know, tens and twenties
or hundreds of people, just one person can sit down and operate all the whole, the whole
of it without understanding a single thing, how it works inside.
But knowing, with seeing what happened, this is like so powerful.
Yeah.
Part of Earth.
It lets you focus on just the steps and not all the bit together, right?
So yeah, let's focus on a couple of things on the website here that I think are maybe worth
calling out.
One of the things here is that the project has four principles that are really nice.
Maybe you want to highlight those for people?
Yeah, I think.
Okay.
So the four principles, it's that Airflow is dynamic, extensible, elegant, and scalable.
And I am going to go ahead and pick my favorite one right here.
And it's one that we've kind of touched upon without spelling out clearly, which is that
Airflow is extensible.
Yarek talked about how we have these 70 plus providers, these various integrations with all
kinds of services from the big cloud providers to things like Slack, Snowflake, which I know
are also kind of big, to much smaller ones.
And if a provider doesn't exist or if an operator doesn't exist for a task that you need to perform,
you can write it and you can either write it and be running it in your instance of Airflow.
Or if you're being a good steward of open source, you can write it and contribute it back to the
community.
So other people who need to do that task can also benefit from what you've already figured out.
Yeah, that's really neat.
So a lot of these would be things down here,
like if only one person has to write,
how do I connect to Hadoop?
Or if you go to airflow.apache.org,
or you go to the bottom, there's all these different--
are these the operators, or what are these?
Or the tasks?
GIL DIPERSON: Those are integrations, integrations
with the different services you have.
So Google, for example, is a big provider,
but it consists of integration like Google Cloud,
CMS, data store, machine learning.
So you have a number of integrations per provider,
even sometimes.
GIL DIPERSON: OK, cool.
And Leo, if I was going to create one of these,
if I was going to be a good citizen, I'm like, oh,
I want to create one with AWS Lambda.
That exists.
But something like that, right?
GIL DIPERSON: Yeah.
GIL DIPERSON: Does that get contributed back to Airflow?
So when I pip install Airflow, does that come with it?
Or is there some external way to bring in--
GIL DIPERSON: Yes.
We do actually-- well, I'll have to double check with Yarek
and Caxel, because I know we've been messing around
with how we do the installs lately.
So it used to be that Airflow operators
were packaged along with Airflow.
And when you did pip install Airflow,
you would get everything.
And I think that you do still get a certain number of base operators
that are kind of like provider agnostic that come with Airflow.
GIL DIPERSON: But the way we have things now is that all of these provider-based operator sensors,
all these provider task things are packaged separately.
And you add them just like you would any other kind of Python package.
GIL DIPERSON: Right.
GIL DIPERSON: So for example, if you want to install the Google Cloud operators, you have that separately.
And the advantage of that is that they're released on a separate release schedule.
GIL DIPERSON: And follow versioning that ensures they're compatible with versions of Airflow.
And they're very clear about that.
And it's a lot easier for Airflow users to upgrade just the providers package than it is to upgrade the entirety of Airflow,
which for folks running in production, that is not always feasible or practical.
GIL DIPERSON: Yeah, you can actually click on documentation link on this page, Michael.
And then you will see all of those providers.
So you see the list of different provider packages.
And you can see the documentation of that versions, the different versions.
We release them very frequently.
Like every month, we have a bunch of providers released, which are adding new functionality.
And they are done completely separately, as Leah said.
Not the same release schedule as Airflow, and you can start using them faster.
And this is actually super cool that you can actually always find something there.
But if you don't, we don't actually force you to go this community route.
Like those are all providers which are developed by community and maintained by the community of Apache Airflow
under the Apache Software Foundation rules, which is called like Apache Way.
So the way how Apache releases software.
But if you want, you can actually build your own custom provider.
You can build your own custom operators and you can release them separately.
And somebody can install that.
And they even-- we even have integration points that if people are writing the custom providers,
they can use exactly the same feature as the community driven ones.
And you can install them as a package, as another Python package, completely independent from Airflow.
And it just plugs in the UI of Airflow, plugs into the whole framework, and you can start using it.
So it's both community and custom.
Yeah, you can go either path, right?
That's neat.
I think, Leah, what you're saying about the cadence, the release frequency, and maybe even the degree of seriousness with which you have to apply to these.
You might want the main Airflow to be treated differently than some edge package or integration, right?
Yes, definitely.
There was a proposal for requests, the very popular HTTP library, to be integrated into Python to replace Python's HTTP layer.
And the decision of the core devs, I believe, was we don't want to do that to request.
To request, like it will actually make requests go much slower and only get released once a year with changes rather than, you know, as quickly as it needs to go.
Same thing for you all, right?
That was one of the biggest reasons for us to separate the providers, because when we were releasing 1.10.2, 1.10.3, 1.10.4, it meant that all the development was happening in the main or master branch.
And we were not releasing from master branch because we were just releasing the minor or pet versions right now.
And because the code has to be tested thoroughly, even if there's a small bug in one of the providers, let's say a Google GCS bucket operator or something, it has to wait until the entire code has been tested and released.
So the cycle can be large, whereas what everyone was thinking, at least the committers and PMC members, that providers can be released more frequently, even if it means it can be released.
If we find a bug right now, we should fix it and go with the normal ESF releasing way, which is like three days of voting and release it.
So it is quicker release rather than waiting for the next month to club it into the core airflow release.
Plus that way, it's easier to also check the changes that happens because imagine checking the change log for 70 odd providers, including the airflow core in a single page.
So it will be a nightmare.
Yeah, I bet.
I'm just thinking of all the coordination of, well, there's some people working on the Discord integration and someone's working on the Samba integration and we're going to do a new release.
You've got to kind of feature freeze all that stuff.
So yeah, it makes a ton of sense to separate these things.
Actually, this is super, super cool that, you know, I'm the release manager for providers so far.
So I was releasing, I don't know, maybe six, seven releases over the last year.
And actually, I do it myself in like two, three hours.
I'm able to bring all the changes and put the release notes for all the 70 providers.
It's all fully automated and we can manage and release that without a worry that it will break something.
Because if one of those releases goes wrong, providers go wrong, we can simply yank this release.
This is this fantastic feature of PyPype that you can yank the release.
And this actually happened yesterday.
So we discovered that the PostgreSQL we released, 2.1.0 version, had an incompatibility back with previous version of Airflow.
We haven't discovered that during our testing.
We test a lot of things, but this one slipped through.
But what we've done, just yanked this release.
Anyone can use the previous one.
When they install Airflow and PostgreSQL operators, they will install the latest version.
And in the meantime, we can just fix the PostgreSQL and release a new version.
And that's super cool, actually, for maintenance release and usability and stability of your installation.
Yeah, that's really good that you can change it around.
All right.
So I want to talk about, first of all, let's talk about installing.
So how do I get Airflow onto my computer?
It depends on if you want a hosted, managed version, like Cloud Composer, which I work on.
Or there is one for Amazon, MWAA.
And there's also Astronomer, which is for Caxelworks.
Or if you want to do it yourself.
Yes.
In general, though, we at least say that use the constraints file.
So every time when we release an Airflow version, we also tag in GitHub the constraints file for each of the release.
A constraints file contains the set of known dependencies that we have tested Airflow with on the CI.
Because Airflow has a lot of dependencies.
And before we started using constraints, there were a lot of instances where we just released Airflow.
And one of the dependencies released a breaking change in a minor or a patch version, which means users could install Airflow.
And to get over it, we came up with this idea of using constraints file because Airflow is a library as well as an application.
So for library users who want the latest versions, whereas for application, you want the stable versions of everything.
So we came up with this balance of using the constraints file.
So if you check that Airflow version 2.1.2, we get the Python version and then we fetch that constraints file from GitHub and use that constraint file.
Because that way we can guarantee that it is reproducible and it will work for sure.
Yeah, very cool.
So if I go to the documentation, there's a couple of options.
I can run it locally.
I can run it in Docker.
I can run it in Astronomer.
But looking through the script to set things up here, it looks like there's a couple of steps.
So there's a database that does something.
There's some users who execute the task or, you know, you don't want to run as root most likely.
I suspect that's something you all discourage.
Probably.
And there's a web server and there's a scheduler.
So maybe tell us about that.
Whoever wants to take it.
Yes, I'll take it.
So Airflow is pretty complex in setup because it has multiple components.
Depending on the setup, you can talk to a Kubernetes cluster.
It can execute the workflow there.
Or you can have a salary queue system processing your tasks and executing them on distributed workers.
Because the scalability part, which was one of those features of Airflow.
So you can have multiple workers, multiple machines, even several hundreds of them if you want.
And Airflow can be installed using all those capacity.
So we have salary workers, we have Kubernetes workers, we have scheduler, we have web server.
And putting it together is not as simple as you would think.
Or actually, you can think that it's complex.
And it is.
However, we've made, like recently especially, we've put a lot of effort to make the kind of very simple way of installing Airflow.
Like, you know, like you just install it and it works.
And also, if you want to scale it to like a very complex one, you can also turn on all the knobs, put as many components you want in a way that fits you best.
So coming back a little bit to this installation, we have a Docker image.
So that's something I also worked for quite some time.
Together with Caxil and the other maintainers, we iterated and perfected it.
So we have a very nice Docker image that can be used to both run Airflow as it is or build your own custom image, which contains all the new dependencies you want or all the special packages that you want to install, which are needed for you.
And then from that, we have Docker Compose, which is kind of a quick start.
So you can just, and this is this running Airflow in Docker, this part there.
When you run in Docker, does, say, the web server run in one container and the scheduler in another or something like that?
That's exactly what this Docker quick start.
It's orchestrated, yeah.
Okay.
Yes.
But it's super easy.
It's a really quick start.
You just download the Docker Compose file.
You just run two commands.
If you go a little bit down, then there's like a few commands to run.
And then off you go.
You have all these components talking together to each other and processing the DAGs.
And you can start playing with that.
It's not production ready, the Docker one.
But then there is the next step.
So you have a local installation.
It gives you Docker Compose.
And then I will transfer it to Kaxi because he was working mostly on that.
Yeah.
So we also have the Helm chart that we did.
The first version of Helm chart we released in March of this year.
So that's what we recommend for production uses.
That uses the official Docker image.
So we release like a lot of artifacts for Airflow.
And again, the documentation for Helm chart.
If you click on documentation again at the top and scroll all the way down, you will see a separate documentation for the Helm chart.
All right.
So go to Helm chart.
Yeah.
Okay.
Got it.
We have versioned all this documentation separately because they are different artifacts and all of them have different release cadence and are released separately.
And Helm chart is what we recommend for users because it comes with all the configurations that we have tested it in production environments.
Astronomer donated the Helm chart last year and we traded on it a lot of time before we released it.
We also, me and Jarek, had a presentation in a recently concluded Airflow Summit.
So if users are interested in it, we can probably drop a link at the end of this session, I guess.
Yeah.
You all just had the Airflow Summit, right?
Yes.
Yeah.
Oh, I have a lot to say about this.
All right.
Well, tell us.
Community is definitely where the majority of my contributions to Airflow come in.
So this is our second ever Airflow Summit.
So far, it's been an annual thing, but I'm always nervous to say annual.
We can't, I don't want to make promises, but it's looking good.
Like we'll have it again.
So we had our first summit in 2020.
We had originally planned to have it be this 500 person in-person event and it's going to be in Mountain View.
That's how I got involved because we were looking to host it at the Computer History Museum.
And I said, oh, that's really close to where I work.
I can like be your liaison to the location.
And then, you know, there's a whole pandemic and everything.
And we ended up pivoting to a totally virtual event and it was a great success.
We did it in partnership with Software Guru.
They helped us run the summit last year.
And we felt that it was such a good success that we did it again this year.
And it just finished up in July.
We had 10,000, I think more than 10,000 at this point, registered attendees from all over the world.
That's really good for an online conference.
And for only the second edition too.
We're pretty proud.
Yeah.
And we had it live streamed in a bunch of different time zones.
So sometimes it was more Americas friendly.
Sometimes it was more EMEA friendly.
Sometimes it was more APAC friendly.
And we had all variations of talks.
We had ones that were customer use cases.
So people who are running Airflow in production or running one of the hosted managed versions of Airflow and what they're using it for.
We had people who are contributors talking about their first time contribution experience and why you shouldn't be scared to contribute to Airflow because we're really nice.
I promise we are, or at least we try to be, but, and we had more experienced contributors like Yarg and Kaxal talk about some of the more complex things that they've been working on over the past year and everything in between.
And there are so many talks and you have the summit page up right now.
Actually, all of the recordings and slides for those presentations that had slides available are up there for you to watch.
If you go to airflowsummit.org, there's many, many, many hours of content.
I highly encourage you to watch whatever sounds interesting for you.
Yeah.
I think this is great.
Like I said, congratulations on having 10,000 registered.
Thank you.
Yeah.
That's pretty amazing.
I think there's obviously a big group of people who know that this is like the right tool.
I think there's a lot of people who necessarily don't know for sure.
Like for example, there's on the Airflow GitHub page, it's 23,000 stars.
That's big time.
Yeah.
Jango and Flask are 50, 50 K.
So, I mean, that's, that's a lot of people using this and interested in this and so on.
I think that the best part about Airflow is the community.
And that's like why we have those stars, but also like why we had such a summit.
And Kaxal, you were going to say something.
Yeah.
I was just going to say that if you go by the PyPy stats, we have like 3 million downloads
a month or something like that, which is insane.
I know a good number of those come from CI and automated processes, but hey, all the other
packages also have the same thing.
So you can at least compare them between packages.
Yeah.
It's a relative statement at least, right?
Exactly.
And likely I mentioned like the biggest part about or biggest greatest thing about Airflow
is its community.
If you check the new contributors, I think we are to more than 1600 contributors to the Airflow
project, which is great.
And every day we at least get a few new contributors trying to contribute to the project with whatever
they can and they must.
And I, again, through your medium, I would encourage people to go to Airflow website.
If you find anything, contribute it, fix it.
If you have some ideas about hooks, operators, anything, contribute it.
And we are there to help you.
Not only three of us, there are more than 30, 40 committers and PMC members, and there are
users helping users in the Airflow Slack channel.
We have more than 16,000, 17,000 members in the Airflow Slack workspace as well.
Wow.
That's cool.
So I actually want to give a quick plug for an Airflow Summit talk I gave this year that
was authored by me and a colleague.
It's called You Don't Have to Wait for Someone to Fix It for You.
And it is about the kinds of contributions that you can make to Airflow because there's all
those things that Coxell mentioned.
But my personal opinion is that one of the best and easiest ways to contribute to Airflow or
any open source project really is to find something that is driving you nuts and to fix it.
Or at least to articulate really well what's driving you nuts and what needs to change.
Because a really good issue can be just as good of a contribution as a PR.
Because you may have just made the foundation for someone else to write a fabulous PR with a really
detailed issue.
And let me add to that as well because the community is definitely the thing that I love
most about Airflow.
The people are fantastic here.
And we are, all of us, all the committers, we are so much into making, like inviting people
to come and to join us or to give back for whatever they got from Airflow.
Like it's a free software.
Anyone can use it for free.
Giving back is just super nice.
But we don't stop talking, only talking about them.
Because if you see, if you see, scroll down a little bit above, you would see that we also
run a workshop during the Airflow Summit.
And this workshop is about contributing to Apache Airflow.
This year we had like 20 attendees coming and learning in three hours how to make your first
PR, how to communicate, how to be present in the community, how to make the most of it,
how to be super helpful to others as well.
And then we were just, it was like part of it was about coding, but all the rest was all
about communication, about speaking to people, about being able to express yourself and all
the stuff that you just needed.
And it is super important.
Who should I ask about this and things like that?
I know exactly who you should ask.
So actually one of our, one of my favorite stories about this year's Airflow Summit is we
had a speaker, I forget her last name.
Her first name is Tatiana and she's like a principal data engineer at the BBC.
And she went to the workshop last year.
And this year she was a speaker at the summit.
And her talk about how to basically like kind of debug when crazy stuff is going wrong in Airflow
was fabulous.
Oh, super.
Okay.
Yeah.
And you can, that's, people can live stream that off the sessions.
That's really cool.
Yeah.
Doing in Airflow, Airflow obstructions.
Awesome.
So that is an example of that workshop working.
Yeah.
Very cool.
Yeah.
I was just saying Airflow Summit is also one of a kind conference.
It's not like the normal conferences, mainly because we had the local meetup groups hosting
that day of the event.
So we had like the London meetup group.
We had the Bangalore meetup group, Melbourne, Warsaw meetup group.
And every, though we were bringing the community together.
So let's say the first day was hosted by the London meetup group, which was me, Ash and
other folks.
We were hosting that event for just for the Monday slot.
And then on the Tuesday, there were other PMC members, other community members from Japan
hosting that, some from Melbourne hosting that.
Similarly, those were the slots.
And someday even we had like some sort of overlap because we were trying to cover the
Pacific time zone and the Asian time zones, which was incredible because now you have tons
of content for the Airflow users to watch out.
Also, we had two community days.
We started from Thursdays.
So we had Thursday, all the talks about community, how you could make the contributions and stuff
like that.
Friday, we had that workshop.
And then from Monday to Friday, there were more about the Airflow use cases and why Airflow
2.0 was the big milestone for the project and what we are planning ahead for Airflow and
stuff like that.
There's a ton of stuff here.
I think people could watch for the rest of the year and study this and get a lot out
of it.
It's true.
I do think so.
And we actually even had a networking event there Friday night.
And that was a blast, actually.
It was.
The networking this year was like people learn how to use it online.
And that was like, well, not maybe as good as physical conferences.
So I'm looking forward to next year, which hopefully will be going to be partially at least a physical
event.
But it was good enough.
And I think that was really cool to talk to those people about all the different things,
not only Airflow.
So we are not only Airflow and not only Python and not only programming, but also people.
Yeah.
I feel like this is a project that would be easy to contribute to in the sense that if
I'm going to say contribute as a newcomer to Django, that's going to be hard because that's a highly
polished single piece of software.
And if you're going to make a change that affects millions of people and it's not easy.
Whereas here, if you want to add some kind of integration and it didn't exist before, you're
not going to break anybody's code.
You don't want to work with a bunch of legacy code.
There's a bunch of sort of broad but shallow places people could jump in and participate.
Well, and if people, if a newcomer does want to come in and like really jump into the deep
end, we do have this concept called AIP, which stands for Airflow Improvement Proposal.
And it kind of sets you up to not run into heartbreak if you open this, what you think is an
amazing PR and we're like, oh, no, no, no.
Hold on.
We're not ready for that.
Because it's almost like writing the outline before you write your essay.
I know it sounds kind of dry, but what it really is, is it's an opportunity to fully flesh out
this amazing idea you have and share it with the community and the community will give you
feedback and they will be productive about it because if they're not, they're not abiding
by community code of conduct.
Yeah.
I find it very unfortunate.
I feel really bad if people come and do a PR to some project that I have.
And granted, these are all very small open source projects.
But if they come and they actually do the work and the first I know about it is, boom, here's
a PR.
Yeah.
That's just not in the same zen of what I'm trying to accomplish with this.
And it's going to break the thing that makes it special.
It's a bummer.
So I have to reject it, right?
But you don't want to.
Yeah.
It'd be much better to say, I have this idea.
If I built this, would you want it?
You know, do you want the puppy?
Here's a puppy for Christmas.
Yes, exactly.
This is precisely what we are teaching people at those workshops because it's not obvious.
If you come from outside, you don't understand that.
We are not only teaching people about contributing the code, but also how to find yourself there,
like how to be empathetic, how to think about, put yourself in our shoes.
And on the other hand, how to tell what he wants to tell in the way that we will understand
it.
Because it's sometimes really different worlds, different people, different backgrounds, different
expectations and assumptions.
So all this is the communication is that I'm a software engineer.
I love to do software engineering, but like 30, 40, 50% of my time is communication.
It's not actually coding.
And this is cool.
I related to this, I actually want to call out a really important Apache value that I
think that Airflow embodies, which is the concept of the importance of community over code.
And I really feel that the Airflow project lives that value.
And folks in the community really are trying to foster a positive community because they
understand that if the Airflow community is not healthy, then the Airflow code will not
live on.
It doesn't matter.
Yeah, it doesn't matter.
And if folks have questions about that, I do want to acknowledge that I am the one woman
in the room.
I am often the one woman in the room when it comes to Airflow.
And I would love to see that change and have more gender diverse folks come join.
And so if you are someone who identifies with that and wants to hear Leah's unfiltered views
on the community, feel free to reach out to me in the Airflow Slack or on my Twitter.
And like I said, I do think this is a project that if you want to get into open source, it's
one that has relatively low barriers, technically speaking.
Yes.
Oh, yeah.
The keynote talk I gave in the Airflow Summit on Thursday, the first talk.
So if you go to the Airflow Summit page, the first talk, then I talk about my journey as
well.
Because I was very afraid of contributing to open source because it feels intimidating at
first on everything will be public.
Oh, who knows if I screw something up?
What would people say?
On my permanent record.
Yeah.
And I didn't know Python or didn't know it proficiently.
So I talk about my journey of how I did it.
I talk about 10 minutes about that and then how a new user can start contributing to the
project.
Because Airflow is a relatively still a larger code base.
And there are a lot of areas that people can target because if you try to learn everything
at once, it is going to be very difficult.
We have Helm charts.
We have Docker images.
We have scheduler, which is code to Airflow.
We have executors.
We have the CLI, REST API, and a lot of things like that.
So there are a lot of room for people to get expertise in a certain area.
And then if you start including all the integrations, then it's a whole piece, right?
You can just add your own integration and be an expert at that and become a contributor,
a PMC member just with that contributions.
Well, and in the interest of empathy, I would like to share that I do not know all of these
parts.
I think the part I'm most familiar with is the Google provider.
And I have never touched the Helm chart and it scares me because I haven't taken the time
to learn what it's all about.
But the good news is that other community members know and I know that I can look to them for
help when I do need to mess around with it.
Yeah, that's fantastic.
That's the beauty of the project, right?
If everyone knows everything, then why are we all here?
Each one of us knows their part, then that's the community.
Otherwise, it's not a community project.
Yeah.
Yes.
We're getting short on time.
I do want to touch on a couple of things that I think we haven't got a chance to touch
on that are really important.
One, let's talk about the user interface because one of the ways you all position to this is
you don't want to do this all with just cron jobs and like sort of little scripts that are
put together and run on weird random triggers.
And one of the real big benefits is you have this really beautiful UI for all sorts of visualization
of like running workflows and all kinds of stuff, right?
You want to tell us about that?
I'll do the simple version because I think that Kaxel and Yarek know more about it than me,
but I'll tell you the two things I'm most excited about.
One of them is that it just got a huge makeover with Airflow 2.
So if you're an Airflow user and you haven't upgraded to Airflow 2,
if you need one reason alone, it is that the UI is so much prettier and it is much more responsive.
And as a former cron user, I'll say that the best, easiest benefit you get from this
is you can just see what's failing.
If you don't have to dig around and try to figure out what's missing,
like you know that something went wrong.
All right, Yarek and Kaxel, that's my, I'm off my soapbox now.
Yeah, basically you have all the information you need, all the historical view in front of you.
Like if you want to see which task failed historically, you could just check the tree view.
And then this is the graph view where you can see how your task is proceeding.
Plus we now have auto refresh, like Leah mentioned from 2.0,
which is like you don't need to press the refresh button,
which was a bit annoying for the Airflow 1.10X version, which is very good.
Your task will continue.
You can see the progress that the Airflow is continuing this task.
If you click on that task, it will show you the logs of that task.
So everything is very intuitive and easy to monitor.
For people who are listening and are not watching the live stream,
you can go and for example, in the graph, it'll show you all your tasks that you would do,
like download this file or run this bash script or whatever.
And then it actually shows you how they're working together.
And then they're colored as you progress through this DAG of tasks, right?
So you can actually visually see, was this one skipped?
Was this one successful?
Which one failed?
How far are you visually as a graph?
Which I think is awesome.
Yeah.
And one of the interesting thing over there is to understand the dependencies,
which was very interesting when I initially started with Airflow,
that for a user or for a company to understand what all the tasks they are working on
and in a single flow, how does that dependency graph work on?
If you're depending on a data from a single client, how does that go to a dashboard?
So that end-to-end view, like it's an actual pipeline of sorts that you can see.
Yes. And just to add on that, so the visualization of the data flow is like super important
because then you can, with a glance, you can see what's going on
and you can go to any part of it and focus on that and understand what's going on.
However, I will come back to kind of the roots
because Airflow doesn't have a way by default to define those flows visually.
You can see them visually, but they are all defined as Python code.
And this is like the beauty of it.
And that was a very, very deliberate choice.
And this is the reason why we are at the Python talks today,
because Airflow is all about Python.
So this visualization that you see here are really reflection of the code that you wrote as a writer.
And it means also that the common language between people using Airflow,
different parts of it, is Python.
This is the common language that we're using.
And this makes it so powerful.
And the visual part is pretty much an addition.
And it's necessary.
And it's more kind of result of the Python code which is being written.
A lot of workflow systems try to go in reverse, right?
They're like, here's your draggy, droppy set of tasks and options.
You drag it all together.
Then you press go.
Yes.
This lets you live at the code level.
This all breaks at the very moment when you want to have some custom work.
Because if you are used to the drag and dropping, you will not do coding.
You will not code the kind of customization that you want to do.
You will ask someone else to do that.
In Airflow, this is quite reverse.
I mean, everything is Python.
Everything.
Dependencies are Python.
The code itself is Python.
The blocks are Python.
But you can also write your own.
In the same place where you define your DAG, you can write your own custom operator
without having to use a black box operator of sorts.
And you don't have to leave the box of working on Python while doing that.
And this is so powerful.
I think this is the way why it is so popular between data engineers all over the world.
I think this is like one of the most popular workflow orchestration engine in the world right now.
That's it.
I don't have hard data on that.
So it's just a feeling.
But I think that's the case.
I mean, we did have 10,000 people at the summit, Jarek.
Yes.
Yeah, for sure.
And while it is written in Python, you can use the bash operator to run like your Java code,
for example, or Scala or whatever.
So while everything is in Python, you can use it to run any other languages too.
You can run Docker image, Kubernetes task.
Because a lot of those workflows are also, okay, we have Kubernetes.
So we run everything in Kubernetes.
We run them as Docker containers.
And that's the only way you can do that.
Airflow can do that as well.
No problem whatsoever.
There is Kubernetes pod operator.
You can spin off a new Kubernetes pod to run your task.
But you can also have a Python code, which is very easy to put together and play with and run locally without all the overhead of building the Docker images and making them available to run you as a task.
So, so much more extensible and powerful.
Yeah, that's a very good point.
There's a lot of escape hatches to bring in other technologies.
That's cool.
Yeah.
Let me give people just a super quick sense of what it's like to write code for this, this Python code.
So you would say with DAG, with directed acyclic graph, and you give it some details.
And then you create these various tasks, like a task might be a bash operator or something like that, or like you said, a Kubernetes pod or whatever.
And then you just run them.
One thing I did want to ask you all about, like, what is this T1 double arrows into list of T2, T3 for the tasks?
Ooh, good question.
So you had those tasks matched to variables called T1, T2, and T3.
And this is how that visualization is defined, using those, like the bit shift operators in Python.
So this one would say that T2 and T3 run after T1, and they run in parallel.
And there are different ways of setting dependencies.
If you scroll down or just search for setting up dependencies on the right side of your, on the right side.
Yeah, setting up dependencies.
Yeah, there you go.
There are different ways you can set those dependencies between tasks.
You could do T1-test-do-do or T1.setupstreet.
You can, like, right shift.
You can left shift.
You can double bit shift as a transitive type thing.
It's set upstream.
Okay.
And the beauty of that, again, is that you can, this is all Python code.
Those are custom operators.
The left shift and right shift, they are just custom Python operators over with them.
Right.
And you can override them in the task, right?
Just like pathlib overrides forward slash to mean, like, combine parts of the path, right?
Wouldn't probably recommend that if you don't know about Airflow that much.
But the better thing there is that you can actually programmatically build the tasks and build the relationships.
So this is not something that is predefined in one file in the declarative way, like it's an XML file or JSON.
This is a Python code.
So you can pretty much dynamically build the DAG.
So very complex.
Like we saw, like, you know, the DAGs, which were like thousands, thousands of nodes built with like 200 lines of code because you could build those tasks.
You know what, which relationships you want to build in what way, like in for loop.
It's very hard to have a conditional in a JSON file or a XML file.
Yeah.
That's the thing.
Or loop.
Actually loop in JSON file is like, no.
I mean, there is no way to do that.
I mean, we do have XSLT.
You could go crazy.
Come on.
Yeah.
Please no.
And also from Airflow 2.0, this is an explicit way of setting dependencies, but from Airflow 2 and onwards, there's also an implicit way of having dependencies, which is like,
if you say that your mesh operator takes an input from another task, then Airflow sets dependencies between them implicitly because you are depending on an output of another task.
So it knows.
Yeah.
That makes a lot of sense.
Cool.
All right.
So I think just two really quick things before we wrap it up.
We are short on time here.
One is we talked about the web UI for the stuff we're looking at, but there's also, you will describe a rich command line utility.
To perform complex surgeries on DAGs.
Okay.
Why would you perform a surgery on one of these things?
And what is this all about?
Who wants to take that one?
Oh, I don't know that I've done surgery with the CLI, but I have used the CLI to give me information about my environment to figure out when things are misbeheaving.
Yeah.
Okay.
Cool.
Like for diagnosis and stuff like that.
Yeah.
Like, cause we have, there's one command list DAGs and it also shows you how long the DAGs are taking to load.
So you can kind of see if one of them is your problem DAG.
If it's taking way longer to load than the rest, that usually means that I've made a mistake.
Yeah.
That command also gives you the parsing time and everything like that.
So it will tell you that it took five seconds to parse your DAG file, which means something is wrong in your DAG file.
You are probably importing a lot of things or doing some database calls on the top of your file, not inside the objects.
Gotcha.
So you could find those sort of issues.
Also, you could use Airflow backfill CLI command to run all the backfilling of data if you got the data today.
And if you want to run it for last one year or so.
But also it's what is not mentioned in the document.
There is this, well, it is mentioned in the documentation.
We have also a very, very powerful and rich and very well written API.
So we have a stable Assov Airflow 2.
That was one of the improvements implemented.
So if you go to Apache Airflow, yeah, and scroll down on the left, yes, not this one, this stable.
All the way down, yeah.
Even below, there was like stable REST API.
Yeah, very good.
Yeah, yeah, yeah, gotcha.
Okay.
Yeah.
This API is like written in open API standards, which means that all the tools which you can imagine for like managing access, for trying out things, for testing the API calls, all the beautiful documentation that you see here with examples, this is all automatically generated.
From our API.
This is super cool because you can actually, and this is surprising.
You said that the UI is fantastic.
And yeah, it is.
But there are some companies who have their own UI, their own ways of looking at the processing pipelines.
And many, many, we've learned during the Airflow Summit, many of those companies, they actually build their own UI.
They don't use Airflow UI at all.
They just use the engine to execute it.
Right.
Maybe you want to integrate it into some larger thing they already have or something, yeah.
Exactly.
And this API makes it possible.
So you can just query which DAX you have, which are the relationships, how this all works, which is successful, which not.
And then you can build beautiful UI or even ugly UI if you want.
But the UI, that is something that you're used to without looking even at the Airflow UI.
And this is also super powerful.
Yeah.
And this is straight up REST API.
So while Python is awesome, if you're not a Python person, but you still want to adopt this, here's a way to integrate with it.
Right.
Absolutely.
And we have already started creating clients in different languages, like we have a Java client for Airflow built on this API spec.
Users can create their own APIs for a specific language because it, under the hood, uses OpenAPI.
So you can auto-generate clients for different languages.
Yeah.
Fantastic.
All right.
I think that is about time for us.
I did want to point out that Astronomer and AWS, but Astronomer, where you work, Axel, is a sponsor.
So if you want to run sort of Airflow as a service, that's kind of your job, right?
A hundred percent.
And also we, Astronomer, has their own registry.
So if you do open registry.astronomer.io, it makes it very easy to search for built-in providers that are baked inside Airflow.
Or if users create and maintain their own providers, it is very easy to search that as well.
I just posted a link if you want to check out.
One comment on that, because we also have Google Cloud Composer.
So we have Astronomer, AWS, and Cloud Composer.
These are like big embrace of Airflow as a service.
For us, it's like you can choose either you run it on your own, you run it using Astronomer, which have like great expertise in everything.
Because we have lots of people from Astronomer or our communities.
Then there are Amazon people.
Then there are Google or Amazon offering and Google offering.
And you are free to choose whatever you want.
Like how you want to run Airflow.
And you can move probably if you decide you need to move.
Yeah.
Absolutely.
That just has to do with the infrastructure.
The DAGs will be the same no matter where you take them.
You might have to do a few changes when it comes to like auth and making sure your keys are up to date.
Cool.
All right.
Let's wrap this up with a little bit of future looking.
Just whoever has the right visibility in our group here.
Just, you know, where are things going in the future?
People are excited about Airflow.
Like what can they look forward to?
There's a really good talk from the Airflow Summit that's called Looking Ahead Beyond Airflow 2.0.
That is with Ash from Astronomer and Ajemal from Google.
And I think the thing that Ash said over and over again is, well, there is no roadmap, but we do always have things going on.
So I'll turn it over to Caxon.
No promises.
But there are lots of that.
So yeah, we pretty much know the direction we are heading to.
So we want Airflow to be the orchestrator you want to use for whatever workflows you want to run.
That's it.
And there are lots of things like to happen in order to get there because we are so specialized on one hand on what we are opening up.
But we are on the road to really make it easy to accommodate more use cases, make it easier to run, make it faster, make it serve those cases which currently cannot be served because of some reasons, historical reasons mainly.
This is definitely some direction we are heading to open up to even more cases without losing the single focus.
Like we want to be great at scheduling tasks and orchestration.
That's it.
We don't want to do processing.
We don't want to go into this direction.
That doesn't make sense for us.
We want others to do processing and we will do orchestration the best way it's possible.
Yeah.
And the two immediate things that we are already working on and we are almost close to merging it on the main branches, making the Airflows schedule more powerful.
That is a user who will have more power than just like expressing it in Cron.
Users will also be able to say run it on the third of the third trading day of the month or something like that.
Like that level of powerful timetable we want to provide to the users.
We call it timetables.
We will have Cron timetable.
We will have time delta timetable of sorts.
We are figuring that out.
But we'll have that plus something called deferred operators.
I mentioned about the sensors which are currently we put a book for the API call and see until it succeeds.
We are going to have a new component called trigger that will use Python's async library to use resources in a more optimized manner.
Instead of polling, you just wait for it to happen and then boom, off it goes.
Yeah.
Okay.
That sounds cool.
Just one comment to this scheduling because those great examples.
One of the cases we want to serve, there is a real astronomer, not the company, real astronomer using Earthflow.
And he wanted to start DAX when there is a sunset and sunrise.
And, you know, when you are astronomer and flying around Earth, that's a little bit complex.
So the whole scheduling is going to be there to implement this astronomer request.
Yeah.
Fantastic.
It sounds really useful.
All right.
Well, I think that's it for covering Airflow.
But let's quickly wrap up with, I guess, just one of the questions since we're a little bit over time that I usually ask at the end.
So I'll ask you about your editor.
Yarek, if you're going to work on Airflow and other stuff, but what editor do you use for Python?
On a daily basis, I use IntelliJ, Ultimate.
That's my favorite editor.
However, very, very frequently, my favorite editor is VI.
I mean, I'm an old type guy and VI is always when I have to do something quick.
Somewhere where I don't have the editor started, VI is there.
And I, you know, have it in my, you know, like fingers.
I know how to quit VI.
It's easy.
I can learn you.
I can teach you, no problem.
Fantastic.
Yeah, I love that joke about random strings.
Kaxel?
For me, it's PyCharm.
I love PyCharm.
It's debugging.
It's going to the source code.
And those intelligent habits, QSOA.
Just a big fan of PyCharm.
Right on.
I use a combination of VS Code.
And I also have Southspot for Vamble.
Yeah, very cool.
Vamble if it's going to be fast.
VS Code if it's not.
Yeah, we're going to be here for a while.
Let's get down to it.
Yeah.
Right on.
Well, thank you all for being here.
It's been really great.
Final call to action.
People want to get started either using Airflow or contributing to Airflow.
What do you tell them?
Oh, I tell them to go to the community page on the Airflow website.
And I tell them to sign up for the dev list and to join the Airflow Slack.
Yeah.
Fantastic.
All right.
Well, thanks again.
Thanks for being here.
Thank you.
Thank you for inviting us.
It was a great time.
Yeah.
Thank you.
Thanks.
Bye.
This has been another episode of Talk Python to Me.
Our guests in this episode were Yarek Potik, Kaxal Naik, and Leah Cole.
And it's been brought to you by us over at Talk Python Training, as well as the transcripts
have been brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the
direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to
subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Bye.
Thank you.