Nâng cao chất lượng dữ liệu: Khám phá hợp đồng dữ liệu với Lyft

Có vẻ như đây là phần 2 trong loạt bài về Chất lượng dữ liệu của tôi!

Trong bài đăng trước , tôi đã khám phá chiến lược của Airbnb nhằm nâng cao chất lượng dữ liệu thông qua các biện pháp khuyến khích. Họ đã triển khai một điểm số duy nhất và các tiêu chí chấm điểm rõ ràng để thiết lập sự hiểu biết chung giữa người sản xuất dữ liệu và người tiêu dùng, thúc đẩy ý thức sở hữu thực sự.

Giờ đây, Lyft đang thực hiện một cách tiếp cận khác biệt, không cố gắng làm khác đi cùng một thứ mà tập trung vào các khía cạnh khác nhau của chất lượng dữ liệu. Và chiến lược của Lyft sẽ bổ sung cho những nỗ lực của Airbnb. Mặc dù tôi coi điểm DQ của Airbnb (hoặc bất kỳ điểm tương tự nào) là một phương tiện hiệu quả để củng cố nhiều nỗ lực khác nhau nhằm nâng cao chất lượng dữ liệu, Lyft đang giải quyết thách thức này từ một góc độ khác.

Điểm DQ của Airbnb đóng vai trò là công cụ có giá trị để cung cấp hình ảnh trực quan cụ thể về chất lượng dữ liệu. Về bản chất, bất kỳ sáng kiến nào nhằm nâng cao chất lượng dữ liệu đều sẽ có tác động rõ rệt đến điểm số này. Mặt khác, Lyft đưa ra một sáng kiến khả thi nhằm chủ động nâng cao chất lượng bằng cách kiểm tra và xác thực dữ liệu theo các tiêu chí chất lượng cụ thể.

Về cơ bản, đó là một điểm khác trong vòng đời chất lượng dữ liệu. Việc đưa ra một cơ chế để cải thiện chất lượng đòi hỏi khả năng đo lường nó ngay từ đầu.

Vì vậy, trong khi trọng tâm của Airbnb là đo lường và quan sát chất lượng dữ liệu, thì Lyft lại thực hiện một cách tiếp cận khác. Lyft chú trọng vào việc tích cực kiểm tra và xác nhận chất lượng dữ liệu, cung cấp cho cả nhà sản xuất và người tiêu dùng các phương tiện để cải thiện và kiểm soát chất lượng một cách hiệu quả.

Nói chung, các phương pháp tiếp cận này cung cấp một chiến lược toàn diện để giải quyết và nâng cao chất lượng dữ liệu trong suốt vòng đời của nó.

Vì lý do này, tôi đặc biệt quan tâm đến việc xem xét kỹ hơn cách tiếp cận của Lyft.

Một yếu tố khác khiến tôi tò mò là thử nghiệm, cụ thể hơn là thử nghiệm theo hợp đồng, đã được sử dụng từ nhiều năm nay trong công nghệ phần mềm cơ bản với sự xuất hiện của kiến trúc microservice. Tuy nhiên, hợp đồng dữ liệu là một thứ gì đó mới hơn trong lĩnh vực kỹ thuật dữ liệu và được coi là đỉnh cao hoặc một trong những bước cuối cùng để thực hiện trên con đường xây dựng đường dẫn dữ liệu chất lượng cao. Đây là lý do tại sao tôi muốn xem xét cách tiếp cận của Lyft chi tiết hơn và khám phá một số điểm tương đồng tiềm năng.

Như đã đề cập, các phương pháp tiếp cận của Airbnb và Lyft là bổ sung cho nhau và nhằm đạt được cùng một mục tiêu: cải thiện chất lượng dữ liệu.

Airbnb đã phát triển điểm DQ, điểm này tập trung vào việc đo lường và nâng cao 4 khía cạnh riêng biệt của chất lượng dữ liệu :

