Trong bài viết này, tác giả Trần Gia Quốc Hưng sẽ chia sẻ về cơ chế thực hiện trên Databricks để có được phương pháp xử lí linh hoạt và có thể cập nhật qua cấu hình.

Trong một dự án về Big Data gần đây, tôi phụ trách phần xử lí dữ liệu từ nhiều nguồn dữ liệu khác nhau, mỗi nguồn dữ liệu sẽ có từng quy trình xử lí khác nhau. Điểm mấu chốt đó là các quy trình xử lí này cần có khả năng cập nhật dễ dàng, việc tạo mới quy trình xử lí cần hạn chế tạo tác động tới những luồng đang có, ngoài ra còn có thể có thể cập nhật qua cấu hình.

Với những yêu cầu như trên, cả team quyết định sử dụng Azure Databricks cho Big Data Analytics service. Bên cạnh đó, tập tin cấu hình sẽ dùng định dạng JSON. Việc quan trọng đó là tìm cách nào để kết nối JSON và Databricks với nhau để hệ thống hoạt động linh hoạt và có khả năng cập nhật dễ dàng.

I. Tổng quan Databricks

Azure Databricks là dịch vụ triển khai Databricks trên nền tảng Azure, cung cấp khả năng autoscale, tương tác với các thành viên khác dễ dàng thông qua workspace. Azure Databricks hỗ trợ nhiều ngôn ngữ như Java, Python, Scala… Trong dự án thì tôi sử dụng Scala và Python là ngôn ngữ chính.

Để có thêm nhiều thông tin, các bạn có thể tìm hiểu thêm trong các đường dẫn sau:

II. Quy trình xử lý linh động trong Databricks

Có một cách để thiết kế nền tảng Databricks đó là tạo một notebook cho mỗi data flow. Tuy nhiên cách này lại có một số nhược điểm như:

  • Nếu data flow được bổ sung thường xuyên, đội ngũ phát triển sẽ phải tạo một notebook mới từ đầu.
  • Cập nhật data flow rất tốn thời gian, và không phải flow nào cũng phù hợp với yêu cầu.
  • Dù phát triển các tính năng giống nhau nhưng mỗi developer sẽ có cách làm khác nhau, gây khó khăn trong việc cập nhật

Trong khi đó, yêu cầu đặt ra là thực hiện cơ chế để xử lý cho nhiều luồng dữ liệu, hệ thống cần có tính linh hoạt và có thể cập nhật qua cấu hình để có thể thay đổi luồng xử lí theo nhu cầu. Vì thế, thay vì tạo riêng notebook cho mỗi luồng xử lí, tôi tạo một cơ chế như sau:

Giải thích cơ chế:

  • Input: Tôi tạo một tập tin cấu hình cho mỗi luồng xử lí riêng biệt. Khi dữ liệu của một luồng được xử lí, các bước cụ thể của luồng xử lí sẽ được lấy từ trong tập tin cấu hình này.
  • Coordinate notebook: notebook này có nhiệm vụ download input file, kiểm tra tập tin cấu hình và gọi các feature notebook theo như cấu hình để thực thi luồng xử lí dữ liệu.
  • Feature notebooks: Các notebook này cung cấp nhiều khả năng xử lí dữ liệu khác nhau, và có thể được mở rộng tùy theo nhu cầu trong tương lai.

Tiếp theo, tôi sẽ thực hiện cơ chế mẫu cho 2 feature notebook: format phone number (định dạng số điện thoại) và remove sensitive column (xóa các cột thông tin nhạy cảm). Việc hiện thực hóa được thực hiện bằng Azure Databricks và Azure Storage Blob.

Đầu tiên, tôi tạo các common notebook để tải và ghi tập tin, tương tác với Azure Storage Blob.

Tải xuống file notebook (scala):

Tiếp theo, viết tệp notebook (python):

Sau đó, cần tạo notebook để chuyển đổi định dạng số điện thoại thành định dạng chuẩn, và xóa những số điện thoại không thể định dạng được.

Tiếp theo, tạo notebook để xóa các cột dữ liệu nhạy cảm.

Tiếp theo là tạo coordinate notebook.

Cuối cùng sẽ là bước kiểm thử luồng xử lí bằng cách upload data file và configuration file vào Azure Blob Storage.

Data file sample:

User_ID,Phone_No,User_Name,Password

