AWS Study Group

Làm tan băng — Cách Natural Intelligence đơn giản hóa việc di chuyển data lake sang Apache Iceberg

Tác giả: Yonatan Dolan và Haya Axelrod Stern, Zion Rubin, Michał Urbanowicz
Ngày đăng: 28/04/2025
Danh mục: Advanced (300), Analytics, AWS Glue, Best Practices, Case Study, Technical How-to

Bài viết này được đồng tác giả cùng Haya Axelrod Stern, Zion Rubin và Michał Urbanowicz từ Natural Intelligence.

Nhiều tổ chức lựa chọn data lake để có được sự linh hoạt và khả năng mở rộng cần thiết nhằm quản lý khối lượng lớn dữ liệu có cấu trúc và phi cấu trúc. Tuy nhiên, việc di chuyển một data lake hiện có sang một định dạng bảng mới như Apache Iceberg có thể mang lại những thách thức đáng kể cả về mặt kỹ thuật lẫn tổ chức.

Natural Intelligence (NI) là đơn vị dẫn đầu toàn cầu trong lĩnh vực marketplace đa danh mục. Các thương hiệu hàng đầu của NI như Top10.com và BestMoney.com giúp hàng triệu người trên toàn thế giới đưa ra các quyết định sáng suốt mỗi ngày. Gần đây, NI đã bắt đầu hành trình chuyển đổi data lake kế thừa của mình từ Apache Hive sang Apache Iceberg.

Trong bài blog này, NI chia sẻ hành trình của họ, các giải pháp sáng tạo đã được xây dựng, cũng như những bài học quan trọng có thể giúp định hướng cho các tổ chức khác đang cân nhắc con đường tương tự.

Bài viết tập trung mô tả cách tiếp cận thực tế của NI đối với quá trình di chuyển phức tạp này — ít đi sâu vào đặc tả kỹ thuật của Apache Iceberg, mà tập trung nhiều hơn vào các thách thức trong thực tế và những giải pháp đã được áp dụng khi chuyển sang Apache Iceberg, một vấn đề mà nhiều tổ chức hiện nay đang phải đối mặt.

Vì sao chọn Apache Iceberg?

Kiến trúc dữ liệu tại NI tuân theo mô hình medallion architecture phổ biến, bao gồm ba tầng bronze–silver–gold, như minh họa trong hình sau:

  • Bronze layer: Dữ liệu thô chưa xử lý từ nhiều nguồn khác nhau, được lưu trữ dưới định dạng gốc trong Amazon Simple Storage Service (Amazon S3), và được ingest thông qua Apache Kafka brokers.
  • Silver layer: Chứa dữ liệu đã được làm sạch và enrich, được xử lý bằng Apache Flink.
  • Gold layer: Lưu trữ các tập dữ liệu sẵn sàng cho phân tích, phục vụ BI và reporting, được tạo ra bằng các pipeline Apache Spark và được tiêu thụ bởi các dịch vụ như Snowflake, Amazon Athena, Tableau và Apache Druid. Dữ liệu được lưu ở định dạng Apache Parquet, với metadata được quản lý bởi AWS Glue Catalog.
BDB4681-Arch1

Mặc dù kiến trúc này đáp ứng tốt nhu cầu phân tích của NI, nó lại thiếu đi sự linh hoạt cần thiết cho một nền tảng dữ liệu thực sự mở và dễ thích nghi. Tầng gold chỉ có thể hoạt động với các query engine hỗ trợ Hive và AWS Glue Data Catalog. Dù có thể sử dụng Amazon Athena, Snowflake lại yêu cầu phải duy trì một catalog khác để truy vấn các external table này.

Vấn đề này khiến việc đánh giá hoặc áp dụng các công cụ và engine thay thế trở nên khó khăn nếu không chấp nhận việc nhân bản dữ liệu tốn kém, viết lại truy vấn và đồng bộ data catalog. Khi quy mô kinh doanh mở rộng, NI cần một nền tảng dữ liệu có thể hỗ trợ đồng thời nhiều query engine với một data catalog duy nhất, đồng thời tránh vendor lock-in.

