AWS S3 상에 대량의 로그가 있고, Amazon Athena로 검색·분석하고 있는 환경에 대해, Oracle Autonomous Database / Autonomous AI Lakehouse를 사용하여 추가적인 AI 분석을 할 수 없을까 하는 상담을 받을 때가 있습니다.

예를 들어, S3 상에 다음과 같은 로그가 있는 케이스입니다.

• Amazon Aurora / RDS의 Error Log
• Slow Query Log
• DB Audit Log
• OS Log
• Application Log
• CloudTrail 등의 조작 감사 로그
• Jira의 장애 티켓, 변경 티켓, 대응 이력

이때, 처음에 오해하기 쉬운 것이,

"AI Database를 사용한다면, 모든 로그를 Vector Store에 넣어서 RAG를 하는 것 아닌가?"

라는 생각입니다.

결론부터 말씀드리면, 모든 로그를 Vector화하여 RAG를 할 필요는 없습니다.

로그와 같이 대량이고, 시계열적이며, 구조화하기 쉬운 데이터는 우선 SQL로 다루는 것이 기본입니다. 그 위에 에러 메시지, 스택 트레이스 (Stack Trace), Jira 코멘트, 장애 대응 메모 등 의미 검색 (Semantic Search)이 필요한 텍스트만을 Vector Search / RAG의 대상으로 삼는 것이 현실적입니다.

이 기사에서는 다음과 같은 흐름으로 정리합니다.

1. 우선 용어 정리

2. S3 로그를 Oracle Autonomous Database에서 읽는 방법

3. Raw Log 직접 참조와 Curated Parquet 참조의 차이

4. Curated Parquet는 "로그 종류별"로 만든다

5. 파티션 (Partition) 설계

6. 외부 테이블을 고속화하는 3가지 선택지: Lake Cache, Data Lake Accelerator, Gold Data

7. SQL로 해야 할 일

8. Vector Search로 해야 할 일

9. RAG로 해야 할 일

10. 추천하는 Hybrid 구성

11. PoC에서 확인해야 할 포인트

참고로, 본 기사에서는 Oracle Autonomous AI Database를 총칭하여 ADB라고 표기합니다. Lakehouse 맥락의 이야기를 할 경우에만 Autonomous AI Lakehouse라고 기재합니다.

ADB에서는 Object Storage 상의 파일에 액세스하기 위해 Credential을 등록하고, DBMS_CLOUD.CREATE_EXTERNAL_TABLE로 외부 테이블을 생성할 수 있습니다. Amazon S3 상의 데이터도 이 외부 테이블 액세스 대상에 포함할 수 있습니다.

참고: Query External Data with Autonomous Database

S3, Athena, Glue, ADB, AI Lakehouse 이야기를 하다 보면 다음 단어들이 섞이기 쉽습니다.

• 데이터 (Data)
• 스키마 (Schema)
• 메타데이터 (Metadata)
• 카탈로그 (Catalog)

데이터는 실제 내용물입니다.

예를 들어, S3에 있는 다음과 같은 Parquet 파일의 내용물입니다.

s3://log-bucket/curated/rds_audit_log/dt=2026-07-06/hour=00/part-0001.snappy.parquet

로그 한 줄 한 줄, Audit Event, SQL 실행 이력, 에러 행 등이 데이터입니다.

스키마는 데이터의 구조입니다.

예를 들어, RDS Audit Log를 다음과 같은 열(Column)로 다룬다면 이것이 스키마입니다.

event_time TIMESTAMP
db_identifier VARCHAR2
user_name VARCHAR2
...

즉, 스키마는,

• 어떤 열이 있는지
• 각 열의 데이터 타입은 무엇인지
• 어떤 열이 일시인지
• 어떤 열이 문자열인지
• 어떤 열이 수치인지

를 정의하는 것입니다.

메타데이터는 데이터를 읽기 위한 설명 정보입니다.

예를 들어, 다음과 같은 정보입니다.

