Kategorie: Google Cloud Platform

Cook up your own ML recipes with AI Platform

For anyone with a sweet tooth for confections and machine learning, I have some good news. You might remember recently my colleagues, Sara Robinson and Dale Markowitz, collaborated to create some delicious new baked inventions, including the Breakie (a fusion between cake, cookies, and bread). All of this was done through a baking ML model that they built with AutoML Tables, a no-code way to create machine learning models on tabular data.Well, it wasn’t long before legendary confectionery manufacturer Mars Wrigley approached Sara and Cloud AI for a Maltesers + AI kitchen collaboration. Sara trained a new ML model to generate recipes for cookies, cakes, scones, traybakes, and any “hy-bread” of these. After hours of model training and baking experiments, Sara combined Maltesers with her model’s AI-optimized cake and cookie recipes to create a brand new dessert, which even includes the classic British ingredient, Marmite. To break it down, Sara used a few tools to build and customize her model:AI Platform Notebooks (Jupyter lab environment for feature engineering and model development) and TensorFlow AI Platform Hyperparameter Tuning(model training)AI Platform Prediction (model deployment)You can try out Sara’s AI-powered Mars recipe yourself, but if you have an appetite to build your own ML model for other creations like pizzas, pies, milkshakes, or stir-frys, let’s boil down the objectives and steps to get you started:Objective: Create a model that takes a type of dish as input, and produces the amounts of the different ingredients needed to create it.Steps:Collect the data. You’ll want to collect a sizable dataset around the dish recipes you’re interested in (various types of pizzas, baked goods, or noodles for example). You’ll want data on the amount of each ingredient that goes into the dish. So if you’re focused on pizzas, you need data on the amounts of dough, cheese, and toppings that make up each pizza type. Prepare the data. Whittle down each of those recipes to core ingredients that span the dishes. This might be a bit arbitrary but think about which ingredients affect the fundamental makeup of all dishes like texture, flavor, or consistency. In the pizza example, I’d narrow it down to only dough ingredients, cheese type, sauce, and common toppings. Preprocess the data. Make sure all ingredient amounts are in the same measurement unit (e.g., ounces or grams). You may also need to scale the model inputs so that all ingredient amounts fall within a standard range. You can use data augmentation to create new training examples. If you’re using AutoML you can skip this step, as it handles many data preparation tasks for you, but keep in mind best practicesfor creating training data. Build your model. AI Platform lets you develop, train, and deploy your model using notebooks, a built-in Data Labeling Service, and the ability to store datasets in Cloud Storage or BigQuery. You can also use AutoML Tables and import data directly from CSV files, Google Sheets, or a BigQuery database. Train your model. You can use AI Platform Hyperparameter Tuning, a service for running multiple training job trials to optimize a model’s hyperparameters. Additionally,  AutoML Tables provides automated feature engineering. With either tool, you can determine which ingredients are important predictors of each dish type, such as basil  being an important predictor of a Margherita pizza (this can be more easily done using AutoML). Deploy your model and predict. Once you have tuned your hyperparameters and trained your model, you can use AI Platform Prediction to create custom recipes (amounts of ingredients to create a dish or combo-dish). With both AI Platform and AutoML you can also discover feature importance scores (how heavily weighted ingredients are for a dish). AI-powered recipes delivered! Now before you run off to grab your apron, let me share some sweet resources to help you get started.AI resources to give you a tasteAI Platform QuickstartThis tutorial shows how to train a neural network on AI Platform using the Keras sequential API and how to serve predictions from that model. You can also run the tutorial as a notebook in Colab. You’ll learn how to:Train a model on AI Platform using prewritten Keras codeDeploy the trained model to AI PlatformServe online predictions from the deployed modelPlus learn how to dig into the training code used for this model and ensure it’s compatible with AI Platform. Even though the dataset is around US Census income, you can use the tutorial as a framework for understanding how to train, deploy, and serve models on AI Platform for cooking-inspired (or other) datasets of your choosing. Build your first AI Platform NotebookIn this tutorial, Sara walks you through tools in AI Platform Notebooks for exploring your data and prototyping ML models. You’ll learn how to: Create and customize an AI Platform Notebooks instanceTrack your notebook code with git, directly integrated into AI Platform NotebooksUse the What-If Tool within your notebookAutoML TablesI’d be remiss if I didn’t emphasize that you can also create custom ML models without code. I mentioned that when Sara and Dale teamed up to create their Breakie recipe, they used AutoML Tables, which relieves much of the heavy burden by automating feature engineering so you can easily build and deploy state-of-the-art machine learning models on structured data. The codeless interface guides you through the full end-to-end ML workflow, making it easy for anyone to build models and reliably incorporate them into broader applications. There are a ton of quickstarts, samples, and videos to help you get started on AutoML Tables. Use them to learn how to:Create a dataset and modelImport data into a datasetDeploy a modelEvaluate your modelUse AutoML Tables from a Jupyter notebookAI Adventures video playlistCheck out coverage from Yufeng Guo and Priyanka Vergadia on AI Platform. In this featured video, Yufeng covers how you can use AI Platform built-in algorithms to train and deploy machine learning models without writing any training code. Plus check out other videos in the playlist to learn about:Training models with custom containers on AI PlatformAI Platform Pipelines for improving the reliability of your ML workflowsUsing AI Prediction service to get explanations of your models and better understand their outputsMaking the most of the AI Data Labeling service on AI PlatformIf you’ve made it to this point, you’re probably getting hungry and eager to put this in action. You can explore more AI on Google Cloud, and share your recipes with Sara, Dale, and me online. We’ve tried this with baking, but we’d love to hear if you have success with models for other types of recipes! – StephanieRelated ArticleHow sweet it is: Using Cloud AI to whip up new treats with Mars MaltesersMars uses Google Cloud AI to invent a tasty new cake that includes maltesers and marmite!Read Article
Quelle: Google Cloud Platform

