Data Pipeline Là Gì?

Scrapeless Web Unlocker truy xuất nội dung web cho giai đoạn thu thập của một data pipeline, bao gồm cả các trang yêu cầu render JavaScript.

Data Pipeline Là Gì?

Một data pipeline là một chuỗi các bước xử lý được kết nối với nhau, dùng để di chuyển dữ liệu từ nguồn tới đích, cùng với mọi thao tác trích xuất, biến đổi, kiểm tra và phân phối cần thiết trên đường đi. Nguồn có thể là cơ sở dữ liệu ứng dụng, tệp, luồng sự kiện hoặc một website công khai được ủy quyền. Đích có thể là bảng báo cáo, chỉ mục tìm kiếm hoặc một ứng dụng khác. Pipeline mô tả khối lượng công việc giữa hai bên và các quy tắc quyết định khi nào kết quả trở nên có thể sử dụng được.

Một script tải xuống một trang có thể là một thành phần của pipeline. Một data pipeline web hoàn chỉnh cũng giải thích đã thu thập những gì, bản ghi nào được chấp nhận, chúng được lưu ở đâu, và khi nào bên tiêu thụ có thể sử dụng chúng. Sự phân biệt này quan trọng khi một tác vụ kết thúc thành công nhưng tạo ra một danh mục chưa đầy đủ. Hoàn thành tiến trình xử lý và hoàn thành tập dữ liệu là hai sự kiện khác nhau.

Pipeline Cần Những Giai Đoạn Nào?

Một pipeline cần các ranh giới rõ ràng cho việc thu thập, diễn giải, chấp nhận và phân phối, ngay cả khi một chương trình triển khai mọi giai đoạn. Bắt đầu với một hợp đồng nguồn: tập dữ liệu nào nằm trong phạm vi, quyền truy cập nào được cho phép, và điều gì cấu thành một lần quan sát đầy đủ. Với một danh mục sản phẩm, điều đó có thể là các danh mục đã được phê duyệt, một thị trường, và một khoảng thời gian quan sát được xác định.

Ingestion đưa byte hoặc sự kiện từ nguồn vào hệ thống. Parsing chuyển các byte đó thành các bản ghi ứng viên. Transformation gán ý nghĩa nhất quán cho các trường, chẳng hạn như tách số tiền giá khỏi loại tiền tệ. Validation quyết định bản ghi có đáp ứng hợp đồng của đích hay không. Delivery giúp các bản ghi được chấp nhận sẵn sàng cho người đọc. Orchestration lập lịch cho các hoạt động này và thực thi các quan hệ phụ thuộc giữa chúng.

Giữ bằng chứng thu thập tách biệt với các trường nghiệp vụ đã biến đổi. Mô hình PROV cho nguồn gốc dữ liệu mô tả cách các thực thể, hoạt động và tác nhân chịu trách nhiệm liên hệ với nhau. Một hiện thực thực tiễn có thể bắt đầu với vị trí nguồn, thời điểm quan sát, phiên bản parser và mã định danh cho mỗi lần chạy. Những trường này cho phép nhà phân tích lần ngược một giá trị bất ngờ về bằng chứng đã tạo ra nó.

Batch Và Streaming Khác Nhau Thế Nào?

Batch pipeline xử lý một tập hợp có giới hạn, trong khi streaming pipeline xử lý một chuỗi sự kiện diễn ra liên tục. Một lần xuất dữ liệu theo lịch tự nhiên là có giới hạn: một job nhận một đầu vào được xác định và tạo một đầu ra cho lần chạy đó. Một luồng luôn hoạt động và phải quyết định khi nào một sự kiện đã sẵn sàng để tổng hợp, đặc biệt khi sự kiện đến không theo thứ tự.

Độ mới nên là một yêu cầu chứ không phải khẩu hiệu. Một báo cáo thị trường hằng ngày có thể chấp nhận xử lý theo lô theo lịch. Một cảnh báo vận hành có thể cần cập nhật sớm sau một sự kiện liên quan. Streaming thêm các quyết định về thời gian sự kiện, thời gian đến, bộ đệm và dữ liệu trễ. Lịch chạy nhanh hơn không tự động khiến một nguồn web trở nên cập nhật hơn; nguồn đó có thể công bố không thường xuyên hoặc tự cache kết quả của nó.

Thiết kế lai (hybrid) rất phổ biến. Một luồng có thể hỗ trợ các góc nhìn vận hành hiện tại trong khi một job có giới hạn xây lại các tổng hợp lịch sử. Cả hai nhánh nên sử dụng các định nghĩa tương thích, nếu không bảng điều khiển thời gian thực và báo cáo sau này có thể bất đồng vì những lý do không liên quan đến thay đổi ở nguồn.