데이터의 위치:
s3://log-bucket/curated/rds_audit_log/
파일 형식:
...

중요한 것은, 스키마는 메타데이터의 일부라는 점입니다.

메타데이터
├─ 스키마 정보
│ ├─ 열 정의
...

이와 같이 스키마 정보는 메타데이터의 일부입니다.

메타데이터에는 열 정의뿐만 아니라, S3 상의 저장 위치, 파일 형식, 압축 형식, 파티션, 생성 작업 (Job), 권한이나 태그 등 데이터를 관리·이용하기 위한 정보도 포함됩니다.

카탈로그는 메타데이터를 관리하는 장부입니다.

대표적인 예는 다음과 같습니다.

Athena에서는 AWS Glue Data Catalog를 사용하여 S3 상의 데이터에 대한 데이터베이스, 테이블, 스키마 정보를 관리할 수 있습니다. 또한, Glue Crawler를 사용하면 S3 상의 데이터로부터 스키마를 추정할 수 있습니다.

참고: Using AWS Glue Data Catalog with Athena

반면, Glue를 사용하지 않고 ADB에서 S3를 직접 읽는 경우에는 Oracle 측의 외부 테이블 (External Table) 정의로서 메타데이터를 생성합니다.

Parquet는 데이터 본체뿐만 아니라 열 이름 (Column Name), 데이터 타입 (Data Type), Row Group, 열별 통계 정보, 압축 방식 등의 메타데이터를 파일 내부에 보유하는 열 지향 (Columnar) 파일 형식입니다.

반면, Object Storage 상의 저장 위치, 파티션 (Partition), 여러 파일을 묶은 테이블 정의, 권한, 설명 등은 경로 구조나 외부 테이블 정의, Glue Data Catalog, Iceberg Catalog 등 Parquet 파일 외부에서 관리됩니다.

즉, Parquet는 "데이터와 파일 내부의 메타데이터"를 가지고, 카탈로그는 "여러 Parquet 파일을 테이블로서 관리하는 메타데이터"를 가진다고 정리할 수 있습니다.

ADB에서 S3 로그를 읽는 기본 형태는 DBMS_CLOUD.CREATE_EXTERNAL_TABLE입니다.

대략적으로 다음과 같은 사항을 지정합니다.

1. 어디에 있는가
→ S3의 파일 경로 (File Path) / prefix / URI
2. 어떻게 읽는가
...

Oracle 문서에서는 클라우드 상의 파일을 질의하는 경우, Object Storage의 자격 증명 (Credential) 정보를 데이터베이스에 저장한 후, DBMS_CLOUD.CREATE_EXTERNAL_TABLE로 외부 테이블을 생성하는 흐름을 설명하고 있습니다.

참고: Query External Data with Autonomous Database

S3에 액세스하기 위한 자격 증명 (Credential)을 Oracle 측에 등록합니다.

BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'AWS_S3_CRED',
...

참고로 위 내용은 액세스 키 (Access Key) 방식의 예시입니다.

DBMS_CLOUD.CREATE_CREDENTIAL은 params 파라미터를 통해 AWS IAM 역할 (Role)의 ARN (aws_role_arn)을 지정하는 역할 기반 인증 (Role-based Authentication)도 지원합니다.

BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'AWS_S3_CRED_ARN',
...

장기 유효한 액세스 키를 데이터베이스에 저장할 필요가 없고, AWS 측의 역할 (Role)과 정책 (Policy)으로 액세스 범위를 제어할 수 있기 때문에 운영 환경에서는 역할 ARN 방식을 권장합니다. 사전에 ADB 측에서의 ARN 이용 활성화와 AWS 측에서의 Role / Policy / 신뢰 관계 (Trust Relationship) 설정이 필요합니다.

참고: Use Amazon Resource Names (ARNs) to Access AWS Resources

어떤 방식을 사용하든 운영 환경에서는 권한을 제한한 IAM Role / Policy, 네트워크 제어, 키 관리, 감사 (Audit)를 포함하여 설계해야 합니다.