Google Cloud and AVEVA’s OSIsoft serve the industrial sector a new flavor of PI

Across the industrial sector, many digital enablers and disruptive technologies are transforming businesses to be more efficient, profitable, nimble, and secure: smart factories with connected machines, the rise of the industrial internet of things (IIoT), proliferation of sensors and data, and new cloud strategies, to name a few.Our work with the PI System is designed to help industrial companies modernize their data and take it beyond the operational space to Google Cloud, deriving more insights and business value. Thanks to our partnership with AMD and OSIsoft, now part of AVEVA, customers can effectively, safely, and easily deploy a fully functioning PI System to Google Cloud. Together, we assist customers along that transformational journey through the launch of GCP deployment scripts for PI Core.The PI System is the market-leading data management platform for industrial operations in essential industries such as energy, mining, oil and gas, utilities, pharmaceutical, facilities, manufacturing, and more. The PI System automatically captures sensor data from every relevant source, refines and contextualizes the data, and delivers it to a broad ecosystem of people, tools, and applications for analysis and strategic planning. It also serves as a single source of truth for consistent decision making.With the PI System, industrial companies can generate insights from their data, including:Analyzing seasonal trends  Determining if utilities are meeting the demands of production  Comparing the performance of different lots of raw material  Determining when maintenance is required on equipment  Optimizing the utilization or performance of a production line  The new deployment scripts are a natural addition to PI Integrator for Business Analytics, which integrates Google Cloud with PI Core, the on-premises portion of the PI System. PI Integrator for Business Analytics can deliver critical operational data directly to Google Cloud destinations like Cloud Storage, BigQuery, and Pub/Sub. It can also be deployed either on-prem or on Google Cloud.The solution allows customers to take time-series data from one or many of their PI Core deployments and move it onto BigQuery, Google Cloud’s enterprise data warehouse for analytics. Customers can take advantage of exabyte-scale storage and petabyte-scale SQL queries in this high-speed, in-memory BI engine, enabling cloud-based artificial intelligence (AI) and machine learning (ML) tools that provide deep insights like anomaly detection and predictive maintenance from that data.Through our partnership, PI Core-based solutions for industrial customers are further protected by Google Cloud’s robust security features, like encrypting cloud data at rest by default, that keep data safe and more secure. What’s more, PI Core is aligned with real-time mission-critical industrial applications, avoiding delays in time-sensitive process automation or discrete manufacturing processes. Serving a new slice of PI (System) on Google CloudGCP deployment scripts for PI Core are the latest achievement in our partnership. We developed these deployment scripts for PI Core on Google Cloud using Infrastructure as Code (IaC) with PowerShell and Terraform technologies. With PI Core on Google Cloud, customers can generate business insights through the power of Google Cloud’s Smart Data Platform with AI/ML combined with other contextualized data. The scripts accelerate an industrial customer’s digital transformation and support quick and iterative testing and prototyping. They’re also designed for customers who are considering moving their on-prem system to Google Cloud, or customers who would like to deploy PI Core as an aggregation system to bring diverse on-prem data from multiple PI Systems into one place.Click to enlargeThese deployment scripts automate the provision of the PI Core components running on Google Cloud N2D VM instances powered by hardware such as 2nd Gen AMD EPYC™ processors. GCP deployment scripts for PI Core include recommended practices for both platforms by delivering automation to deploy test and development environments.  The scripts are offered in non-high availability (non-HA) configuration, with an HA version providing failover capabilities for PI Core coming soon. These scripts are open-sourced, and the non-HA version is now available on Google’s GitHub.By running PI Core on Google Cloud, the industrial sector has an easy and efficient path to business insights, generating more value from their collected data in a safe and managed environment. Enabling PI Core deployment on Google Cloud through scripts is just one of the solutions that we’re building together. Stay tuned for more updates.Learn more about PI Core and the overall PI System for the industrial sector. Learn more about Google Cloud instances powered by AMD. Ready to get started with our deployment scripts? Visit the GCP deployment scripts for PI Core on our Github.Related ArticleCOVID-19 reshapes manufacturing landscape, new Google Cloud findings showAccording to our new research released today, manufacturers around the world have started to revamp their operating models and supply cha…Read Article
Quelle: Google Cloud Platform

