BigQuery - incrementable tables

Google Cloud Data Analytics
1

I am currently running a pipeline through Airflow every 12 hours. Each time the pipeline is run, the BigQuery table is rewrittem (WRITE_TRUNCATE). This is working fine.

However, I want to append only the new data into the table. Instead of using WRITE_APPEND can I use another means to append the table. LAst tme I used WRITE_APPEND, I fgaced issues as the table was populated with repated rows in many cases.

Can I have a timestamp column (current_timestamp) so that after the time stamp the rows get appended into the BigQuery table?

2

There are two refined approaches to append new data to a BigQuery table without using WRITE_APPEND and avoiding duplicate rows:

Using a Staging Table:

  1. Create a temporary staging table to store the new data.
  2. Load the new data into the staging table.
  3. Use a MERGE query to combine the new data from the staging table into the main table, handling duplicates carefully.
  4. Optionally, delete the staging table once the merge is complete.

Using a Temporary Table:

  1. Load the new data into a temporary table created through a query.
  2. Use a query to append the new data from the temporary table to the main table, ensuring duplicates are not created.
  3. The temporary table will be automatically dropped at the end of the session.

Both approaches effectively append new data to the BigQuery table and allow adding a timestamp column (current_timestamp) to the new data before appending it to the main table.

Example Using a Staging Table:

-- Assuming staging_table and main_table are already created
-- Load data into staging_table (done via bq command line, API, or GCP console)
MERGE INTO main_table
USING staging_table
ON main_table.id = staging_table.id
WHEN MATCHED THEN UPDATE
SET main_table.name = staging_table.name,
main_table.current_timestamp = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT
(id, name, current_timestamp)
VALUES (staging_table.id, staging_table.name, CURRENT_TIMESTAMP());

-- Optionally, drop the staging table if it's no longer needed
1 Like
3

Thank you. My case is as follows:

  1. I have a BQ table in project X

  2. I do not control project X. Data is fed into project X every 8 hours

  3. That is: A BQ table Table A is being updated in Project X every 8 hours. I’m not responsible for this update.a This is happening by another responsible team and is happening right

  4. Now I want to ingest data from project X into my project which is project Y and table B

  5. I want only new data to come into table B each time pipeline runs

Is your description coherent with my use case?

Firstly how do I load new data into staging table? What identifies new data?

1 Like
4

Based on your use case of ingesting data from a BigQuery table in Project X into your table in Project Y, here’s an enhanced approach to ensure efficient and accurate data transfer:

Ingesting New Data from BigQuery Table in Project X to Project Y

  1. Identifying New Data:

    • Preferably use a timestamp column if available in Project X’s table.
    • If a timestamp column is absent, identify new data using alternative methods like the highest ID or a unique key.

  2. Loading New Data into a Staging Table:

    • Create a staging table in Project Y.
    • Write a query to select data from Project X’s table, focusing on rows that are newer than those in your last update.
    • Load these filtered results into the staging table in Project Y.

  3. Transferring Data to Main Table (Table B):

    • Utilize a MERGE statement to efficiently transfer data from the staging table to Table B in Project Y.
    • Design the MERGE statement to avoid duplicates, typically by matching on a unique identifier.

Simplified Example:

-- Query to select new data from Project X's table
INSERT INTO ProjectY.staging_table
SELECT *
FROM ProjectX.TableA
WHERE timestamp_column > (
  SELECT MAX(timestamp_column)
  FROM ProjectY.TableB
);

-- Merge statement to insert new data into your main table
MERGE INTO ProjectY.TableB
USING ProjectY.staging_table
ON ProjectY.TableB.id = ProjectY.staging_table.id
WHEN NOT MATCHED THEN INSERT (columns...)
VALUES (values...);

-- Optionally, clean up the staging table

Additional Considerations:

  • Incremental Data Loading: Implement incremental loading for efficiency, especially for large datasets.
  • Error Handling: Develop robust error handling mechanisms within your pipeline.
  • Data Integrity Checks: Perform checks post-transfer to ensure data accuracy and completeness.
  • Scheduling: Automate and schedule your pipeline runs in alignment with the data update patterns in Project X.
  • Documentation and Maintenance: Maintain up-to-date documentation for your data pipeline for ease of maintenance and future modifications.
  • Compliance and Security: Adhere to compliance and security protocols, especially when handling sensitive data.

