Airflow là gì?

Scrapeless Web Unlocker truy xuất nội dung web công khai cho các tác vụ thu thập mà một quy trình làm việc Apache Airflow có thể điều phối.

Apache Airflow là một nền tảng mã nguồn mở để định nghĩa, lập lịch và giám sát quy trình làm việc bằng Python. Một quy trình làm việc mô tả các tác vụ rời rạc và các quan hệ phụ thuộc giữa chúng. Đối với một nhóm dữ liệu, điều đó có nghĩa là một tác vụ trích xuất có thể hoàn thành trước khi việc xác thực bắt đầu, và một tác vụ báo cáo có thể phụ thuộc vào dữ liệu đã được chấp nhận thay vì chỉ phụ thuộc vào việc đến một thời điểm nhất định trên đồng hồ.

Sự khác biệt này quan trọng khi một chương trình thu thập trở thành một dịch vụ dùng chung. Một script có thể truy xuất một trang chính xác trong khi quy trình xung quanh vẫn thiếu một chủ sở hữu rõ ràng, một khoảng thời gian thu thập dự kiến, hoặc một định nghĩa đáng tin cậy về việc hoàn thành. Airflow cung cấp điều phối xung quanh công việc đó. Ứng dụng vẫn chịu trách nhiệm quyết định ý nghĩa của dữ liệu trả về.

Cách một DAG của Airflow biểu diễn công việc

Một DAG của Airflow mô hình hóa các tác vụ và mối quan hệ thực thi của chúng. Từ viết tắt này xuất phát từ directed acyclic graph: các kết nối có hướng, và các đường phụ thuộc không quay vòng lại chính chúng. Một tác vụ có thể phụ thuộc vào một tác vụ ở phía thượng nguồn, và nhiều tác vụ độc lập có thể trở nên đủ điều kiện để thực thi sau một điều kiện tiên quyết chung.

Mô hình quy trình làm việc Airflow kết hợp định nghĩa tác vụ với lập lịch và các thiết lập vận hành khác. Python giúp định nghĩa này có thể được rà soát trong hệ thống quản lý phiên bản. Do đó, một thay đổi đối với đồ thị phụ thuộc có thể trải qua cùng quy trình rà soát như một thay đổi đối với logic nghiệp vụ của ứng dụng.

Tách định nghĩa quy trình làm việc khỏi một lần thực thi cụ thể. Một quy trình báo cáo hàng ngày là một định nghĩa có thể tái sử dụng; lần thực thi cho một khoảng báo cáo cụ thể là một run. Tương tự, tác vụ có tên extract có một ngữ cảnh thực thi trong run đó. Giữ cho các khái niệm đó tách biệt giúp giải thích vì sao hai run có thể có kết quả khác nhau dù chúng dùng chung cùng mã quy trình làm việc.

Ranh giới tác vụ nên bám theo các đầu ra có ý nghĩa. Tải xuống tài liệu nguồn, kiểm tra danh tính của nó, trích xuất bản ghi, và ghi các bản ghi được chấp nhận là những trách nhiệm khác nhau. Gộp mọi thứ vào một tác vụ mờ đục có thể thuận tiện ban đầu, nhưng nó làm cho trạng thái tác vụ ít cung cấp thông tin hơn khi một lần thu thập tạo ra dữ liệu không đầy đủ.

Những gì bộ lập lịch điều phối

Bộ lập lịch điều phối công việc đủ điều kiện bằng cách sử dụng lịch, các phụ thuộc tác vụ, và trạng thái thực thi đã ghi nhận. Chi tiết thực thi phụ thuộc vào triển khai và executor của nó. Cơ sở dữ liệu metadata lưu trữ trạng thái điều phối; nó không nên trở thành điểm đến lưu trữ tình cờ cho bộ dữ liệu nghiệp vụ được thu thập.

Worker thực hiện công việc ứng dụng được giao cho chúng. Một tác vụ có thể thực thi Python, chạy một lệnh, hoặc gửi công việc tới một dịch vụ khác. Airflow có thể điều phối việc gửi đó, nhưng xác nhận chấp nhận của một dịch vụ riêng biệt có thể mô tả một mốc khác với việc hoàn thành cuối cùng của nó. Định nghĩa tác vụ của bạn nên xác định rõ mốc nào mà nó cam kết.

Một giao diện web hiển thị trạng thái quy trình làm việc và tác vụ để người vận hành có thể điều tra các run. Giao diện đó chỉ hữu ích khi log của tác vụ chứa đúng ngữ cảnh. Ghi lại nguồn, phạm vi thu thập, vị trí đầu ra, và kết quả xác thực. Tránh ghi log thông tin xác thực hoặc toàn bộ nội dung mà người vận hành không cần để chẩn đoán quy trình làm việc.