New flexibility: Run your Dataprep jobs with BigQuery or Dataflow

Cloud Dataprep by Trifacta is Google Cloud’s intelligent data service for visually exploring, cleaning, and preparing structured and unstructured data for analytics and machine learning. Due to its serverless architecture, Dataprep does not need any infrastructure to deploy or manage, and is fully scalable.Designed and built through a partnership between Google and Trifacta – the data engineering  platform, Dataprep allows users of all skill levels to prepare data.  Dataprep has a graphical user interface so there is no need to write code to create a pipeline. Additionally, each UI input automatically predicts and suggests the next step for data transformation, making it easy and flexible for the end user. After making all desired transformations, Dataprep users can build repeatable data pipelines that can be executed at scale using the processing power of Google Cloud.Introducing Dataprep BigQuery pushdownSpeaking of processing power, today we’re excited to announce a new addition to Dataprep – BigQuery pushdown.  BigQuery pushdown gives you the flexibility to run jobs using either BigQuery or Dataflow.  If you select BigQuery  then Dataprep can automatically determine if data pipelines can be partially or fully translated in a BigQuery SQL statement.  Any portions of the pipeline that cannot be run in BigQuery are executed in Dataflow.  Utilizing the power of BigQuery results in highly efficient data transformations, especially for manipulations such as filters, joins, unions, and aggregations. Dataprep BigQuery pushdown leads to better performance, optimized costs, and increased security with IAM and OAuth support.Dataprep leverages BigQuery or Dataflow to wrangle data (click to enlarge)In today’s data focused world, the modern equivalent to ETL (Extract, Transform, Load) is ELT (Extract, Load, Transform). The ELT framework enables data savvy business users to transform data rather than relying on IT teams to both transform and load data. With ELT, technical teams can handle the logistics of moving and managing data in BigQuery, while business users can leverage the power of SQL for intermediate transformations. This reduces cycles between the technical and business teams for finalizing data transformation requirements, and reduces the burden on the technical teams. Dataprep BigQuery pushdown complements the ELT framework helping data savvy business users and the technically focused IT teams with data transformation and data preparation tasks.In summary, the new BigQuery pushdown on Dataprep enables faster data transformations, optimized costs, and increased flexibility. You can learn more about Dataprep BigQuery pushdown and get started today by trying Dataprep on the Google Cloud Marketplace.
Quelle: Google Cloud Platform

Creating a serverless pipeline for real-time market data