This enhanced approach should provide a robust framework for transferring only new data from Project X to Project Y, ensuring data integrity, efficiency, and compliance with security standards.

2 Likes
5

Thank you @ms4446 and this is working great. You mentioned:

Data Integrity Checks: Perform checks post-transfer to ensure data accuracy and completeness.

Can you give me some best practices for Data Integrity checks - I am using Airflow /BQ/Dataform.

6

Data integrity checks are essential to ensure the accuracy and completeness of your data after transferring data from Project X to your table in Project Y. Utilizing Airflow, BigQuery, and Dataform, you can implement a robust framework for these checks:

Data Validation:

  • Row Count Checks: Compare the row count in the staging table with the expected number of new rows, considering the type of data operation (append vs. replace) and expected changes in row count.
  • Data Type Checks: Verify that the data types and formats of each column (especially dates and strings) match the expected types in the destination table.
  • Null Value Checks: Ensure that null values are correctly handled and do not violate any business logic or constraints.
  • Unique Constraint Checks: Verify the absence of duplicate rows in the destination table, particularly when using alternative identifiers for new data. Identifying the correct unique key is crucial for these checks.

Data Completeness:

  • Missing Values Checks: Identify any missing values in critical columns and determine if they require imputation or error handling.
  • Foreign Key Checks: Validate that foreign key relationships are maintained between tables after the data transfer, crucial for maintaining referential integrity.
  • Data Lineage Checks: Track the source and transformation steps of the data to ensure its origin and integrity, which is vital for debugging and understanding data transformations.

Data Quality Checks:

  • Data Quality Metrics: Calculate specific metrics like error rates, completeness percentages, or accuracy scores to assess the overall quality of the data after transfer.
  • Anomaly Detection: Use advanced statistical methods or machine learning algorithms to detect anomalies and outliers in the transferred data.
  • Data Profiling: Analyze the distribution of data values, identify potential skewness or bias, and ensure data quality aligns with expectations.

Tools and Techniques:

  • Airflow: Orchestrate the entire process, including triggering checks post-load, handling dependencies, and using Python scripts for custom validations.
  • BigQuery: Utilize BigQuery’s built-in functions, SQL queries, query history, job information, and execution plans for row count checks, data type validations, and data lineage tracking.
  • Dataform: Leverage Dataform for defining data models, ensuring consistency, and implementing data quality checks through SQL queries and custom rules.

Additional Recommendations:

  • Schedule Regular Checks: Automate the execution of data integrity checks after each data transfer process for timely issue identification.
  • Implement Alerts: Set up specific types of alerts, such as email notifications or integration with incident management systems, to notify stakeholders of any check failures.
  • Document Your Checks: Maintain up-to-date and accessible documentation of your data integrity checks and data quality metrics.
  • Monitor Trends: Use visualization tools or dashboards to track data quality metrics trends over time for easier interpretation and quicker decision-making.
7

I have a problem in one of the table @ms4446 . The issue in this table is:

  1. I do have a timestamp column

  2. However, the same time stamp (say 12-12-2023: 19:11:23:55) is repeated in multiple records.

  3. This is because the data is such that there are multiple entries in the table for several records at the same instant of timestamp

  4. I get a unique record (that is: Count =1) if I use the following query.

SELECT
    X,
    session_timestamp,
    session_Id,
    equipment_number,
    COUNT(*) AS count_records
FROM
    `proj_A.dataset_A.table_A`
GROUP BY
    X,
    session_timestamp,
    session_Id,
    equipment_number
HAVING
    COUNT(*) > 1
ORDER BY
    X,
    session_timestamp,
    session_Id,
    equipment_number
LIMIT 1000

  1. Therefore, you can think of it as I have 4 primary id’s as demonstrated in the query above

  2. It is also possible that for the pipeline run at: 10 AM, the max time stamp column is 12-12-2023 15:00:56 but for a pipeline run at 12:00 there will be a timestamp of 11-12-2023:09:00:12 . This contradicts the logic of max time stamp you were suggesting.

In that case, do you sugggest any better way of using incremental tables. I was thinking of inserting X, session_timestamp, session_Id, equipment_number making a check the comination of 4 does not exist in the main table. Is this a wise thing to do? OR do you suggest any betterw ay of using incrementing tables in this scenario?

