The Home Depot (THD) is the world’s largest home-improvement chain, growing to more than 2,200 stores and 700,000 products in four decades. Much of that success was driven through the analysis of data. This included developing sales forecasts, replenishing inventory through the supply chain network, and providing timely performance scorecards.

However, to compete in today’s business world, THD has taken this data-driven approach to an entirely new level of success on Google Cloud, providing capabilities not practical on legacy technologies.

The pressures of contemporary growth that drove much of the work are familiar to many businesses. In addition to everything it was doing, THD needed to better integrate the complexities in its related businesses, like tool rental and home services. It needed to better empower teams, including a fast-growing data analysis staff and store associates with mobile computing devices. It wanted to better use online commerce and artificial intelligence to meet customer needs, while maintaining better security.

Even before addressing these new challenges, THD’s existing on-premises data warehouse was under stress as more data was required for analytics and data analysts were utilizing the data with increasingly complex use cases. This drove rapid growth of the data warehouse, but also created constant challenges for the team in managing priorities, performance, and cost.

In order to add capacity to the environment, it was a major planning, architecture, and testing effort. In one case, adding on-premises capacity took six months of planning and a three-day service outage. Within a year, capacity was again scarce, impacting performance and ability to execute all the reporting and analytics workloads required. The capacity refresh cycles were shrinking, and the expecations for data were growing. There had to be a better way.

Still, THD did not take its move to the cloud lightly. A large-scale enterprise data warehouse migration involves tremendous effort among people, process, and technology. After careful consideration, THD chose Google Cloud’s BigQuery for its cloud enterprise data warehouse.

BigQuery, a scalable serverless data warehouse, was better on cost, infrastructure agility, and analytics capability, driving better insights with improved performance. There are no service interruptions when capacity is added, and that capacity can be added within a week (and soon same day). It doesn’t require complex system administration, and its standard SQL support means people can easily ramp up quickly. Valuable BigQuery products like Identity and Access Management meant THD could create many separate Google Cloud projects, while ensuring that different teams weren’t interfering with each other or accessing protected data.

THD also utilizes BigQuery’s flat-rate monthly pricing model that allows teams to budget their capacity based on need and provides billing predictability. The capacity not being used by a given project is available for enterprise use. This ensures no surprises when the monthly bill arrives and provides all analytical users access to significant computing power.

While THD’s legacy data warehouse contained 450 terabytes of data, the BigQuery enterprise data warehouse has over 15 petabytes. That means better decision-making by utilizing new datasets like website clickstream data and by analyzing additional years of data.

As for performance, look at this chart:

With the cloud EDW migration complete, and the legacy on-premises data warehouse retired, analysts now execute more complex and demanding workloads that they would not have been able to complete before, such as utilizing Datalab for orchestrating analytics through Python Notebooks, utilizing BigQuery ML for machine learning directly against the BigQuery data (no movement of large datasets), and AutoML to help determine the best model for predictions.

Additionally, engineers at THD have adapted BigQuery to monitor, analyze, and act on application performance data across all its stores and warehouses in real time, something that was not practical in the on-premises system.

With over 600 projects that THD now has on Google Cloud, the BigQuery story is just one of the many ways that Google Cloud is working with THD to deliver meaningful business results, every day.

Weather forecasting and climate modeling are two of the world’s most computationally complex and demanding tasks. Further, they’re extremely time-sensitive and in high demand — everyone from weekend travelers to large-scale industrial farming operators wants up-to-date weather predictions. To provide timely and meaningful predictions, weather forecasters usually rely on high performance computing (HPC) clusters hosted in an on-premises data center. These on-prem HPC systems require significant capital investment and have high long-term operational costs. They consume a lot of electricity, have largely fixed configurations, and the underlying computer hardware is replaced infrequently.

Using the cloud instead offers increased flexibility, constantly refreshed hardware, high reliability, geo-distributed compute and networking, and a “pay for what you use” pricing model. Ultimately, cloud computing allows forecasters and climate modelers to provide timely and accurate results on a flexible platform using the latest hardware and software systems, in a cost effective manner. This is a big shift compared with traditional approaches to weather forecasting, and can appear challenging. To help, weather forecasters can now run the Weather Research and Forecasting (WRF) modeling system easily on Google Cloud using the new WRF VM image from Fluid Numerics, and achieve the performance of an on-premises supercomputer for a fraction of the price. With this solution, weather forecasters can get a WRF simulation up and running on Google Cloud in less than an hour!