Sức mạnh của Apache Iceberg

Apache Iceberg nổi lên như một giải pháp lý tưởng — một định dạng bảng mở, linh hoạt, phù hợp với chiến lược Data Lake First của NI. Iceberg mang lại nhiều lợi ích quan trọng như ACID transactions, schema evolution, time travel, cải thiện hiệu năng và nhiều hơn nữa. Tuy nhiên, giá trị chiến lược lớn nhất nằm ở khả năng hỗ trợ đồng thời nhiều query engine.

Các lợi ích nổi bật bao gồm:

  • Tách biệt storage và compute: Định dạng bảng mở cho phép tách lớp lưu trữ khỏi query engine, giúp dễ dàng thay thế và hỗ trợ nhiều engine song song mà không cần nhân bản dữ liệu.
  • Độc lập nhà cung cấp: Là một định dạng bảng mở, Apache Iceberg giúp tránh vendor lock-in và mang lại sự linh hoạt khi nhu cầu phân tích thay đổi.
  • Hệ sinh thái rộng: Apache Iceberg được hỗ trợ rộng rãi bởi các nền tảng và công cụ lớn, đảm bảo khả năng tích hợp liền mạch và tính bền vững lâu dài.

Bằng việc chuyển sang Iceberg, NI đã xây dựng được một nền tảng dữ liệu mở thực sự, mang lại tính linh hoạt, khả năng mở rộng và khả năng tương tác lâu dài, đồng thời vẫn duy trì một nguồn dữ liệu duy nhất (single source of truth) cho toàn bộ nhu cầu phân tích và báo cáo.

Những thách thức gặp phải

Việc di chuyển một data lake production đang hoạt động sang Iceberg là một thách thức lớn do các yếu tố vận hành phức tạp và ràng buộc từ hệ thống kế thừa. Dịch vụ dữ liệu tại NI vận hành hàng trăm pipeline Spark và machine learning, quản lý hàng nghìn bảng dữ liệu, và hỗ trợ hơn 400 dashboard — tất cả đều hoạt động 24/7. Bất kỳ quá trình migration nào cũng phải được thực hiện không gây gián đoạn hệ thống production; việc điều phối một quá trình chuyển đổi như vậy trong khi mọi hoạt động vẫn phải diễn ra trơn tru là một bài toán rất khó.

NI cần phải đáp ứng nhiều nhóm người dùng khác nhau, từ data engineer, data analyst cho đến data scientist và các đội BI, mỗi nhóm có yêu cầu và lộ trình chuyển đổi khác nhau.

Thách thức càng lớn hơn khi xét đến các ràng buộc từ hệ thống cũ. Một số công cụ hiện tại chưa hỗ trợ đầy đủ Iceberg, do đó vẫn cần duy trì các bảng dựa trên Hive để đảm bảo khả năng tương thích. NI nhận ra rằng không phải tất cả consumer đều có thể chuyển sang Iceberg ngay lập tức. Vì vậy, cần có một kế hoạch cho phép chuyển đổi dần dần, không downtime và không làm gián đoạn các hoạt động hiện tại.

Các trụ cột chính cho quá trình migration

Để đảm bảo quá trình chuyển đổi diễn ra suôn sẻ và thành công, NI đã xác định sáu trụ cột quan trọng:

  • Hỗ trợ vận hành liên tục: Duy trì khả năng tương thích với các hệ thống và workflow hiện có trong suốt quá trình migration.
  • Minh bạch với người dùng: Giảm thiểu tác động tới người dùng bằng cách giữ nguyên tên bảng và cách truy cập dữ liệu.
  • Chuyển đổi consumer theo từng giai đoạn: Cho phép các consumer chuyển sang Iceberg theo tốc độ riêng, tránh việc bắt buộc chuyển đổi đồng loạt.
  • Linh hoạt ETL: Di chuyển các pipeline ETL sang Iceberg mà không áp đặt ràng buộc lên quá trình phát triển hay triển khai.
  • Tối ưu chi phí: Giảm thiểu việc nhân bản storage và compute trong giai đoạn migration.
  • Giảm công sức vận hành: Hạn chế gánh nặng quản lý song song hai định dạng bảng (Hive và Iceberg) trong thời gian chuyển tiếp.