24306,303-555-0011,achigeol,8[gxXv*QDt9sTQX

65824,225-556-1923,hermathe,Q7#CDYrr?hdxnth6

14506,219-557-3874,stashero,Vq8#upVE7qj9_M+n

71463,215-558-9821,inghthlo,WXzshf8rU^ts8CUN

36808,262-559212-212,adeldona,[email protected]%Dws5

69170,319-660-9832,wdyalbow,r3^T8++f9MhVJe5h

17255,229-661-2134,introsgo,eXH8ENa8J!c*d^P4

56940,216-662-8732,burienti,BSZC_vxPgTm^q4J%

52720,210-663-8724,itereart,A$F3Rtnc4b%Rtk

Configuration file sample:

[{“action”:”remove-column”,”param”:{“column”:”Password”}},{“action”:”format-phone-number”,”param”:{“phoneCol”:”Phone_No”}}]

Quá trình kiểm thử như sau:

  • Upload data file với tên “user.csv” vào “input” container
  • Upload configuration file với tên “user-configuration.json” vào “configuration” file
  • Tạo “output” container

Những tên này được hard code trong coordinate notebook để phục vụ cho việc demo. Trong thực tế, ta sẽ lấy những giá trị này từ parameter hoặc configuration file.

Sau khi đã chuẩn bị các tập tin, ta sẽ chạy coordinate notebook. Output file với tên “user.csv” sẽ được xuất ra trong “output” container. Nội dung kì vọng:

User_ID,User_Name,Phone_No

65824,hermathe,+(84)255561923

24306,achigeol,+(84)035550011

56940,burienti,+(84)166628732

71463,inghthlo,+(84)155589821

17255,introsgo,+(84)296612134

14506,stashero,+(84)195573874

69170,wdyalbow,+(84)196609832

52720,itereart,+(84)106638724

Cột “Phone number” được chuyển thành định dạng chuẩn, và cột “Password” được xóa khỏi dữ liệu.

III. Kinh nghiệm

1. Khả năng cập nhật và tái sử dụng (configurable and reusable)

Với cơ chế như trên, các feature có thể được tạo mới hoặc cập nhật riêng biệt. Việc này giúp các feature có thể phát triển riêng biệt. Hơn nữa, một feature notebook có thể được tái sử dụng cho nhiều luồng xử lí khác nhau.

Lợi thế của cơ chế trên:

  • Chỉ cần một tệp cấu hình cho mỗi processing flow mới. Với UI/UX, doanh nghiệp sẽ có thể tự cập nhật/tạo lập các flow.
  • Hệ thống có thể được bổ sung tính năng xử lý mới mà không gây ảnh hưởng tới bất cứ thành phần nào khác. Chi phí phát triển một tính năng cũng rẻ hơn so với việc thực hiện một processing flow hoàn toàn mới.
  • Các tính năng có thể được tái sử dụng cho các processing flow khác.

2. Trigger Databricks bằng Azure Logic App

Trong trường hợp cần tích hợp với các hệ thống khác, bạn có thể dùng Azure Logic App để trigger Databricks khi một tập tin dữ liệu được upload vào blob container. Các bước như bên dưới:

  • Tạo Databricks Job để publish coordinate notebook, bạn có thể trigger job này để run notebook bằng Azure Databricks REST API
  • Tạo Logic App để gọi Azure Databricks REST API nhằm trigger notebook. Logic App này có thể được trigger khi tập tin dữ liệu upload vào blob container
  • Cấu hình blob container để gọi Logic App khi tập tin dữ liệu được upload

3. Cải tiến hiệu quả

Theo kinh nghiệm sử dụng Azure Databricks của tôi, việc chạy notebook từ một notebook khác có thể chậm hơn so với xử lí cùng notebook. Đó là vì các notebook cần thời gian khởi động trước khi chạy. Vì thế, nếu có quá nhiều feature trong luồng xử lí, bạn có thể cân nhắc các điểm sau để cải thiện performance:

  • Thay vì dùng notebook riêng rẽ theo feature, bạn có thể tách notebook theo nghiệp vụ (gồm nhiều feature), hoặc mỗi luồng xử lí có một notebook riêng. Tất cả các feature cần thiết đều được hiện thực trong cùng notebook. Cơ chế này có thể làm giảm bớt tính tái sử dụng, nhưng có thể cải thiện performance.
  • Build feature thành các thư viện và import vào coordinate notebook để gọi mà không cần phải thông qua các notebook khác. Mặc dù mỗi lần cập nhật tính năng sẽ cần phải cập nhật lại các thư viện, nhưng nếu nghiệp vụ không yêu cầu update thường xuyên thì cơ chế này phù hợp để cải thiện performance.

Kết lại, dù việc ứng dụng vào thực tiễn có có rất nhiều hạn chế và khó khăn, nhưng tôi hy vọng bạn sẽ tìm thấy vài điểm hữu ích giúp bạn hiện thực được luồng xử lí dữ liệu bằng Databricks.

Trần Gia Quốc Hưng – Ban Giải pháp & Công nghệ, FPT Software

Tin liên quan: