Article 3: Designing a Data Warehouse for Google Cloud Platform

This is the third in a series of articles, collaboratively written by data and solution architects at Myers-Holum, Inc., PRA Health Sciences, and Google, describing an architectural framework for conversions of data warehouses from Teradata to the Google Cloud Platform.  The series will explore common architectural patterns for Teradata data warehouses and outline best-practice guidelines for porting these patterns to the GCP toolset.

David Chu, Knute Holum and Darius Kemeklis, Myers-Holum, Inc.

Michael Trolier, Ph.D., PRA Health Sciences

August 2018

Table of Contents

⇒ Capture versus land

⇒ What does a data warehouse look like on Google Cloud Platform?

⇒ Dust-off Your Semantic Model

⇒ Creating the Physical Schema

⇒ Example using our Travel Reservation Model

⇒ Semantic Model Example using our Travel Reservation Star Schema

⇒ Physical Model Example for Reservation_Payment_Fact

⇒ Physical Model Example for Room_Reservation_Fact

⇒ Additional Considerations

⇒ Wrap-up, what’s next

Recap:  In the first article of this series, Article 1: Understanding Your Current Data Warehouse, we discussed source data capture as the first architectural layer of most data warehouses.  We categorized the three types of source capture processes (pull, push or stream) and the typical Teradata implementation strategies for landing the data into the data warehouse for each type of process.

In the second article of this series, Article 2: Source Data Capture, we recommended the creation of a unified landing model, as an architectural component we called the “Landing Zone”.  All source data capture activities target the Landing Zone with associated control processes managing the accessibility and lifespan of those slices of captured data.   We discussed the detailed requirements you should consider in your implementation of the Landing Zone to facilitate your decisions on whether existing Teradata source data capture processes can truly be converted.

Conversion versus Re-implementation:  As you read this series of articles, we are going to differentiate between approaches for converting your data warehouse from Teradata to the Google Cloud Platform versus re-implementing your data warehouse in Google Cloud Platform.  Arbitrarily, we are going to assume certain differences between the two approaches.   The conversion project will be assumed as justified based on an expense reduction/capital spend avoidance ROI model, and therefore the cost of the conversion must be constrained to fit within this cost reduction model.   We would also expect the implementation timeline to be oriented toward a single deliverable, and timed such that the next Teradata infrastructure upgrade can be avoided.

On the other hand, the reimplementation project will be assumed as justified based on a business benefit model, with implementation (capital) costs factored into the internal rate of return for the project.  We would also expect the implementation timeline to be phased into multiple deliverables based on the order of business initiatives you want to undertake.

What does a data warehouse look like on Google Cloud Platform?

To understand the scope of your Teradata conversion effort, you need to understand both the source and target requirements.  Only with this knowledge, can you understand the data integration processes in between that will make up the bulk of your conversion effort.

Cloud BigQuery is Google’s recommended technology for implementing your data warehouse.   BigQuery is a fully managed, petabyte-scale, low-cost enterprise data warehouse for business intelligence.  It is probably one of the principal reasons you are considering a data warehouse conversion.   

Migrating your Teradata data warehouse means that you will be instantiating your semantic logical data model into a new physical data model optimized for BigQuery.  As you recall in Article 1, we discussed the importance understanding how the Teradata semantic layer has been implemented and the extent to which it is actually being used.    

The migration from Teradata will require a bottom up approach, you will be implementing a series of BigQuery tables representing the semantic requirements of a given subject area.  Subject areas will be integrated using common dimensional data (such as customer, product, supplier, organization or employee).

The bottom up approach will allow for an iterative conversion process.  Subject areas can be implemented using an incremental approach, where you weigh subject areas that provide highest conversion benefit.  For example, at our client “Company X”, the customer marketing subject area consumes 60 percent of the existing Teradata storage capacity.  In addition, 14 of the top 25 most frequently used queries access this data.  Therefore, migrating this subject area off Teradata not only provides BigQuery benefits to the users of customer marketing, but also to the remaining Teradata users utilizing different subject areas which now benefit from the new Teradata capacity now available.   

Dust-off Your Semantic Model

You will need a semantic logical data model that represents the data presentation requirements for a given subject area before you can begin any BigQuery physical design.  We recommend using a star schema (following Kimball standards) as the basis for your semantic model.  We also recommend the use of a data modeling tool (ER/Studio, CA-ERWin, InfoSphere, etc.) to maintain it.   The metadata created and maintained in the data modeling tool will become an important component of your overall data warehouse metadata strategy, which we will cover in a future article.     