Đánh giá các phương pháp migration truyền thống

Apache Iceberg hỗ trợ hai phương pháp migration chính: In-place và Rewrite-based.

Migration kiểu In-place

Cách hoạt động: Chuyển đổi tập dữ liệu hiện có thành bảng Iceberg bằng cách tạo metadata Iceberg trên các file dữ liệu hiện hữu, không cần nhân bản dữ liệu và vẫn giữ nguyên layout cũng như định dạng file.

Ưu điểm:

  • Tiết kiệm chi phí lưu trữ (không nhân bản dữ liệu)
  • Triển khai đơn giản
  • Giữ nguyên tên bảng và vị trí lưu trữ
  • Không cần di chuyển dữ liệu và yêu cầu compute tối thiểu, giúp giảm chi phí

Nhược điểm:

  • Yêu cầu downtime: Mọi thao tác ghi phải dừng lại trong quá trình chuyển đổi — điều này không thể chấp nhận với NI vì dữ liệu và phân tích được xem là hệ thống trọng yếu, hoạt động 24/7
  • Không hỗ trợ chuyển đổi dần: Tất cả consumer buộc phải chuyển sang Iceberg cùng lúc, làm tăng rủi ro gián đoạn
  • Khả năng kiểm chứng hạn chế: Không có cơ hội validate dữ liệu trước khi cutover; rollback yêu cầu khôi phục từ backup
  • Ràng buộc kỹ thuật: Schema evolution trong quá trình migration khó khăn; không tương thích kiểu dữ liệu có thể làm dừng toàn bộ quy trình

Migration kiểu Rewrite-based

Cách hoạt động: Migration dạng rewrite tạo một bảng Iceberg mới bằng cách ghi lại và tái cấu trúc toàn bộ dữ liệu hiện có sang định dạng và cấu trúc tối ưu của Iceberg nhằm cải thiện hiệu năng và khả năng quản lý dữ liệu.

Ưu điểm:

  • Không downtime trong quá trình migration
  • Hỗ trợ chuyển đổi consumer theo từng giai đoạn
  • Cho phép kiểm chứng dữ liệu kỹ lưỡng
  • Cơ chế rollback đơn giản

Nhược điểm:

  • Tốn tài nguyên: Chi phí storage và compute tăng gấp đôi trong thời gian migration
  • Phức tạp vận hành: Quản lý song song hai pipeline dữ liệu làm tăng gánh nặng vận hành
  • Khó đảm bảo tính nhất quán: Việc duy trì dữ liệu đồng bộ tuyệt đối giữa hai hệ thống là rất khó
  • Ảnh hưởng hiệu năng: Độ trễ tăng do ghi dữ liệu kép; pipeline có thể bị chậm lại

Vì sao không phương án nào là đủ tốt?

NI nhận thấy rằng không phương án nào trong hai cách trên đáp ứng đầy đủ các yêu cầu quan trọng:

  • Migration in-place không phù hợp do downtime không thể chấp nhận và không hỗ trợ chuyển đổi dần.
  • Migration rewrite-based không phù hợp do chi phí quá cao và độ phức tạp trong vận hành.

Phân tích này đã dẫn NI đến việc xây dựng một giải pháp hybrid, kết hợp ưu điểm của cả hai phương pháp và giảm thiểu tối đa các hạn chế.

Giải pháp hybrid

