<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Advice on efficiently cleansing and transforming delta table in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15525#M9841</link>
    <description>&lt;P&gt;As the table grows it's expectable for query to take a longer time. You can either play with partitioning/table optimization (https://www.youtube.com/watch?v=daXEp4HmS-E) or increase your cluster size.&lt;/P&gt;</description>
    <pubDate>Thu, 22 Dec 2022 13:15:46 GMT</pubDate>
    <dc:creator>daniel_sahal</dc:creator>
    <dc:date>2022-12-22T13:15:46Z</dc:date>
    <item>
      <title>Advice on efficiently cleansing and transforming delta table</title>
      <link>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15524#M9840</link>
      <description>&lt;P&gt;I have a delta table that is being updated nightly using Auto Loader.  After the merge, the job kicks off a second notebook to clean and rewrite certain value using a series of UPDATE statements, e.g.,&lt;/P&gt;&lt;PRE&gt;&lt;CODE&gt;UPDATE TABLE foo
  SET field1 = some_value
  WHERE some_condition_is_met&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;As the table grow, this step is taking longer and longer. I suspect it is scanning through the entire table each time.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there a way to make this step more efficient, i.e. scanning only the delta update or append?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 20 Dec 2022 22:04:13 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15524#M9840</guid>
      <dc:creator>lawrence009</dc:creator>
      <dc:date>2022-12-20T22:04:13Z</dc:date>
    </item>
    <item>
      <title>Re: Advice on efficiently cleansing and transforming delta table</title>
      <link>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15525#M9841</link>
      <description>&lt;P&gt;As the table grows it's expectable for query to take a longer time. You can either play with partitioning/table optimization (https://www.youtube.com/watch?v=daXEp4HmS-E) or increase your cluster size.&lt;/P&gt;</description>
      <pubDate>Thu, 22 Dec 2022 13:15:46 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15525#M9841</guid>
      <dc:creator>daniel_sahal</dc:creator>
      <dc:date>2022-12-22T13:15:46Z</dc:date>
    </item>
    <item>
      <title>Re: Advice on efficiently cleansing and transforming delta table</title>
      <link>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15526#M9842</link>
      <description>&lt;P&gt;I would partition the table by some sort of date that autoloader can use. You could then filter your update further and it'll automatically use partition pruning and only scan related files.&lt;/P&gt;</description>
      <pubDate>Thu, 29 Dec 2022 07:42:05 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/advice-on-efficiently-cleansing-and-transforming-delta-table/m-p/15526#M9842</guid>
      <dc:creator>Jfoxyyc</dc:creator>
      <dc:date>2022-12-29T07:42:05Z</dc:date>
    </item>
  </channel>
</rss>

