Hệ thống quản lý chất lượng dữ liệu – Data Quality | TopDev

Một ngày của Data team ở Amanotes bắt đầu bằng việc xử lý rất nhiều tin nhắn được gửi cho data team, ví dụ như sự chênh lệch của chỉ số, tại sao trendline có vẻ thay đổi,… Những câu hỏi về các vấn đề liên quan đến data nhân lên rất nhiều lần cho các metrics trên rất nhiều dashboard của công ty.

Tìm việc làm QC làm online tại nhà

Điều này khiến data team suy nghĩ đến việc nên làm sao để mọi người không phàn nàn về những vấn đề liên quan đến data nữa. Và nhờ vậy chúng tôi quyết định build một hệ thống quản lý chất lượng data. Đó cũng là lý giải cho việc tại Amanotes quyết định build hệ thống này và team đã build nó như thế nào?

Tại sao việc build hệ thống này lại quan trọng với data  quality cũng như data team của một công ty?

Mỗi ngày, business stakeholders sẽ có những quyết định quan trọng và tất cả những quyết định đó đều dựa trên data. Và điều quan trọng nhất là mọi người phải tin vào data mà họ nhìn thấy, chỉ có như vậy mới tối ưu hóa được lợi ích mà data mang lại cho user cũng như giúp cho business stakeholders tốn ít thời gian hơn trong việc double check data, complain data và tự tin hơn trong quyết định của họ.

Về sự phân cấp giá trị mà data đem lại, bắt đầu từ data bằng việc processing và khai thác những thông tin quan trọng từ nó chúng ta mới bắt đầu có information. Dựa vào information, stakeholders sẽ có knowledge, từ đó build up thành wisdom – sự thông thái và hiểu biết về những gì đang diễn ra trong business của mình. Vậy nên data chính là nền tảng của tất cả những hiểu biết, những thế mạnh của một doanh nghiệp. Và data quality chính là bước đầu tiên để kiểm soát nguồn thông tin, dữ liệu và sự hiểu biết trong doanh nghiệp.

Vậy data team đã copy lại cách user complain về data như thế nào?

User complain flow

User complain flow – những gì thực chất diễn ra bằng con người và Data Quality Control System.

Cũng giống như data team hằng ngày bắt đầu làm việc bằng việc check dashboard, sẽ có 2 cách để check xem data ngày hôm nay có bất thường hay không hoặc có bug gì xảy ra với data hay không.

Có thể check bằng mắt, xem trendline của ngày hôm đó so với các ngày trước có thay đổi hay không, có quá cao hay quá thấp hay không. Nếu như nhìn ở góc độ data quality control system thì đó chính là thuật toán Anomaly Detection. Sau khi đã xem qua các metrics rồi thì bản thân các business stakeholders sẽ có những kiến thức về mặt business để xét xem những con số này có chính xác hay không. Nếu có 2 metrics liên quan đến nhau trên cùng một dashboard thì liệu 2 metrics này có đi cùng một trend hay không… Điều này tương tự với những Rule-based Auto-Tests được đưa vào trong Data Quality Control System.

Và dĩ nhiên là cả Anomaly Detection Algorithm và Rule-based Auto-Tests đều apply trên cùng một data source mà chính những data source đó được sử dụng để visualize lên những dashboard đang có. Dựa vào thông tin của Eye-check và Business Intuition thì bản thân các business stakeholders sẽ quyết định xem những bất thường này có nghiêm trọng hay không. Nếu nó thật sự nghiêm trọng và ảnh hưởng đến quá trình ra quyết định thì họ sẽ liên lạc với data team.

Xem thêm Khái niệm transaction trong database

Data team dựa vào các câu hỏi của stakeholders sẽ đào ngược lại vào trong data source, test, investigate, explore lại xem lỗi này xảy ra như thế nào. Để mimic (mô phỏng/bắt chước) lại quá trình đó thì trong Data Quality Control System sẽ có thêm Data Quality Scoring. Data Quality Scoring là hệ thống check tất cả những input từ Run-based Auto-Tests và các thuật toán để detect anomal, scoring nó để đánh giá data quality của ngày hôm nay có tốt hơn ngày hôm qua hay không. Đưa ra một con số để tất cả user nhìn vào con số của ngày hôm nay biết được tình trạng data quality của toàn bộ pipeline đó như thế nào.