Chiến lược migration hybrid được thiết kế dựa trên năm thành phần nền tảng, tận dụng các dịch vụ phân tích của AWS cho orchestration, xử lý dữ liệu và quản lý trạng thái.

  1. Hive-to-Iceberg CDC: Tự động đồng bộ các bảng Hive sang Iceberg thông qua cơ chế change data capture (CDC) tùy chỉnh nhằm hỗ trợ các consumer hiện tại. Khác với CDC truyền thống tập trung vào thay đổi theo từng dòng, quy trình này hoạt động ở mức partition để phù hợp với cách Hive cập nhật dữ liệu bằng việc overwrite partition. Điều này giúp đảm bảo tính nhất quán giữa Hive và Iceberg mà không cần thay đổi logic ETL trong giai đoạn migration.
  2. Đồng bộ schema liên tục: Schema evolution trong quá trình migration tạo ra nhiều thách thức vận hành. Các tiến trình đồng bộ schema tự động được xây dựng để so sánh schema giữa Hive và Iceberg, xử lý sự khác biệt và vẫn đảm bảo tương thích kiểu dữ liệu.
  3. Iceberg-to-Hive reverse CDC: Cho phép đội dữ liệu chuyển các ETL job sang ghi trực tiếp vào Iceberg, đồng thời vẫn duy trì các pipeline dựa trên Hive chưa được migrate. Reverse CDC giúp Iceberg ghi dữ liệu nhưng vẫn cập nhật các bảng Hive cho các hệ thống downstream phụ thuộc.
  4. Quản lý alias trong Snowflake: Alias trong Snowflake đảm bảo các bảng Iceberg vẫn giữ nguyên tên gốc, giúp quá trình chuyển đổi trở nên trong suốt đối với người dùng. Cách tiếp cận này giảm thiểu đáng kể công sức cấu hình lại cho các đội và workflow liên quan.
  5. Thay thế bảng (Table replacement): Hoán đổi các bảng production trong khi vẫn giữ nguyên tên bảng ban đầu, hoàn tất quá trình migration.

Phân tích kỹ thuật chuyên sâu (Technical deep dive)

Quá trình migration từ Hive sang Iceberg được xây dựng theo nhiều bước rõ ràng như sau.

1. Pipeline Hive-to-Iceberg CDC

Mục tiêu: Giữ cho các bảng Hive và Iceberg luôn được đồng bộ mà không tạo ra công việc trùng lặp.

Hình trên minh họa cách mỗi partition được ghi vào bảng Hive sẽ tự động và minh bạch được sao chép sang bảng Iceberg thông qua cơ chế CDC. Quy trình này đảm bảo hai bảng luôn được đồng bộ, cho phép migration diễn ra dần dần và liền mạch mà không làm gián đoạn các hệ thống downstream.

NI lựa chọn đồng bộ ở mức partition vì các ETL Hive legacy vốn đã cập nhật dữ liệu bằng cách overwrite toàn bộ partition và cập nhật lại partition location. Việc áp dụng cùng cách tiếp cận này trong CDC pipeline giúp giữ nguyên hành vi quản lý dữ liệu ban đầu, giúp migration diễn ra mượt mà hơn và tránh phải viết lại logic xử lý ở mức row.

Triển khai:

  • Để đồng bộ Hive và Iceberg mà không tạo thêm chi phí dư thừa, NI xây dựng một pipeline tinh gọn. Bất cứ khi nào partition trong bảng Hive được cập nhật, AWS Glue Catalog sẽ phát ra các sự kiện như UpdatePartition.
    Amazon EventBridge bắt các sự kiện này, lọc theo database và table quan tâm dựa trên rule đã cấu hình, sau đó kích hoạt một hàm AWS Lambda.
  • Hàm Lambda phân tích metadata của sự kiện và gửi thông tin partition thay đổi vào một Apache Kafka topic.
  • Một Spark job chạy trên Amazon EMR tiêu thụ message từ Kafka (chứa thông tin partition được cập nhật từ các sự kiện Data Catalog). Dựa trên metadata này, Spark job truy vấn bảng Hive tương ứng và ghi dữ liệu sang bảng Iceberg trong Amazon S3 bằng API overwritePartitions của Spark Iceberg, như ví dụ sau:
{
   "id":"10397e54-c049-fc7b-76c8-59e148c7cbfc",
   "detail-type":"Glue Data Catalog Table State Change",
   "source":"aws.glue",
   "time":"2024-10-27T17:16:21Z",
   "region":"us-east-1",
   "detail":{
      "databaseName":"dlk_visitor_funnel_dwh_production",
      "changedPartitions":[
         "2024-10-27"
      ],
      "typeOfChange":"UpdatePartition",
      "tableName":"fact_events"
   }
}
  • Bằng cách chỉ xử lý các partition đã thay đổi, pipeline (được minh họa trong hình sau) đã giảm đáng kể nhu cầu rewrite toàn bộ bảng — vốn rất tốn kém. Các lớp metadata mạnh mẽ của Iceberg, bao gồm snapshot và manifest file, được cập nhật liền mạch để phản ánh các thay đổi này, đảm bảo đồng bộ chính xác và hiệu quả giữa Hive và Iceberg.