Editor’s note: This is the second part in our special series on working with market data in Google Cloud. This post highlights how we leveraged serverless components to build a flexible data ingestion pipeline. Check out the first post on visualizing real-time market data in the cloud.Capital markets firms must rapidly extract insights from unbounded real-time datasets. A firm’s market data pipelines should weigh the end user’s data access requirements as a central design consideration, but oftentimes the rigidity of delivery mechanisms and analytical tools block this goal. Serverless data offerings can solve this problem by removing operational friction when introducing a new, well-suited tool. This makes it simple for one data pipeline to serve separate user goals—say, one for training a real-time machine learning model and another for analyzing historical data. With a serverless data pipeline, capital markets firms can focus on insights, not infrastructure, and stay ahead in a fast-moving industry. In this post, you’ll see best practices for real-time data ingestion using CME Group’s Smart Stream top-of-book (ToB) JSON feed. The reference architecture considers data usage patterns and schema when selecting storage and transport options. It also encapsulates business logic in Cloud Functions to increase the speed of development and to offload operational complexities. These patterns and designs can be applied to a wide variety of use cases.Figure 1 depicts the ingestion pipeline’s reference architecture.Figure 1: Reference architectureHow we set up real-time data ingestionThe source of the real-time data we used is Smart Stream, a service available on Google Cloud from CME Group. The data originates with the CME Globex trading platform as a multicast stream running over UDP. The instrument price data is forwarded over an interconnect to different Pub/Sub topics, each corresponding to a single product, like silver or orange juice concentrate futures.Pub/Sub is serverless and tightly integrated with other Google Cloud services. It’s also fully managed by Google, alleviating users from many scaling, planning, and reliability concerns. Google provides open-source Dataflow templates to ingest data from Pub/Sub to various sinks such as BigQuery and Cloud Storage. Bigtable was leveraged as a real-time data store, serving most recent data and features to a prediction endpoint. (The endpoint passes this data to machine learning models hosted on Google Cloud’s AI Platform). In parallel, we use BigQuery as a scalable analytics warehouse. Pub/Sub data was streamed to both sinks with separate Dataflow jobs.Figure 2 is a shell snippet launches a Dataflow job with a Google-provided template for PubSub-to-BigQuery pipelines:Figure 2: Launching a Dataflow template to ingest messages from Pub/Sub to BigQueryFigure 3 depicts a Dataflow pipeline with three input Pub/Sub topics (one per trading instrument) and Bigtable as a sink:Figure 3: Dataflow job graphThe class in Figure 4 defines an Apache Beam pipeline to ingest data from a single topic (i.e., product code) and write to Bigtable:Figure 4: Apache Beam ingestion pipeline to BigtableAt first glance, the app’s predictive models and web front-end charts are similar in their demand for data freshness. On further inspection, however, a difference emerges—the charts can use the Smart Stream price data directly without an intervening data store. So for front-end delivery, we settled on Pub/Sub via websockets.Using Pub/Sub with serverless ingestion components offered architectural flexibility and removed operational complexity as a constraint. Data coming from one Pub/Sub topic can be stored in Bigtable for machine learning or in BigQuery for analytics, in addition to being sent directly over websockets to power rapidly changing visualizations.Storage and schema considerationsIdeally, the time spent managing data is minimal compared to the time spent using data. If schema design and storage architecture is executed properly, users will feel that the data is working for them, rather than them working for the data.Row key design is critical to any Bigtable pipeline. Our key concatenates a product symbol with a reverse timestamp, which is optimized for our access pattern (“fetch N most recent records”) while avoiding hotspotting. In order to reverse the timestamp, we subtract it from the programming language’s maximum value for long integers (such as Java’s java.lang.Long.MAX_VALUE). This forms the key: <SYMBOL>#<INVERTED_TIMESTAMP>. A product code’s most recent events appear at the start of the table, speeding up the query response time. This approach accommodates our primary access pattern (which queries multiple recent product symbols)—but may yield poor performance for others. A post on Bigtable schema design for time series data has additional concepts, patterns and examples.Figure 5 shows a sample data point ingested into Bigtable:Figure 5: Representation of a market data record within BigtableWhile Bigtable is well-suited to deliver low-latency data to machine learning models, we also needed a more analytically tuned query engine for longer-lookback insights. BigQuery was a natural fit because of its serverless and scalable nature, as well as its integration with tools such as AutoML. When designing, we considered three options for preparing the BigQuery data for visualization as classic OHLC “candlesticks.” First, we could store the nested Pub/Sub JSON into BigQuery and write a complex SQL query to unnest and aggregate. Second, we could write a view that unnests, and then write a simpler SQL query that aggregates (without unnesting). Third, we could develop and run a Dataflow job to unnest Pub/Sub records into a “flat” format for storage in BigQuery, and could then aggregate with a simple SQL query. Though the third option may represent a superior design longer term, time constraints steered us towards the second option. The BigQuery view was simple to set up, and the team got productive quickly when querying against the flattened schema. Thanks to a DATE partition filter, the SQL view definition scans only the most recent day from the underlying table storing the quotes. This dramatically improves performance of the queries against the view.   A sample of the data transformation and views for this specific chart using the second methodology are shown in Figures 6 and 7.Figure 6: SQL view definition to flatten original source recordsFigure 7: SQL view definition that generates OHLC bars (“candlesticks”)Because both Bigtable and BigQuery are serverless, the maintenance of each storage solution is minimal, and more time can be spent deriving and delivering value from the data, rather than capacity planning around procurement of storage arrays and operational complexities.Market data microservicesCloud Functions offer developers two primary benefits. First, they provide the ability to bypass non-differentiating low-level implementation details in favor of business-specific code. Second, they support flexible use of data by encapsulating business logic outside of the database. In our pipeline, we accordingly used Cloud Functions for isolated, task-specific code chunks. One example is our pipeline’s Fetch Predictionfunction, which retrieves trade records from Bigtable and extracts first-order features (mean, sum, max, etc) for input to the machine learning model. This enables rapid predictions that are used by the bots to make algorithmic trading decisions in near real-time. This is demonstrated in Figure 8.Figure 8: Python routine to fetch predictions at runtimeFetch Candles is a Cloud Function that fetches a recent price summary from BigQuery detailing the opening, closing, highest and lowest price observed for each minute. To improve the request-response performance, we enabled HTTP(s) load balancing with a serverless network endpoint group for our app, and then optimized delivery with Cloud CDN. Configured this way, Fetch Candles will query BigQuery only for the first request for a given minute and product code. Subsequent requests will be delivered from the Cloud CDN cache, until the maximum cache TTL of one minute is reached. This can significantly reduce the overall volume of query executions as web client traffic scales up. Since the data is in a lookback window, there’s no functional necessity for BigQuery to calculate the aggregates more than once per individual duration.Figure 9: OHLC “candlestick” chart visualizationBy enabling a microservices architecture, Cloud Functions allowed each developer to develop in their preferred language, and to develop, test, and debug individual functions in isolation.Figure 10 shows an inventory of the principal functions used in our market data pipelines.Figure 10: Sample inventory of Cloud FunctionsMany of these functions provide input to a machine learning model, while others fetch data from  BigQuery for visualizations of trader performance in a real-time Profit/Loss ledger.ConclusionA data pipeline built from serverless components allows capital markets firms to focus on developing valuable insights and offerings, and not on managing infrastructure. In a serverless environment, the end users’ data access patterns can strongly influence the data pipeline architecture and schema design. This, in conjunction with a microservices architecture, minimizes code complexity and reduced coupling. As organizations continue to add data sources and information tools to their operations, using serverless computing models enable them to focus on value-added tasks of using data to make better decisions.Learn more about Google Cloud for financial services.Related ArticleNew white paper: Strengthening operational resilience in financial services by migrating to Google CloudLearn how migrating to Google Cloud can play a critical role in strengthening operational resilience in the financial services sector.Read Article
Quelle: Google Cloud Platform