Bản thân mã quy trình làm việc cũng có chi phí vận hành. Giữ các công việc thu thập và chuyển đổi tốn kém bên trong đường thực thi tác vụ dự định. Một định nghĩa thực hiện công việc từ xa trong lúc được nạp sẽ làm mặt phẳng điều khiển khó vận hành hơn và có thể làm mờ ranh giới giữa việc kiểm tra một quy trình làm việc và thực sự chạy nó.

Thời gian lập lịch khác với thời gian quan sát

Lịch của một quy trình làm việc mô tả khi nào công việc đến hạn, trong khi thời gian quan sát ghi lại khi nguồn thực sự được đọc. Các giá trị đó có thể khác nhau. Một run bị trì hoãn có thể thu thập một trang hiện tại ngay cả khi khoảng báo cáo dự định của nó đề cập đến một giai đoạn trước đó.

Đặt tên rõ ràng cho các dấu thời gian này trong hợp đồng dữ liệu. Đối với một quan sát giá công khai, khoảng thời gian dự định xác định báo cáo mà nó thuộc về; dấu thời gian quan sát xác định khi trang cung cấp giá trị đó. Một lần thực thi sau này không thể tái tạo một mức giá trước đó trừ khi một nguồn lịch sử thực sự cung cấp nó. Lịch sử lập lịch không phải là dữ liệu nguồn lịch sử.

Python phân biệt đối tượng ngày-giờ aware và naive. Hãy sử dụng xử lý múi giờ có chủ đích tại ranh giới quy trình làm việc thay vì giả định rằng đồng hồ cục bộ của máy chủ khớp với múi giờ báo cáo nghiệp vụ. Tài liệu hóa múi giờ nào xác định một ngày báo cáo, đặc biệt khi một nhóm và hạ tầng của họ hoạt động ở các khu vực khác nhau.

Đối với các dấu thời gian được trao đổi, quy ước dấu thời gian Internet cung cấp một cách biểu diễn rõ ràng về thời gian và độ lệch. Định dạng một dấu thời gian một cách nhất quán không giải quyết được ý nghĩa nghiệp vụ của nó. Tên trường và hợp đồng vẫn cần giải thích liệu nó ghi lại thời điểm nguồn được xuất bản, được thu thập, được xác thực, hay được chèn vào cơ sở dữ liệu.

Một quy trình thu thập với chấp nhận rõ ràng

Một quy trình thu thập web nên tiến triển dựa trên các đầu ra được chấp nhận thay vì dựa trên sự tồn tại của một tệp đã tải xuống. Hãy xem xét một nhóm thu thập tính sẵn có sản phẩm công khai cho một so sánh tồn kho hàng ngày. Quy trình làm việc bắt đầu từ một danh sách nguồn đã được phê duyệt mà các mục của nó xác định sản phẩm và locale dự kiến.

Tác vụ thu thập gửi yêu cầu tới từng nguồn được phép. Scrapeless Web Unlocker có thể cung cấp nội dung trang công khai tại ranh giới này, và Scrapeless Web Unlocker capabilities mô tả phạm vi của dịch vụ. Airflow điều phối tác vụ thu thập mà không trở thành bộ kết xuất trang hay bộ phân tích HTML. Giữ phản hồi đã truy xuất tách biệt với các bản ghi cuối cùng được phê duyệt để báo cáo.

Quá trình xác thực sau đó kiểm tra định danh trang và nội dung bắt buộc. Một thông báo truy cập được tải xuống thành công không nên đáp ứng cùng một hợp đồng như trang sản phẩm. Một trường tình trạng còn hàng bị thiếu phải tạo ra một kết quả không đầy đủ một cách rõ ràng thay vì bị âm thầm chuyển đổi thành một quan sát hết hàng.

Nhiệm vụ tiếp theo trích xuất các bản ghi đã chuẩn hóa và lưu chúng kèm ngữ cảnh nguồn. Chỉ đầu ra được chấp nhận mới đủ điều kiện đưa vào báo cáo. Một phản hồi bị từ chối có thể giữ lại tham chiếu chẩn đoán để điều tra, trong khi bảng nghiệp vụ vẫn có thể diễn giải được. Thiết kế này làm cho một khoảng thời gian không đầy đủ trở nên hiển thị thay vì công bố một phép so sánh trống gây hiểu lầm.

Lựa chọn độ chi tiết của nhiệm vụ và các điểm bàn giao

Độ chi tiết của nhiệm vụ quyết định những gì người vận hành có thể hiểu và kiểm soát một cách độc lập. Một ranh giới hữu ích có đầu vào rõ ràng, điều kiện hoàn thành rõ ràng và đầu ra mà các nhiệm vụ ở bước sau có thể nhận diện mà không cần đoán.