2. Pipeline Iceberg-to-Hive reverse CDC

Mục tiêu: Tiếp tục hỗ trợ các consumer sử dụng Hive trong khi cho phép các pipeline ETL chuyển dần sang Iceberg.

BDB4681-arch4

Hình trên mô tả quy trình ngược lại: mỗi partition được ghi vào bảng Iceberg sẽ tự động và minh bạch được sao chép sang bảng Hive thông qua một cơ chế CDC. Điều này giúp đảm bảo dữ liệu luôn đồng bộ cho các hệ thống legacy vẫn còn phụ thuộc vào Hive trong giai đoạn chuyển đổi sang Iceberg.

Triển khai:

Đồng bộ dữ liệu từ Iceberg về Hive đặt ra một thách thức khác. Không giống Hive, AWS Glue Catalog không theo dõi các thay đổi partition của bảng Iceberg, vì partition trong Iceberg được quản lý nội bộ thay vì nằm trong Data Catalog. Do đó, NI không thể dựa vào các sự kiện từ Glue Catalog để phát hiện thay đổi.

Để giải quyết vấn đề này, NI triển khai một giải pháp tương tự luồng trước, nhưng được điều chỉnh phù hợp với kiến trúc của Iceberg. Apache Spark được sử dụng để truy vấn các bảng metadata của Iceberg — cụ thể là bảng snapshots và entries — nhằm xác định các partition đã thay đổi kể từ lần đồng bộ gần nhất. Câu truy vấn được sử dụng như sau:

SELECT e.data_file.partition, MAX(s.committed_at) AS last_modified_time 
FROM $target_table.snapshots 
JOIN $target_table.entries e 
  ON s.snapshot_id = e.snapshot_id 
WHERE s.committed_at > '$last_sync_time' 
GROUP BY e.data_file.partition;

Câu truy vấn này chỉ trả về những partition đã được cập nhật kể từ lần đồng bộ trước đó, cho phép hệ thống tập trung xử lý đúng phần dữ liệu thay đổi. Dựa trên kết quả này, tương tự như pipeline trước, một Spark job sẽ đọc các partition đã cập nhật từ Iceberg và ghi ngược lại vào bảng Hive tương ứng, đảm bảo đồng bộ liền mạch giữa hai hệ thống.

3. Đồng bộ schema liên tục (Continuous schema synchronization)

Mục tiêu: Tự động hóa việc cập nhật schema để đảm bảo tính nhất quán giữa Hive và Iceberg.

BDB4681-arch5

Hình trên minh họa cách quy trình đồng bộ schema tự động giúp đảm bảo schema giữa bảng Hive và Iceberg luôn nhất quán. Trong ví dụ này, một cột mới Channel được thêm vào, giảm thiểu công việc thủ công và việc phải bảo trì song song trong suốt giai đoạn migration kéo dài.

Triển khai:

