NỘI DUNG
1.1 - BỐ CỤC CỦA BÀI BÁO CÁO
Bố cục của bài tiểu luận sẽ bao gồm các phần chính sau:
Lịch sử và bối cảnh của kiến trúc lưu trữ dữ liệu bắt đầu từ sự phát triển của Data Warehouse và Data Lake, nơi mà sự ra đời, ưu điểm và nhược điểm của các kiến trúc này được phân tích Điều này không chỉ cung cấp cái nhìn tổng quan về quá trình tiến hóa trong lĩnh vực lưu trữ dữ liệu mà còn làm nổi bật sự cần thiết cho sự xuất hiện của kiến trúc Data Lakehouse, nhằm đáp ứng những yêu cầu ngày càng cao trong quản lý và phân tích dữ liệu.
Kiến trúc Data Lakehouse mang lại nhiều ưu điểm vượt trội, giúp giải quyết các vấn đề tồn tại trong các kiến trúc trước đó Với tính linh hoạt và khả năng tính toán cao, kiến trúc này hỗ trợ hiệu quả cho dữ liệu phi cấu trúc và khả năng tích hợp tốt hơn Bên cạnh đó, các công nghệ và thành phần quan trọng như Apache Hadoop, Apache Spark, Delta Lake và các công cụ quản lý dữ liệu cũng đóng vai trò thiết yếu trong việc tối ưu hóa hiệu suất của Data Lakehouse.
Xây dựng ứng dụng kiến trúc Data Lakehouse bao gồm quy trình lưu trữ và xử lý dữ liệu hiệu quả Để triển khai một môi trường Data Lakehouse, cần sử dụng các công nghệ và công cụ phù hợp Quá trình này trải qua các bước quan trọng như xác định yêu cầu, thiết kế kiến trúc, triển khai hệ thống và quản lý dữ liệu.
Ứng dụng kiến trúc Data Lakehouse trong thực tế cho phép xây dựng báo cáo và hệ thống gợi ý sản phẩm hiệu quả Bài viết sẽ trình bày chi tiết các bước và quy trình phát triển, bao gồm thu thập dữ liệu, tiền xử lý dữ liệu, phân tích dữ liệu và trực quan hóa kết quả, nhằm tối ưu hóa việc triển khai các ứng dụng dựa trên Data Lakehouse.
GIỚI THIỆU
1.1 - BỐ CỤC CỦA BÀI BÁO CÁO
Bố cục của bài tiểu luận sẽ bao gồm các phần chính sau:
Lịch sử phát triển của các kiến trúc lưu trữ dữ liệu, bao gồm Data Warehouse và Data Lake, sẽ được trình bày, phân tích những ưu điểm và nhược điểm của từng kiến trúc Điều này nhằm cung cấp bối cảnh cần thiết cho sự ra đời và phát triển của kiến trúc Data Lakehouse, từ đó làm nổi bật vai trò và tầm quan trọng của nó trong việc tối ưu hóa quản lý dữ liệu hiện đại.
Kiến trúc Data Lakehouse mang lại nhiều ưu điểm vượt trội, giải quyết hiệu quả các vấn đề của các kiến trúc dữ liệu trước đó Nó nổi bật với tính linh hoạt, khả năng tính toán mạnh mẽ, hỗ trợ tốt cho dữ liệu phi cấu trúc và khả năng tích hợp đa dạng Bên cạnh đó, các công nghệ và thành phần quan trọng như Apache Hadoop, Apache Spark, Delta Lake và các công cụ quản lý dữ liệu đóng vai trò thiết yếu trong việc xây dựng và vận hành kiến trúc này.
Xây dựng ứng dụng kiến trúc Data Lakehouse bao gồm quá trình lưu trữ và xử lý dữ liệu hiệu quả Để triển khai một môi trường Data Lakehouse, cần xác định yêu cầu, thiết kế kiến trúc và triển khai hệ thống sử dụng các công nghệ và công cụ phù hợp Quản lý dữ liệu cũng là một bước quan trọng trong quá trình này.
Ứng dụng kiến trúc Data Lakehouse trong thực tế cho phép xây dựng các báo cáo và hệ thống gợi ý sản phẩm hiệu quả Bài viết sẽ trình bày chi tiết các bước và quy trình phát triển, triển khai ứng dụng, bao gồm thu thập dữ liệu, tiền xử lý dữ liệu, phân tích dữ liệu và trực quan hóa kết quả Việc áp dụng Data Lakehouse giúp tối ưu hóa quy trình xử lý và phân tích dữ liệu, mang lại giá trị thực tiễn cho doanh nghiệp.
Mục tiêu của bài viết này là cung cấp cái nhìn tổng quan về kiến trúc Data Lakehouse, bao gồm lịch sử, bối cảnh, cách xây dựng và ứng dụng thực tế Qua việc nghiên cứu chi tiết các khía cạnh này, người đọc sẽ hiểu rõ hơn về tiềm năng và lợi ích của Data Lakehouse trong việc lưu trữ và xử lý dữ liệu phi cấu trúc.
KIẾN THỨC NỀN TẢNG
Tổng quan về kiến trúc
Hình 2.2.1: Kiến trúc Data Lakehouse
Lakehouse là mô hình kết hợp giữa Data Warehouse và Data Lake, giữ lại tính AICD và cho phép lưu trữ dữ liệu không cấu trúc trong bảng Mô hình này đặc biệt hỗ trợ truy vấn dữ liệu từ các phiên bản trong quá khứ, mang lại nhiều ưu điểm nổi bật cho kiến trúc Data Lakehouse.
Lakehouse cung cấp khả năng lưu trữ dữ liệu linh hoạt, cho phép lưu trữ cả dữ liệu thô và đã được xử lý Khác với Data Lake chỉ hỗ trợ dữ liệu thô, Data Lakehouse có thể lưu trữ cả dữ liệu có cấu trúc và không cấu trúc Điều này mang lại sự đa dạng và linh hoạt trong lưu trữ dữ liệu, đồng thời vẫn đảm bảo tính ACID (atomicity, consistency, isolation, durability) mà các Data Warehouse truyền thống đã cung cấp.
Lakehouse mang lại hiệu suất tối ưu và tiết kiệm chi phí nhờ khả năng cung cấp dữ liệu với độ sẵn sàng cao, đồng thời tách biệt giữa lớp lưu trữ và lớp tính toán Việc này không chỉ giúp cải thiện hiệu suất truy vấn dữ liệu mà còn giảm thiểu chi phí Các dịch vụ lưu trữ đối tượng trên đám mây có chi phí thấp hơn so với lưu trữ truyền thống, trong khi các công cụ tính toán chỉ tính phí khi sử dụng, từ đó giúp doanh nghiệp tiết kiệm đáng kể trong việc lưu trữ và xử lý dữ liệu.
Data Lakehouse cung cấp tính năng quản lý phiên bản cho các bảng dữ liệu, cho phép người dùng truy vấn các phiên bản trước đó Tính năng này giúp theo dõi và khôi phục dữ liệu khi có sai sót hoặc lỗi, từ đó tăng cường tính linh hoạt và an ninh trong quản lý dữ liệu trong môi trường Data Lakehouse.
Những ưu điểm của kiến trúc Data Lakehouse bao gồm tính linh hoạt, hiệu suất cao, bảo mật tốt và khả năng tiết kiệm chi phí trong việc lưu trữ và xử lý dữ liệu.
Các thành phần của Data Lakehouse
Các thành phần chính của kiến trúc Data Lakehouse bao gồm:
Trong kiến trúc Data Lakehouse, dữ liệu và công cụ tính toán được tách biệt, điều này dẫn đến việc sử dụng Cloud Object Storage để lưu trữ, nhằm đảm bảo tính sẵn sàng cao cho dữ liệu trong hệ thống.
Hình 2.2.2.1: Các hệ thống lưu trữ đối tượng đám mây phổ biến
Hiện nay, các nhà cung cấp điện toán đám mây hàng đầu bao gồm Amazon Web Services, Google Cloud Platform và Microsoft Azure Mỗi nhà cung cấp này đều cung cấp dịch vụ Cloud Object Storage riêng biệt, cho phép chúng ta tận dụng để lưu trữ dữ liệu cho Data Lakehouse.
Compute Engine cung cấp nhiều công cụ tính toán mã nguồn mở cho kiến trúc Data Lakehouse, bao gồm Apache Spark, Dask, Trino, Flink và Arrow Trong số này, Apache Spark là công cụ phổ biến nhất, được Databricks áp dụng cho nền tảng Lakehouse của họ Mỗi công cụ tính toán đều có những ưu và nhược điểm riêng, do đó, lựa chọn công cụ phù hợp sẽ phụ thuộc vào từng trường hợp sử dụng cụ thể.
25 hình 2.2.2.2: Các công cụ tính toán phổ biến
Quản trị dữ liệu là một vấn đề quan trọng mà các doanh nghiệp và tổ chức cần chú trọng khi xây dựng hệ thống, nhằm đảm bảo tính toàn vẹn và an toàn cho dữ liệu trong bối cảnh dữ liệu ngày càng gia tăng Mỗi dòng dữ liệu bị mất có thể ảnh hưởng lớn đến việc giám sát doanh thu và hoạt động kinh doanh Kể từ khi bắt đầu kỷ nguyên dữ liệu lớn, các công cụ lưu trữ metadata như Apache Hive Metastore đã trở thành những giải pháp không thể thay thế.
Hình 2.2.2.3: Các hệ thống sử dụng Apache Hive Metastore
Mặc dù ra đời đã lâu, nhưng Hive Metastore vẫn tồn tại tới thời điểm bây giờ bởi nó hỗ trợ nhiều nền tảng và công cụ khác nhau
Định dạng bảng là một thành phần quan trọng trong kiến trúc Data Lakehouse, quyết định cách thức lưu trữ bảng dữ liệu Hiện tại, chỉ có ba công cụ hỗ trợ định dạng lưu trữ cho Data Lakehouse, cho phép tận dụng Cloud object storage để lưu trữ dữ liệu Những công cụ này cung cấp AICD đầy đủ như một Data Warehouse thực thụ, đồng thời hỗ trợ lưu trữ dữ liệu bán cấu trúc và không cấu trúc.
Delta Lake Databricks là sản phẩm được phát triển bởi đội ngũ sáng lập Apache Spark, một framework tính toán phân tán nổi tiếng Nhờ đó, Delta Lake cung cấp sự hỗ trợ mạnh mẽ cho Apache Spark trong việc xử lý dữ liệu.
Apache Iceberg là một định dạng hiệu suất cao dành cho các bảng phân tích lớn, cung cấp độ tin cậy và tính đơn giản cho dữ liệu lớn Nó cho phép các công cụ như Spark, Trino, Flink, Presto, Hive và Impala hoạt động đồng thời và an toàn trên cùng một bảng.
Apache Hudi là nền tảng hồ dữ liệu giao dịch, cung cấp khả năng cho cơ sở dữ liệu và kho dữ liệu trong môi trường Data Lake Hudi tái tạo quy trình xử lý dữ liệu hàng loạt thông qua khung xử lý gia tăng, cho phép phân tích dữ liệu với độ trễ thấp ở cấp độ phút.
Hình 2.2.2.4: Đo điểm của Delta Lake, Apache Hudi, Apache Iceberg bằng thời gian đọc-ghi
Theo đánh giá của OneHouse, Delta Lake và Apache Hudi có thời gian đọc-ghi nhanh hơn so với Apache Iceberg Tuy nhiên, Apache Iceberg và Apache Hudi lại hỗ trợ nhiều công cụ tính toán hơn.
- Quality Layer: Theo sự khuyến khích của Databricks [12], mỗi kiến trúc Lakehouse nên có 3 layer chính, bao gồm:
Bronze (Dữ liệu thô) là lớp thu thập dữ liệu từ các hệ thống nguồn bên ngoài, với cấu trúc bảng tương ứng với hệ thống nguồn "nguyên trạng" Lớp này bao gồm các cột siêu dữ liệu bổ sung như ngày/giờ tải và ID quy trình Trọng tâm của lớp này là khả năng thu thập dữ liệu thay đổi nhanh chóng và cung cấp thông tin một cách hiệu quả.
Kho lưu trữ lịch sử của nguồn (kho lạnh) cho phép lưu trữ dòng dữ liệu một cách hiệu quả, đồng thời cung cấp khả năng kiểm tra và xử lý lại dữ liệu khi cần thiết mà không phải đọc lại từ hệ thống nguồn.
Lớp Silver trong lakehouse là nơi dữ liệu từ lớp Bronze được làm sạch, hợp nhất và tuân thủ, nhằm cung cấp cái nhìn tổng quan về các thực thể kinh doanh chính như khách hàng, cửa hàng và giao dịch Lớp này cho phép phân tích tự phục vụ, hỗ trợ báo cáo đặc biệt, phân tích nâng cao và machine learning Nó đóng vai trò là nguồn dữ liệu cho các Nhà phân tích, Kỹ sư dữ liệu và Nhà khoa học dữ liệu, giúp họ phát triển các dự án và phân tích để giải quyết các vấn đề kinh doanh trong lớp Gold.
Lớp Gold trong lakehouse chứa dữ liệu được tổ chức trong cơ sở dữ liệu "dành riêng cho dự án" và sẵn sàng sử dụng cho báo cáo Đây là nơi áp dụng quy tắc chuyển đổi dữ liệu và đảm bảo chất lượng dữ liệu, với các mô hình dữ liệu tối ưu hóa cho việc đọc và ít kết nối hơn Các dự án như phân tích khách hàng, phân tích chất lượng sản phẩm, phân tích hàng tồn kho, và đề xuất sản phẩm đều phù hợp với lớp này Nhiều mô hình dữ liệu trong lớp Gold áp dụng lược đồ ngôi sao theo phong cách Kimball hoặc Data mart theo phong cách Inmon.
HỆ THỐNG GỢI Ý, ĐỀ XUẤT NHÀ HÀNG
Huấn luyện mô hình ALS
Nhóm đã phát triển một ứng dụng đơn giản bằng cách sử dụng tập dữ liệu thu thập được để xây dựng một hệ thống gợi ý Cụ thể, mô hình này áp dụng thuật toán ALS nhằm dự đoán những nhà hàng ưa thích cho người dùng.
The Alternating Least Squares (ALS) algorithm is a key component of matrix factorization in recommendation systems As illustrated in Figure 3.2.1, the left side displays a rating matrix that represents the relationship between users and movies, which, in the context of our study, refers to businesses.
Thuật toán phân rã ma trận (matrix factorization) được phát triển để xử lý ma trận rỗng, nơi người dùng chỉ đánh giá một số ít nhà hàng Phương pháp này phân tách ma trận ban đầu thành hai ma trận con, với d được xem như các nhân tố ẩn, giúp loại bỏ các giá trị rỗng không cần thiết Khi cần dự đoán, chỉ cần lấy vector tương ứng từ hai ma trận này cho người dùng và nhà hàng, từ đó cải thiện đáng kể tốc độ dự đoán.
Thuật toán này sử dụng các thuộc tính của người dùng, sản phẩm và đánh giá của người dùng để tính toán mối tương quan với các giá trị khác, nhằm gợi ý sản phẩm phù hợp Nó được coi là hiệu quả nhất vì kết hợp cả hai phương pháp giảm chiều ma trận và tìm kiếm nhóm tương đồng (lọc cộng tác).
Hình 3.4.1.1: Mô tả thuật toán ALS [6]
Hình 3.4.1.1 mô tả về cách nó giảm dimension, từ đó nó tận dụng lại lọc cộng tác
Hình 3.4.1.2: Hàm loss trong mô hình [6]
Hàm loss trong mô hình ALS mô tả sai số giữa giá trị thực tế và dự đoán Để tối ưu hóa hàm này, người ta thường điều chỉnh giá trị lambda nhằm giảm thiểu sai số.
Lọc cộng tác là phương pháp lựa chọn người dùng có sở thích tương đồng, thường dựa trên việc đánh giá sản phẩm Mục tiêu của phương pháp này là dự đoán xu hướng trong tương lai bằng cách sử dụng dữ liệu gần nhất từ ngày tháng trong bảng đánh giá.
Hình 3.4.1.3: Phân bố vote theo thời gian
Hình 3.4.1.3 cho thấy rằng lượng người bỏ phiếu cho các nhà hàng tập trung nhiều hơn trong thời gian gần đây, điều này cho thấy mục tiêu dự đoán của chúng ta không nên dựa vào quá khứ Ngoài ra, xu hướng bỏ phiếu 5 sao cũng chủ yếu diễn ra ở hiện tại.
Hình 3.4.1.4: Phân bố user vote lần đầu theo thời gian
Trước tiên dữ liệu rating ban đầu có gần 7 triệu rating, matrix MxN có Ta chia dữ liệu làm 7/2/1 (train/validate/test)
Tuning: Trong ALS, ta phải tuning các thông số để minimize RMSE Có 3 thông số quan trọng trong mô hình:
+ Rank: số nhân tố ẩn (latent factor) của mô hình
+ regularization: tham số chuẩn hóa (để tránh over fitting)
Hình 3.4.1.4: Tinh chỉnh siêu tham số iter (số lần lặp)
Hình 3.4.1.4 cho thấy sự dao động của iter, cho thấy rằng hàm này thường không thay đổi nhiều khi xét trung bình Tuy nhiên, khi xem xét giá trị min, iter=4 có khả năng đạt được RMSE thấp nhất một cách dễ dàng.
Hình 3.4.1.5: Tinh chỉnh siêu tham số rank(số nhân tố ẩn)
Hình 3.4.1.5 minh họa sự dao động của rank Để giảm bớt sự phức tạp trong các yếu tố, chúng ta nhận thấy rằng rank=4 là lựa chọn an toàn với giá trị RMSE thấp Ngược lại, rank=3 gần sát cận và không được xem xét Do đó, rank=4 sẽ được chọn.
Hình 3.4.1.6: Tinh chỉnh siêu tham số reg (regularization)
Hình 3.4.1.6 minh họa sự dao động của regularization, một thông số quan trọng giúp giảm thiểu hiện tượng overfitting Dễ dàng nhận thấy rằng giá trị hội tụ ở reg=0.35, vì vậy chúng ta sẽ chọn reg=0.35 là giá trị tối ưu nhất.
Như vậy, sau quá trình kiểm tra ta sẽ được rank=4, maxIter=4, reg=0.35
Kết quả cho lần chạy tốt nhất là: RMSE= 1.3710067457429629
Mô hình hiện tại có sai số cao do dữ liệu thưa thớt, với ma trận MxN là 1,9 triệu x 190 nghìn nhưng chỉ có khoảng 6 triệu bản ghi Tuy nhiên, trong tương lai, mô hình này sẽ cải thiện nhờ vào việc số lượng đánh giá ngày càng tăng.
Sau khi hoàn thành quá trình huấn luyện, nếu model đạt yêu cầu về độ tin cậy, chúng ta có thể lưu trữ model để sử dụng cho các dự đoán trong tương lai mà không cần phải huấn luyện lại Hình 3.4.1.7 minh họa một thư mục chứa model đã được lưu.
Hình 3.4.1.7 Folder chứa save model
Sau đó, ta có thể lấy mode để recommend cho user và collect user mong muốn
Hình 3.4.1.8: Kết quả gợi ý nhà hàng
Hình 3.4.1.8 chính là mô tả output của recommendation cho user 15 và 20 Tất cả các nhà hàng được recommend đều có rating cao mới được đề xuất cho user
3.4.2 – Xây dựng hệ thống gợi ý dùng mô hình đã huấn luyện
Sau khi huấn luyện mô hình gợi ý nhà hàng bằng dữ liệu trước đó, chúng ta sẽ áp dụng mô hình này để gợi ý nhà hàng cho người dùng Kết quả gợi ý cho hai người dùng có userid 20 và 15 cho thấy bốn nhà hàng được đề xuất, như minh họa trong hình dưới đây.
Hình 3.4.1.9: Kết quả gợi ý nhà hàng cho người dùng
Mặc dù sai số RMSE trong quá trình huấn luyện mô hình tương đối cao, nhưng khi đưa ra gợi ý, mô hình vẫn cung cấp các đánh giá cao nhất, do đó kết quả gợi ý vẫn đảm bảo độ ổn định và có thể chấp nhận được.
3.5 - XÂY DỰNG TRANG WEB GỢI Ý
Hình 3.5.1.1: Mô hình hoạt động
Xây dựng trang web với mô hình gợi ý sản phẩm cần tối ưu hóa thời gian tải và nâng cao trải nghiệm người dùng Nhóm đã quyết định sử dụng mô hình client-server để đảm bảo tính linh hoạt và khả năng mở rộng của hệ thống.