A closer look at WRF
Weather Research and Forecasting (WRF) is a popular open-source numerical weather prediction modeling system used by both researchers and operational organizations. While WRF is primarily used for weather and climate simulation, teams have extended it to support interactions with chemistry, forest fire modeling, and other use cases. WRF development began in the late 1990s through a collaboration between the National Center for Atmospheric Research (NCAR), National Oceanic and Atmospheric Administration (NOAA), U.S. Air Force, Naval Research Laboratory, University of Oklahoma, and the Federal Aviation Administration. The WRF community comprises more than 48,000 users spanning over 160 countries, with the shared goal of supporting atmospheric research and operational forecasting.

The Google Cloud WRF image is built using Google’s MPI best practices for HPC, with the exception that hyperthreading is not disabled by default, and is easily integrated with other HPC solutions on Google Cloud, including SchedMD’s Slurm-GCP. Normally, installing WRF and its dependencies is a time consuming process. With these new WRF VM images, deploying a scalable HPC cluster with WRF v4.2 pre-installed is quick and easy with our Codelab. OpenMPI 4.0.2 was used throughout this work. Google has had good success with Intel MPI, and we intend to study whether further performance gains can be achieved in this context.

Optimizing WRF

Determining the optimal architecture and build settings for performance and cost was a key part of the process in developing the WRF images. We evaluated how to select the ideal compiler, right CPU platform, and the best file system for handling file IO, so you don’t have to. As a test case for assessing performance, we used the CONUS 2.5km benchmark.

Below, the CONUS 2.5km runtime and cost figure shows the run time required for simulating WRF over a two-hour forecast using 480 MPI ranks (a way of numbering processes) for different machine types available on Google Cloud. For each machine type, we’re showing the lowest measured run time from a suite of tests that varied compiler, compiler optimizations, and task affinity.

We found that compute-optimized c2 instances provided the shortest run time. The Slurm job scheduler allows you to map the MPI tasks to compute hardware using task affinity flags. When optimizing the runtime and cost for each machine type, we compared using srun –map-by core –bind-to core to launch WRF, which maps each MPI process to a physical core (two vCPU per MPI rank), and srun –map-by thread –bind-to thread, which maps each MPI process to a single vCPU. Mapping by core and binding MPI ranks to cores is akin to disabling hyperthreading.

The ideal simulation cost and runtime for CONUS 2.5km for each platform is found when each MPI rank is subscribed to each vCPU. When binding to vCPUs, half as many compute resources are needed when compared to binding to physical cores lowering the per-second cost for the simulation. For CONUS 2.5km, we also found that although mapping MPI ranks to cores results in reduced runtime for the same number of MPI ranks, the performance gains are not significant enough to outweigh the cost savings. For this reason, the WRF-GCP solution does not disable hyperthreading by default.

Runtime and simulation cost can be further reduced by selecting an ideal compiler: the figure below (CONUS 2.5km Compiler Comparisons) shows the simulation runtime for the WRF CONUS 2.5km benchmark on eight c2-standard-60 instances, using GCC 10.30, GCC 11.2.0 and the Intel® OneAPI® compilers (v2021.2.0). In all cases, WRF is built using level 3 compiler optimizations and Cascade Lake target architecture flags. By compiling WRF with the Intel® OneAPI® compilers, the WRF simulation runs about 47% faster than the GCC builds, and at about 68% of the cost, on the same hardware. We’ve used OpenMPI 4.0.2 with each of the compilers as the MPI implementation in this work. With other applications, Google has seen good performance with Intel MPI 2018, and we intend to investigate performance comparisons with this and other MPI implementations.

File IO in WRF can become a significant bottleneck as the number of MPI ranks increases. Obtaining the optimal file IO performance requires using parallel file IO in WRF and leveraging a parallel file system such as Lustre.