ETL Và ELT Có Giống Data Pipeline Không?

ETL và ELT là các cách sắp xếp pipeline khác nhau ở chỗ biến đổi diễn ra ở đâu. Extract, transform, load chuẩn bị dữ liệu trước khi đưa vào đích. Extract, load, transform đưa dữ liệu nguồn vào trước rồi thực hiện biến đổi bằng môi trường xử lý của đích. Khái niệm pipeline rộng hơn cũng bao gồm các workflow sao chép dữ liệu mà không thay đổi ý nghĩa nghiệp vụ của nó.

Lựa chọn này ảnh hưởng tới truy cập và khôi phục. Biến đổi trước khi phân phối có thể giữ các trường không phù hợp tránh xa hệ thống báo cáo. Đưa dữ liệu thô vào trước có thể bảo toàn bằng chứng cho việc diễn giải lại trong tương lai, nhưng cũng tạo ra một kho lưu trữ cần kiểm soát thời gian lưu giữ và hạn chế truy cập. Lưu trữ thô chỉ hữu ích khi ai đó có thể nhận diện phiên bản nguồn và quy trình đã tạo ra nó.

Mô tả các đích tách biệt với mã hóa tệp. Một dataset có thể có nhiều bản có thể tải về khác nhau mà không trở thành nhiều dataset không liên quan. Sự phân biệt DCAT giữa datasets và distributions giúp làm rõ sự tách biệt đó trong các catalog và trong quá trình bàn giao.

Một pipeline dữ liệu web trông như thế nào?

Một pipeline dữ liệu web chuyển các quan sát trang đã được chấp thuận thành các bản ghi mà các hệ thống hạ nguồn có thể diễn giải. Hãy xem một thiết kế minh họa cho việc giám sát danh mục. Đầu vào là một danh sách danh mục đã được phê duyệt. Tầng thu thập lấy từng trang liên quan. Tầng khám phá theo cơ chế phân trang/tiếp tục của trang web. Tầng trích xuất xác định sản phẩm và các thuộc tính hiển thị của chúng. Tầng chuẩn hóa ghi nhận số tiền, đơn vị tiền tệ, tình trạng sẵn có và danh tính nguồn thành các trường riêng biệt.

Giai đoạn chấp nhận kiểm tra rằng phản hồi chứa danh mục dự kiến chứ không phải thông báo truy cập hoặc một khung trang rỗng. Sau đó nó kiểm tra các định danh bắt buộc và kiểu trường. Một giá bị thiếu được giữ nguyên là thiếu với một trạng thái giải thích khi nguồn thực sự bỏ qua nó. Nó không bị chuyển thành số 0. Cuối cùng, tầng phân phối ghi một quan sát được khóa bằng danh tính sản phẩm và ngữ cảnh quan sát.

Scrapeless Web Unlocker nằm ở ranh giới tầng thu thập. Hợp đồng yêu cầu Web Unlocker xác định cách yêu cầu nội dung. Ứng dụng của bạn vẫn sở hữu phạm vi khám phá, quy tắc phân tích cú pháp, xác thực bản ghi và lưu trữ. Sự phân chia này ngăn việc một yêu cầu thu thập thành công bị nhầm với một lần nạp kho dữ liệu hợp lệ.

Đối với các lần thu thập theo lịch, web scraping gia tăng và phát hiện thay đổi có thể giảm công việc hạ nguồn không cần thiết. Một thay đổi tài liệu và một thay đổi bản ghi nghiệp vụ là hai câu hỏi riêng biệt. Một banner điều hướng có thể thay đổi tài liệu trong khi mọi thuộc tính sản phẩm vẫn giữ nguyên.

Các checkpoint và xử lý trùng lặp nên hoạt động như thế nào?

Một checkpoint nên đại diện cho dữ liệu đã được chấp nhận một cách bền vững, không chỉ đơn thuần là đã được yêu cầu. Nếu một worker ghi nhận token tiếp tục trước khi lưu lô hiện tại, một tiến trình bị dừng có thể để lại một khoảng trống chưa được ghi nhận. Hãy lưu đầu ra đã được chấp nhận và mốc tiến độ của nó trong một ranh giới mà bạn hiểu rõ hành vi khi lỗi.

Hãy chọn danh tính đích dựa trên câu hỏi nghiệp vụ. Một bảng trạng thái mới nhất có thể dùng định danh nguồn và sản phẩm. Một lịch sử quan sát cũng cần một ranh giới quan sát. Hai lần nhìn thấy cùng một sản phẩm vào các ngày khác nhau có thể là lịch sử hợp lệ. Hai lần phân phối cùng một quan sát không nên tạo ra các sự kiện nghiệp vụ bổ sung.

