Pandera kiểm tra dữ liệu crawl và tách quarantine

Pandera kiểm tra dữ liệu crawl kiểm schema ở mức DataFrame sau khi dữ liệu đã được tải và trích. Batch có cột đúng tên vẫn có thể chứa giá âm hoặc thiếu mã hàng. Bài này dùng ba record tự tạo, gom lỗi theo dòng và đối soát tập được nhận với quarantine trước khi xuất dữ liệu. ProxyVN hướng dẫn cách kiểm trên dữ liệu mẫu.

Pandera kiểm tra dữ liệu crawl sau bước trích xuất

Pandera kiểm các điều kiện dữ liệu theo schema được định nghĩa. Nó không sửa selector, không tải HTML và không cấu hình proxy cho crawler. Pipeline nên đưa record đã trích vào DataFrame rồi kiểm theo hợp đồng trước khi ghi vào kho chính.

Nếu selector lấy nhầm giá từ một sản phẩm khác nhưng giá vẫn không âm, schema đơn giản có thể cho qua. Vì vậy kiểm định cấu trúc không thay thế nhãn đối chiếu nguồn. Nó bảo vệ những điều đã được viết thành điều kiện, không tự biết giá nào thuộc sản phẩm nào.

DataFrame Schemas của Pandera là nguồn đối chiếu API theo backend. Bài dùng pandas và import pandera.pandas cho môi trường lab đã khóa. Không nhận kết quả này là xác nhận cùng code chạy trên mọi backend mà không chỉnh.

Schema là một hợp đồng có phiên bản

Hợp đồng cần nêu tên trường, kiểu, giá trị được phép và cách xử lý thiếu. Một thay đổi schema có thể làm nhiều record từ đạt thành không đạt dù nguồn không đổi. Ghi version giúp phân biệt lỗi nguồn với thay yêu cầu nội bộ.

Chọn điều kiện theo tác vụ, không theo dữ liệu đẹp nhất trong một batch. Nếu mọi giá lab đều dương, điều đó không tự đủ để cấm giá bằng không ở nguồn thật. Kỳ vọng cần được nghiệp vụ xác định rồi mới đưa thành Check.

Giữ raw record trước những bước chuyển kiểu có thể làm mất thông tin. Khi validation thất bại, người vận hành cần thấy nguồn của giá trị, không chỉ một DataFrame đã được fillna hoặc cắt dòng. Dữ liệu lỗi có provenance giúp sửa có mục tiêu.

Pandera kiểm tra dữ liệu crawl với bộ ba record lỗi

Bộ thử có một record A giá 12.5, record B giá âm và record thứ ba thiếu SKU. Mỗi record giữ source_url tự tạo để nối lỗi với nguồn. Dữ liệu không đến từ website hoặc khách hàng, nên expected output được biết trước.

Ba record và schema pandas

Chuẩn bị DataFrame có index duy nhất

Ví dụ dùng RangeIndex mặc định để map lỗi dòng. Nếu dữ liệu thật dùng index khác, giữ định danh nguồn riêng và kiểm index có duy nhất không. Một lỗi index trùng có thể khiến thao tác loc chọn nhiều dòng hơn dự kiến.

import pandas as pd
import pandera.pandas as pa
frame = pd.DataFrame([
    {'sku': 'A', 'price': 12.5, 'source_url': 'http://lab.invalid/a'},
    {'sku': 'B', 'price': -1.0, 'source_url': 'http://lab.invalid/b'},
    {'sku': None, 'price': 3.0, 'source_url': 'http://lab.invalid/c'},
])
assert frame.index.is_unique
schema = pa.DataFrameSchema({
    'sku': pa.Column(str, nullable=False),
    'price': pa.Column(float, pa.Check.ge(0), nullable=False),
}, strict=False, coerce=False)

strict false cho phép giữ source_url ngoài hai cột được kiểm trong ví dụ. Điều đó không có nghĩa source_url đã được validate là URL hợp lệ. Các field không có điều kiện cần được gọi đúng phạm vi khi bàn giao.

coerce false giúp ca này kiểm dữ liệu đã có kiểu theo thiết kế, thay vì tự đổi mọi chuỗi thành số. Giá float dùng cho fixture minh họa kiểu; nếu nhiệm vụ cần một biểu diễn số khác, chọn và nghiệm thu schema tương ứng. Đừng suy mọi dữ liệu giá phải dùng float.