Below, we show the speedup in file IO activities relative to serial IO on an NFS file system. For this example, we are running the CONUS 2.5km benchmark on c2-standard-60 instances with 960 MPI ranks. By changing WRF’s file IO strategy to parallel IO, we accelerate file IO time by a factor of 60.

We further speed up IO and reduce simulation costs by using a Lustre parallel file system deployed from open-source Lustre Terraform infrastructure-as-code from Fluid Numerics. Lustre is also available with support from DDN’s EXAScaler solution in the Google Cloud Marketplace. In this case, we use four n2-standard-16 instances for the Lustre Object Storage Server (OSS) instances, each with 3TB of Local SSD. The Lustre Metadata Server (MDS) is an n2-standard-16 instance with a 1TB PD-SSD disk. After mounting the Lustre file system to the cluster, we set the Lustre stripe count to 4 so that file IO can be distributed across the four OSS instances. By switching to the Lustre file system for IO, we speed up file IO by an additional factor of 193, which is orders of magnitude faster than a single NFS server with serial IO.

Adding compute resources and increasing the number of MPI ranks reduces the simulation run time. Ideally, with perfect linear scaling, doubling the number of MPI ranks would cut the simulation time in half. However, adding MPI ranks also increases communication overhead, which can increase the cost per simulation. The communication overhead is due to the increased amount of communication necessitated by splitting the problem more finely across more machines.

To assess the scalability of WRF for the CONUS 2.5km benchmark, we can execute a series of model forecasts where we successively double the number of MPI ranks. Below, we show two- hour forecasts on the c2-standard-60 instances with the Lustre file system, varying the number of MPI ranks from 480 to 1920. In all of these runs, MPI ranks are bound to vCPUs so that the number of vCPUs dedicated to each simulation increases with the increase in MPI ranks. While many HPC workloads run best with simultaneous multithreading (SMT) disabled, we find the best performance for CONUS 2.5km with SMT enabled. Thus, the number of MPI ranks in our runs equals the total number of vCPUs.

As you can see, the CONUS 2.5km Runtime & Cost Scaling figure shows that the run time (blue bars) decreases as the number of MPI ranks and the amount of compute resources increases, at least up to 1920 ranks. When transitioning from 480 to 960 MPI ranks, the run time drops, yielding a speedup of about 1.8x. Doubling again to 1920 MPI ranks, though, we obtained an additional speedup of just 1.5x. This declining trend in the speedup with increasing MPI ranks is a signature of MPI overhead, which increases with more MPI ranks.

Determining your best fit

Most tightly-coupled MPI applications such as WRF exhibit this kind of scaling behavior, where scaling efficiency decreases with increasing MPI ranks. This makes assessing cost-scaling alongside performance-scaling critical when considering Total Cost of Ownership (TCO). Thankfully, per-second billing on Google Cloud makes this kind of analysis a little bit easier. As shown above, a second doubling of the count from 960 cores to 1920 cores can provide an additional 1.5x speedup, but at a 32% higher cost. In some circumstances, this faster turnaround may be needed and worth the extra cost.

If you want to get started with WRF quickly and experiment with the CONUS 2.5km benchmark, we’ve encapsulated this deployment in Terraform scripts and prepared an accompanying codelab.

You can learn more about Google Cloud’s high performance computing offerings at https://cloud.google.com/hpc, and you can find out more about Google’s partner Fluid Numerics at https://www.fluidnumerics.com.

Editor’s note: Google Cloud partner commercetools shares how modern technologies like composable commerce, cloud-native infrastructure and artificial intelligence/machine learning (AI/ML) will lead the way in business-to-business (B2B) digital commerce this year.

Digital commerce in B2B has been predicted as the next big thing for years; yet, at the start of COVID-19, 60% of B2B companies had zero or limited eCommerce capabilities. The pandemic accelerated digitization and eCommerce has finally taken off: As of February 2022, 65% of B2B companies offered eCommerce capabilities.

The behavior of B2B buyers is also changing: Consumer-like expectations are at the heart of successful B2B commerce, and this is how manufacturers, distributors and wholesalers will shape their customer experiences. Today, 73% of B2B buyers want a personalized business-to-consumer or B2C-like experience. 83% prefer ordering or paying through digital commerce and 72% are eager to purchase across channels.