If you do not have an existing semantic logical data model, creating one in a conversion scenario is not that difficult.  Remember you have an existing Teradata implementation you can analyze to create it.   Here are some approaches for doing that:

  • Use your Teradata database views:
    • If you have used views to standardize end user access to your data warehouse, and those views are more than simple wrappers of your data warehouse tables, then these views may be an effective approach for creating a semantic logical data model.
  • Use the semantic model from your BI tool:
    • Many BI products like Business Objects, MicroStrategy, and Cognos incorporate semantic layers.
    • If you have predominantly standardized end user access via the BI tool, this may be an effective source for creating a semantic logical data model.
  • Analyze your current reports and dashboards:
    • Within a representative sample of reports:
      • What is the underlying granularity of the report (fact level)
      • To what level is the report aggregated (by region, by fiscal period, by product)
      • What other dimensional data is reported
    • We create an Excel spreadsheet to contain this analysis with the rows reflecting the underlying granularity and the columns reflecting the aggregate levels and other dimensions.

Creating the Star Schema

As you create the star schema representing your semantic model, it is important to focus on the following objectives:

  • Identifying fact tables and declaring their associated grain:
    • Fact tables tend to mirror business processes and the associated measures for that business process.  It is important that you use this information to declare the grain of the fact table independently of the levels of granularity contained within the source data.  For example, our sample reservation source model contains levels of granularity reflecting the reservation (order level), reservation item (order item level), booking level (inventory level) and booking detail (pricing level).   However, our reservation star schema contains fact tables representing the business processes at the grain we want to analyze: reservation, reservation item, and reservation payment.  What you name your fact tables should clearly indicate the grain.  
    • Fact tables always have a date (or date/time) dimension, typically representing the transaction or event date.  And that date dimension is typically qualified each time the fact table is accessed by an end user.  In other words, we are looking in advance to identify how we intend to the date partition each fact table.
    • Fact tables are the only tables in a star schema with a composite primary key.  That primary key is always composed of the date dimension and enough other referenced dimensions to guarantee uniqueness.     
  • Identifying the dimension types (type 1, 2 or 3):
    • As you identify the dimensions that apply to each fact table, you need to understand the strategy to handle any change in the associated dimensional values.  Thus the dimension should be clearly declared as to its type; where type 1 means overwrite the value, type 2 means add a dimensional row, and type 3 means add a dimensional column.   
    • In effect, the type of dimension consistently declares the point in time relationship between the dimensional values and the associated fact measures.   Having a consistent definition of this point in time relationship will be immensely helpful as when we create the physical schema, and further physically de-normalize it for performance.
    • For type 2 and type 3 dimensions, don’t automatically assume an effective end date (or current indicator) is needed.   It has no relationship to the associated fact table and typically is not mandatory as a dimension attribute.   In the next article, we will identify the significant data integration benefit of not having to maintain it.  
    • Remember it is OK to have the same dimension as both type 1 and type 2.  This gives you both the historical and as the current point in time in relation to the fact.  You would simply define the same dimension as different entities in your logical model.          
  • Identifying aggregate needs:
    • Make sure you have the dimensions available to support the common aggregations you captured during your analysis of your current reports and dashboards.   If you have implemented aggregate awareness via either Teradata join indexes or within your BI tool, this will be another method of identifying these dimensions you summarize by.
    • Since BigQuery is column oriented store and can very efficiently aggregate column values, we typically do not model pre-computed aggregates (aka summary tables).       

Creating the Physical Schema

The physical schema represents how your end users and associated end user oriented tool sets will see the data warehouse in BigQuery.  Implementing this schema requires the same compromise between ease of use (with potentially inefficient access) versus efficient data access (with potential difficulty to use) that we have all made many times before.  Our physical design approach seeks to optimize ease of use for as many business use cases as possible but also recognizing that physical schema optimization for query performance and cost may be needed in certain situations.

BigQuery’s ability to support a huge data set is a clear advantage of the Google product and most of our clients have at least future plans to utilize this capability.  However, it is important to realize that in a conversion scenario, typical data set sizes coming from Teradata will allow a degree of sub-optimal design while still meeting expected end user SLA’s and cost constraints.  

BigQuery physical schema optimization revolves around two key capabilities:

  • Implementing date based partitioning
  • Using nested and repeating fields to flatten multiple tables into one table to co-locate the data and eliminate required joins