Song song với Data Quality Scoring thì có thêm Severity Rating là tất cả các text và out layer sẽ trả về một list kết quả test là fail hay pass. Mình sẽ có những logic khác nhau dựa trên các chuẩn mực riêng biệt để đánh giá xem lỗi fail test có nghiêm trọng hay không. Nếu nghiêm trọng mình sẽ đưa vào Alerting System và data team sẽ giải quyết vấn đề này trước khi một stakeholders nào check nó trên dashboard.

Tại sao lại cần có Severity Rating để đánh giá data quality?

Có thể hiểu là ở bước Rule-based Auto-Tests và Anomaly Detection nó sẽ trả về rất nhiều loại fail hay pass test. Thậm chí lượng fail test có thể chiếm 10 – 15% của tất cả những test mà mình từng viết nếu như ngày hôm đó không được may mắn cho lắm. Nếu coi tất cả những test đó như nhau và cho nó vào Alerting System thì một ngày data team sẽ nhận được rất nhiều alert!

Và đương nhiên là, nếu liên tục nhận được những signal, những alert không thật sự nghiêm trọng thì dần dần đối tượng của Alerting System sẽ không tin vào lỗi được báo nữa nên  mục đích của Severity Rating ở đây là source lists và filter data. Chỉ những tests nào fail thật sự nghiêm trọng và trigger khiến data team phải can thiệp lại việc fail test đó thì mới đưa vào alerting system. Đó là một bước để tối ưu hóa hiệu quả của hệ thống và giúp data team hoạt động hiệu quả hơn trong việc build các bugs và kiểm soát được chất lượng của hệ thống dữ liệu.

Framework bên dưới để quá trình này diễn ra hoạt động như thế nào?

Analytics Engineering Flow mà hiện tại Amanotes sử dụng có 3 loại technology. Đầu tiên là Google BigQuery như Data Warehouse, đây cũng là technology rất phổ biến dạo gần đây. Thứ hai là Airflow được sử dụng Airflow như công cụ để điều phối các tasks liên quan đến data cũng là một công cụ rất nổi tiếng. Công cụ tiếp theo mới được sử dụng gần đây là dbt. Đây là một công cụ mới cho phép các data engineers và các bạn analytic engineers có thể apply một template cho auto develop và auto test framework với các best practices trong software engineering trên Sql để apply cho BigQuery.

Framework sẽ hoạt động từ Data loader đưa vào trong Raw data. Từ Raw data sẽ đi qua các bước Snapshot, Transform, Test, Deploy và Document. Ngôn ngữ chính đang sử dụng ở đây là BigQuery Sql và dbt. Bình thường khi nhắc đến Sql mọi người sẽ không đánh giá cao nó như một ngôn ngữ mang các best practices của Software Engineering và thiếu đi rất nhiều công cụ để test code đã được viết hoặc để deploy hay document nó.

Nhưng dbt xuất hiện trong framework cho phép thực hiện tất cả những điều này với Sql bao gồm cả version control và test. Đồng thời trong dbt nó cũng automate toàn bộ documentation liên quan đến pipeline gồm các components và các metrics được tạo ra như thế nào. Cùng với version control, Amanotes cũng đang build Alerting và Logging. Alerting và Logging là sự kết hợp của rất nhiều công cụ đang sử dụng trong stack này bao gồm logging từ Airflow và dbt. Amanotes cũng có 1 product inhouse để combine nó lại và đưa vào trong Alerting System. Sau khi raw data đã đi qua tất cả các bước transforming này thì sẽ được show lên BI tool cùng với Metabase.

3 components chính trong hệ thống quản lý chất lượng data

3 components này gồm Rule-based Auto-Tests, Anomaly Detection và Data Quality Scoring. Alerting là output cuối cùng nhận tất cả các kết quả ở 3 hệ thống vừa được đề cập.

1. Rule-based Automated Tests