Expected output cần có trước khi validate

Record A phải nằm trong tập được nhận. Record B bị loại vì miền giá trị theo Check, record thiếu SKU bị loại vì nullable false. Hai lỗi có nguyên nhân khác nhau và cần được giữ lý do theo field.

Tổng ba record bằng một record được nhận cộng hai record quarantine theo bộ thử. Nếu report đếm ba lỗi thành ba dòng bị loại, cần kiểm số failure case khác số record. Một dòng có thể vi phạm nhiều điều kiện.

Không xóa record lỗi khỏi nguồn rồi chạy lại để mọi thứ pass mà không giữ báo cáo. Quarantine là đầu ra có chủ đích của bước kiểm, không phải rác không cần đối soát. Nó giúp biết số lượng và loại dữ liệu chưa đáp ứng hợp đồng.

Pandera kiểm tra dữ liệu crawl với lazy validation

Lazy validation cho phép thu nhiều lỗi trong phạm vi API hỗ trợ thay vì chỉ dừng ở một lỗi đầu. Điều này hữu ích khi cần báo cáo batch. Tuy nhiên bảng lỗi có thể chứa cả lỗi theo dòng và lỗi ở mức schema, cần được phân biệt trước khi tách quarantine.

Đọc failure cases theo đúng đơn vị

Tài liệu Lazy Validation mô tả SchemaErrors và thông tin lỗi. Trong fixture, các index không đạt là một và hai. Không dùng số hàng của failure_cases làm số record lỗi nếu cùng index xuất hiện nhiều lần.

Một lỗi thiếu cột hoặc không đúng cấu trúc có thể không gắn với một index dòng cụ thể. Không chuyển giá trị thiếu index thành số không rồi loại record đầu tiên. Đó là lỗi batch cần chính sách riêng, chẳng hạn dừng công bố và báo schema không phù hợp.

Giữ check, column, failure_case và index nếu chúng có mặt trong output đã kiểm. Trường có thể khác theo version và loại lỗi, nên parser báo cáo cần được test. Không giả định mọi error object đều có cùng shape chỉ từ một ca giá âm.

Tách lỗi dòng với lỗi toàn batch

Đoạn sau áp dụng fixture có index duy nhất và những lỗi dòng đã thiết kế. Nó dừng khi bảng lỗi có dòng không xác định index để tránh loại nhầm dữ liệu. Pipeline thực cần mở rộng chính sách cho các loại schema error mà dự án chấp nhận.

try:
    accepted = schema.validate(frame, lazy=True)
    quarantine = frame.iloc[0:0].copy()
except pa.errors.SchemaErrors as error:
    failures = error.failure_cases
    if failures['index'].isna().any():
        raise RuntimeError('Batch-level schema error needs review') from error
    bad = failures['index'].drop_duplicates().tolist()
    quarantine = frame.loc[bad].copy()
    accepted = frame.drop(index=bad).copy()
assert len(frame) == len(accepted) + len(quarantine)
assert len(accepted) == 1 and len(quarantine) == 2

Đây là chiến lược xử lý phía ứng dụng, không phải tuyên bố mọi lỗi Pandera đều map được sang dòng. Giữ assertion tổng giúp phát hiện mất hoặc đếm lặp record. Với index không duy nhất, thiết kế mapping phải khác và cần ca riêng.

Không bắt mọi exception rồi xuất accepted rỗng như một batch hợp lệ. Lỗi import, thiếu file hoặc schema không chạy cần trạng thái khác dữ liệu bị từ chối. Báo cáo phải cho biết validator có thật sự thực thi hay không.

Pandera kiểm tra dữ liệu crawl với dtype và nullable

Kiểu và trạng thái thiếu có quan hệ nhưng không phải cùng một điều kiện. Một cột có dtype đúng vẫn có thể có giá trị thiếu theo cách backend biểu diễn. Một chuỗi nhìn như số cũng chưa có dtype số nếu chưa qua bước chuẩn hóa.

Dtype nullable và miền giá trị

Chuyển kiểu cần giữ dữ liệu gốc

