Wrap-up of Overview of Builder Workloads
1. Wrap-up of Overview of Builder Workloads
We just covered a massive amount of material. I’m a Snowflake employee, and it’s my job to think about this every day, and even I end up thinking: “Wow, the Snowflake platform does a lot.” If you’re feeling overwhelmed, I hope you can take comfort as I do in the fact that no single one of these topics is super complicated. Snowflake works very hard to make each feature and object user-friendly and simple, and each is learnable in a finite amount of time. Okay, so here’s a quick recap of what we’ve covered: At the beginning of the course, we learned about Snowflake’s Core Objects and Architecture. Things like virtual warehouses, stages, basic ingestion, databases, and more. In the next part of our course, we learned about many Snowflake features and a few new objects as well. We covered time travel, cloning, UDFs, UDTFs, stored procedures, and Snowpark dataframes, to name a few of the topics. And in the series of videos we just completed, we ran through overviews of several Builder workloads and tried out one feature from each of those workloads. We talked about Snowflake’s data engineering capabilities, and then tried out Snowpipe. We talked about Snowflake’s GenAI capabilities, and then tried out Snowflake Cortex LLM functions. We talked about Snowflake’s ML capabilities, and then tried out Snowpark ML. We talked about Snowflake’s app capabilities, and then tried out Streamlit. And finally we talked about what it means for Snowflake to the Data Cloud. I structured this module so that we’d go workload by workload, which I think was the right approach, because you can’t tackle everything all at once. But I worry that this presents a picture of Snowflake as broken into bins, which is definitely not the case. Snowflake is one integrated platform, and users of Snowflake can set up a Snowpipe and then immediately clean that data, register features in the Snowflake Feature Store, train an ML model, and serve the results through a Streamlit app. Remember that just because you’re not a data engineer, say, doesn’t mean that many elements of the data engineering learning journey on Snowflake won’t be relevant or useful to you. I wanted to finish this module on Builder Workloads by returning to the idea of what it means to be a Builder. First of all, I want to emphasize that if you’re taking this course, that means you are a Builder or an aspiring Builder, because it means you are building or are interested in building ML models, pipelines, apps, and more. I don’t think specialized roles will disappear, but I do believe in this Builder vision that as Snowflake becomes better and better at making one seamless set of tooling, distinct roles will find it easier and easier to build stuff against the same data that once would have been thought to be outside “their domain.” I believe that it’s only going to get easier for data engineers to incorporate ML into their pipelines and deploy the result as an app. Or for app developers to work further upstream and build out more of the data processing steps they’re relying on for their data app. Or for data scientists to do more upstream pipeline work, or simple app delivery. So I hope as you come out of this module, that you feel not only ready and motivated to build something with Snowflake, but that you don’t feel constrained to building just one type of thing. You’re a builder. Don’t feel bound by your job title, or hoped-for job title. Build whatever you want!2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.