Điểm DQ có các nguyên tắc hướng dẫn, bao gồm phạm vi bao phủ đầy đủ, tự động hóa, khả năng hành động, đa chiều và khả năng phát triển. Nó có các khía cạnh như Độ chính xác, Độ tin cậy, Khả năng quản lý và Khả năng sử dụng.

Lyft's Verity là một nền tảng được thiết kế để nâng cao chất lượng dữ liệu trên 5 chiều

Xác định chất lượng dữ liệu là thước đo mức độ dữ liệu có thể được sử dụng như dự định, bao gồm các khía cạnh như tính chính xác về mặt ngữ nghĩa, tính nhất quán, tính đầy đủ, tính duy nhất, tính chính xác và tính kịp thời .

Thật dễ dàng để tìm ra sự tương đồng giữa 5 khía cạnh chất lượng dữ liệu được Verity của Lyft cải thiện và 4 khía cạnh chất lượng dữ liệu được đo bằng điểm DQ của Airbnb. Ví dụ: các khía cạnh như Tính kịp thời chắc chắn sẽ góp phần vào Độ tin cậy của điểm DQ, trong khi Độ chính xác sẽ phụ thuộc vào tính chính xác về ngữ nghĩa, tính đầy đủ và tính duy nhất của dữ liệu. Mặt khác, điểm Khả năng sử dụng bị ảnh hưởng bởi tính nhất quán của dữ liệu giữa các yếu tố khác.

Lyft's Verity tập trung vào việc xác định các kiểm tra liên quan đến tính chính xác về mặt ngữ nghĩa, tính nhất quán, tính đầy đủ, tính duy nhất, tính đúng đắn và tính kịp thời . Nó tuân theo phương pháp thử nghiệm trước và xác thực, trong khi điểm DQ thống nhất của Airbnb nhấn mạnh việc đánh giá chất lượng dữ liệu thông qua nhiều khía cạnh khác nhau.

Nếu chúng tôi muốn kết hợp điểm DQ vào lược đồ cuối cùng này, thì nó sẽ nằm ở các bước Cảnh báo/Gỡ lỗi.

Điểm DQ của Airbnb sử dụng các tín hiệu khác nhau để đánh giá chất lượng dữ liệu trên các khía cạnh Độ chính xác, Độ tin cậy, Khả năng quản lý và Khả năng sử dụng .

Chúng tôi cũng có một bộ tín hiệu đầu vào đo lường chất lượng trực tiếp hơn (chứng nhận Midas, xác thực dữ liệu, lỗi, SLA, kiểm tra DQ tự động, v.v.), trong khi các tín hiệu khác giống như các đại diện cho chất lượng (ví dụ: quyền sở hữu hợp lệ, quản trị tốt, việc sử dụng công cụ đường dẫn được trải nhựa).

Như đã thảo luận trước đó, có thể có sự trùng lặp giữa điểm DQ của Airbnb và Verity. Trong khi Airbnb tập trung vào việc đẩy chất lượng dữ liệu sang bên phải, nhấn mạnh vào việc đo lường và tính điểm thì Verity của Lyft thực hiện cách tiếp cận chủ động bằng cách chuyển cấu hình định nghĩa kiểm tra, quy trình kiểm tra và xác thực sang bên trái, nhấn mạnh vào việc chủ động cải thiện chất lượng dữ liệu.

Bây giờ, mối quan tâm chính của tôi nằm ở bên trái, trong các khía cạnh cấu hình định nghĩa kiểm tra, kiểm tra và xác thực.

Lyft tích hợp kiểm tra chất lượng dữ liệu vào quy trình của mình như thế nào?

Trước tiên chúng ta hãy kiểm tra các đường dẫn thực hiện.

Hiện tại, Verity của Lyft chủ yếu tập trung vào việc đảm bảo chất lượng dữ liệu được lưu trữ trong kho dữ liệu Hive của mình. Tuy nhiên, có kế hoạch mở rộng khả năng của mình để hỗ trợ các nguồn dữ liệu khác trong tương lai.