Introducing request priorities for Cloud Spanner APIs

Today we’re happy to announce that you can now specify request priorities for some Cloud Spanner APIs. By assigning a HIGH, MEDIUM, or LOW priority to a specific request, you can now convey the relative importance of workloads, to better align resource usage with performance objectives. Internally, Cloud Spanner uses priorities to differentiate which workloads to schedule first in situations where many tasks contend for limited resources.Customers can take advantage of this feature if they are running mixed workloads on their Cloud Spanner instances. For example, if you want to run an analytical workload while processing DML statements, and you are okay with your analytical workload taking longer to run. In that case, you’d run your analytical queries at a LOW priority, signaling to Spanner that it can reorder more urgent work ahead if it needs to make tradeoffs.When there are ample resources available, all requests, regardless of priority, will be served promptly. Given two requests, one with HIGH priority and the other with LOW priority, but otherwise identical, there will not be noticeable differences in latency between the two when there is no resource contention. As a distributed system, Spanner is designed to run multiple tasks in parallel, regardless of their priority. However, in situations where there aren’t enough resources to go around, such as a sudden burst of traffic or a large batch process, the scheduler will try to run high-priority tasks first. This means that lower priority tasks may take longer than in a similar system that wasn’t resource constrained. It is important to note that priorities are a hint to the scheduler rather than a guarantee. There are situations where a lower priority request will be served ahead of a higher priority request, or example, when a lower priority request is holding a transaction lock that a higher priority request needs access to.Using Request PrioritiesThe Priority parameter is part of a new optional RequestOptions you can specify in the following APIs:ReadStreamingReadExecuteSqlExecuteStreamingSqlCommitExecuteBatchDmlYou can access this newly added parameter if you are directly issuing requests to our RPC API, REST APIor via the Java or Go Client libraries, with the rest of the client libraries implementing support for this parameter soon.The following sample code demonstrates how to specify the priority of a Read request using the Java Client LibraryQueryOption queryOption = new PriorityOption(RpcPriority.LOW);ResultSet resultSet = dbClient.singleUse().executeQuery(Statement.of(“SELECT * FROM TABLE”), queryOption);Note: Even though you can specify a priority for each request, it is recommended that requests that are part of the same transaction all have the same priority. MonitoringCloud Console reflects these new priorities in the CPU utilization, grouping metrics into HIGH and LOW/MEDIUM buckets.In the screenshot above, at 5:08 there was a low priority workload that was running with no other competing workloads. The low priority workload was allocated 100% of the available CPU. However, when a high priority workload started at ~5:09, the high priority workload was served immediately and the low priority workload CPU utilization dropped to 60%. When the high priority workload completed, the low priority workload resumed using 100% of the available CPU,Access this newly added parameter by issuing requests to our RPC API, REST APIor via the Java or Go Client libraries.Related ArticleIntroducing Django ORM support for Cloud SpannerToday we’re happy to announce beta support for Google Cloud Spanner in the Django ORM. The django-google-spanner package is a third-party…Read Article
Quelle: Google Cloud Platform