Our design approach seeks to apply a consistent set of physical modeling rules to the star schema logical model, then perform testing using actual data, and then flatten tables further if justified.   Here are the physical modeling rules we use:

  • Start with the fact tables and always keep the declared grain intact.  While we may move dimensional data into the physical fact table to flatten it, we do not move in any data that is at a lower level of granularity than the declared grain.  
  • Fact tables should be date partitioned based on the date dimension you identified in the logical model as most suitable.  We are expecting almost every end user query to specify _PARTITIONTIME to qualify the range of fact table rows needed.  
  • Type 2 dimension tables that are at the same grain as the fact table should be moved into the physical table to flatten it.  For example, in the logical model you have a sales order fact and a sales order dimension because you wanted to separate the additive versus the descriptive attributes.
  • Since type 1 dimensions are often conforming dimensions or contain a limited number of values, we make every effort to preserve them as separate tables.  Know the compressed data sizes of your type 1 dimensions and whether they fit within the 100MB limit that allows for the best performing BigQuery joins.
  • Other type 2 dimensions are candidates to be moved into the physical table to flatten it, but we wait until performance concerns dictate it.
  • We create any summary tables that are needed for exact numeric aggregations.

Beyond physical modeling rules, it is important to consider the data integration requirements that will correspond to the physical schema being created.   A single source to single target is the ideal (and easiest to implement) data integration model.   You will find the more you create a big flat table, the more data sources you will need at data integration time to load it.  And the complexities of ensuring all those source tables are in sync will often require sophisticated data staging approaches that will need to be coded and that will impact your end latency.

⇒ Example using our Travel Reservation Model

Let’s work through the logical and physical modeling process using a subset of our travel industry reservation model.   Here is the entity relationship diagram for the model:

A travel reservation is a variant of a standard sales order.  In the above model, colors are used to reflect the various levels of granularity within this model.  

  • Grey – Reflects the itinerary or sales order level.  Your travel agency reservation confirmation number would be at this level.  
  • Yellow – A reservation can be made up of multiple items.  For example, you may have booked a flight, hotel and car rental under the same travel agency reservation.   Like a sales order item, we carry the common attributes for each reservation item at this level of granularity.
  • Red – Reservation items are bookings with different travel providers.  You booked your flight with United, your hotel with Marriot and your car rental with Avis.  Here we carry the attributes specific to the type of travel provider.     
  • Green – Each booking (air, hotel or car) has fulfillment details associated with it.  In addition, there are attributes reflecting pricing details like rate, taxes, and fees.  

⇒ Semantic Model Example using our Travel Reservation Star Schema

As we design our semantic layer, we identify the levels of granularity we want to present to our business users and the associated measures we want to incorporate at that grain.  We represent these requirements using fact tables at the associated grain.  In our example, we are declaring fact tables at the reservation, reservation payment, and reservation item levels.   We also identify the supporting dimensions, their dimensional type and whether they are conformed dimensions in this semantic model.      

Let’s look at a subset of the star schema model we designed:

In the above model, colors are used to reflect the type of entity.   Let’s declare the grain of the two fact tables (shown in light blue):  

  • Reservation_Payment_Fact – Payments are specific to a reservation as a whole, so the overall grain is reservation level.   The primary key is the reservation, payment date and payment time.  
  • Room_Reservation_Fact – A room reservation is a specific booking type within a reservation item, so the overall grain is reservation item level.  The primary key is reservation and reservation item.

⇒ Physical Model Example for Reservation_Payment_Fact

Now let’s go through our physical modeling rules we discussed in “Creating the Physical Schema” above.

  • What is the fact table grain? - The Reservation_Payment_Fact table is at reservation level.  
  • How will the fact table be date partitioned? - It will be partitioned based on payment date (Payment_Dim_ID).  
  • Are there type 2 dimension tables that are at the same grain as the fact table? – Yes, Reservation_Dim should be moved into the fact table.
  • Are there large type 1 dimensions that might not efficiently join to the fact table? – No, Date_Dim and Time_Dim are small dimensions of static values.  While the fact that they contain static values would make them easy to move into the fact table, they are also conforming dimensions making our preference to leave them as separate tables until performance issues dictate a different approach.  

We end up with the following physical BigQuery table:

⇒ Physical Model Example for Room_Reservation_Fact