Đối với các bộ dữ liệu lớn, hãy truyền một vị trí lưu trữ bền vững và siêu dữ liệu mô tả giữa các giai đoạn thay vì coi thông điệp điều phối là kho lưu trữ dữ liệu chính. Bao gồm phạm vi sưu tập và phiên bản schema được chấp nhận cùng với vị trí đó. Một nhiệm vụ ở bước sau phải có thể xác định rằng nó đang đọc đúng hiện vật cho lần chạy dự định.

Tên tệp có thể thay đổi dùng chung là một nguồn gây mơ hồ thường gặp. Nếu nhiều lần chạy đều ghi vào cùng một tệp latest, một nhiệm vụ ở bước sau bị trễ có thể đọc nội dung từ một khoảng thời gian khác. Nên ưu tiên định danh đầu ra gắn với một lần chạy hoặc một phân vùng dữ liệu bất biến, rồi chỉ cập nhật bất kỳ con trỏ latest nào sau khi bộ dữ liệu đã vượt qua bước chấp nhận.

Việc thực thi trùng lặp cũng cần một quyết định ở tầng ứng dụng. Một thao tác lưu trữ phải có cách ổn định để định danh một quan sát hoặc một lô được chấp nhận. Ghi lại cùng một lô đã được chấp nhận không nên tạo ra một sự kiện nghiệp vụ thứ hai chỉ vì dịch vụ điều phối thực thi lại một nhiệm vụ. Bộ lập lịch không thể suy ra giúp bạn định danh bản ghi chính xác.

So sánh Airflow với một lệnh chạy theo lịch đơn lẻ

Airflow mang lại giá trị khi các phụ thuộc và lịch sử thực thi cần có mô hình vận hành riêng. Một lệnh chạy theo lịch đơn lẻ có thể là đủ khi lệnh đó sở hữu một khối lượng công việc nhỏ, độc lập và đầu ra của nó có thể được kiểm tra trực tiếp.

Đừng áp dụng Airflow chỉ vì một script chạy mỗi ngày. Hãy áp dụng khi nhóm cần thấy và quản lý các phụ thuộc giữa thu thập, xác thực, lưu trữ và công bố. Các phụ thuộc đó là lý do để chấp nhận thêm trách nhiệm về dịch vụ, cấu hình và bảo trì.

Giới hạn trách nhiệm của Airflow

Airflow điều phối công việc hữu hạn; nó không làm cho nguồn bên ngoài trở nên đúng hay đầy đủ. Một nhiệm vụ hoàn thành thành công vẫn có thể đã dùng sai locale, chọn nhầm một trang không liên quan, hoặc ghi các quan sát trùng lặp nếu logic ứng dụng cho phép hành vi đó.

Tiêu thụ thông điệp liên tục là một ranh giới khác. Một luồng công việc có thể điều phối triển khai hoặc xử lý hữu hạn xung quanh một dòng sự kiện, nhưng một bộ tiêu thụ chạy vô thời hạn có vòng đời khác với một nhiệm vụ batch. Hãy quyết định hệ thống nào sở hữu vòng đời đó trước khi nhúng nó vào bên trong một luồng công việc theo lịch.

Chi phí cũng thuộc về hợp đồng. Xem lại Scrapeless pricing khi việc thu thập sử dụng một dịch vụ bên ngoài trả phí, và giới hạn phạm vi nguồn cho mỗi lần chạy. Lên lịch một danh sách nguồn lớn hơn với tần suất cao hơn sẽ thay đổi nhu cầu thu thập ngay cả khi DAG gần như không thay đổi. Ghi lại phạm vi dự định cùng với thay đổi luồng công việc để người xem xét có thể đánh giá tác động thực tế.

Phần thảo luận đi kèm về thu thập dữ liệu web theo lịch với Airflow cho thấy các giai đoạn thu thập khớp với nhau như thế nào. Hãy xem đó là bối cảnh triển khai trong khi vẫn giữ nguyên các quy tắc chấp nhận nguồn riêng của bạn. Một luồng công việc ví dụ không thể quyết định những trường bị thiếu hoặc khoảng thời gian không đầy đủ nào mà người dùng báo cáo của bạn có thể chấp nhận được.

Kết luận

Airflow mang lại cho công việc dữ liệu định kỳ một đồ thị rõ ràng, lịch và lịch sử thực thi. Tính hữu dụng của nó phụ thuộc vào các hợp đồng nhiệm vụ mô tả đầu ra thực: một trang đã được nhận diện, các bản ghi được chấp nhận, một bộ dữ liệu đã được cam kết và một báo cáo được xây dựng từ bộ dữ liệu đó. Hãy bắt đầu bằng cách vẽ các ranh giới đó và đặt tên cho các mốc thời gian. Luồng công việc thu được phải cho phép người vận hành giải thích một lần chạy dự định điều gì, đã quan sát điều gì và những gì đã trở nên sẵn sàng cho người dùng ở bước sau.