이 문서에서는 쓰기 시간에 Bigtable 데이터를 집계하는 방법을 간략하게 설명합니다. 이 문서를 읽기 전에 Bigtable 개요를 숙지해야 합니다.
많은 애플리케이션은 인앱 보고, 실시간 추천, 비율 제한을 비롯한 사용 사례를 유도하는 운영 측정항목을 추적합니다.
이러한 운영 측정항목의 예는 다음과 같습니다.
주간 활성 사용자 수
광고 노출수
소셜 콘텐츠 조회수 또는 공유수
미디어 스트림 수
이러한 측정항목은 사용자 대상 애플리케이션에서 또는 머신러닝 모델의 입력으로 사용할 수 있으며, 일반적으로 이를 사용하려면 지연 시간이 짧고 처리량이 높아야 합니다. 쿼리 시 이러한 유형의 측정항목을 계산하는 것은 대규모로 실행하기에는 비현실적이므로 데이터 처리 중에 사전 집계하는 것이 실시간 시스템에 적합한 접근 방식입니다.
Bigtable은 충돌이 없는 복제된 데이터 유형, ReadModifyWriteRow 요청, 연속 구체화된 뷰를 비롯하여 쓰기 시 데이터를 집계하는 여러 가지 방법을 제공합니다.
쓰기 시 Bigtable 데이터를 집계하면 추출, 변환, 로드 (ETL) 또는 스트리밍 처리 소프트웨어를 사용하여 Bigtable에 데이터를 쓰기 전후에 데이터를 집계할 필요가 없습니다. 예를 들어 애플리케이션이 이전에는 Pub/Sub에 메시지를 게시한 후 데이터를 Bigtable에 기록하기 전에 Dataflow를 사용하여 메시지를 읽고 데이터를 집계했다면 이제 데이터를 Bigtable의 집계 셀에 직접 전송할 수 있습니다.
충돌이 없는 복제된 데이터 유형
Bigtable을 사용하면 집계 유형의 셀만 포함된 column family를 만들 수 있습니다. 집계 셀은 증분 업데이트에 최적화된 충돌이 없는 복제된 데이터 유형 구조입니다.
Apache Cassandra, Redis, Valkey와 같은 데이터베이스에서 Bigtable로 마이그레이션하는 경우 이러한 시스템의 유사한 구조는 카운터라고 합니다.
다음 표에는 지원되는 작업과 새로 작성된 값이 처리되는 방식이 나와 있습니다.
작업
설명
합계
셀 값은 새로 추가된 값과 현재 셀 값의 합계로 대체됩니다.
최소
셀 값은 새로 추가된 값과 현재 셀 값 중 더 낮은 값으로 대체됩니다.
최대
셀 값은 새로 추가된 값과 현재 셀 값 중 더 큰 값으로 대체됩니다.
HyperLogLog
쓰여진 값은 가장 최근 재설정 이후 추가된 모든 값의 확률적 집합에 추가됩니다. 셀 값은 해당 집합의 상태를 나타냅니다. HLL 알고리즘에 관한 일반적인 내용은 HyperLogLog를 참고하세요.
쓰기 시점에 데이터를 집계하는 또 다른 방법은 ReadModifyWriteRow 요청을 사용하는 것입니다. 이 요청을 사용하면 트랜잭션 방식으로 값을 증분하거나 추가하여 셀의 값을 조작할 수 있습니다. 이 접근 방식을 사용하는 경우의 자세한 내용은 추가를 참고하세요.
연속 구체화된 뷰
연속 구체화된 뷰는 소스 테이블의 데이터를 집계하는 SQL 쿼리의 미리 계산된 결과입니다. 뷰는 소스 테이블에 처리될 때 데이터를 연속적으로 처리하고 업데이트를 일괄 처리합니다. 여기에는 업데이트 및 삭제가 포함됩니다. 연속 구체화된 뷰를 사용하면 성능과 효율성을 높일 수 있습니다. 자세한 내용은 연속 구체화된 뷰를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eBigtable aggregates allow for the aggregation of cell values directly at write time, merging new values with existing aggregated data within the cell.\u003c/p\u003e\n"],["\u003cp\u003eAggregates are useful in scenarios where summarized data is needed rather than individual data points, such as creating counters or time buckets.\u003c/p\u003e\n"],["\u003cp\u003eCreating and updating aggregate cells requires the use of \u003ccode\u003eMutateRow\u003c/code\u003e requests with either \u003ccode\u003eAddToCell\u003c/code\u003e to increment or \u003ccode\u003eMergeToCell\u003c/code\u003e to copy values, sent to specially defined aggregate column families.\u003c/p\u003e\n"],["\u003cp\u003eBigtable supports various aggregation types, including sum, minimum, maximum, and HyperLogLog (HLL), each with specific input types.\u003c/p\u003e\n"],["\u003cp\u003eAggregate cells are subject to garbage collection and replication like other cells, but if an add request is sent to a deleted aggregate cell, a new aggregate cell will be created.\u003c/p\u003e\n"]]],[],null,["# Aggregating values at write time\n================================\n\nThis document provides an overview of the ways that you can aggregate your\nBigtable data at write time. Before you read this document, make\nsure that you're familiar with the [Bigtable\noverview](/bigtable/docs/overview).\n\nMany applications track operational metrics that drive use cases\nincluding in-app reporting, real-time recommendations, and rate limiting.\nExamples of such operational metrics include the following:\n\n- Weekly active users\n- Number of ad impressions\n- Views or shares of social content\n- Number of media streams\n\nYou can use these metrics in user-facing applications or as inputs to machine\nlearning models, and their uses typically require low latency and high\nthroughput. Because computing these types of metrics at query time is\nimpractical at scale, pre-aggregation during data ingestion is the preferred\napproach for real-time systems.\n\nBigtable offers multiple ways of aggregating data at write time,\nincluding conflict-free replicated data types, `ReadModifyWriteRow` requests,\nand continuous materialized views.\n\nAggregating your Bigtable data at write time lets you avoid the\nneed to use any extract, transform, and load (ETL) or streaming processing\nsoftware to aggregate your data before or after you write it to\nBigtable. For example, if your application published messages to\nPub/Sub previously and then used Dataflow to read the messages\nand aggregate the data before writing it to Bigtable, you can\ninstead send the data directly to aggregate cells in Bigtable.\n\nConflict-free replicated data types\n-----------------------------------\n\nBigtable lets you create column families that contain only cells\nof type *aggregate* . Aggregate cells are [conflict-free replicated data\ntype](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)\nstructures that are optimized for incremental updates.\n\nIf you're migrating to Bigtable from databases such as Apache\nCassandra, Redis, or Valkey, similar structures in those systems are referred to\nas *counters*.\n\nThe following table lists the supported operations and how newly written values\nare handled.\n\nThe mutation types that you can send to create and update aggregate cells are\n[`AddToCell`](/bigtable/docs/reference/data/rpc/google.bigtable.v2#google.bigtable.v2.Mutation.AddToCell)\nand\n[`MergeToCell`](/bigtable/docs/reference/data/rpc/google.bigtable.v2#mergetocell).\n\nTo get started with counting in Bigtable, see the\n[Create and update counters in\nBigtable](/bigtable/docs/create-update-counters) quickstart.\n\nRead then write\n---------------\n\nAnother way to aggregate your data at write time is by using a\n[ReadModifyWriteRow](/bigtable/docs/reference/data/rpc/google.bigtable.v2#readmodifywriterowrequest)\nrequest, which lets you manipulate the value of a cell by incrementing or\nappending to the value transactionally. For more information about when to use\nthis approach, see\n[Appends](/bigtable/docs/writes#appends).\n\nContinuous materialized views\n-----------------------------\n\nA continuous materialized view is a pre-computed result of a SQL query that\naggregates data in a source table. The view continuously processes data as it's\ningested into the source table and batches the updates. This includes updates\nand deletes. Using continuous materialized views can increase performance and\nefficiency. For more information, see [Continuous materialized\nviews](/bigtable/docs/continuous-materialized-views).\n\nWhat's next\n-----------\n\n- [See code samples showing how to add a value to an aggregate\n cell](/bigtable/docs/writing-data#increments-appends).\n- [Review concepts related to schema design.](/bigtable/docs/schema-design)"]]