Using our physical modeling rules we discussed in “Creating the Physical Schema” above.

  • What is the fact table grain? - The Room_Reservation_Fact table is at the reservation item level.  
  • How will the fact table be date partitioned? - It will be partitioned based on reservation date (Reservation_Date_Dim_ID).  
  • Are there type 2 dimension tables that are at the same grain as the fact table? – Yes, Reservation_Item_Dim should be moved into the fact table.     
  • Are there large type 1 dimensions that might not efficiently join to the fact table? – No, Business_Unit_Dim and Channel_Dim are very small dimensions of static values.  Resort_Dim is a larger dimension, but it is a conforming dimension that we would leave as a separate table until performance issues dictate a different approach.   The two bridge tables Reservation_Status_Bridge and Reservation_Class_Bridge, each reference a single row in their associated dimensions.  We need these to stay as separate tables so that any change in the status of classification becomes immediately effective (type 1 point in time).
  • Are there large type 2 dimensions that might not efficiently join to the fact table? – Yes, Reservation_Dim is at the reservation level and therefore can be moved into the fact table without any requirement for nested/repeating attributes.  Product_Dim is another conforming dimension that we would leave as a separate table until performance issues dictate a change.  Again, due to the star schema design, no requirement for nested/repeating attributes is needed.

We end up with the following physical table:

⇒ Additional Considerations

We try to keep conforming dimensions as separate tables as much as possible.   They are enterprise dimensions standardized across many subject areas.  They are typically enhanced (more attributes) over time as more and more subject areas use them.  As they are enhanced, every subject area using them should benefit, which will happen automatically if they remain as separate tables.

With BigQuery’s support for nested and repeating structures, we could have physically modeled this as a single nested table at the reservation grain, with nested structures for reservation item, room booking, booking detail and booking amount.  Essentially, you are just implementing your operational model as a single nested table and you will end up with nesting within nesting due to the relational nature of the original data model.   For this type of data, we find this nested/repeating structure more difficult to use for the business end user, and less compatible with many legacy BI tools implemented in your enterprise.  While we certainly implement BigQuery’s support for nested and repeating structures for other types of data structures (for example unstructured or XML based), in a Teradata conversion scenario, the dominant source data structures will be relational.   Therefore, we like the use the star schema fact table based approach.

⇒ Wrap-up, what’s next

In this third article of the series, we explored the details of how to design your data warehouse for Google Cloud BigQuery.  Starting with a semantic logical model, we discussed logical data modeling techniques using a star schema.  We then discussed how to apply a consistent set of physical modeling rules to the star schema in order to create a well performing physical schema for BigQuery.   Finally, we used a specific subject area example (travel reservations) to further explain the techniques we use.   

In the next (fourth) article of the series, we will start to discuss the data integration approaches that will be necessary to load the actual data warehouse.  We will focus introduce the staging area and the typical data integration use cases that require it.

Article 2: Source Data Capture

This is the second in a series of articles, collaboratively written by data and solution architects at Myers-Holum, Inc., PRA Health Sciences, and Google, describing an architectural framework for conversions of data warehouses from Teradata to the Google Cloud Platform.  The series will explore common architectural patterns for Teradata data warehouses and outline best-practice guidelines for porting these patterns to the GCP toolset.

David Chu, Knute Holum and Darius Kemeklis, Myers-Holum, Inc.

Michael Trolier, Ph.D., PRA Health Sciences

July 2018

Table of Contents

Capture versus land

Capture is a formal contract with the source system

Nuances of landing data

Checklist for evaluating your source data capture processes

ETL is still the most robust and platform portable tool for implementing your source data capture processes

Implementing the Landing Zone on Google Cloud Platform

Sample scenarios for Landing Zone implementations

⇒ Wrap-up, what’s next

Recap:  In the first article of this series, Article 1: Understanding Your Current Data Warehouse, we discussed source data capture as the first architectural layer of most data warehouses.  We categorized the three types of source capture processes (pull, push or stream) and the typical Teradata implementation strategies for landing the data into the data warehouse for each type of process.

We recommended conversion rather than re-implementation of your current source data capture processes as a very important aid to facilitate side-by-side validation of your converted data warehouse.   We also recommended the creation of a unified landing model, as an architectural component we called the “Landing Zone”.  All source data capture activities target the Landing Zone with associated control processes managing the accessibility and lifespan of those slices of captured data.

In this article, we will discuss detailed requirements you should consider in your implementation of the Landing Zone.  An understanding of these requirements will facilitate your decisions on whether existing Teradata source data capture processes can truly be converted.