CSV나 텍스트 로그의 경우, 파일 자체에 명확한 스키마 (Schema)가 없는 경우가 많으므로 Oracle 측에서 컬럼 (Column) 정의를 지정합니다.

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'EXT_RDS_AUDIT_LOG',
...

생성 후에는 일반 테이블과 같이 SQL로 액세스할 수 있습니다.

SELECT
event_time,
db_identifier,
...

이때 데이터 본체는 S3에 그대로 남아 있습니다.

Oracle 측에는 S3의 위치, 파일 형식, 컬럼 정의 등의 외부 테이블 메타데이터가 등록됩니다.

Parquet의 경우는 CSV나 텍스트 로그와는 조금 다릅니다.

Parquet, ORC, Avro는 파일 내부에 메타데이터를 가지고 있으며, ADB에서는 DBMS_CLOUD.CREATE_EXTERNAL_TABLE이 이 메타데이터를 활용하여 외부 테이블 생성을 간소화할 수 있습니다.

참고: Parquet, Avro 또는 ORC 형식의 외부 데이터 쿼리

예를 들어, Parquet 파일을 외부 테이블 (External Table)로 만드는 경우는 다음과 같이 할 수 있습니다.

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'EXT_RDS_AUDIT_PARQUET',
...

이 경우, Parquet 파일 내의 스키마 (Schema) 정보를 이용하여 Oracle 측의 열 (Column) 정의를 생성할 수 있습니다.

S3 로그를 Oracle에서 읽는 방법에는 크게 두 가지가 있습니다.

방식 A:
Raw Log를 직접 외부 테이블로 읽기
방식 B:
...

이번과 같은 대량 로그 분석에서는, PoC(Proof of Concept)에서는 Raw Log를 직접 참조하고, 본 운영 분석에서는 Curated Parquet를 참조한다고 생각하는 것이 현실적입니다.

Raw Log 직접 참조는 S3 상의 CSV, JSON, 텍스트 로그를 그대로 외부 테이블로 읽는 방식입니다.

S3 Raw Log
↓
DBMS_CLOUD 외부 테이블
...

적합한 용도는 다음과 같습니다.

• PoC
• 간이 조사
• 로그 형식이 비교적 깔끔함
• CSV / JSON으로 읽을 수 있음
• 대상 로그 종류가 적음
• 대상 기간이 한정되어 있음

예를 들어, 앱 로그를 먼저 한 줄의 텍스트로 읽은 뒤, SQL의 LIKE나 REGEXP_SUBSTR를 사용하여 조사할 수도 있습니다.

SELECT
message
FROM ext_raw_app_log
...

Oracle Database에 접속하는 애플리케이션의 로그라면, message LIKE '%ORA-%'와 같은 Oracle 에러 코드 검색도 유효합니다.

하지만 Raw Log 직접 참조에는 한계가 있습니다.

• 멀티라인 로그 (Multi-line log)에 취약함
• 스택 트레이스 (Stack trace) 처리가 어려움
• 로그 형식이 도중에 변경되면 깨지기 쉬움
• timestamp나 severity 추출이 매번 필요함
• 대량 분석 시 성능이나 유지보수성이 떨어짐
• Jira와의 JOIN이나 AI 분석에 사용하기 어려움

따라서 Raw Log 직접 참조는 "우선 읽을 수 있는지 확인하는" 용도에 적합합니다.

Curated Parquet 참조는 Raw Log를 사전에 정형화하여, 분석하기 쉬운 Parquet 형식으로 변환한 뒤 Oracle에서 읽는 방식입니다.

S3 Raw Log
↓
ETL / Parser
...

Parquet화에는 Athena CTAS, AWS Glue Spark ETL, EMR / Spark, Lambda / ECS / Batch 등을 사용할 수 있습니다.