Mục đích của testing là để validate lại những assumptions của data team nên test được thiết kế tốt là test có thể bắt được những assumption sai về data mà mình đang có. Assumption cụ thể ở đây là khi viết Query, ta assume là kết quả trả ra sẽ như vậy và nếu bộ data đủ phức tạp thì một developer sẽ không thể bao quát hết tất cả những corner case liên quan đến nó. Do đó việc apply test là để check lại kết quả của các query dựa trên một số assumption mà dev biết.

Nếu là fail assumption thì đây sẽ là trigger để cho biết data đang có vấn đề gì và assumption cho thấy data đang không chính xác. Ở đây mình chia tất cả các test thành rất nhiều components khác nhau: comment issues mà data users hay đưa lên cho data team, team biến nó trở thành những automatic tests. Tất cả những issues này sẽ thuộc về những nhóm khác nhau. Ví dụ như revenue đưa xuống ở country level quá lớn thì nó thuộc group Source of Truth vì bên cạnh những dashboard internal mình cũng có những dashboard partners external.

Một trong những cách đơn giản nhất để viết automatic test này là compare cùng một thông tin từ 2 nguồn data khác nhau để đối chứng với nhau. Có những thông tin liên quan đến data không fresh ví dụ như việc đếm số new users data trong một ngày, như hôm nay là ngày 10 nhưng trong data không có ngày 10 thì lúc này team sẽ biết là data đang không đúng và có vấn đề trong data pipeline của mình.

Tiếp theo là có thể theo dõi inconsistent data hoặc historical trend bằng việc xem LTV trendline của nó qua mỗi ngày có consistent hay không, hay đột nhiên có vấn đề lệch ra khỏi quỹ đạo thông thường. Tất cả các tasks này sẽ được viết bằng Sql để kết quả trả ra là yes hay no và dbt chính là sản phẩm cho phép chúng ta làm được chuyện đó bằng Sql trong BigQuery trong framework. Khi team sử dụng version control để kiểm soát toàn bộ những code mà bọn mình từng viết trong data pipeline này, nếu đã full request thì dbt sẽ tự động chạy. Hoạt động này cũng giống như dbt tự động chạy mỗi ngày trong pipeline để check lại tất cả các bảng data cũng như các metrics quan trọng. Để xem đi qua hết list object này, trải rộng suốt một pipeline thì tất cả các task của mình có pass hay không. Nếu tất cả các test đều pass hết thì sẽ có một report được gửi về cho data team và đảm bảo ngày hôm nay không có vấn đề gì xảy ra.

Xem thêm Bài toán đồng thuận trong Distributed Systems

2. Data Profiling & Anomaly Detection Algorithm

Data Profiling cũng mô phỏng lại một hành vi của user. Cách thức để tìm ra một vấn đề xảy ra trong chart đó là nhìn vào những điểm data bất thường dựa vào những điểm data xung quanh nó. Đây cũng là điểm cốt lõi của Data Profiling và Outlier Detection. Có những quan sát sẽ đi chệch ra nhiều hơn so với những quan sát khác đứng phía trước và sau nó, thường sẽ là đằng sau vì phía trước là dữ liệu trong tương lai mình không thể quan sát được. Và những thứ đi chệch ra này sẽ khiến users hoặc người làm data đưa ra những nghi vấn rằng mọi thứ có đang diễn ra bình thường hay không hay đang có vấn đề bất thường.

Với Anomaly Detection, cần phân biệt được data discrepancy, sự khác biệt của metrics so với một điểm data nào đó. Ở đây mình so với 3 tiêu chí khác nhau:

Một là một điểm data với Business Normal Range, tức là khoảng bình thường theo rule của business. Tiêu chí thứ 2 là so với giá trị trung bình của 7 ngày trước đó. Thứ 3 là so với giá trị trung bình của 4 ngày cùng thứ của 4 tuần trước đó. Tiêu chí thứ 3 này là tiêu chí cần phải có vì ví dụ như với Amanotes là một công ty về mobile app thì vào cuối tuần, behaviours và lượng thông tin sẽ rất khác so với các ngày trong tuần nên thông tin sẽ không công bằng và không capture được outlier thực tế của nó. Trong đó Outliers có 2 dạng: thứ nhất là có lỗi xảy ra và thứ hai là không có lỗi nào cả, chỉ đơn giản là bản chất của data mà thôi.