Conversion versus Re-implementation:  As you read this article, we are going to differentiate between approaches for converting your data warehouse from Teradata to the Google Cloud Platform versus re-implementing your data warehouse in Google Cloud Platform.  Arbitrarily, we are going to assume certain differences between the two approaches.   The conversion project will be assumed as justified based on an expense reduction/capital spend avoidance ROI model, and therefore the cost of the conversion must be constrained to fit within this cost reduction model.   We would also expect the implementation timeline to be oriented toward a single deliverable, and timed such that the next Teradata infrastructure upgrade can be avoided.  

On the other hand, the re-implementation project will be assumed as justified based on a business benefit model, with implementation (capital) costs factored into the internal rate of return for the project.  We would also expect the implementation timeline to be phased into multiple deliverables based on the order of business initiatives you want to undertake.    

Capture versus land

Your existing Teradata implementation first captures data from various sources of record, then lands the data either in some form of staging (flat files, relational tables or XML formats) or loads it directly to your data warehouse.   Let’s discuss the capture and land processes separately.    

Capture is a formal contract with the source system

This is important to remember.  We doubt your original data warehouse implementers had rights to access any source data of their choosing without regard to operational system impact, data security constraints, or IT infrastructure considerations.  They worked out a “contract” with the stakeholders of that source data repository, within which the source capture process operates today.   

So in the analysis to determine the extent you can convert your existing source capture processes, it is important to separate the analysis of how well the contract meets the business need, from how well the actual source capture process is implemented.  Over time you may have created a variety of methods in which you implemented the actual source capture (BTEQ to TPT to ETL).  Clearly, you can define scope within your conversion process to standardize the implementation method without impacting the underlying contract it operates within.   Saying this in another way, you may consider the modernization of your source capture processes while striving to deliver the same dataset as before.     

It is when you decide the contract no longer meets the business need that you cross from conversion to re-implementation.  If the majority of source data contracts no longer meet the business need, then you should be able to quantify those business requirements to justify the additional cost of a re-implementation, especially considering that source data capture changes will make automating side by side testing against the existing Teradata data warehouse much more difficult.

Nuances of landing data

All relational databases, Teradata included, enforce data integrity through the use of pre-defined schemas and data definitions that include type, length, and nullability.  Therefore, there is always a data quality component to landing captured source data into a relational database.   Specific functionality may be added to your source data capture processes to handle source data that does not meet these minimal requirements.  Below are some examples of how you may be handling this:

  • ETL (Informatica PowerCenter) – Generates a flat file store (BAD files) of any source records rejected by the target.  
  • Teradata Utilities – Populate error tables if any source records are rejected because of source format, data conversion, or constraint violations.

So in the analysis to determine the extent you can convert your existing source capture processes, it is important to determine which of those processes are depending on BAD files or error tables, either to stop the capture process entirely, or provide a mechanism to analyze and potentially correct and recycle the bad source data.   Knowing which source capture processes rely on the data integrity provided by the relational database is needed to best understand which Google Cloud Platform product can supply similar capabilities.

Checklist for evaluating your source data capture processes

You can use the following checklist to help evaluate the extent that conversion rather than re-implementation of your current source data capture processes will be possible:

  • Are the majority of your source data contracts meeting business needs?  If not, are the new business needs quantifiable and able to justify a re-implementation approach?
  • How have the various source data capture processes been implemented?   For example, via ETL or BTEQ scripts or via an external scripting tool (shell, perl)
    • Do you have a few standardized implementation patterns or are they all source specific implementations?
    • How portable are each of the implementations assuming Teradata was removed?
      • ETL would be very portable, especially if the ETL tool (PowerCenter, Talend, etc.) directly integrates with Google Cloud Platform.
      • External scripting that implements all the control flow and merely calls out to a Teradata utility to execute specific SQL commands would be fairly portable, assuming you implement the equivalent utility in the specific Google Cloud Platform product.  
      • Teradata specific scripting especially when the control flow is embedded within that script or when Teradata specific features are used (INMOD) would not be very portable.
      • Note that there are several metadata analysis tools that will greatly help with this assessment (Manta Tools).
  • Which of the various source data process capture processes have downstream data quality requirements?
    • Requirement to meet data type, format, and nullability standards.
    • Requirement to standardize data (“CA”, “CALIF”, “California” all become “CA” )
    • Requirement to cleanse data (“102 Main” becomes “102 E. Main St.”)
    • Requirement for a less formal schema (hyper-changing source formats)
  • Which of the various source data process capture have integrated balance and control processes?
    • Source capture process also captures control totals (counts, sum checks) about the capture itself.
    • These control totals are then used by independent processes to validate completeness of all data movement.
  • To what extent have your source data process captured lineage metadata?
    • How pervasive is the use of this metadata within your organization?