Lưu ý rằng mặc dù họ coi Hive là một kho dữ liệu, nhưng họ thực sự sử dụng nó như một giải pháp lưu trữ dữ liệu kết hợp, hoạt động như một kho dữ liệu cho dữ liệu có cấu trúc, được xử lý và làm sạch (lớp bạc) đồng thời đóng vai trò là hồ dữ liệu cho sự kiện thô dữ liệu (lớp đồng).

Chất lượng dữ liệu kém trong Hive gây ra các số liệu thử nghiệm bị hỏng, các tính năng học máy không chính xác và bảng điều khiển thiếu sót.

Kiểm tra của Verity có thể được tích hợp vào Airflow DAG để đảm bảo rằng chỉ dữ liệu thô chất lượng cao mới được xử lý và lưu trữ trong Hive dưới dạng dữ liệu phái sinh.

Nhà sản xuất dữ liệu và người tiêu dùng có thể xác định việc kiểm tra chất lượng dữ liệu của họ và xác minh dữ liệu khi nó được tạo ra hoặc trước khi nó được sử dụng bên trong Luồng khí hoặc Flyte .

…

VerityAirflowOperator có thể được sử dụng theo kiểu chặn để tạm dừng DAG khi kiểm tra không thành công, ngăn chặn dữ liệu xấu tiếp cận sản xuất. Điều này sử dụng “ Giai đoạn-Kiểm tra-Trao đổi ” mẫu: chúng tôi tạo dữ liệu theo lược đồ theo giai đoạn, xác minh dữ liệu bằng toán tử chặn, sau đó đưa dữ liệu đó vào sản xuất nếu vượt qua quá trình kiểm tra chất lượng.

Việc kiểm tra cũng có thể được thực hiện thủ công hoặc được lên lịch tự động để xác minh cả dữ liệu thô và dữ liệu phái sinh.

Kiểm tra theo lịch trình của Verity được tách biệt khỏi mọi công cụ điều phối dữ liệu, vì vậy chúng vẫn chạy ngay cả khi Airflow hoặc Flyte ngừng hoạt động hoàn toàn. Điều này khắc phục sự cố thường gặp là kiểm tra không cảnh báo vì Tác vụ luồng khí không bao giờ chạy.

Vì vậy, về cơ bản có 3 cách chính để kích hoạt kiểm tra: như một phần của Airflow DAG, theo cách thủ công hoặc được lên lịch thông qua nền tảng/UI Verity.

Tôi không tin rằng các bước kiểm tra hiện tại có thể được tích hợp vào các đường dẫn phát trực tuyến theo thời gian thực (chẳng hạn như Flink + Kafka) để xác thực dữ liệu mẫu khi nó đi vào Hive (hoặc thậm chí sớm hơn).

Việc triển khai loại kiểm tra thời gian thực này sẽ cho phép phát hiện kịp thời những khác biệt, dẫn đến giảm chi phí lưu trữ và xử lý cũng như nâng cao chất lượng dữ liệu tổng thể.

Chà, nói một cách kỹ lưỡng, việc kiểm tra Verity được quản lý thông qua máy chủ API, máy chủ này có thể được sử dụng để kích hoạt kiểm tra theo chương trình thông qua một số API.

Máy chủ API Verity - Dịch vụ này xử lý tất cả các API bên ngoài liên quan đến việc chạy kiểm tra cũng như duy trì và truy xuất kết quả của chúng. Máy chủ API không thực hiện bất kỳ kiểm tra nào mà viết một thông báo vào Hàng đợi kiểm tra của chúng tôi, sử dụng Dịch vụ hàng đợi đơn giản (SQS).

Vì vậy, có thể, bạn có thể kích hoạt những công việc này theo cách thời gian thực hơn, chẳng hạn như từ công việc phát trực tuyến hoặc thậm chí, trong thời gian dài, bằng cách tích hợp với tính năng thu thập dữ liệu thay đổi Hive (CDC).