Nếu nguồn trả chuỗi giá, bước chuẩn hóa phải biết dấu phân cách và đơn vị. Coercion không tự giải quyết mơ hồ giữa dấu phẩy hàng nghìn và phần thập phân. Giữ raw_price cùng lỗi chuyển để người nhận biết dữ liệu đã được diễn giải ra sao.

Một chuỗi rỗng chuyển thành thiếu không phải nguồn đã công bố giá bằng không. Không fillna bằng không để làm điều kiện không âm đạt. Quy tắc sửa hoặc điền mặc định phải thuộc hợp đồng riêng và có lý do, không chỉ phục vụ validation.

Khi bật coerce ở schema khác, kiểm ca thành công và ca không thể chuyển. Thêm record có chuỗi không phải số để xác nhận lỗi còn nhìn thấy. Không dùng một ca số ASCII đơn để khẳng định mọi định dạng giá từ web sẽ chuyển đúng.

Nullable không xác nhận ý nghĩa nghiệp vụ

Một field cho phép null có thể hợp lệ khi nguồn không công bố, nhưng cần trạng thái để downstream biết thiếu. Một field không cho null có thể làm cả record bị quarantine. Chọn theo mục tiêu và chi phí thiếu dữ liệu, không theo việc muốn tăng tỷ lệ đạt.

Nếu nguồn thay từ SKU sang một định danh khác, schema cũ có thể báo nhiều lỗi thiếu. Đừng tự điền tên sản phẩm vào SKU để giảm fail. Cần đánh giá lại mapping nguồn và version schema, giữ các record bị ảnh hưởng để tái xử lý.

Kiểm not-null cũng không thay điều kiện chuỗi không trắng. Một SKU là vài dấu cách có thể cần Check riêng. Nếu tác vụ yêu cầu điều đó, tạo fixture trắng và expected fail trước khi thêm vào schema.

Pandera kiểm tra dữ liệu crawl với miền giá trị

Một điều kiện không âm chỉ bảo vệ ranh giới đã viết. Nó không xác nhận số hữu hạn, đơn vị đúng hoặc quan hệ với trường khác. Schema cần được mở rộng theo yêu cầu thực và có ca phản ví dụ cho từng lớp.

Giá trị đặc biệt cần được nhận diện

Số vô cực dương có thể thỏa phép so lớn hơn hoặc bằng không trong phép toán số. Vì vậy Check.ge không nên được gọi là kiểm mọi giá hợp lệ. Nếu dữ liệu yêu cầu hữu hạn, thêm điều kiện hữu hạn với API và backend đã kiểm.

NaN và các dạng thiếu có thể chịu quy tắc nullable cùng cách Check xử lý của thư viện. Đọc tài liệu phiên bản và chạy fixture thay vì suy theo cách Python so một giá trị đơn. Một điều kiện đúng trên scalar chưa đủ để nhận hành vi cả Series.

Validating with Checks giúp đối chiếu cách viết điều kiện. Bài không đặt khoảng giá tối đa tùy tiện cho mọi sản phẩm. Một ngưỡng nghiệp vụ cần nguồn yêu cầu và tập mẫu, không được bịa để có thêm Check.

Quan hệ giữa các trường và khóa

SKU có thể lặp qua nhiều ngày nếu dữ liệu là snapshot lịch sử. Ép unique trên SKU toàn bộ batch nhiều ngày có thể loại record hợp lệ. Nếu cần duy nhất theo SKU và ngày, hợp đồng phải nêu khóa ghép phù hợp.

Giá trị currency cần được giữ nếu tác vụ có nhiều đơn vị. Không so số price giữa hai đồng tiền như cùng một đại lượng. Schema kiểm cột riêng không tự xác nhận mọi phép tổng hợp downstream đã đúng đơn vị.

Với hai cột như min và max, quan hệ cần được kiểm theo dòng bằng điều kiện phù hợp. Đừng nhận hai cột đều có dtype số là bảo đảm thứ tự đúng. Chọn những quan hệ mà người sử dụng dữ liệu thật sự cần bảo vệ.

Pandera kiểm tra dữ liệu crawl và quarantine có nguồn