Xem thêm Big data là gì? Trò chuyện cùng CTO của Datamart Solutions để hiểu hơn về data

Ngoài ra, còn có các solution khác nhau để identify một outlier dựa vào 3 tiêu chí của data discrepancy. Đầu tiên là dựa vào statistics distribution based ví dụ như so sánh stability index của distribution. Thứ 2 là distance based, thứ 3 là density based và thứ 4 là deviation based. Đây là 4 phương pháp kết hợp và tạo ra outlier. Hiện tại data team mình sử dụng là high bridge của nhiều solution khác nhau và combine output từ những thứ khác nhau như vậy để đi đến quyết định cuối cùng là một data bond có phải là outlier hay không.

3. Data Quality Scoring

2 components trên sau khi hoạt động sẽ trả ra kết quả là pass or fail, bản thân Abnormal Detection cũng sẽ output ra kết quả pass or fail. Ví dụ như một data bond được nhận diện là outlier thì sẽ trả về kết quả là fail và mình coi outlier detection đó cũng là test như Rule based Tests nhưng Abnormal Detection là một database, machine learning base test được apply lên data. Một chuỗi kết quả fail and pass này sẽ được đưa vào Data Quality Scoring. Mục đích của nó là tạo được một metrics, score về data quality của pipeline trên tất cả những metrics trong dashboard ngày hôm đó.

3.1. Data Quality

Data Quality là một metrics để measure rất nhiều criteria khác nhau.

Đầu tiên là tính chính xác của data. Tính chính xác này đến từ rule based, automatic tests hoặc so sánh nó với source of truth hoặc outlier thì sẽ compare với historical data.

Thứ 2 là tính toàn vẹn của data. Data có thể hiện hết những value mà mình đang quan tâm hay không. Có những metrics rất quan trọng nhưng 70 – 80% của nó là missing value.

Thứ 3 là relevance. Ở đây sẽ có những điểm data, vậy liệu những điểm data liên quan tới nhau có đang thể hiện một mối tương quan giống trong quá khứ hay không.

Thứ 4 là timeliness. Nó thể hiện được data có fresh hay không, có đến vào đúng thời điểm mà mình cần hay không. Vì thật ra tất cả các data source không đến cùng một thời điểm, có rất nhiều nguồn data được control internally thì timeliness và độ trẻ của nó sẽ ít hơn nhưng cũng có nhiều data mình kéo bằng API, từ nhiều nguồn ở ngoài sẽ có độ trẻ lâu hơn. Thường timeliness sẽ compare data availability với hiểu biết mà mình đã có về độ trẻ của data.

Thứ 5 là clarity, nghĩa là tất cả những data, những metrics có thỏa mãn về mặt syntax và grammar rules hay không. Thật ra mảng này hiện không được cover trong Data Quality Scoring hiện tại của mình.

Thuộc tính cuối cùng là Accessibility – data có thân thiện, hiệu quả và access được với tất cả mọi người hay không.

Ở đây sẽ có những metrics quan trọng hơn các metrics khác như completeness, relevant và timeliness là những tiêu chí rất dễ hình dung để đưa ngay vào trong data quality control system của mình. Accuracy ngược lại hơi mang tính chủ quan hơn vì thực chất có rất nhiều bộ data đang có chỉ mang tính tương đối và cũng không biết được đâu là source of truth để compare data mình đang có với nó. Clarity và Accessibility cũng mang tính chất khách quan nhiều hơn và hiện nay với version hiện tại của Data Quality Control System ở Amanotes không cover 2 metrics này.

3.2. Cách để measure data quality

Đầu tiên là Accuracy – tất cả những rule based auto tests bị fail. Thứ 2 là abnormal detection. Thứ 3 là tính toàn vẹn của data, tức NULL rate trong dữ liệu của mình. Cuối cùng là usability mà cụ thể là Zero rate của một metrics nào đó.

Vậy sự khác nhau giữa NULL rate và Zero rate là gì?