Tuy nhiên, khi được thực thi bên ngoài Airflow, những công việc này sẽ không thể chặn công việc xử lý dữ liệu; thay vào đó, chúng sẽ tạo ra các cảnh báo không đồng bộ được đẩy tới Hàng đợi Kiểm tra. Một số người tiêu dùng muốn trì hoãn quá trình xử lý dữ liệu khi kiểm tra không thành công, trong khi những người khác lại muốn tiếp tục và nhận được cảnh báo.

Bây giờ, hãy xem các bài kiểm tra chất lượng dữ liệu này.

Sau đây là ví dụ kiểm tra xem rider_events.session_id có bao giờ rỗng hay không. Điều này được thực hiện thông qua sự kết hợp của các thành phần truy vấn và điều kiện.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity chủ yếu tập trung vào việc xác định và thực thi kiểm tra chất lượng dữ liệu thay vì xác định các lược đồ dữ liệu hoàn chỉnh.

Xác thực lược đồ không phải là một khái niệm mới. Có một số phương pháp để xác định lược đồ dữ liệu sự kiện trong các hệ thống dựa trên sự kiện, chẳng hạn như Lược đồ JSON, Bộ đệm giao thức, Avro hoặc các định dạng lưu trữ như Parquet. Sự lựa chọn tối ưu phụ thuộc vào nền tảng công nghệ, cách sử dụng và các yêu cầu cụ thể của bạn.

Mặc dù lược đồ dữ liệu có giá trị trong việc xác định cấu trúc tổng thể của đối tượng dữ liệu hoặc hàng trong bảng, nhưng chúng lại thiếu khả năng nắm bắt các hoạt động kiểm tra xác thực phức tạp hơn dành riêng cho người tiêu dùng, chẳng hạn như phân phối dữ liệu, quy tắc kinh doanh, SLA và ngưỡng.

Hợp đồng dữ liệu vượt xa việc xác thực lược đồ, tập trung vào việc xác định lỗi cú pháp . Cá nhân tôi thấy rằng Lược đồ JSON cung cấp ở đây một tùy chọn phù hợp và dễ đọc hơn, tách biệt hiệu quả các khả năng xác thực cấu trúc và cú pháp này khỏi các mối lo ngại về tuần tự hóa hoặc lưu trữ.

Tuy nhiên, để giải quyết các lỗi ngữ nghĩa và nâng cao độ chính xác của dữ liệu, việc có một phương tiện xác định kiểm tra dữ liệu hiệu quả sẽ cho phép xác định khía cạnh khác của hợp đồng dữ liệu.

Đây là lúc Verity DSL phát huy tác dụng.

Ngoài việc xác thực về mặt ngữ nghĩa, hợp đồng dữ liệu còn đưa ra một khía cạnh quan trọng khác đáng được quan tâm.

Từ quan điểm cú pháp, việc kiểm tra xác thực vẫn nhất quán bất kể người tiêu dùng hay nhà sản xuất có liên quan. Bộ quy tắc xác thực không bị ràng buộc với bất kỳ người tiêu dùng hoặc nhà sản xuất cụ thể nào và có thể được xác định một lần và mãi mãi dưới dạng một lược đồ duy nhất.

Tuy nhiên, hợp đồng dữ liệu Verity DSL cung cấp mức độ chi tiết tốt hơn khi xác định các quy tắc độc lập nhỏ, đặc biệt phù hợp với bối cảnh này: ý nghĩa ngữ nghĩa và cách sử dụng dữ liệu khác nhau tùy thuộc vào người tiêu dùng cụ thể. Ngoài ra, không phải tất cả người tiêu dùng đều cần sử dụng tất cả các thuộc tính của một đối tượng. Kỳ vọng của họ khác nhau. Điều này không có nghĩa là chúng mâu thuẫn với nhau (điều này chắc chắn sẽ là một vấn đề), mà là những điểm bổ sung và khác biệt.