Quarantine cần đủ thông tin để tái xử lý mà không phải đoán record từ một giá trị lỗi. Giữ source_url, snapshot hoặc mã input, vị trí dòng và schema version theo nhu cầu. Không chỉ xuất một cột giá âm rồi mất liên kết tới dữ liệu gốc.

Quarantine nối với failure cases

Một record có thể có nhiều lý do

Bảng record lỗi và bảng failure cases có thể được lưu riêng rồi nối bằng định danh. Cách này tránh nhân đôi record khi nó có nhiều vi phạm. Report nên có số record riêng và số lỗi riêng để người nhận hiểu khối lượng cần xử lý.

Nếu index DataFrame bị reset giữa validation và export, mapping lỗi có thể sai. Giữ một row_id ổn định hoặc tách quarantine ngay trên cùng frame theo thiết kế. Không dùng số thứ tự hiện trên màn hình như định danh vĩnh viễn qua mọi phép sort và join.

Khi có lỗi mức batch không gắn dòng, giữ report schema và dừng công bố theo chính sách. Không tự bỏ qua lỗi vì không biết quarantine dòng nào. Một batch thiếu cột bắt buộc có thể cần quay lại bước trích thay vì lọc một vài record.

Đối soát sau khi ghi file

Đọc lại accepted và quarantine để kiểm số lượng, khóa và nguồn còn nguyên. JSONL cần hợp đồng encoding và cách biểu diễn null. Một DataFrame đúng trong RAM vẫn có thể bị xuất sai kiểu hoặc mất ID ở bước ghi.

Giữ manifest gồm tổng input, số được nhận, số bị từ chối và lỗi batch nếu có. Nếu các nhóm không cộng về tổng theo chiến lược đã chọn, dừng để kiểm mapping. Đừng sửa tổng bằng tay để bảng báo cáo trông hợp lý.

Khi mua proxy cho tầng thu, kiểm đường tải riêng. Giá âm do parser hoặc nguồn không được sửa bằng việc validator chạy qua một tuyến khác. Bộ lab của bài không dùng gateway thương mại và không thu dữ liệu bên ngoài.

Pandera kiểm tra dữ liệu crawl khi tích hợp định kỳ

Chạy định kỳ cần quan sát tỷ lệ và loại lỗi theo nguồn, không chỉ pass toàn batch. Một layout đổi có thể làm lỗi tăng ở một nhóm nhỏ. Tách số liệu theo nguồn và schema version giúp phát hiện nơi cần sửa.

Đối soát batch trước công bố

Theo dõi thay đổi mà không tự xóa lỗi

Nếu số record thiếu SKU tăng sau một lần deploy parser, so snapshot và mapping trước khi nới nullable. Nếu nguồn thật không còn SKU, đó là thay đổi hợp đồng cần đánh giá. Một cấu hình cho phép mọi thứ sẽ làm validator mất tác dụng.

Quarantine không nên bị xóa ngay sau mỗi lượt để giữ kho sạch. Chọn chính sách lưu theo nhu cầu tái xử lý và quyền dữ liệu. Giữ ít nhất báo cáo tổng cùng nguyên nhân cần thiết theo chính sách để biết một lỗi đã được giải quyết hay chỉ biến mất khỏi thống kê.

Khi sửa parser, tái xử lý từ input có nguồn còn được phép giữ rồi chạy validation lại. Không sửa trực tiếp output lỗi thành giá trị đẹp nếu không có bằng chứng. Ghi phương pháp và version để phân biệt dữ liệu được thu mới với dữ liệu được tái diễn giải.

Điều kiện bàn giao

Bộ thử ba record đã chạy trả một record được nhận và hai record quarantine theo hai loại lỗi. Nó chưa chứng minh mọi ràng buộc dữ liệu sản phẩm hoặc mọi backend Pandera. Giữ phạm vi này trong ghi chú và thêm ca theo schema thực trước production.

Tài liệu pandas indexing giúp đối chiếu thao tác chọn dòng trong ví dụ. Quy tắc lỗi dòng chỉ an toàn khi index và mapping được giữ đúng. Nếu thay cách tổ chức frame, chạy lại những assertion tổng và khóa nguồn.

Giữ fixture, schema, failure cases và output đọc lại cùng version. Một validator hữu ích phải chỉ ra record nào không đạt và vì sao. Số test xanh không thay bằng chứng dữ liệu đã được đối soát ở ranh giới công bố cuối.