Để xử lý các thay đổi schema giữa Hive và Iceberg, NI xây dựng một quy trình tự động phát hiện và đối soát sự khác biệt. Khi schema của một bảng Hive thay đổi, Data Catalog sẽ phát ra sự kiện UpdateTable. Sự kiện này (được chuyển tiếp qua EventBridge) sẽ kích hoạt một hàm Lambda, hàm này lấy schema mới nhất của bảng Hive từ Data Catalog và so sánh với schema của bảng Iceberg.

Cần lưu ý rằng trong kiến trúc của NI, các thay đổi schema luôn xuất phát từ Hive, vì bảng Iceberg được ẩn phía sau các alias trong toàn bộ hệ thống. Do Iceberg chủ yếu được sử dụng cho Snowflake, nên việc đồng bộ một chiều từ Hive sang Iceberg là đủ. Vì vậy, không cần cơ chế phát hiện hay xử lý các thay đổi schema được tạo trực tiếp trên Iceberg trong workflow hiện tại.

Trong quá trình đối soát schema (được minh họa trong hình tiếp theo), các kiểu dữ liệu được chuẩn hóa để đảm bảo tương thích — ví dụ chuyển VARCHAR của Hive sang STRING của Iceberg. Các field mới hoặc thay đổi kiểu dữ liệu sẽ được validate và áp dụng vào schema Iceberg thông qua một Spark job chạy trên Amazon EMR.
Amazon DynamoDB được sử dụng để lưu checkpoint của quá trình đồng bộ schema, cho phép theo dõi lịch sử thay đổi và đảm bảo tính nhất quán lâu dài giữa Hive và Iceberg.

BDB4681-arch6

Việc tự động hóa đồng bộ schema đã giúp giảm đáng kể chi phí vận hành và giải phóng các developer khỏi việc phải duy trì schema thủ công, khiến giai đoạn migration dài trở nên dễ quản lý hơn rất nhiều.

Hình trên mô tả một workflow tự động nhằm duy trì tính nhất quán schema giữa các bảng Hive và Iceberg. AWS Glue ghi nhận các sự kiện thay đổi trạng thái bảng từ Hive, sau đó kích hoạt một sự kiện trên Amazon EventBridge. Sự kiện này gọi một hàm Lambda, hàm này sẽ lấy metadata từ DynamoDB và so sánh schema được lấy từ AWS Glue cho cả bảng Hive và Iceberg. Nếu phát hiện sự khác biệt, schema của Iceberg sẽ được cập nhật để đảm bảo đồng bộ, giảm thiểu tối đa can thiệp thủ công và hỗ trợ vận hành ổn định trong suốt quá trình migration.

4. Quản lý alias trong Snowflake

Mục tiêu: Cho phép các consumer trên Snowflake sử dụng Iceberg mà không cần thay đổi các truy vấn hiện có.

Hình trên cho thấy cách Snowflake alias cho phép migration diễn ra liền mạch bằng cách ánh xạ các truy vấn như
SELECT platform, COUNT(clickouts) FROM funnel.clickouts
sang các bảng Iceberg trong Glue Catalog. Ngay cả khi các suffix được thêm vào trong quá trình migration Iceberg, các truy vấn và workflow hiện có vẫn không thay đổi, giúp giảm thiểu tác động đến các công cụ BI và analyst.

Triển khai:

Để đảm bảo trải nghiệm liền mạch cho các công cụ BI và analyst trong suốt quá trình migration, NI sử dụng Snowflake alias để ánh xạ các external table đến metadata Iceberg được lưu trữ trong Data Catalog. Bằng cách gán alias trùng với tên bảng Hive ban đầu, các truy vấn và báo cáo hiện có được giữ nguyên mà không bị gián đoạn.

Ví dụ, một external table được tạo trong Snowflake và alias về tên bảng gốc như sau:

CREATE OR REPLACE ICEBERG TABLE dlk_visitor_funnel_dwh_production.aggregated_cost 
EXTERNAL_VOLUME = 's3_dlk_visitor_funnel_dwh_production_iceberg_migration' 
CATALOG = 'glue_dlk_visitor_funnel_dwh_production_iceberg_migration' 
CATALOG_TABLE_NAME = 'aggregated_cost'; 