Ghi ghi-idempotent khiến việc phân phối lặp lại cùng một đầu vào logic tạo ra cùng một kết quả được lưu trữ. Tính chất này phụ thuộc vào khóa và ngữ nghĩa ghi; nó không được bảo đảm bởi một hàng đợi hoặc bộ lập lịch. Hãy ghi rõ liệu một lần nạp thay thế một partition, trộn theo khóa, hay chỉ thêm các quan sát. Tránh tuyên bố hành vi exactly-once xuyên suốt nếu không phải mọi ranh giới liên quan đều hỗ trợ tuyên bố đó.

Đối với các đầu ra dạng bảng, siêu dữ liệu bảng và ràng buộc khóa cung cấp một từ vựng hữu ích cho các hàng, cột, khóa chính và quan hệ. Hãy thống nhất về các ý nghĩa đó trước khi bên tiêu thụ bắt đầu join đầu ra.

Bạn nên giám sát những gì?

Hãy giám sát tình trạng của bộ dữ liệu đã phân phối cùng với tình trạng của các worker. Thời lượng job và số lượng yêu cầu giải thích việc sử dụng tài nguyên. Bản ghi được chấp nhận, bị từ chối, mức độ bao phủ nguồn và độ tuổi của quan sát đã hoàn tất mới nhất giải thích liệu đầu ra có hữu ích hay không. Một job không có ngoại lệ vẫn có thể không phân phối được gì.

Định nghĩa độ mới tại điểm tiêu thụ. Thời điểm nguồn xuất bản, thời điểm thu thập và thời điểm khả dụng trong kho dữ liệu trả lời những câu hỏi khác nhau. Một timestamp thu thập gần đây không thể chứng minh rằng nội dung nguồn là gần đây. Hãy giữ các phân biệt này thay vì cho mọi thời điểm vào một trường gọi là updated time.

Khi một partition không vượt qua được giai đoạn chấp nhận, hãy giữ partition được chấp nhận cuối cùng có thể nhận diện được và đánh dấu partition hiện tại là chưa hoàn chỉnh. Một bên tiêu thụ nên có khả năng phân biệt dữ liệu cũ nhưng đã được chấp nhận với dữ liệu vừa được thu thập nhưng chưa vượt qua xác thực. Gán một người phụ trách cho mỗi quy tắc quan trọng để cảnh báo dẫn tới quyết định chứ không chỉ là một log bị bỏ mặc.

Hãy đo chi phí trên mỗi kết quả nghiệp vụ được chấp nhận khi so sánh các thiết kế. Giá Scrapeless thông tin cho việc lập kế hoạch thu thập, trong khi lưu trữ, chuyển đổi và rà soát tạo thêm chi phí. Cải thiện độ chính xác trích xuất có thể có giá trị hơn là tăng thông lượng yêu cầu thô.

Làm sao để bạn bắt đầu với một thiết kế có thể quản lý được?

Hãy bắt đầu với một nguồn, một hợp đồng đầu ra và một quyết định của bên tiêu thụ. Viết ra cấp độ hạt (grain) của bản ghi, các trường bắt buộc, quy tắc đầy đủ, hạn chót độ mới và người phụ trách. Triển khai một lần chạy có giới hạn trước khi thêm lập lịch phân tán. Dùng một mẫu nguồn đại diện để sớm lộ ra các trường bị thiếu và định danh mơ hồ.

Tách bạch các thay đổi của nguồn với các thay đổi trong cách bạn diễn giải nó. Một bản phát hành parser có thể thay đổi đầu ra mà không cần bất kỳ cập nhật nào từ nguồn. Lưu đủ bằng chứng để giải thích sự khác biệt đó, tùy theo thời hạn lưu trữ được cho phép. Việc thu thập thông tin cá nhân yêu cầu mục đích riêng, kiểm soát truy cập và quy trình xóa; tính công khai không giải quyết các nghĩa vụ đó.

Kết luận

Một pipeline dữ liệu hữu ích có ranh giới chấp nhận rõ ràng và ranh giới phân phối rõ ràng. Bắt đầu với đường đi nhỏ nhất từ nguồn đến bên tiêu thụ, khiến tiến độ và bằng chứng của nó có thể được kiểm tra, rồi chỉ mở rộng sau khi bên tiêu thụ có thể giải thích mỗi bản ghi được lưu trữ đại diện cho điều gì.