8

Hi @ayushmaheshwari ,

In scenarios where you have a complex primary key composed of multiple fields (X, session_timestamp, session_Id, equipment_number), and where timestamps may not always be chronologically ordered, consider the following approaches for incremental updates:

  1. Check for Duplicate Combinations Before Inserting:

    • Implement a check to see if the combination of X, session_timestamp, session_Id, and equipment_number already exists in the main table before inserting new records. This can be efficiently done using a LEFT JOIN or NOT EXISTS clause in SQL, which can be more performant than a simple WHERE clause check for large datasets.

  2. Use a Staging Table with Unique Constraint:

    • Create a staging table with a unique constraint or primary key based on the four columns. This setup prevents duplicate inserts. In BigQuery, use a MERGE statement to handle the insertion of new records and the updating of existing records based on this unique combination. This approach ensures data integrity but requires careful management of the staging table.

  3. Use a Hash of the 4 Columns:

    • Generate a hash value for the combination of the four columns and use it as a unique identifier. This method simplifies duplicate checking to a single column comparison. However, be mindful of the rare possibility of hash collisions, especially in large datasets.

Additional Considerations:

  • Performance: For handling large datasets, consider performance optimization techniques such as table partitioning and clustering.
  • Data Integrity: Regularly perform data integrity checks to ensure no duplicates are introduced and all expected new records are present.
  • Maintainability: Opt for a solution that is scalable, maintainable, and easy to understand for future modifications.
  • Timestamp Handling: Develop strategies to manage out-of-order timestamps, which might include more frequent data loads or additional logic in the data pipeline.

Choosing the Best Approach:

  • The method of checking for duplicates is straightforward but may be less efficient for large datasets.
  • A staging table with a unique constraint ensures data integrity but adds complexity to your workflow.
  • Hashing the four columns can be efficient for large datasets but requires additional logic and consideration of hash collisions.

Ultimately, the best approach depends on your specific needs, dataset size, and update frequency. It should balance efficiency, data integrity, and maintainability to fit within your operational context.

9

Thanks @ms4446 , just to remind you of my use case:

  1. I have to ingest data from Project A into Project B and the pipeline will be running every hour to ingest incremented data from Project A into Project B

Now, based on what you said:

  1. Let us assume that the staging table (in Project B) already exists. IT actually exists because I have already ingested all the data from Project A into Project B. Now I have to stage the incremented data during every pipeline run

  2. Also the main table already exists in Project B and now I have to ingest the incremented data into the main table from the staging table during every pipeline run

  3. Based on what you explained earlier, what will be SQL(say, pseudo) query to ingest the data into staging table? I did not quite get how will I create a unique constraint or primary key based on the four columns (X, session_timestamp, session_Id, equipment_number) I mentioned above.

  4. What will be the SQL (say, pseudo) query to ingest data from staging to the main table. Will this be a MERGE?

Can you please help with 4 and 5? Just to be clear as this is very crucial part

10

Thanks for clarification. You want to break down the process into two main SQL queries: one for ingesting data into the staging table and another for transferring data from the staging table to the main table in Project B.

1. Ingesting Data into the Staging Table:

For the staging table, you want to ingest data from Project A. Assuming you have a way to identify new or updated records in Project A (e.g., via a timestamp or an incremental ID), your SQL query might look something like this:

INSERT INTO ProjectB.staging_table (X, session_timestamp, session_Id, equipment_number, other_columns...)
SELECT X, session_timestamp, session_Id, equipment_number, other_columns...
FROM ProjectA.source_table
WHERE [condition to identify new or updated records];
  • In this query, replace [condition to identify new or updated records] with the actual logic you use to identify new or updated data in Project A. This could be a timestamp comparison, an incremental ID check, or any other method suitable for your data.

2. Transferring Data from Staging to the Main Table:

For transferring data from the staging table to the main table, you’ll use a MERGE statement. This statement will insert new records and can also update existing records if needed. Here’s a pseudo-SQL example:

MERGE INTO ProjectB.main_table AS main USING ProjectB.staging_table AS staging
ON main.X = staging.X AND main.session_timestamp = staging.session_timestamp
AND main.session_Id = staging.session_Id AND main.equipment_number = staging.equipment_number
WHEN NOT MATCHED THEN INSERT (X, session_timestamp, session_Id, equipment_number, other_columns...)
VALUES (staging.X, staging.session_timestamp, staging.session_Id, staging.equipment_number, staging.other_columns...);