ALTER ICEBERG TABLE dlk_visitor_funnel_dwh_production.aggregated_cost REFRESH;

Khi migration hoàn tất, chỉ cần thay đổi alias để trỏ về location hoặc schema mới, giúp quá trình chuyển đổi diễn ra mượt mà và gần như không ảnh hưởng đến workflow của người dùng.

5. Thay thế bảng (Table replacement)

Mục tiêu: Khi toàn bộ ETL và các workflow dữ liệu liên quan đã được chuyển sang sử dụng Apache Iceberg và các cơ chế đồng bộ hoạt động ổn định, bước cuối cùng là hoàn tất migration bằng cách giữ nguyên tên bảng gốc, tránh sử dụng các prefix trung gian như trong các giai đoạn trước. Điều này giúp cấu hình hệ thống gọn gàng và dễ quản lý hơn.

Hình trên minh họa bước hoàn tất migration, trong đó Hive trên Amazon EMR được sử dụng để đăng ký các file Parquet thành bảng Iceberg, đồng thời giữ nguyên tên bảng ban đầu và tránh việc nhân bản dữ liệu.

Triển khai:

Một trong những thách thức là AWS Glue không hỗ trợ đổi tên bảng, nên không thể áp dụng cách rename trực tiếp cho các bảng đang được đồng bộ. Ngoài ra, AWS Glue cũng không hỗ trợ thủ tục Migrate, vốn cho phép tạo metadata Iceberg trên các file dữ liệu hiện có mà vẫn giữ nguyên tên bảng.

Để vượt qua hạn chế này, NI sử dụng Hive metastore trên một cluster Amazon EMR. Hive trên Amazon EMR hoạt động trong một môi trường metastore tách biệt, cho phép linh hoạt định nghĩa schema và tên bảng mà không bị xung đột với Glue Catalog.

Thủ tục add_files được sử dụng để lần lượt đăng ký toàn bộ các file Parquet hiện có, từ đó xây dựng đầy đủ metadata trong Hive. Đây là bước then chốt nhằm đảm bảo mọi file dữ liệu đều được catalog hóa chính xác trong metastore.

Hình trên minh họa việc chuyển một bảng production sang Iceberg bằng cách sử dụng thủ tục add_files để đăng ký các file Parquet hiện có và tạo metadata Iceberg. Cách tiếp cận này đảm bảo migration diễn ra mượt mà, giữ nguyên dữ liệu gốc và tránh nhân bản không cần thiết.

Cách thiết lập này cho phép tái sử dụng các file Parquet hiện có mà không cần sao chép dữ liệu, từ đó tiết kiệm tài nguyên. Mặc dù luồng đồng bộ sử dụng các bucket riêng cho kiến trúc cuối cùng, NI quyết định giữ nguyên các bucket ban đầu và dọn dẹp các file trung gian. Điều này dẫn đến cấu trúc thư mục khác nhau trên Amazon S3: dữ liệu lịch sử có các thư mục con cho từng partition nằm trực tiếp dưới thư mục bảng gốc, trong khi dữ liệu Iceberg mới được tổ chức trong thư mục data. Sự khác biệt này được chấp nhận để tránh nhân bản dữ liệu và bảo toàn các bucket Amazon S3 ban đầu.

Tóm tắt kỹ thuật (Technical recap)

AWS Glue Data Catalog đóng vai trò là nguồn dữ liệu chuẩn (single source of truth) cho các cập nhật schema và bảng. Amazon EventBridge thu thập các sự kiện từ Data Catalog để kích hoạt các workflow đồng bộ. AWS Lambda phân tích metadata sự kiện và quản lý việc đồng bộ schema, trong khi Apache Kafka đóng vai trò buffer cho xử lý near real-time. Apache Spark trên Amazon EMR đảm nhiệm việc transform dữ liệu và cập nhật gia tăng, còn Amazon DynamoDB lưu trữ trạng thái hệ thống, bao gồm checkpoint đồng bộ và mapping bảng. Cuối cùng, Snowflake tiêu thụ các bảng Iceberg thông qua alias mà không làm gián đoạn các workflow hiện có.