Zero rate không mixing, data này thật sự có giá trị là 0 nhưng nó ảnh hưởng đến usability vì nếu một metrics có đến 70 – 80% nhận cùng giá trị 0 thì đó không phải là một metrics có ý nghĩa và không add được nhiều value cho business của mình. 4 criteria này sẽ được đưa vào một Ranking/Weighting Algorithm.

Weighting Algorithm đến từ việc mình đang có nhiều criteria khác nhau và mỗi criteria này có references khác nhau mà mình collect input này từ phía stakeholders. Ví dụ như trong số những criteria này thì Accuracy là criteria quan trọng nhất và Usability là criteria ít quan trọng nhất. Nó được chấm dựa trên thang điểm từ 1 đến 5. Weighting Algorithm sẽ kết hợp tất cả những criteria đã được weighting và cho ra một kết quả có ý nghĩa, làm sao để tiêu chí được đánh giá, được cho điểm cao nhất và nó không dominate score cuối cùng của mình cũng như làm sao để tiêu chí được cho điểm thấp nhất vẫn có tầm quan trọng nhất định.

Framework chính để Anomates thiết kế Algorithm là dựa trên decision making framework trong management science và sử dụng ranking trên một decision. Sau khi đưa input từ accuracy, abnormal detection, completeness và usability vào Ranking/Weighting Algorithm thì kết quả trả về là score có giá trị từ 0 đến 1. Đề xuất cho data user là nếu bạn đang cân nhắc sử dụng một nguồn data nào đó mà đang có nhiều lựa chọn, nhiều data sources thì hãy lựa chọn data sources có data quality scoring cao hơn.

Data Alerting System

Data quality control system sẽ trả ra hàng loạt test và những test này sẽ được đánh giá về mức độ usability dựa trên nhiều yếu tố. Đầu tiên là metrics này có quan trọng hay không và độ lệch của nó có nghiêm trọng hay không. Nhìn vào dashboard, data team sẽ biết nên ưu tiên sửa vấn đề nào trước và nên làm gì với những vấn đề đó.

Cuối cùng là phải tối ưu hóa data quality alerting system. Mục đích của việc này là để giảm đi lượng false positive và có thể tăng productivity của data team lên rất cao, giảm các công việc liên quan đến việc tìm bug, thông báo và communicate với end-user.

Vậy việc tối ưu sẽ diễn ra như thế nào?

Hiện nay interface để entrust với data alerting system mà data team đang sử dụng là thông qua notification của Slack và những thông số trên Metabase giống như rất nhiều dashboard trước đó. Có rất nhiều states khác nhau có thể apply để tối ưu, thứ nhất là smart grouping, kết hợp những alert có liên quan tới nhau và những alert lặp đi lặp lại. Thứ 2 là exception list, có những test lặp đi lặp lại và đây là lỗi mà team không thể sửa được hoặc lỗi này nằm bên ngoài system nhưng không ảnh hưởng quá lớn đến data pipeline và quyết định của mình thì cũng có thể đưa vào exception list.

Thứ 3 là automatic synchronization giữa các platforms để đảm bảo tất cả mọi thứ hoạt động trơn tru và không bị spam quá nhiều cho các thành viên của datateam. Bên cạnh đó thì việc optimize anomaly detection, data quality scoring và severity levels cũng giúp optimize data alerting system.

Nhưng sự thật thì sẽ không thể nào dự đoán được chuyện gì sẽ xảy ra với data, luôn có rất nhiều corner cases trong khi data là những gì đã xảy ra trong quá khứ. Chúng ta sẽ không bao giờ đoán trước được việc data ngày mai sẽ diễn ra như thế nào, nó có thay đổi hay không và bug nào sẽ xảy ra tiếp theo. Do đó quá trình build data quality control system sẽ là một nỗ lực liên tục, teamwork cùng nhau, làm việc cùng các stakeholders để nâng cao chất lượng của data và có thể đưa data vào ứng dụng hơn nữa nhằm tạo ra benefit cho business của mình.

Bài viết được trích dẫn từ phần trình bày của chị Đặng Huỳnh Mai Anh tại sự kiện Vietnam Web Summit 2020 LIVE do TopDev tổ chức

Có thể bạn quan tâm:

Xem thêm các việc làm Developer hấp dẫn tại TopDev