Explanation:

  • The ON clause defines the matching condition for rows between the tables using a composite key.
  • The WHEN NOT MATCHED clause specifies inserting new rows from the staging table if no match is found.
  • This MERGE statement efficiently handles both inserts and updates based on matching conditions.

Additional Notes:

  • Unique Constraint in Staging Table: Consider defining a unique constraint on the staging table’s key combination (X, session_timestamp, session_Id, equipment_number) to prevent duplicate inserts.
  • Performance Considerations: Use BigQuery’s features like partitioned and clustered tables for efficient data handling with large datasets.
  • Error Handling: Implement robust error handling mechanisms to manage any issues during data transfer.
11

Thanks again, @ms4446 . But that is my problem. How do I get this condition to identify new or updated data in Project A? This is because, as I said the timestamps are not in chronological order and I have a complex table with 4 primary ids. I am not sure how to defining a unique constraint on the staging table’s key combination (X, session_timestamp, session_Id, equipment_number)

I could prevent the staging table completely but that’s not the preferred approach as you might also suggest? Can you help ? Thanks again

12

Given the complexity of your scenario, where timestamps are not in chronological order and you have a composite key of four columns (X, session_timestamp, session_Id, equipment_number), identifying new or updated records for incremental loading becomes more challenging. Here are some strategies you can consider:

1. Using a Last Processed Marker

If you can track the last record or batch of records processed during each pipeline run, you can use this as a marker to identify new or updated records. This approach requires maintaining a record of what was last processed (e.g., in a separate metadata table or storage).

For example, if you can store the maximum session_Id (assuming it’s a unique, incrementing identifier) processed in the last run, your query to fetch new data might look like this:

SELECT X, session_timestamp, session_Id, equipment_number, other_columns...
FROM ProjectA.source_table
WHERE session_Id > [last_session_id];

2. Full Comparison

If a marker like session_Id is not available or suitable, you might need to perform a full comparison between the source and destination datasets. This is more resource-intensive but ensures that no records are missed.

For this, you would compare the composite key of each record in Project A with those in Project B to find records that are either new or updated. This can be done by a LEFT JOIN or NOT EXISTS query, but it can be quite heavy on performance for large datasets.

3. Timestamp Window with Buffer

Since your timestamps are not strictly chronological, consider using a timestamp window with a buffer. This means you select records from a time range that slightly overlaps with the previous ingestion. This approach might lead to some duplication, which you can handle during the merge process into the main table.

For example:

SELECT X, session_timestamp, session_Id, equipment_number, other_columns...
FROM ProjectA.source_table
WHERE session_timestamp >= DATE_SUB([last_run_timestamp], INTERVAL 1 HOUR);

4. Skipping the Staging Table

If the volume of data is manageable and the performance impact is not significant, you might consider loading data directly into the main table using a MERGE statement, as previously described. This approach simplifies the pipeline but requires careful handling of duplicates and updates.

Please Note:

  • Performance and Scalability: Each of these methods has trade-offs in terms of performance and complexity. You’ll need to balance these based on your specific dataset size and update frequency.
  • Testing and Validation: Regardless of the method chosen, thorough testing and validation are crucial to ensure that the data integrity is maintained and that the pipeline behaves as expected.
  • Documentation and Monitoring: Keep detailed documentation of the logic and process used, and monitor the pipeline’s performance and accuracy regularly.
13

Hi @ms4446

Thanks again. One question, fundamental one, if you do not mind. Ok, I am going by the 4th option. That is: I am skipping the staging table and directly inserting the data into the main table using MERGE As follows. Assume that th main table already exists and I am inserting the incremental data.

MERGE INTO `Project_Y.Dataset_B.Table_Q` AS target
USING `Project_X.Dataset_A.Table_P` AS source
ON target.X = source.X AND
target.session_timestamp = source.session_timestamp AND
target.session_Id = source.session_Id AND
target.equipment_number = source.equipment_number
WHEN NOT MATCHED THEN INSERT (X, session_timestamp, session_Id, equipment_number)
VALUES (source.X, source.session_timestamp, source.session_Id, source.equipment_number);