Kết quả migration

Quá trình migration được hoàn tất với zero downtime; toàn bộ hệ thống vẫn hoạt động liên tục, hỗ trợ hàng trăm pipeline và dashboard mà không bị gián đoạn. Migration được thực hiện với tư duy tối ưu chi phí, sử dụng các cập nhật gia tăng và đồng bộ ở mức partition để giảm thiểu tài nguyên compute và storage.

Quan trọng hơn, NI đã xây dựng thành công một nền tảng dữ liệu hiện đại, trung lập với nhà cung cấp (vendor-neutral), cho phép mở rộng linh hoạt các nhu cầu phân tích và machine learning trong tương lai. Nền tảng này hỗ trợ tích hợp liền mạch với nhiều compute và query engine, tạo tiền đề cho sự đổi mới liên tục.

Kết luận

Việc Natural Intelligence di chuyển sang Apache Iceberg là một bước ngoặt quan trọng trong quá trình hiện đại hóa hạ tầng dữ liệu của công ty. Thông qua việc áp dụng chiến lược hybrid và khai thác sức mạnh của kiến trúc event-driven, NI đã đảm bảo một quá trình chuyển đổi liền mạch, cân bằng giữa đổi mới công nghệ và sự ổn định vận hành.

Trên hết, yếu tố kinh doanh luôn được đặt làm trọng tâm và trải nghiệm người dùng được ưu tiên hàng đầu. Nhờ đó, NI đã khai thác được tính linh hoạt và khả năng mở rộng của data lake, đồng thời giảm thiểu gián đoạn, cho phép các đội ngũ tận dụng các năng lực phân tích hiện đại, đưa tổ chức sẵn sàng cho tương lai của quản lý dữ liệu.

Nếu bạn đang cân nhắc migration sang Apache Iceberg hoặc đang đối mặt với các thách thức tương tự về hạ tầng dữ liệu, chúng tôi khuyến khích bạn khám phá các khả năng mà Iceberg mang lại. Hãy sử dụng định dạng mở, tự động hóa tối đa và thiết kế hệ thống dựa trên nhu cầu riêng của tổ chức. Hành trình có thể phức tạp, nhưng giá trị về khả năng mở rộng, linh hoạt và đổi mới là hoàn toàn xứng đáng. Bạn có thể tham khảo thêm AWS prescriptive guide để tìm hiểu cách sử dụng Apache Iceberg hiệu quả cho tổ chức của mình.

Tác giả

Yonatan Dolan là Principal Analytics Specialist tại Amazon Web Services. Yonatan là một evangelist của Apache Iceberg.

Haya Stern là Senior Director of Data tại Natural Intelligence. Cô dẫn dắt việc phát triển nền tảng dữ liệu quy mô lớn của NI, tập trung vào enable analytics, tinh gọn workflow dữ liệu và cải thiện hiệu quả phát triển. Trong năm vừa qua, cô đã lãnh đạo thành công quá trình chuyển đổi từ kiến trúc dữ liệu cũ sang kiến trúc lakehouse hiện đại dựa trên Apache Iceberg và Snowflake.

Zion Rubin là Data Architect tại Natural Intelligence với hơn mười năm kinh nghiệm thiết kế các nền tảng big data quy mô lớn. Hiện tại, anh tập trung phát triển các hệ thống intelligent agent nhằm chuyển đổi dữ liệu phức tạp thành insight kinh doanh theo thời gian thực.

Michał Urbanowicz là Cloud Data Engineer tại Natural Intelligence, có chuyên môn về migration data warehouse và triển khai các quy trình retention, cleanup và monitoring nhằm đảm bảo khả năng mở rộng và độ tin cậy của hệ thống. Anh cũng phát triển các automation để tối ưu và hỗ trợ hoạt động quản lý campaign trong môi trường cloud.

←
→

Leave a comment