With digital commerce dictating how B2Bs will grow in 2023 and beyond, what trends will spur digital transformations across this business model? Here’s what the team at commercetools expects to unfold in B2B eCommerce this year.

#1 B2B firms are switching to cloud-native, composable commerce

B2B players still plagued with manual processes and siloed backend systems will move away from monolithic platforms and choose composable commerce. In a nutshell, composability enables businesses to select best-of-breed components, such as search, cart or checkout, and “compose” them into a custom application.

B2B firms will modernize their commerce backend, interoperating siloed systems like Configure Price Quote solutions (CPQs) for sales and enterprise resource planning solutions (ERPs) for order entry with an API-first and composable commerce stack. They will also pivot from on-premise deployments to cloud-native architectures as the baseline for auto-scaling capabilities instead of pre-provisioning online capacity during traffic peaks. That way, B2Bs can customize customer-centric experiences to boost revenue while reducing the complexity and cost of in-house IT infrastructure, as well as gaining operational efficiencies

B2Bs will maximize the cross-section of composable commerce and cloud-native infrastructure by leveraging a commerce backend like commercetools Composable Commerce hosted on Google Cloud. This combined solution provides commercetools’ ready-to-use components built as microservices and exposed as APIs, such as product information management (PIM) and unified cart, integrated through the Google Cloud Marketplace.

#2 Strong focus on data quality and personalization

Focusing on data quality continues to be a big trend in 2023. B2B buyers expect product, pricing, inventory and shipping data points to be accurate across every touchpoint so they can make better purchasing decisions, such as when to order products and calculate quantities.

With so many data points to capture throughout the customer journey — product, inventory, pricing and customer data — we’ll see more B2B companies reorganizing their vast information pools to elevate customer experiences. They will pivot to modular and API-first solutions, plus flexible data models, so they can break data silos from legacy monolithic platforms and access such data when needed.

We also expect to see more customer analytics to unlock data on buyer behavior. By understanding what customers see, click and add to their shopping lists, B2B businesses get valuable insights into how buyers behave, using this data in the shopping journey according to product interests. That way, it’s possible to offer personalized experiences across touchpoints without hassle.

“It is important for B2B companies to look at their data as if it is one of their products; invest in its upkeep and integrity while finding ways to continuously improve it. Using advanced analytics powered by AI and ML to identify patterns from large amounts of data, B2B companies can activate insights into customer decision journeys to maintain loyalty, personalize experiences to improve satisfaction and boost revenue, while also finding ways to optimize costs. For example, with analytics, enterprises can streamline spend to focus on the highest-performing channels and reduce waste.” — Carrie Tharp, Google Cloud VP of Retail and Consumer

With data-driven tools coming into play like Google Cloud’s Discovery AI, Recommendations AI and Vision Product Search connected with composable commerce, B2B players can boost customer analytics to personalize experiences, improve customer satisfaction and reduce churn.

#3 The B2B customer experience will be redesigned

B2B players are taking a page out of the B2C playbook to elevate experiences throughout the customer journey. While intense work needs to happen in the backend commerce engine, B2B players will also redesign their digital frontends. That means boosting website performance, while mobile responsiveness and personalization will be at the forefront of these advanced digital initiatives.

More than ever, B2B companies are looking for digital storefronts delivered as progressive web applications (PWAs) for optimized performance and responsiveness across devices, as well as fast-loading and responsive experiences to boost your digital presence, SEO rankings and conversion rate. B2Bs can further streamline frontend development with solutions natively connecting to Google Cloud Marketplace, which supports a variety of storefront providers, including commercetools Frontend.

Leveraging Google Cloud’s unique capabilities, such as PWA web app development, Google Cloud Discovery AI solutions that include Retail Search and Vision API Product Search, among many others, B2B companies are well positioned to boost digital commerce in the years to come.

What’s next in 2023?

2022 was already a turbulent year; for better or worse, 2023 is expected to have a similar fate. For B2Bs, even the ones with tight budgets, investing in digital commerce can help future-proof businesses for whatever’s happening this year. To dive deeper into all predictions and insights by commercetools in collaboration with Google Cloud, read the guide Pivotal Trends and Predictions in B2B Digital Commerce in 2023.