Will the above result in a less costly query than simply doing a WRITE_TRUNCATE of all the rows in all columns? Because we are doing a comparison for every row anyways? What will be the benefit of using the above than a complete rewrite/WRITE_TRUNCATE of all the data?

14

Hi @ms4446

Thanks again. One question, fundamental one, if you do not mind. Ok, I am going by the 4th option. That is: I am skipping the staging table and directly inserting the data into the main table using MERGE As follows. Assume that th main table already exists and I am inserting the incremental data.

MERGE INTO `Project_Y.Dataset_B.Table_Q` AS target
USING `Project_X.Dataset_A.Table_P` AS source
ON target.X = source.X AND
target.session_timestamp = source.session_timestamp AND
target.session_Id = source.session_Id AND
target.equipment_number = source.equipment_number
WHEN NOT MATCHED THEN INSERT (X, session_timestamp, session_Id, equipment_number)
VALUES (source.X, source.session_timestamp, source.session_Id, source.equipment_number);

Will the above result in a less costly query than simply doing a WRITE_TRUNCATE of all the rows in all columns? Because we are doing a comparison for every row anyways? What will be the benefit of using the above than a complete rewrite/WRITE_TRUNCATE of all the data?

15

Choosing between using a MERGE statement for incremental updates and performing a complete rewrite (WRITE_TRUNCATE) of all the data in your table depends on several factors, including the size of your dataset, the frequency of updates, and the nature of the changes. Here are some considerations:

  1. Cost and Efficiency:

    • A MERGE statement, as you’ve outlined, is generally more efficient for incremental updates where only a small portion of the data changes. It avoids the need to rewrite the entire table, which can be costly and time-consuming, especially for large datasets.
    • A complete rewrite (WRITE_TRUNCATE) might be simpler and could be more efficient if a significant portion of the table changes frequently. However, it’s typically more resource-intensive as it involves reprocessing and storing the entire dataset.

  2. Data Freshness and Availability:

    • Incremental updates using MERGE ensure that your data is always up-to-date and available, as only the new or changed rows are processed.
    • A complete rewrite might result in temporary unavailability of the data or outdated information until the rewrite is completed.

  3. Complexity and Maintenance:

    • The MERGE statement requires careful handling to ensure that it correctly identifies and processes new and updated records. This can add complexity to your data pipeline.
    • A complete rewrite is straightforward but requires ensuring that the entire dataset is consistently and correctly processed each time.

  4. Data Integrity:

    • Incremental updates reduce the risk of data corruption or loss during the update process, as they only affect a subset of the data.
    • Complete rewrites involve a higher risk since the entire dataset is replaced. Any error during the process could impact the entire table.

If your updates involve a small portion of the data and data integrity and availability are critical, using a MERGE statement for incremental updates is usually the better choice. However, if your dataset changes significantly and frequently, and the simplicity of the process is a priority, a complete rewrite might be more suitable.

It’s important to analyze your specific use case, considering factors like data size, update frequency, and resource availability, to determine the most cost-effective and efficient approach.

16

Thank you @ms4446 , you said that

  • A MERGE statement, is generally more efficient for incremental updates where only a small portion of the data changes. It avoids the need to rewrite the entire table, which can be costly and time-consuming, especially for large datasets.

But before the MERGE I am also doing a comparison of all records (See below) and inserting only when not matched. Although number of records to be inserted during every 12 hourly pipeline run will be few in number but there will be huge data already from previous runs that will have to be checked as per the query below. Is MERGE it still more efficient (cost wise and performance wise) than WRITE_TRUNCATE?

MERGE INTO `Project_Y.Dataset_B.Table_Q` AS target
USING `Project_X.Dataset_A.Table_P` AS source
ON target.X = source.X AND
target.session_timestamp = source.session_timestamp AND
target.session_Id = source.session_Id AND
target.equipment_number = source.equipment_number
WHEN NOT MATCHED THEN INSERT (X, session_timestamp, session_Id, equipment_number)
VALUES (source.X, source.session_timestamp, source.session_Id, source.equipment_number);
17