Do đó, việc cho phép tất cả người tiêu dùng thiết lập các quy tắc duy nhất mà khi được kết hợp một cách cộng tác có thể mang lại sự hiểu biết toàn diện về ý nghĩa ngữ nghĩa của chất lượng dữ liệu là khá quan trọng.

Và khía cạnh hợp tác này đặc biệt gây ấn tượng với tôi. Hãy kiên nhẫn với tôi, điều này có vẻ như quá đáng, nhưng theo quan điểm của tôi, nó đáng được đề cập. :)

Trao đổi dữ liệu cho phép các nhóm khác nhau (nhà sản xuất và người tiêu dùng) cộng tác hiệu quả. Việc thiết lập sự hiểu biết chung về những trao đổi dữ liệu này là điều tối quan trọng, giống như API trong phát triển phần mềm truyền thống. Trong kiến trúc vi dịch vụ, một phương pháp thử nghiệm cộng tác được gọi là hợp đồng hướng tới người tiêu dùng (CDC) đã xuất hiện, trong đó người tiêu dùng xác định hành vi dự kiến của API do nhà sản xuất cung cấp. Nhà sản xuất có trách nhiệm xác minh các hợp đồng này trước khi phát hành phiên bản mới.

Tôi nghĩ các hợp đồng dữ liệu có tinh thần hợp tác tương tự. Mặc dù việc xác thực dữ liệu được thực hiện trên dữ liệu thực, thay vì tại thời điểm phát hành và không chặn việc phát hành, nhưng nó dựa trên sự hợp tác và khuyến khích tinh thần đồng đội giữa nhà sản xuất dữ liệu và người tiêu dùng. Tôi thực sự tin rằng phương pháp hợp tác này là chìa khóa để cải thiện chất lượng dữ liệu và cần được tích hợp sâu hơn vào quy trình.

Chà, tôi rất thích vẽ những sự tương đồng…

Thực sự cần lưu ý rằng khía cạnh hợp tác này cũng được đề cập như một phần trong điều lệ xác thực của Lyft.

VerityUI cung cấp trải nghiệm khám phá dữ liệu hợp lý thông qua Trang chủ Verity. Tìm kiếm toàn văn của chúng tôi trên Siêu dữ liệu Định nghĩa Kiểm tra cho phép người dùng xem tất cả các kiểm tra hiện đang được thực thi và Kết quả Kiểm tra của chúng. Điều này có các tập hợp hữu ích như sở hữu nhóm, tên bảng và thẻ.

Tôi không hoàn toàn hiểu rõ về cách chia sẻ các vấn đề về hợp đồng dữ liệu giữa người tiêu dùng và nhà sản xuất thông qua giao diện người dùng nền tảng Verity, nhưng tôi chắc chắn nhận ra tầm quan trọng của việc cộng tác thông qua trang tổng quan:

• Nhà sản xuất giao diện sản phẩm dữ liệu có thể tự tin đảm bảo rằng họ không vô tình gây ra sự cố ở hạ lưu mà họ không lường trước được.

• Người sử dụng giao diện có thể yên tâm rằng sự phụ thuộc của họ vào giao diện không và sẽ không bị tổn hại.

Mặc dù Verity là một công cụ đáng chú ý để xác định việc kiểm tra chất lượng dữ liệu nhưng rất tiếc nó không phải là nguồn mở.

May mắn thay, có một khung chất lượng dữ liệu nguồn mở khác có tên Soda Core cung cấp chức năng tương tự.

Soda Core là một công cụ dòng lệnh mã nguồn mở và miễn phí và thư viện Python cho phép các kỹ sư dữ liệu kiểm tra chất lượng dữ liệu. Nó sử dụng đầu vào do người dùng xác định để tạo các truy vấn SQL chạy kiểm tra các tập dữ liệu trong nguồn dữ liệu để tìm dữ liệu không hợp lệ, bị thiếu hoặc không mong muốn. Khi kiểm tra không thành công, chúng sẽ hiển thị dữ liệu mà bạn đã xác định là "xấu" trong lần kiểm tra.