ETL is still the most robust and platform portable tool for implementing your source data capture processes

The more you have used ETL to implement your existing source data capture processes for loading your Teradata data warehouse, the easier your conversion will be.   If you have Teradata specific source data load processes you need to modernize, you should consider re-implementing them in ETL.

  • ETL can efficiently access both your on premise source systems as well as cloud sources (Salesforce, Google Analytics).
  • ETL can source data using a variety of access methods (SQL query, database log, message queue, or application API) in both batch and real-time.
  • ETL provides source to target lineage metadata.
  • ETL vendors now have both on premise as well as cloud versions of their toolsets.

It is important to note the above comment applies to the source data capture processes only in a conversion type project.  In a future article, we will discuss ETL in comparison to other approaches like Google Cloud Dataproc or Cloud Dataflow.

Implementing the Landing Zone on Google Cloud Platform

Logical Design

First, let’s show the logical design for the Landing Zone.  This is the portion that reflects the final target (persisted data) of the source data capture process.  This is the component that will be implemented in Google Cloud Platform.

Within the above diagram:

  • Landing Zone – Represents instantiated data located in one or more Google Cloud products.  
  • Snapshots – Represents a specific set of captured source data (finite window).  
  • Run Control – An entity of the Balance and Control schema that records the start of a run to capture data from one or more source systems.
  • Process History – An entity of the Balance and Control schema that records the status of the attempt to capture source data.
  • Balance and Control - An entity of the Balance and Control schema that records the control totals (counts, sum checks) applicable to a specific capture of source data, plus the state of its independent validation.

Implementation Design

Now let’s discuss the key rules for implementing the Landing Zone as the final target in your source data capture processes:

  • What the snapshot represents:
    • For additive only based sources, the snapshot reflects a specific timestamp or aggregate within a time window.
    • For delta sources, the snapshot reflects all changes (CRUD) for a specific timeframe.  Note that the merge of changed data coming from sources with the old state of data does not occur during the landing process.
    • For full replace sources, the snapshot reflects a full set of source data as of the specific extract timestamp.  Like with delta sources, comparison of the latest source data with the previous version does not occur during the landing process.
  • Use minimal transformations:
    • The Landing Zone should represent raw source data as much as possible, as it is the recovery point for when transformation errors occur.
    • Only transformations needed to support data type, format and nullability constraints are needed.
    • Data quality standardization and cleansing is not performed here, it is performed after the original source data is captured (in a later architectural layer).
  • Only an insert path is implemented, data in the Landing Zone is never updated or deleted except in special circumstances (like a data repair scenario)
  • The Landing Zone is the final target, but you can still utilize local intermediate targets.  For example, you may have IT security constraints that dictate how PII data has to be specifically encrypted and copied to Cloud Storage.  

Other Implementation Considerations

  • As you plan for the implementation of your Landing Zone, you should consider if you have the following requirements:
    • Partitioning the Landing Zone – Snapshots of source data contained in the Landing Zone typically reflect an interval of time, with most subsequent access to Landing Zone data qualified to a specific range of time.  Therefore, it is very common to implement a date based range partitioning scheme (like a Teradata PPI).
    • Archiving and removing snapshots of data – Along with partitioning, consider your requirements for archiving and purging data in the Landing Zone.  Typically, you want to define an SLA for how long snapshots are retained.  The primary reason for retaining data in the Landing Zone, once it is processed into the data warehouse, is to ensure the raw data is still available if any downstream processing errors occurred.  As end users actually use the data warehouse, the risk of discovering undetected transformation errors diminishes over time.  It is a common practice to retain the original snapshots for around 90 days, after which it is archived or data is purged.  Consider Google Cloud Platform technologies that support partition level operations (like Teradata DROP RANGE) to avoid the cost of purging data row by row.    
    • Join Support – Google Cloud BigQuery is the Google recommended technology for implementing your data warehouse.   Depending on how you design your data model, you may find multiple source tables need to be joined together and loaded in BigQuery as a single data stream (multi-source/single target).  For example, in your logical data model you have ORDER_HEADER, ORDER_ITEM and ORDER_DETAIL entities, but you de-normalize it in BigQuery to a single ORDER entity using nested fields.  In this case, you likely need to join multiple source tables to load the ORDER entity.  In a future article we will discuss BigQuery de-normalization trade-offs, but be aware of the Landing Zone impact for now.      
    • Data Lake Support – As a repository for raw source data, the Landing Zone can be a component of your Data Lake architecture.   As you look at which specific Google Cloud products you want to use to implement the Landing Zone, consider that products ability support your data mining needs.   

