Spark Storage & FileSystem Foundation

Câu hỏi

Spark đọc object storage qua abstraction nào, và vì sao đây là bypass surface lớn?

Mental model

Spark/Hadoop thường đọc path qua Hadoop FileSystem:

s3a://bucket/path
  -> fs.s3a.impl
  -> S3AFileSystem
  -> credential provider chain
  -> AWS API

Tương tự với ADLS/GCS/DBFS/local file. Config như core-site.xml quyết định scheme nào map tới implementation nào.

Vì sao đây là governance risk

Nếu user/query bị chặn ở catalog nhưng vẫn có credential đọc object storage trực tiếp, họ có thể đi vòng:

spark.read.table("secure.table")   # bị policy chặn
spark.read.parquet("s3a://raw/path") # có thể bypass nếu credential quá rộng

Vì vậy storage boundary phải gắn với identity/policy, không thể chỉ dựa vào table ACL.

Vì sao liên quan Databricks Runtime

Trong snapshot, Databricks thay/wrap rất nhiều filesystem:

• LokiFileSystem cho nhiều cloud schemes;
• CredentialScopeFileSystem cho UC credential scope;
• CredentialPassthroughFileSystem / FixedCredentialsFileSystem;
• WorkspaceLocalFileSystem cho file://;
• hadoop-safety-jars shadow class Hadoop gốc.

Để hiểu mấy thứ đó, trước hết phải hiểu fs.<scheme>.impl, credential provider chain, FileSystem cache, và raw path bypass risk.

Đọc tiếp

• Credential & Storage Boundary