Athena의 CTAS는 쿼리 결과로부터 새로운 테이블을 생성하는 기능으로, 소스 테이블을 다른 형식의 테이블로 변환하는 용도로도 사용할 수 있습니다. Athena에서는 CTAS를 통해 Parquet 형식을 지정할 수 있습니다.

참고: CREATE TABLE AS - Amazon Athena

예를 들어, Athena CTAS로 Raw 로그를 Parquet화하는 이미지입니다.

CREATE TABLE curated_rds_audit_log
WITH (
external_location = 's3://log-bucket/curated/rds_audit_log/',
...

참고로, Athena CTAS에는 한 번의 쿼리로 생성할 수 있는 파티션 (Partition)이 100개까지라는 제한이 있습니다. 대량의 과거 로그를 처음 변환할 경우에는 CTAS로 테이블을 생성한 후 INSERT INTO를 사용하여 기간을 나누어 투입하거나, Glue ETL 사용을 검토하십시오.

참고: Use CTAS and INSERT INTO to work around the 100 partition limit

AWS Glue를 통해서도 S3 상의 데이터를 Parquet로 변환하는 ETL 작업을 구성할 수 있습니다. AWS의 Prescriptive Guidance에서는 AWS Glue의 여러 작업 유형을 사용하여 S3 데이터를 Apache Parquet로 변환하는 패턴을 소개하고 있습니다.

참고: Use AWS Glue ETL jobs to convert data to Apache Parquet

대량 로그를 Parquet화할 때는 하나의 거대한 테이블에 모두 밀어 넣기보다, 먼저 로그 종류별로 Curated Parquet 데이터 세트 (Dataset)를 만드는 것이 좋습니다.

s3://log-bucket/curated/
rds_error_log/
rds_audit_log/
...

예를 들어, RDS Audit Log와 Slow Query Log는 컬럼(Column) 구성이 크게 다릅니다.

억지로 하나의 테이블로 통합하면 NULL 값이 가득 차게 되어 유지보수가 어려워집니다.

따라서 우선 다음과 같이 로그 유형별 상세 테이블을 생성합니다.

나아가 Jira 연동이나 AI 분석을 위해, 모든 로그를 가로지르는 공통 테이블도 생성합니다.

log_event_common

공통 로그 테이블의 스키마 (Schema) 예시입니다.

event_time
source_type
aws_account_id
...

핵심은 모든 로그의 고유 항목을 억지로 열(Column)로 만들지 않는 것입니다.

로그 유형별로만 사용하는 항목은 attributes_json과 같은 열로 분리하는 설계도 유효합니다.

Curated Parquet에서는 S3 프리픽스(Prefix)를 Hive 형식으로 설정해 두면 다루기 쉬워집니다.

s3://log-bucket/curated/log_event_common/
source_type=rds_error/dt=2026-07-06/hour=00/part-0001.snappy.parquet
source_type=rds_error/dt=2026-07-06/hour=01/part-0002.snappy.parquet
...

파티션 키 (Partition Key)는 우선 다음과 정도로 충분합니다.

source_type
dt
hour

필요에 따라 다음을 추가합니다.

aws_account_id
region
environment
...

단, 다음과 같이 카디널리티 (Cardinality)가 너무 높은 항목은 성급하게 파티션 키에 포함하지 않는 것이 좋습니다.

host_name
user_name
trace_id
...

파티션을 너무 잘게 나누면 작은 파일이나 폴더, 메타데이터가 증가하여 오히려 검색이나 운영이 복잡해집니다.

Autonomous AI Database에서는 Object Storage 상의 계층적인 폴더 구조로부터 파티션 열과 값을 도출하는 **암묵적 파티셔닝 (Implicit Partitioning)**을 이용할 수 있습니다.

예를 들어, 다음 S3 경로를 생각해 보겠습니다.

s3://log-bucket/curated/log_event_common/
source_type=rds_error/
dt=2026-07-06/
...

이 경로에는 다음과 같은 파티션 정보가 포함되어 있습니다.

source_type = rds_error
dt = 2026-07-06
hour = 00

source_type, dt, hour가 Parquet 파일 내의 열로 저장되어 있지 않더라도, ADB는 폴더 이름으로부터 열과 값을 도출할 수 있습니다.

source_type=rds_error
├─ 열 이름: source_type
└─ 값: rds_error
...

암묵적 파티셔닝에서는 파티션 열과 값이 쿼리 (Query) 실행 시점에 검출됩니다. 또한, S3 상에서 파일이나 폴더가 추가/삭제된 경우에도 Object Storage 구조의 변경을 실행 시점에 검출할 수 있습니다.

새로운 로그 파일을 S3에 추가
↓
외부 테이블의 재생성이나 파티션 동기화가 불필요
...

명시적인 외부 파티션 테이블에서 필요했던 동기화 처리를 생략할 수 있기 때문에, 로그와 같이 파일이 지속적으로 추가되는 데이터와 궁합이 좋습니다.

나아가 SQL로 파티션 열을 필터링하면, ADB는 관련된 Object Storage 상의 파일에만 접근합니다.

SELECT
service_name,
error_code,
...

이 SQL에서는 주로 다음 경로에 해당하는 파일이 검색 대상이 됩니다.

source_type=rds_error/
dt=2026-07-06/
hour=00/

전 기간·전체 로그 종류의 파일을 모두 읽지 않아도 되므로, Object Storage에서 읽어오는 데이터 양과 쿼리 시간 (Query Time)을 줄일 수 있습니다.

암시적 파티셔닝 (Implicit Partitioning)에서는 주로 다음 두 가지 폴더 형식을 이용할 수 있습니다.

Hive 형식에서는 폴더 이름에 파티션 컬럼 이름과 값을 포함합니다.

<table>/
source_type=rds_error/
dt=2026-07-06/
...

=의 좌측이 컬럼 이름, 우측이 값으로 인식됩니다.

source_type=rds_error
컬럼 이름 값

경로만 보고도 데이터의 내용을 이해할 수 있고, Athena나 AWS Glue와 같은 AWS 서비스와도 연계하기 쉽기 때문에, 이번 로그 분석에서는 Hive 형식을 이용하는 것이 이해하기 쉽습니다.

Path Tail 형식에서는 폴더 이름에 값만 저장합니다.

<table>/
rds_error/
2026-07-06/
...

이 경우, 경로만으로는 각 값이 무엇을 나타내는지 판단할 수 없으므로, 외부 테이블 (External Table) 정의 시 파티션 컬럼을 순서대로 지정해야 합니다.

1번째 폴더:
source_type
2번째 폴더:
...

Path Tail 형식에서는 폴더 값의 순서와 지정하는 파티션 컬럼의 순서를 일치시켜야 합니다.

Hive 형식의 S3 데이터를 암시적 파티셔닝이 적용된 외부 테이블로 생성하는 예시입니다.

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'EXT_LOG_EVENT_COMMON',
...

implicit_partition_config에서는 다음과 같이 지정하고 있습니다.

partition_type:
hive
partition_columns:
...

Parquet, Avro, ORC와 같은 구조화된 파일(Structured File)은 파일 내부의 스키마 (Schema)를 이용할 수 있으므로, column_list를 생략할 수 있습니다. 파티션 컬럼은 partition_columns로 지정한 S3 경로로부터 도출됩니다.

생성한 외부 테이블에 대해서는 일반 테이블과 동일하게 질의(Query)할 수 있습니다.

SELECT
source_type,
dt,
...

이 SQL에서는 지정한 source_type, dt, hour에 해당하는 파티션 파일만을 대상으로 할 수 있습니다.

또한, file_uri_list에서 와일드카드 (Wildcard)를 사용하는 경우, 와일드카드는 마지막 슬래시(/) 뒤에 지정합니다.

strict_column_order=true는 매우 많은 파일이나 서브 폴더를 가진 Hive 형식의 데이터에서, 질의 실행 전의 경로 목록 취득이나 계획 (Planning) 시간을 단축하기 위한 최적화입니다.

ADB는 미리 정의된 파티션 컬럼의 순서를 이용하여, 검색 조건과 관계없는 디렉터리를 빠른 단계에서 건너뛸 (Skip) 수 있습니다.

단, 모든 S3 경로에서 파티션 컬럼이 동일한 순서로 나열되고, 중간에 컬럼이 누락되지 않는 경우에만 true를 지정합니다.

source_type=<value>/dt=<value>/hour=<value>/

예를 들어, 다음과 같이 모든 경로가 통일되어 있어야 합니다.

source_type=rds_error/dt=2026-07-06/hour=00/
source_type=rds_audit/dt=2026-07-06/hour=01/
source_type=app_log/dt=2026-07-07/hour=00/

반면, 다음과 같이 컬럼이 누락되거나 순서가 바뀌는 경우에는 사용할 수 없습니다.

source_type=rds_error/dt=2026-07-06/hour=00/
source_type=app_log/hour=00/
dt=2026-07-06/source_type=rds_audit/hour=00/

폴더 구성이 일정하지 않은 경우에는 strict_column_order를 false로 설정하거나 생략합니다.

또한, 운용 시작 후에 파티션 컬럼의 추가, 삭제, 정렬 등으로 폴더 규칙을 변경한 경우에는 partition_columns도 업데이트하고, 필요에 따라 strict_column_order

를 비활성화합니다.

경로 규칙이 고정되어 있는 경우:
strict_column_order = true
경로 규칙이 일정하지 않은 경우:
...

암묵적 파티셔닝 (Implicit Partitioning)은 단순히 S3의 폴더를 열 (column)로 보여주는 것만이 아닙니다.

S3 상의 파티션 구조
↓
쿼리 시 열과 값을 검출
...

이 메커니즘을 통해 대량 로그의 전체를 ADB (Autonomous Database)로 가져오지 않고, S3에 둔 채로 효율적으로 SQL 분석을 수행할 수 있습니다.

외부 테이블 (External Table)은 S3 상의 데이터를 ADB 내부로 복사하지 않고, 그대로 SQL로 참조할 수 있는 편리한 메커니즘입니다.

한편, 외부 테이블의 성능은 ADB와 S3 간의 네트워크, 읽어들이는 데이터 양, 파일 형식, 파일 수, 파일 크기, 파티션 설계, SQL 검색 조건 등에 영향을 받습니다.

따라서 처음부터 모든 로그를 ADB 내부로 가져오는 것이 아니라, 먼저 다음과 같은 사항을 최적화합니다.

Raw Log를 Curated Parquet로 변환
적절한 파일 크기로 통합
source_type, dt, hour 등으로 파티셔닝
...

특히 Parquet는 열 지향 형식 (Columnar format)이기 때문에, 쿼리에 필요한 열을 중심으로 읽을 수 있다는 점이 대량 로그 분석에 적합합니다.

그 후에 참조 빈도나 처리 내용에 따라 다음 세 가지 선택지를 검토합니다.

1. Lake Cache
→ 빈번하게 참조하는 외부 데이터를 ADB 내부로 캐싱
2. Data Lake Accelerator
...

이 세 가지는 동일한 목적의 대체 기능이 아닙니다.

Lake Cache는 외부 테이블이나 Mounted Catalog Table에서 빈번하게 참조하는 데이터를 Autonomous AI Database 내부로 캐싱하는 기능입니다.

일반적인 외부 테이블 액세스:
SQL
↓
...

Lake Cache는 애플리케이션에 대해 투명하게(transparently) 이용되므로, 기존의 외부 테이블을 참조하는 SQL이나 대시보드를 수정하지 않고도 캐싱된 데이터를 ADB 내부에서 읽을 수 있습니다.

다음과 같은 용도에 적합합니다.

• 매일 동일한 기간의 로그를 참조하는 대시보드
• 동일한 Parquet 데이터를 반복적으로 스캔하는 정형 보고서 (Regular report)
• 최근 7일 또는 30일의 로그를 빈번하게 조사하는 처리
• 여러 사용자가 동일한 외부 테이블에 액세스하는 환경
• 다른 Cloud나 다른 Region으로의 반복적인 액세스를 줄이고 싶은 경우
• Gold 테이블을 별도로 생성하지 않고, 기존의 외부 테이블 SQL을 가속화하고 싶은 경우

Lake Cache를 생성하여 외부 테이블 전체를 캐싱하는 예시입니다.

BEGIN
DBMS_EXT_TABLE_CACHE.CREATE_CACHE(
owner => 'LOG_ANALYTICS',
...

캐시는 생성 직후에는 비어 있으며, ADD_TABLE 등으로 대상 파일을 등록합니다. 최근에 업데이트된 파일만 캐싱할 수도 있습니다.

BEGIN
DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES(
owner => 'LOG_ANALYTICS',
...

Lake Cache에서는 테이블 전체뿐만 아니라 일부 파일이나 열을 선택하여 캐싱할 수도 있습니다. 캐시는 스키마의 Quota와 ADB 내부 스토리지를 사용하므로, 전 기간을 무조건 캐싱하는 것이 아니라 액세스 빈도가 높은 기간이나 열로 좁히는 것이 포인트입니다.

또한, Lake Cache에는 대상 파일의 추가, Refresh, Retire 등을 명시적으로 관리하는 Policy-based 방식과, 워크로드에 따라 Database가 관리하는 Automatic 방식이 있습니다.

주의할 점은, Policy-based 방식의 캐시는 S3 측에서 파일이 업데이트되어도 자동으로 반영되지 않는다는 것입니다. 업데이트된 파일은 재 Populate가 필요하며, S3 측에서 삭제된 파일의 캐시는 즉시 무효화됩니다.

로그와 같은 추가형 (Append-only) 데이터의 경우에는 Gold 테이블로의 일간 데이터 적재와 마찬가지로, ADD_LATEST_FILES를 DBMS_SCHEDULER로 잡 (Job)화하여 신규 파일을 정기적으로 캐시로 추가하는 운영 방식이 궁합이 좋습니다.

참고로, Lake Cache는 Oracle AI Database 26ai부터 제공되는 기능입니다. 이용하려는 Autonomous AI Database의 버전과 서비스 구성을 사전에 확인하시기 바랍니다.

Data Lake Accelerator는 Object Storage 상의 외부 데이터를 스캔(Scan), 필터링(Filtering), 투영(Projection), 압축 해제(Decompression)하는 처리를 Oracle이 관리하는 전용 Compute로 오프로드(Offload)하는 기능입니다.

Lake Cache가 "빈번하게 참조하는 데이터를 ADB 내부로 가져오는" 기능인 반면, Data Lake Accelerator는 "외부 데이터를 처리하는 계산 능력을 확장하는" 기능입니다.

Lake Cache:
빈번하게 읽는 데이터를 ADB 내부로 캐시(Cache)함
→ 동일한 데이터의 반복 참조에 적합
...

다음과 같은 용도에 적합합니다.

• 수 TB 이상의 Parquet 데이터를 광범위하게 검색할 때
• 장기간의 로그를 횡단적으로 집계할 때
• 애드혹(Ad-hoc) 조사에서 대량의 외부 데이터를 스캔할 때
• 월간 또는 연간 대규모 집계를 실행할 때
• 외부 테이블(External Table)에 대한 동시 액세스가 증가할 때
• 외부 데이터 스캔으로 인해 ADB 본체의 Compute 자원이 압박받는 것을 방지하고 싶을 때

예를 들어, 다음과 같이 장기간의 로그를 횡단 집계하는 처리에서는, 최근 데이터를 캐시하는 Lake Cache보다 Data Lake Accelerator를 통해 스캔 능력을 확장하는 것이 더 적합할 수 있습니다.

SELECT
source_type,
service_name,
...