Physical Design

Now that you captured the source data and know how to move it to Google Cloud (ETL is still the most robust and platform portable tool), the next question is where exactly to actually store this data.  The Landing Zone can be instantiated in one or more Google Cloud products.  Typical requirements that help identify which Google Cloud product to use are:

  • Is the data structured or unstructured?
  • Is there a need to support hyper-changing source data formats / schema?
  • Is there a need for strong data typing, data formatting, and nullability constraints?
  • Is there support for SQL joins or does the API support efficient child record lookups?
  • Can the Google Cloud product easily archive or remove captured source data after a period of time?
  • Is the Google Cloud product compatible with your desired ETL/ELT toolsets?
  • Is the Google Cloud product compatible with your desired data mining tools?
  • Is the Google Cloud product serverless no-ops or does it require you to manage nodes?

Google provides a high-level overview of the Google Cloud storage options on this page.  Let’s review in more detail various requirements and how they map to Google Cloud Storage and Database technologies as they apply to the Landing Zone.  

Product Storage Type Unstructured and Structured Data Hyper-changing Source Formats / Schema Strong Typing, Formatting, Nullability SQL Joins Archival or Purging Supported as a Data Mining Source (Data Lake) Infrastructure Maintenance Effort
Cloud Storage Just Files

Structured /

Unstructured

Yes

simple files

No

Not Natively

(1)

Yes

Yes

from BQ,

not as fast as BQ

None
CloudSQL

Relational store

hosted MySQL and Postgres

Structured Manual alter table Yes Yes Manual Yes Medium
Spanner

Relational store

with interleaved child tables

Structured Manual alter table Yes Yes Manual Limited Small(2)
BigQuery Columnar store with repeated nested structs

Structured /

Unstructured

Yes

autodetect schema

Yes Yes

Yes

time- partitioned tables

Yes None
BigTable NoSQL wide table (many columns)

Semistructured

Name/Value Pairs

Yes

add more columns

No

Not Natively

(1)

Yes

Yes

from BQ,

not as fast as BQ

Small(2)
Datastore Object store with name/value pair attributes Structured

Yes

add more attributes

No No Manual Limited None
  1. “Not Natively” indicates that it can support SQL joins through federated BigQuery capabilities
  2. “Small” indicates the need to scale up virtual nodes when capacity is exceeded.

Structured and unstructured data

Unstructured data formats that might be loaded into the Landing Zone are JSON, XML, log/text files, or binary formats (images, videos).  Cloud Storage is just a file store, so any type of data can be stored and it likely is the best option for storing truly unstructured data.  Cloud Spanner also has capabilities to load binary data into columns.  Cloud BigQuery has capabilities to load json files into a column to be later processed by using either regex or XPath expressions.  It is important to realize you want the unstructured data to be landed (as raw data), not parsed or interpreted into a different format.       

Hyper-changing source data formats

Sometimes source data systems change their data format very frequently.  As an example, consider a web application log file where new data elements are frequently added (or removed) as application functionality is changed.  In this situation, it is a maintenance burden to have to make a schema change every time the underlying source data format changes.  Cloud Storage is just a file store; it is agnostic to the file format being stored. Cloud BigQuery has the capability to adjust table format on the fly based on the new fields appearing in the data extracts.  Cloud BigTable can accommodate a virtually unlimited number of columns, does not require predefined schema before writing, and can accommodate changing data formats easily.   However, Cloud Spanner and Cloud SQL require implicit DDL execution on existing tables to accommodate new data formats.  

Strong data typing, data formatting, and nullability constraints

Cloud Spanner and Cloud SQL have pre-defined schemas with strong data types.  Cloud BigTable uses key/value pairs with no support for data typing.  Cloud BigQuery supports either explicit data typing where table schema is predefined up front, or implicit data typing where it relies on the source format for supplying the data type.  

Join support (multi-source/single)

Cloud Spanner, Cloud SQL and Cloud BigQuery support all the typical ANSI SQL join types (inner, outer).  Cloud BigTable does not support joins, you would have to combine multiple sources using the API or using ETL look-ups.   Cloud Storage is just a file store so no joins are supported unless data retrieval is federated through Cloud BigQuery.  Note that there are certain performance implications on performing join operations on massive tables that can be improved through schema design.

Archival or remove captured source data after a period of time

