如需了解专门针对 AI 和机器学习工作负载的费用优化原则和建议，请参阅 Well-Architected Framework 中的AI 和机器学习视角：费用优化。
性能优化
Vision API 是一种资源密集型 API。因此，大规模处理图片需要仔细编排 API 调用。Dataflow 流水线负责对 API 请求进行批处理、妥善处理与达到配额相关的异常情况，以及生成 API 使用情况的自定义指标。这些指标可帮助您确定是否需要增加 API 配额，或者是否应调整 Dataflow 流水线参数以降低请求频率。如需详细了解如何申请增加 Vision API 配额，请参阅配额和限制。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2024-05-23。"],[[["\u003cp\u003eThis architecture demonstrates how to use a Dataflow pipeline to process image files with Cloud Vision API and store the resulting annotations in BigQuery for large-scale data analysis and model training.\u003c/p\u003e\n"],["\u003cp\u003eThe system ingests images through Cloud Storage, triggers processing via Pub/Sub notifications, and uses Dataflow to send image references to Vision API for analysis.\u003c/p\u003e\n"],["\u003cp\u003eThe processed data is stored in BigQuery, enabling users to query, analyze, and utilize BigQuery ML or Vertex AI to build models based on the image annotations.\u003c/p\u003e\n"],["\u003cp\u003eThe design offers flexibility with design alternatives, including direct Pub/Sub messaging for latency-sensitive use cases and async batch processing for large image sets, while emphasizing security, cost, and performance optimization considerations.\u003c/p\u003e\n"],["\u003cp\u003eThis reference architecture provides a way to achieve processing at scale by batching the API requests, handling exceptions, and producing custom metrics that can be used to determine if an API quota increase or adjustments in parameters are needed.\u003c/p\u003e\n"]]],[],null,["# Build an ML vision analytics solution with Dataflow and Cloud Vision API\n\nIn this reference architecture, you'll learn about the use cases,\ndesign alternatives, and design considerations when deploying a\n[Dataflow](/dataflow)\npipeline to process image files with\n[Cloud Vision](/vision/docs)\nand to store processed results in BigQuery.\nYou can use those stored results for large scale data analysis and to train\n[BigQuery ML pre-built models](/bigquery-ml/docs/introduction).\n\nThis reference architecture document is intended for data engineers and data\nscientists.\n\nArchitecture\n------------\n\nThe following diagram illustrates the system flow for this reference\narchitecture.\n\nAs shown in the preceding diagram, information flows as follows:\n\n1. **Ingest and trigger**: This is the first stage of the system flow where\n images first enter the system. During this stage, the following actions\n occur:\n\n 1. Clients upload image files to a Cloud Storage bucket.\n 2. For each file upload, the Cloud Storage automatically sends an input notification by publishing a message to Pub/Sub.\n2. **Process**: This stage immediately follows the ingest and trigger stage.\n For each new input notification, the following actions occur:\n\n 1. The Dataflow pipeline listens for these file input notifications, extracts file metadata from the Pub/Sub message, and sends the file reference to Vision API for processing.\n 2. Vision API reads the image and creates annotations.\n 3. The Dataflow pipeline stores the annotations produced by Vision API in BigQuery tables.\n3. **Store and analyze**: This is the final stage in the flow. At this stage,\n you can do the following with the saved results:\n\n 1. Query BigQuery tables and analyze the stored annotations.\n 2. Use BigQuery ML or Vertex AI to build models and execute predictions based on the stored annotations.\n 3. Perform additional analysis in the Dataflow pipeline (not shown on this diagram).\n\nProducts used\n-------------\n\nThis reference architecture uses the following Google Cloud products:\n\n- [BigQuery](/bigquery/docs)\n- [Cloud Storage](/storage/docs)\n- [Vision API](/storage/docs)\n- [Dataflow](/dataflow/docs)\n- [Pub/Sub](/pubsub/docs)\n\nUse cases\n---------\n\nVision API supports\n[multiple processing features](/vision/docs/features-list),\nincluding image labeling, face and landmark detection, optical character\nrecognition, explicit content tagging, and others. Each of these features enable\nseveral use cases that are applicable to different industries. This document\ncontains some simple examples of what's possible when using\nVision API, but the spectrum of possible applications is very broad.\n\nVision API also offers powerful pre-trained machine learning models\nthrough REST and RPC APIs. You can assign labels to images and classify them\ninto millions of predefined categories. It helps you detect objects, read\nprinted and handwritten text, and build valuable metadata into your image\ncatalog.\n\nThis architecture doesn't require any model training before you can use it. If\nyou need a custom model trained on your specific data, Vertex AI\nlets you train an AutoML or a custom model for computer vision\nobjectives, like image classification and object detection. Or, you can use\n[Vertex AI Vision](/vertex-ai-vision)\nfor an end-to-end application development environment that lets you\nbuild, deploy, and manage computer vision applications.\n\nDesign alternatives\n-------------------\n\nInstead of storing images in a Google Cloud Storage bucket, the\nprocess that produces the images can publish them directly to a messaging\nsystem---Pub/Sub for example---and the Dataflow pipeline can\nsend the images directly to Vision API.\n\nThis design alternative can be a good solution\nfor latency-sensitive use cases where you need to analyze images of relatively\nsmall sizes. Pub/Sub limits the maximum size of the message to\n10 Mb.\n\nIf you need to batch process a large number of images, you can use a\nspecifically designed\n[`asyncBatchAnnotate`](/vision/docs/reference/rest/v1/images/asyncBatchAnnotate)\nAPI.\n\nDesign considerations\n---------------------\n\nThis section describes the design considerations for this reference\narchitecture:\n\n- [Security, privacy, and compliance](#security,_privacy,_and_compliance)\n- [Cost optimization](#cost_optimization)\n- [Performance optimization](#performance_optimization)\n\n### Security, privacy, and compliance\n\nImages received from untrusted sources can contain malware. Because\nVision API doesn't execute anything based on the images it analyzes,\nimage-based malware wouldn't affect the API. If you need to scan images, change\nthe Dataflow pipeline to add a scanning step. To achieve the same\nresult, you can also use a separate subscription to the Pub/Sub\ntopic and scan images in a separate process.\n\nFor more information, see\n[Automate malware scanning for files uploaded to Cloud Storage](/architecture/automate-malware-scanning-for-documents-uploaded-to-cloud-storage).\n\nVision API uses\n[Identity and Access Management (IAM)](/iam/docs/overview)\nfor authentication. To access the Vision API, the\nsecurity principal needs **Cloud Storage \\\u003e Storage object viewer**\n(`roles/storage.objectViewer`) access to the bucket that contains the files that\nyou want to analyze.\n\n\nFor security principles and recommendations that are specific to AI and ML workloads, see\n[AI and ML perspective: Security](/architecture/framework/perspectives/ai-ml/security)\nin the Well-Architected Framework.\n\n### Cost optimization\n\nCompared to the other options discussed, like low-latency processing and\nasynchronous batch processing, this reference architecture uses a cost-efficient\nway to process the images in streaming pipelines by batching the API requests.\nThe lower latency direct image streaming mentioned in the\n[Design alternatives](#design_alternatives)\nsection could be more expensive due to the additional Pub/Sub and\nDataflow costs. For image processing that doesn't need to happen\nwithin seconds or minutes, you can run the Dataflow pipeline in\nbatch mode. Running the pipeline in batch mode can provide some savings when\ncompared to what it costs to run the streaming pipeline.\n\nVision API supports offline\n[asynchronous batch](/vision/docs/batch)\nimage annotation for all features. The asynchronous request supports up to 2,000\nimages per batch. In response, Vision API returns JSON files that are\nstored in a Cloud Storage bucket.\n\nVision API also provides a set of features for analyzing images.\n[The pricing](/vision/pricing)\nis per image per feature. To reduce costs, only request the specific features\nyou need for your solution.\n\nTo generate a cost estimate based on your projected usage, use the\n[pricing calculator](/products/calculator).\n\n\nFor cost optimization principles and recommendations that are specific to AI and ML workloads, see\n[AI and ML perspective: Cost optimization](/architecture/framework/perspectives/ai-ml/cost-optimization)\nin the Well-Architected Framework.\n\n### Performance optimization\n\nVision API is a resource intensive API. Because of that, processing\nimages at scale requires careful orchestration of the API calls. The\nDataflow pipeline takes care of batching the API requests,\ngracefully handling of the exceptions related to reaching quotas, and producing\ncustom metrics of the API usage. These metrics can help you decide if an API\nquota increase is warranted, or if the Dataflow pipeline\nparameters should be adjusted to reduce the frequency of requests. For more\ninformation about increasing quota requests for Vision API, see\n[Quotas and limits](/vision/quotas).\n\nThe Dataflow pipeline has several parameters that can affect the\nprocessing latencies. For more information about these parameters, see\n[Deploy an ML vision analytics solution with Dataflow and Vision API](/architecture/building-a-vision-analytics-solution/deployment).\n\n\nFor performance optimization principles and recommendations that are specific to AI and ML workloads, see\n[AI and ML perspective: Performance optimization](/architecture/framework/perspectives/ai-ml/performance-optimization)\nin the Well-Architected Framework.\n\nDeployment\n----------\n\nTo deploy this architecture, see\n[Deploy an ML vision analytics solution with Dataflow and Vision API](/architecture/building-a-vision-analytics-solution/deployment).\n\nWhat's next\n-----------\n\n- Learn more about [Dataflow](/dataflow/docs/overview).\n- Learn more about [BigQuery ML](/bigquery/docs/bqml-introduction).\n- Learn more about BigQuery reliability in the [Understand BigQuery reliability](/bigquery/docs/reliability-intro) guide.\n- Learn about storing data in [Jump Start Solution: Data warehouse with BigQuery](/architecture/big-data-analytics/data-warehouse).\n- Review the [Vision API features list](/vision/docs/features-list).\n- Learn how to [deploy an ML vision analytics solution with Dataflow and Vision API](/architecture/building-a-vision-analytics-solution/deployment).\n- For an overview of architectural principles and recommendations that are specific to AI and ML workloads in Google Cloud, see the [AI and ML perspective](/architecture/framework/perspectives/ai-ml) in the Well-Architected Framework.\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture).\n\nContributors\n------------\n\nAuthors:\n\n- [Masud Hasan](https://www.linkedin.com/in/masudhasan1480) \\| Site Reliability Engineering Manager\n- [Sergei Lilichenko](https://www.linkedin.com/in/sergei-lilichenko) \\| Solutions Architect\n- [Lakshmanan Sethu](https://www.linkedin.com/in/lakshmanansethu) \\| Technical Account Manager\n\n\u003cbr /\u003e\n\nOther contributors:\n\n- [Jiyeon Kang](https://www.linkedin.com/in/jiyeon-kang) \\| Customer Engineer\n- [Sunil Kumar Jang Bahadur](https://www.linkedin.com/in/sunilkumar88) \\| Customer Engineer\n\n\u003cbr /\u003e"]]