Pandera kiểm tra dữ liệu crawl qua bảng lỗi đã quan sát

Bảng lỗi của fixture có hai dòng với hai index nguồn khác nhau. Một dòng ghi column sku và check not_nullable ở index hai. Dòng còn lại ghi column price, điều kiện không âm và failure_case âm một ở index một. Những giá trị này đến từ bộ thử đã chạy, không phải mẫu báo cáo được điền bằng tay.

Đọc column và check trước khi chọn cách sửa

Lỗi sku cho biết điều kiện không thiếu bị vi phạm ở record tương ứng. Nó không nói nguồn không có mã hàng, vì parser cũng có thể đã không lấy được. Trước khi sửa, truy lại snapshot bằng source_url hoặc mã input để xác định nơi thông tin biến mất.

Lỗi price cho biết giá trị âm không đáp ứng Check đã chọn. Trong lab, đây là lỗi chủ đích. Với dữ liệu thật, cần hiểu nguồn đang biểu diễn gì; một giá trị âm có thể thuộc trường điều chỉnh khác bị map nhầm, không nên tự đổi dấu để làm record đạt.

Tên check phục vụ diễn giải nhưng pipeline nên có mã lỗi nội bộ ổn định nếu cần báo cáo lâu dài. Một thay đổi wording của thư viện không nên làm dashboard tạo hàng loạt loại lỗi mới. Giữ raw failure case cùng mapping version để vẫn truy được output gốc.

Index nối về dòng chứ không phải một ID nghiệp vụ

Index một và hai trong fixture là vị trí theo RangeIndex của frame được tạo. Sau khi sort hoặc reset_index, cùng con số có thể chỉ record khác. Vì vậy việc map lỗi phải được thực hiện trên đúng frame đã validate hoặc qua một row_id không thay đổi.

Nếu hai dòng cùng nhãn index, loc theo một nhãn có thể lấy cả hai. Lúc đó tập quarantine theo nhãn có thể chứa một record không hề vi phạm. Assertion index.is_unique trong ví dụ là một điều kiện đầu vào quan trọng, không phải chi tiết trang trí.

Với dữ liệu từ nhiều tệp, giữ source_file và line_number hoặc một định danh input tương đương. URL có thể lặp qua nhiều snapshot nên cũng chưa chắc là khóa dòng. Mục tiêu là một lỗi phải nối đúng record của đúng lần quan sát.

Failure case rỗng vẫn có ý nghĩa

Trong lỗi thiếu SKU, failure_case có thể biểu diễn null. Điều đó không làm dòng báo cáo vô nghĩa; nó chính là giá trị gây vi phạm nullable. Đừng dropna toàn bảng lỗi để làm report gọn vì có thể xóa những lỗi cần giữ.

Các cột như check_number cũng có thể thiếu theo loại lỗi. Parser báo cáo cần xử lý trạng thái đó theo schema, không ép mọi ô thành số. Một phép chuyển kiểu lỗi ở bước xuất report sẽ che mất nguyên nhân validation mà người dùng cần xem.

Khi ghi JSONL, dùng serializer phù hợp với null và kiểu dữ liệu của bảng lỗi. Đọc lại để kiểm các trường còn nguyên và không biến giá trị thiếu thành chuỗi “nan” ngoài ý muốn. Report là dữ liệu cần kiểm như output chính.

Pandera kiểm tra dữ liệu crawl với phản ví dụ bổ sung

Ngoài ba record chính, bộ lab còn kiểm hai giới hạn: số vô cực dương và thiếu cột bắt buộc. Chúng cho thấy vì sao một điều kiện nhỏ không được gọi là kiểm mọi giá trị hợp lệ. Các ca được giữ riêng để tránh làm lẫn số lượng của batch ba record.

Không âm chưa đồng nghĩa hữu hạn

Một DataFrame riêng có price là vô cực dương đã vượt qua schema chỉ dùng Check.ge cùng các điều kiện tương ứng. Đây là hành vi toán học phù hợp với phép so được chọn. Nó không đáp ứng yêu cầu giá hữu hạn nếu dự án có yêu cầu đó.