OpenX is serving over 150 billion ad requests per day with cloud databases

Editor’s note: When ad tech provider OpenX was migrating to Google Cloud, they found a scalable, dependable and cost-effective solution in Bigtable and Memorystore for Memcached. Here’s how—and why—they made the move.Running one of the industry’s largest independent ad exchanges, OpenX developed an integrated platform that combines ad server data and a real-time bidding exchange with a standard supply-side platform to help ad buyers get the highest real-time value for any trade. OpenX serves more than 30,000 brands, more than 1,200 websites, and more than 2,000 premium mobile apps.We migrated to Google Cloud to save time, increase scalability, and be available in more regions in the world. As we were migrating to Google Cloud, we also sought to replace our existing open-source database because it was not supported anymore, which led us to search for a cloud-based solution. The combination of Cloud Bigtable and Memorystore for Memcached from Google Cloud gave us the performance, scalability, and cost-effectiveness we required. Leaving behind an unsupported databaseWhen OpenX was hosted on-premises, our infrastructure included a main open source key value database at the back end that offered low latency and high performance. However, the vendor eventually left the market, which meant we had the technology but no commercial support. This opened up the opportunity for us to take the important step of migrating to the cloud and get a more convenient, stable, and predictable data cloud solution.Performance was a huge consideration for us. We used the legacy key value database to understand the usage patterns of our active web users. We have a higher percentage of get requests than update requests, and our main requirement was, and remains, low latency. We need the database requests to be handled in less than 10 milliseconds at P99 (99th percentile). The expected median is less than five milliseconds, and if the time is shorter, it’s better for our revenue.  Scalability was another consideration and, unfortunately, our legacy database wasn’t able to keep up. To handle traffic, our clusters were maxed out and external sharding between two relatively large clusters was required. It wasn’t possible to handle the traffic in a single region by a single instance of this database because we’d reached the maximum number of nodes. In search of a cloud-based solutionChoosing our next solution was a crucial decision, as our database is mission-critical for OpenX. Cloud Bigtable, a fully managed, scalable NoSQL database service, appealed to us because it’s hosted and available on Google Cloud, which is now our native infrastructure. Post migration  we had also made it a policy to leverage managed services when possible. In this case we didn’t see the value in operating (installing, updating, optimizing etc) a key value store on top of Google Kubernetes Engine (GKE) – work that doesn’t directly add value to our products.We needed a new key value store and we needed to move quickly because our cloud migration was happening on a very compressed timeline. We were impressed with the foundation paper written about Bigtable, one of the most-cited articles in computer science, so it wasn’t a complete unknown. We also knew that Google itself used Bigtable for its own solutions like Search and Maps, so it held a lot of promise for OpenX. OpenX processes more than 150B ad requests per day and on average 1M such requests per second, so response time and scalability are both business-critical factors for us. To start, we created a solid proof of concept and tested Bigtable from different aspects and saw that the P99s and the P50s met our requirements. And with Bigtable, scalability is not a concern. Where is the data coming from?In each of our regions, we have a Bigtable instance for our service with at least two clusters replicated and with independent autoscalers because we write to both clusters. Data gets into Bigtable in two very different flows. Our first flow handles event-based updates like user-based activity, page views, or cookie syncing, and these events are connected to the currently active rows. We update Bigtable with the updated cookie. It’s a process focused on updating and during this event processing, we usually don’t need to read any data from Bigtable. Events are published to Pub/Sub and processed on GKE.The second flow manages massive uploads of billions of rows from Cloud Storage, which include batch processing results from other OpenX teams and some external sources.We perform reads when we get an ad request. We’ll look at the different numbers that Memorystore for Memcached provided us later in this blog, but here, before we used Memcached, the reads were 15 to 20 times more than the writes.  The following chart shows the current architecture today for the flows described above:Click to enlargeThings just happen automaticallyEach of our tables contains at least one billion rows. The column families available to us through Bigtable are incredibly useful and flexible because we are able to set up different retention policies for each, what should be read, and how they should be managed. For some families, we have defined strict retention based on time and version numbers, so the old data is set to disappear automatically when the values are updated. Our traffic pattern is common to the industry; there’s a gradual increase during the day and a decrease at night, and we are using autoscaling to handle that. Autoscaling is challenging in our use case. First of all, our business priority is to serve requests that read from the database because we have to retrieve data quickly for the ads broker. We have the GKE components that write to Bigtable and we have Bigtable itself. If we scale GKE too quickly, it might send too many writes to Bigtable and affect our read performance. We solved this by gradually and slowly scaling up the GKE components , and essentially throttling the rate in which we consume messages from Pub/Sub, an asynchronous message service. This allows the open-source autoscaler we are using for Bigtable to kick in and work its magic, a process which takes a bit longer than GKE scaling, naturally. It’s like a waterfall of autoscaling.At this point, our median response time was about five milliseconds. The 95 percentile was below 10 millisecond and the 99 percentile was generally between 10 and 20 milliseconds. This was good, but after working with the Bigtable team and the GCP Professional Services Organization team we felt like we could do better by leveraging another tool in the Google Cloud toolbox.Memorystore for Memcached saved us 50% in costsCloud Memorystore is Google’s in-memory datastore service, a solution we turned to when we wanted to improve performance, reduce response time and optimize overall costs. Our approach was to add a caching layer in front of Bigtable. So we created another POC with Memorystore for Memcached to investigate and experiment with the caching times, and the results were very fruitful. By using Memorystore as a caching layer we reduced the median and P75 to a value close to the Memcached response times and which is lower than one millisecond. P95 and P99 also decreased. Of course, response times vary by region and workload, but they have been significantly improved across the board. With Memorystore, we were also able to optimize the number of requests to Bigtable. Now, over 80% of get requests are fetching data from Memorystore, and less than 20% from Bigtable. As we reduced the traffic to the database, we reduced the size of our Bigtable instances as well. With Memorystore, we were able to reduce our Bigtable node count by over 50%. As a result of this, we are paying for Bigtable and Memorystore together 50% less than what we paid for Bigtable alone before that. With Bigtable and Memorystore, we could leave the problems of our legacy database behind and position ourselves for growth with solutions that provided low latency and high performance in a scalable, managed solution.To learn more about OpenX, visit our site. To explore Memorystore for Memcached, read how it powers up caching.Thank you: None of this would have been possible without the hard work of Grzegorz Łyczba, Mateusz Tapa, Dominik Walter, Jarosław Stropa, Maciej Wolny, Damian Majewski, Bartłomiej Szysz, Michał Ślusarczyk, along with the rest of the OpenX Engineering Teams. We’re also grateful for the support of Google strategic cloud engineer Radosław Stankiewicz.Related ArticleHow Memorystore cut costs in half for Quizlet’s Memcached workloadsSee how online learning platform Quizlet uses managed database service Memorystore for Memcached to cut costs, improve reliability for SRE.Read Article
Quelle: Google Cloud Platform

