<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Bala Hari on Medium]]></title>
        <description><![CDATA[Stories by Bala Hari on Medium]]></description>
        <link>https://medium.com/@balahari619?source=rss-438d8b1ea744------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/0*G0RFtFnLWocaCns7.jpg</url>
            <title>Stories by Bala Hari on Medium</title>
            <link>https://medium.com/@balahari619?source=rss-438d8b1ea744------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sun, 24 May 2026 02:25:22 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@balahari619/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[Structured API Execution in Spark]]></title>
            <link>https://medium.com/@balahari619/structured-api-execution-in-spark-4dabde8d0c6c?source=rss-438d8b1ea744------2</link>
            <guid isPermaLink="false">https://medium.com/p/4dabde8d0c6c</guid>
            <category><![CDATA[spark-dataframe]]></category>
            <category><![CDATA[apache-spark]]></category>
            <category><![CDATA[spark]]></category>
            <category><![CDATA[spark-architecture]]></category>
            <category><![CDATA[spark-sql]]></category>
            <dc:creator><![CDATA[Bala Hari]]></dc:creator>
            <pubDate>Sun, 09 Jul 2023 08:07:35 GMT</pubDate>
            <atom:updated>2023-07-09T08:11:09.311Z</atom:updated>
            <cc:license>https://creativecommons.org/publicdomain/mark/1.0/</cc:license>
            <content:encoded><![CDATA[<h3>Understand the Structured API Execution in Spark</h3><p>Our code is submitted to Spark either through the console (or) via a submitted job. This code then passes through the Catalyst Optimizer, which decides how the code should be executed and lays out a plan for doing so before. finally, the code will run, and the result is returned to the user.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9Hr3e4SNGgvGSMyHKUNNOQ.png" /></figure><h3>Logical Plan:</h3><p>The first phase of execution is meant to take user code and convert it into a logical plan. This logical plan only represents a set of abstract transformations that do not refer to executors or drivers, it’s purely to convert the user’s set of expressions into the most optimized version. It does this by converting user code into an unresolved logical plan. This plan is unresolved because although your code might be valid, the tables or columns that it refers to might or might not exist. Spark uses the catalog, a repository of all table and DataFrame information, to resolve columns and tables in the analyzer. The analyzer might reject the unresolved logical plan if the required table or column name does not exist in the catalog. If the analyzer can resolve it, the result is passed through the Catalyst Optimizer, a collection of rules that attempt to optimize the logical plan by pushing down predicates or selections. Packages can extend the Catalyst to include their own rules for domain-specific optimizations.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*mpOLjM8X1bLZhPDQfAZAVQ.png" /></figure><h3>Physical Plan:</h3><p>Spark begins the physical planning process after successfully creating an optimized logical plan. The physical plan, often called a Spark plan, specifies how the logical plan will execute on the cluster by generating different physical execution strategies and comparing them through a cost model. An example of the cost comparison might be choosing how to perform a given join by looking at the physical attributes of a given table (how big the table is or how big its partitions are). Physical planning results in a series of RDDs and transformations. This result is why you might have heard Spark referred to as a compiler — it takes queries in DataFrames, Datasets, and SQL and compiles them into RDD transformations for you.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Kib0R2M9KhEJ_LJtHiznfg.png" /></figure><h3>Execution:</h3><p>Upon selecting a physical plan, Spark runs all of this code over RDDs, the lower-level programming interface of Spark. Spark performs further optimizations at runtime, generating native Java bytecode that can remove entire tasks or stages during execution. Finally, the result is returned to the user.</p><h3>Overview:</h3><ol><li>Write DataFrame/Dataset/SQL Code.</li><li>If the code is valid, Spark converts this to a Logical Plan.</li><li>Spark transforms this Logical Plan into a Physical Plan, checking for optimizations along the way.</li><li>Spark executes this Physical Plan (RDD manipulations) on the cluster.</li></ol><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4dabde8d0c6c" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>