Cloud Storage has lifecycle configuration capabilities to move data from Nearline to Coldline storage to reduce storage fees, or files can be deleted altogether by a custom process.  Cloud BigQuery table partitions, if not accessed after 90 days, will result in reduced storage fees, or can be dropped altogether by a custom process.  Data archiving and purging can be easily scripted using command line tools to either delete Cloud Storage folders, or Cloud BigQuery table partitions from a specific date range.  Cloud BigTable tables and column families can have TTL (time to live) semantics configured to store values for a specific amount of time only after which those values are automatically purged opportunistically by the background process.  Cloud Spanner and Cloud SQL have row delete syntax that can be executed for a subset of rows to be deleted.  Remember to favor the technologies that support archive or remove at the most effective Google Cloud pricing model.

Compatibility with desired ETL/ELT toolsets

You need to consider which Google Cloud Storage technologies are supported by the toolsets you plan to utilize to implement your data load processes, initially as a target and subsequently as a source to transform and load your data into your Cloud BigQuery data warehouse.   

In the Teradata conversion scenario, we have already recommended ETL as the most robust approach for implementing source data capture.  But as we move on to loading your Cloud BigQuery data warehouse, the good news is that there is a wide variety of both Google and third-party toolsets, and both ETL and ELT style processing can be used.  Make sure your desired ETL and/or ELT toolset, such as Informatica, Talend, Snaplogic, Cloud DataFlow, supports your Landing Zone as a source and Cloud BigQuery as a target.  In a future article we will discuss ETL/ELT in comparison to other approaches like Cloud Dataproc or Cloud Dataflow.    

Compatibility with desired data mining tools

If you plan on using the Landing Zone as a component of your data lake, consider the ability of the underlying Google Cloud storage product to support your data mining toolsets.  

Google DataPrep, Google DataStudio, and Google Datalab provide robust mining capabilities and can connect to all Google Cloud storage products.   

Cloud BigQuery can directly access Cloud BigTable and Cloud Storage to allow a federated query of data in the Landing Zone with your data warehouse in Cloud BigQuery.  This is a frequent data mining need.

Numerous third party products such as Looker, iCharts, Tableau provide various degrees of connectivity to various Google Cloud storage products and are evolving rapidly through 2017.

Requirement to manage nodes

In a Teradata conversion scenario, the ability to migrate from a managed MPP to a serverless environment may be a significant factor in your conversion ROI, at least for the data warehouse.   If the requirement also applies to the Landing Zone, then consider that Cloud Storage and Cloud BigQuery are completely server-less no-ops environments.  There are no compute instances or nodes to manage and they are “hands-off” scalable.  Cloud BigTable and Cloud Spanner require you to manage number of virtual nodes (note: these are NOT virtual machines/compute instances).  Node scaling can be automated, but still requires an explicit effort to monitor and execute resizing when needed.  Cloud SQL has higher infrastructure management needs as you are managing an instance of either MySQL or PostgreSQL, just in the Google Cloud.

Sample scenarios for Landing Zone implementations

Now that we explored various conversion related requirements for the Cloud storage products and reviewed various Google Cloud product capabilities in this regard, let’s look at two specific examples.

Examples Existing Landing Zone Sourcing Technology Landing Zone Storage Recommendations

Relational databases, flat files - first landed into Teradata landing tables through ETL/ELT.

Unstructured data (web logs).   The unstructured data is landed first to HDFS. Then landed into Teradata landing tables through ETL/ELT.

ETL Cloud Storage, Cloud BigQuery, Cloud Spanner, Cloud SQL, Cloud BigTable

Relational databases, flat files - the shell scripts connect to the source database and issue SQL commands to extract the required data and generate flat files.  All source data is ultimately written to flat files in a variety of formats.  The shell scripts then call either the MultiLoad or TPT utility to load the data into landing tables..

Unstructured data (web logs).   The unstructured data is landed first to HDFS. Then landed into Teradata landing tables through Teradata data load utilities.

Teradata Utilities, Shell Scripting and Scheduler Cloud Storage

⇒ Wrap-up, what’s next

In this second article of the series we explored the details of implementing the Landing Zone:

  • How to evaluate your existing source data capture processes
    • Can they really be converted?
  • What is the logical design of the Landing Zone
  • What are the considerations for deciding how to implement the Landing Zone in Google Cloud

In the next (third) article of the series, we will start to discuss the data warehouse layer in the reference architecture.  We will focus on the some of the early data modeling decisions you will need to make, as well as use cases that will require a staging area prior to loading the actual data warehouse.