AI in Retail: Google Cloud transforms Cartier's product search technology

Ever since jeweler Louis-Francois Cartier opened his first workshop in Paris in 1847, the name “Cartier” has been synonymous with exceptional quality. Almost two centuries later, the luxury Maison has popularized wristwatches for men, been dubbed the “jeweler of kings and king of jewelers” by King Edward VII, and continues to design, manufacture, and sell jewelry and watchmaking creations globally renowned for timeless design. While Maison Cartier prides itself on the vastness of its collection, manually browsing its catalog to find specific models, or comparing several models at once, could sometimes take quite some time for a sales associate at one of the Maison’s 265 boutiques. This was not ideal for a brand that is known for its swift and efficient client service. Thus, in 2020, Cartier turned to Google Cloud and its advanced AI and machine learning capabilities for a solution.Thomas Meyer, Data Officer at Cartier: “We aim to build a global data & digital platform for our Maison, providing our teams with at scale analytics, versatile applications and artificial intelligence capabilities. Google Cloud is to be the core component of this data & digital platform.”No time to spare: Overcoming product search challenges with AICartier’s goal was to develop an application which, when shown an image of any Cartier watch ever designed in its 174-year history, could retrieve detailed information about its specific model and suggest similar-looking watches (with possibly different characteristics such as price) in under two seconds. Using the app, sales associates would be able to find specific products swiftly within a catalogue of more than a thousand watches—even some with only very slight variations between them.But creating this app meant Cartier’s data team had to overcome some unique challenges. Training machine learning models requires huge volumes of training data—in this case, images of Cartier wristwatches—but Cartier has always been driven by exclusive design and its prestigious collections had very few in-store product images available, with variations in backgrounds, lighting, quality, and styling, making it difficult to categorize images. As a result, Cartier had to find a way to develop an image recognition system that was performing above the required benchmarks, as the Maison has very high standards for its client service. For the app to be successfully adopted in its stores, Cartier required at least a 90% accuracy rate, with the entire pipeline running within five seconds end-to-end when integrated. That’s when, leveraging their existing partnership with Google Cloud, Cartier’s data team reached out to us for support looking for more advanced machine learning capabilities to bring their vision to life. Move beyond customer experienceWorking together with Cartier’s data team, we were able to help them solve their data and visual search challenge through trying out a number of machine learning experiments with Google Cloud AI Platform services, such as AutoML Vision, and Vision API, before rewriting custom code. In the end we built a data model specifically designed for Cartier’s use case: a combination of classifiers that run in parallel that first recognize a watch’s colors and materials, and then identifies which watch collection it belongs to. In the end, it provides a top three list of possible identities (visually similar watches) for the image, which users can click on to get more information, with up to 96.5% accuracy within three seconds.GCP project architecture & processNow, when customers are in need of a specific Cartier watch, the boutique team can help by taking a picture of the desired model (or use any existing photo of it as reference), and use the app to find its equivalent product page online. This solution also locates visually similar designed products in the catalog, displaying each with their own image, similarity score, and detailed description (if the boutique team clicks on it) for customers to explore. Meanwhile, an automatic tracked feedback mechanism enables users to evaluate how relevant the recommendations were so that the Cartier data team can continually improve the app. Served with style, thanks to the cloudToday, Cartier’s image recognition app has been rolled out across the Maison’s 200+ global stores and is available to sales associates in need of quickly calling up catalogue data on Cartier’s vast watchmaking creations. It now takes a sales associate seconds to answer a question that used to take them several minutes. And over time the Maison hopes to further expand the app’s functionality. “The performance of cutting edge machine learning and easy handling makes Google Cloud Vision API a fantastic tool to quickly prototype most classification projects” explains Alexandre Poussard, Data Scientist at Cartier. “We look forward to deepening our collaboration with Google Cloud in the future.”With AI and machine learning, the future looks bright for Cartier, just in the nick of time. Even beyond the boutiques, the success of this pioneering project is also opening doors to more innovation as it attracts the interest of other retail brands looking to tackle similar challenges. Learn more aboutGoogle Cloud AI and machine learning and retail solutions.Related ArticleGoogle Cloud Retail & Consumer Goods Summit: The Future of RetailJoin us at the Google Cloud Retail & Consumer Goods Summit and learn how combining technology and business insights can solve retail chal…Read Article
Quelle: Google Cloud Platform