Trong quá trình quét tập dữ liệu, Soda Core đánh giá các bước kiểm tra được xác định trước để xác định dữ liệu không hợp lệ, bị thiếu hoặc không mong muốn.

Đây là phép kiểm tra tương đương bằng cách sử dụng cú pháp Soda.core cho bài kiểm tra Verity DSL đã được xác định trước đó.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core là một công cụ mạnh mẽ để đảm bảo chất lượng dữ liệu của bạn. Nó có thể giúp bạn xác định và khắc phục sớm các vấn đề về dữ liệu trước khi chúng có thể gây ra sự cố cho doanh nghiệp của bạn.

Điều đáng chú ý là Soda Core cũng có thể tạo điều kiện thuận lợi cho việc kiểm tra chất lượng dữ liệu để truyền dữ liệu trực tuyến bằng cách tích hợp liền mạch với Spark DataFrames.

Mặc dù việc kiểm tra chất lượng dữ liệu của Verity dành cho Hive được áp dụng cho các tập dữ liệu tĩnh, nhưng việc kiểm tra dữ liệu truyền phát cần phải nhẹ nhàng và hiệu quả hơn.

Dữ liệu thường được xử lý theo các đợt sự kiện nhỏ, có độ trễ rất thấp, khiến chúng phù hợp để kiểm tra theo thời gian thực và các trường hợp sử dụng cụ thể như phát hiện sự bất thường.

Cuối cùng, hãy đề cập đến việc có sẵn các công cụ xác thực dữ liệu khác, chẳng hạn như DeeQu, Great Expectations,…

Khi chúng ta kết thúc, tôi hy vọng bạn hiểu rõ hơn về các bước bạn có thể thực hiện để nâng cao hành trình chất lượng dữ liệu của mình.

Chúng tôi đã thấy hai cách tiếp cận riêng biệt để cải thiện chất lượng dữ liệu, mỗi cách đều có điểm mạnh và phương pháp riêng. Một tập trung vào việc tăng khả năng hiển thị và khả năng quan sát, thúc đẩy các nhà sản xuất dữ liệu nâng cao tiêu chuẩn chất lượng. Giải pháp còn lại ưu tiên nâng cao tiêu chuẩn chất lượng thông qua phương pháp thử nghiệm và xác nhận đầu tiên. Cả hai đều bổ sung.

Verity không chỉ đơn thuần là một ngôn ngữ dành riêng cho miền (DSL) để xác định việc kiểm tra dữ liệu; đó là một nền tảng tập trung trao quyền cho những người thực hiện dữ liệu cộng tác hiệu quả. Nền tảng này giúp nhà sản xuất và người tiêu dùng điều chỉnh các kỳ vọng về chất lượng dữ liệu, bao gồm định dạng, cấu trúc và độ chính xác.

Khả năng quản lý hợp đồng dữ liệu của Verity có thể (là?) được nâng cao hơn nữa bằng cách tích hợp với bộ tính năng rộng hơn, chẳng hạn như quản lý và khám phá siêu dữ liệu, để giải quyết các nhu cầu chất lượng dữ liệu phức tạp hơn.

Tương tự như điểm DQ của Airbnb, Verity của Lyft thúc đẩy vòng phản hồi hợp tác giữa nhà sản xuất dữ liệu và người tiêu dùng. Bằng cách khuyến khích và trao quyền cho mỗi nhóm nắm quyền sở hữu chất lượng dữ liệu, Verity nuôi dưỡng một môi trường hỗ trợ nơi chất lượng dữ liệu liên tục được cải thiện.

Tìm thấy bài viết này hữu ích? Theo dõi tôi trên Linkedin , buổi trưa , Và Trung bình ! Hãy 👏 bài viết này để chia sẻ nó nhé!