Xây dựng hệ thống phân tích trong doanh nghiệp

Kien Vu
6 min readMay 5, 2019
Nguồn: pexels

Hệ thống phân tích là một trong những thành phần cần thiết trong doanh nghiệp. Bài viết này trình bày các bước chúng tôi đã thực hiện để xây dựng hệ thống này.

Centralizing data

Tại phần này thay vì đưa vào DWH truyền thống, tôi sử dụng dataflows để đưa dữ liệu về azure data lake.

Các bước được thực hiện trên power services, dữ liệu được lưu trữ trên cloud ở azure data lake.

Centralizing SQL logic: hermesql

Một trong những vấn đề đau đầu chúng tôi từng gặp phải khi sử dụng các hệ thống báo cáo đó là các nguyên tắc nghiệp vụ liên tục thay đổi, kéo theo đó là code luôn thay đổi. Việc nhân sự không comment code hoặc nghỉ việc cũng khiến cho code thành một mớ hổ lốn.

SQL là ngôn ngữ phổ biến để làm việc với cơ sở dữ liệu quan hệ. Tuy nhiên nó không phù hợp khi số lượng sql code tăng lên quá nhanh và có sự trùng lặp logic giữa các câu lệnh.

Để khắc phục điều này, chúng tôi tạo ra một file json tạm gọi là “ETL model” để thống nhất logic của các code SQL. File có dạng:

Tiếp đó, chúng tôi sử dụng hermesql để load logic từ file json rồi tạo các câu lệnh sql theo nhu cầu để sau đó sử dụng và quá trình truy vấn dữ liệu.

Điều này sẽ giúp cho các logic được tập trung vào một file model duy nhất, tránh hiện tượng phân mảnh và dễ dàng hơn trong việc triển khai câu lệnh.

Version control: git

Để quản lý việc thay đổi các phiên bản, chúng tôi không trực tiếp đặt code trên ETL tool, analysis services hay Power BI. Thay vào đó, chúng tôi file tĩnh và quản lý phiên bản bởi git. Các thay đổi cần phải được kiểm tra kĩ và sau đó commit với nội dung rõ ràng để có thể theo dõi lại.

Analysis services và ETL tool sẽ lấy SQL code thông qua API của github rồi tiến hành truy vấn dữ liệu.

Data modeling: Analysis services

Dữ liệu sau khi được đẩy về datalake sẽ được đưa lên analysis services để xây dựng data model. Chúng tôi sử dụng giải pháp của microsoft vì sau khi đánh giá, nó phù hợp với nhu cầu của công ty hiện tại.

Tại analysis services, chúng tôi chỉ xây dựng một một data model duy nhất để tránh trùng lặp, dư thừa dữ liệu. Việc sử dụng một data model duy nhất cũng đảm bảo business logic thống nhất giữa các phòng ban.

Measure hierarchy

Khi xây dựng các measure, tôi sẽ bắt đầu với các measure tổng quát trước, sau đó tới các measure chi tiết hơn dựa vào các measure chi tiết này.

Việc xây dựng một hệ thống các measure phụ thuộc vào nhau sẽ giúp ích:

  • Khi cần đổi logic, tôi chỉ cần đổi ở measure ở mức tương ứng, các measure phụ thuộc sẽ được thừa hưởng sự thay đổi này.
  • Các measure ở mức chi tiết hơn sẽ thừa hưởng logic thống nhất từ measure trước chứ không bị thay đổi.

Hãy lấy một ví dụ:

Tôi có measure tổng quát:

No booking = COUNTROWS(‘booking’)

Khi tôi chỉ muốn tính các booking thành công, thay vì viết

No booking completed = CALCULATE(COUNTROWS(‘booking’), ‘booking’[status] = “Completed”)

Cách viết trên lặp lại logic tính tổng số booking tôi đã viết từ trường. Vì vậy, cách hợp lý hơn nên là:

No booking completed = CALCULATE([No booking], ‘booking’[status] = “Completed”)

Tiếp tới, chỉ tiêu tỷ lệ booking thành công, thay vì viết:

% booking complete = COUNTROWS(‘booking’)/CALCULATE(COUNTROWS(‘booking’), ‘booking’[status] = “Completed”)

Tôi sẽ viết là:

% booking complete = [No booking completed]/[No booking]

Với các viết này, nếu logic tính tổng số booking của tôi bị thay đổi, tôi sẽ chỉ cần đổi logic của chỉ tiêu [No booking] là đủ, các chỉ tiêu [% booking complete], [No booking completed] sẽ tự động được điều chỉnh tương ứng.

DAX measure table

Nguồn: biinsight

Trong thực tế khi xây dựng DAX measure, chúng tôi gom các measure liên quan vào cùng một bảng thay vì để chúng riêng rẽ ở các bảng khác nhau. Điều này giúp quản lý các measure dễ dàng và thuận tiện khi xây dựng các báo cáo.

Data model documentation

Để document lại ý nghĩa các trường thông tin, công thức, ý nghĩa của các bảng… chúng tôi input trực tiếp thông tin trong analysis services. Sau đó sử dụng DAX để truy vấn các thông tin này thông qua DAX studio hoặc Python.

Các thông tin sẽ được cập nhật mỗi khi có thay đổi. Dựa vào document chi tiết, những nhân sự mới tham gia sẽ có thể nhanh chóng hiểu được nghiệp vụ và dễ dàng thực hiện tiếp công việc.

Reporting: Power BI and excel

Với Power BI services, chúng tôi có thể sử dụng power BI desktop hoặc Excel để kết nối vào dataset để thực hiện báo cáo.

Việc lựa chọn sử dụng power bi hay excel là tùy thuộc vào từng hoàn cảnh. Nếu như tôi muốn tận dụng các đồ thị và các tính năng nâng cao như decomposition tree, key influencers tôi sẽ sử dụng power bi. Nếu cần sự tùy biến hoặc tiện dụng, tôi sẽ dùng excel để kết nối với power bi services.

Statistics and machine learning: tabint

Power BI hoặc Excel có thể thực hiện được các phương pháp thống kê cổ điển, tuy nhiên cá nhân tôi thấy rằng việc này nên được trên một ngôn ngữ phân tích dữ liệu như R hay Python.

Power BI có thể kết nối với Python, tuy nhiên việc kết hợp này chỉ dừng lại ở việc tạo ra các visual trên báo cáo. Nếu bạn muốn lấy dữ liệu của power bi dataset để sử dụng thì cần phải xuất dữ liệu ra csv, sau đó dùng python để đọc dữ liệu rồi tiến hành các bước tiếp theo.

Cá nhân tôi thấy như trên rườm rà, vì vậy trong tabint tôi đã sử dụng lại một class giúp sử dụng DAX để lấy dữ liệu từ power bi data model. Các bước lấy dữ liệu sẽ có dạng:

Thư viện tabint cũng cung cấp các class phục vụ cho thống kê và machine learning. Sau khi lấy dữ liệu từ power bi services, người phân tích có thể đưa vào flow để thực hiện các phân tích chuyên sâu tiếp theo.

Lời kết

Xây dựng hệ thống phân tích là một điều không đơn giản. Hy vọng qua bài viết này các bạn có thể tìm được ý tưởng cho công việc của mình.

Nếu thấy điểm nào còn chưa hợp lý trong bài viết trên, hay comment để tôi biết và cải thiện nhé. :D

--

--