Schema bổ sung điều kiện hữu hạn bằng phép kiểm vector trên Series đã từ chối record này trong lab. Nhờ hai lượt cùng input, có thể thấy điều kiện mới thực bắt lớp lỗi nào. Không cần tạo ngưỡng giá tối đa tùy tiện để nhận biết một giá trị không hữu hạn.

Ca này cũng nhắc rằng dtype đúng không bảo đảm miền giá trị đúng. Một float có thể mang các giá trị đặc biệt. Nếu hợp đồng không cho phép, viết điều kiện và thêm phản ví dụ; nếu hợp đồng khác, ghi rõ thay vì gọi mặc định của kiểu là chính sách nghiệp vụ.

Thiếu cột là lỗi của batch

Trong ca riêng, loại cột sku khỏi frame rồi validate đã tạo lỗi có index không ánh xạ tới một dòng cụ thể. Vì cột bắt buộc không tồn tại, loại một vài record không sửa được cấu trúc batch. Pipeline cần dừng hoặc chuyển nhánh theo chính sách đã định.

Đoạn xử lý mẫu cố ý raise khi gặp lỗi không có index. Đây là điểm dừng để người vận hành xem, không phải một nỗ lực tự đoán record lỗi. Nếu dự án muốn xử lý thiếu cột bằng adapter, tạo bước có version và giữ lý do trước validation.

Không tạo một cột sku toàn null rồi xóa mọi dòng để báo đã xử lý xong lỗi schema. Hành động đó làm mất câu trả lời về nguyên nhân batch sai cấu trúc. Một report lỗi toàn batch rõ ràng hữu ích hơn output rỗng được gắn nhãn thành công.

Kiểm lại accepted thay vì chỉ kiểm quarantine

Sau khi tách lỗi dòng, tập accepted nên được kiểm theo những điều kiện mà nó cần đáp ứng. Nếu thao tác chuẩn hóa hoặc join tiếp theo làm đổi kiểu, một lần validate trước đó không còn chứng minh output cuối. Chọn điểm kiểm theo ranh giới công bố dữ liệu.

Với fixture, accepted phải giữ SKU A, price 12.5 và source_url a. Quarantine phải giữ hai record còn lại cùng giá trị nguyên của chúng. So khóa và giá trị giúp phát hiện một phép chọn dòng nhầm mà assertion tổng số vẫn có thể bỏ qua.

Nếu record có nhiều lỗi, nó vẫn chỉ xuất hiện một lần trong bảng quarantine record. Bảng failure cases có thể có nhiều dòng nối về nó. Đếm hai bảng riêng giúp nhóm sửa biết cả số record chịu ảnh hưởng và số loại vi phạm cần giải quyết.

Tái xử lý cần bằng chứng sửa nguồn

Một record được sửa không nên chỉ có trạng thái từ fail sang pass mà mất lý do. Giữ parser version hoặc quy tắc chuẩn hóa đã tạo lại giá trị. Khi có thể, tái trích từ snapshot còn được phép giữ và đối soát với nhãn thay vì chỉnh trực tiếp output.

Sau sửa, chạy lại schema và giữ kết quả mới bên cạnh kết quả lỗi trước. Nếu source đã đổi, ghi đó là lần thu mới thay vì giả làm cùng input. Phân biệt hai trường hợp giúp báo cáo chất lượng phản ánh quá trình thực, không chỉ tỷ lệ cuối tăng.

Một chính sách tự động có thể chấp nhận một số sửa có tính xác định như chuẩn hóa khoảng trắng, nhưng phải được thiết kế và kiểm trước. Pandera không tự cung cấp ý nghĩa của mọi phép sửa. Validator nên làm rõ dữ liệu không đạt để ứng dụng quyết định theo hợp đồng.

Kiểm schema để nhìn thấy dữ liệu không đạt; quarantine cần giữ nguồn và lý do, không phải chỉ xóa dòng làm batch đẹp hơn.

Anh em hãy lưu dữ liệu mẫu cùng cấu hình và kết quả đối chiếu để lần cập nhật sau có cơ sở kiểm lại. Tham khảo thêm tại Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam. Bắt đầu từ phạm vi nhỏ và tiêu chí rõ ràng khi triển khai Pandera kiểm tra dữ liệu crawl.