You’ve raised an important point about the efficiency of using a MERGE statement, especially when it involves comparing a large volume of existing data to identify new or updated records. Let’s break down the considerations:

  1. Volume of Data to Compare:

    • In your MERGE statement, the comparison is made across all records in both the source and target tables. If your target table (Project_Y.Dataset_B.Table_Q) is large, this comparison can become resource-intensive.

  2. Frequency and Volume of New/Updated Data:

    • If the number of new or updated records added every 12 hours is relatively small compared to the total size of the dataset, the MERGE operation might still be efficient. This is because you’re only writing a small amount of new data, rather than rewriting the entire dataset.

  3. Cost and Performance:

    • The cost and performance of a MERGE versus WRITE_TRUNCATE depend on several factors:
      • Data Read and Write Operations: MERGE reads both tables entirely and writes only new/updated records. WRITE_TRUNCATE rewrites the entire table.
      • Processing Power: MERGE requires more processing to compare records, while WRITE_TRUNCATE is a bulk operation with potentially less computational overhead.
      • Network and I/O Load: MERGE might have a lower network and I/O load since it’s only writing a subset of data.

  4. Data Availability and Integrity:

    • MERGE maintains continuous data availability and integrity, as it doesn’t replace existing data unless necessary.
    • WRITE_TRUNCATE temporarily makes the table unavailable or outdated during the rewrite process.

  5. Long-Term Scalability:

    • As your dataset grows, the efficiency of the MERGE operation might decrease due to the increasing volume of data to compare.
    • WRITE_TRUNCATE remains constant in terms of operation, regardless of dataset size, but always involves full data rewrites.
  • Efficiency of MERGE: It’s more efficient if the volume of new/updated data is small relative to the total dataset size, and the cost of reading the entire dataset for comparison is acceptable.
  • Efficiency of WRITE_TRUNCATE: It might be more efficient if the dataset is so large that the cost of comparing every record outweighs the cost of rewriting the entire table.

Ultimately, the choice depends on your specific data patterns, the relative size of new/updated data, and the resources available for processing. It might be beneficial to conduct performance and cost analysis tests on both methods to determine the most efficient approach for your specific scenario.

18

@ms4446

What about partition tables? Is that approach better in my use case?

19

Using partitioned tables in BigQuery can indeed be a more efficient approach for your use case, especially when dealing with large datasets and frequent updates. Partitioning can optimize query performance and reduce costs by limiting the amount of data scanned during queries. Here’s how partitioning could be beneficial in your scenario:

  1. Improved Query Performance:

    • By partitioning your table, for instance, on the session_timestamp column, BigQuery only scans the relevant partitions for your queries. This is particularly useful if your queries or MERGE statements target specific time ranges.

  2. Cost Efficiency:

    • Since BigQuery charges based on the amount of data processed, partitioning can reduce costs by scanning only the necessary partitions rather than the entire table.

  3. Easier Management of Incremental Updates:

    • If your incremental updates are time-based (e.g., new data every 12 hours), partitioning by date or timestamp can make it easier to manage these updates. You can focus on the most recent partition(s) for updates, which is more efficient than scanning the entire table.

  4. Handling Large Datasets:

    • For large datasets, partitioning can significantly improve performance by breaking the data into smaller, more manageable chunks.

Applying Partitioning to Your Use Case;

  • Partition by Timestamp: Given your data includes a session_timestamp, consider partitioning the table on this column. This way, each partition contains data for a specific time interval (e.g., per day).
  • Update Strategy: When performing your MERGE operation, you can target only the relevant partitions. This reduces the comparison scope and improves efficiency.
  • Backfilling Data: If you receive data that belongs to past partitions (due to out-of-order timestamps), BigQuery can still handle this efficiently as it will only update the specific partition.

Things to Consider:

  • Partitioning Strategy: Choose a partitioning strategy that aligns with your data access patterns. For time-based data, time-unit partitioning (e.g., daily) is common.
  • Clustering: In addition to partitioning, consider clustering your table on other key columns (like X, session_Id, equipment_number) to further improve query performance.
  • Cost of Partitioned Tables: While partitioned tables can reduce query costs, there are costs associated with storage and operations on these tables. Ensure that your partitioning strategy aligns with your cost optimization goals.

Partitioning your tables in BigQuery, especially when combined with a thoughtful update strategy like incremental MERGE operations, can provide significant performance and cost benefits for your use case.

20

@ms4446 Let us say, I am doing some transformations in Dataform. How can I query only on the incremented data for the transformation and not the whole data?