Pydantic chuẩn hóa dữ liệu crawl và giữ lỗi theo URL

Pydantic chuẩn hóa dữ liệu crawl kiểm từng item trước khi dữ liệu đi vào kho chính. Cần chọn rõ nơi cho phép chuyển kiểu và nơi yêu cầu kiểu nghiêm, thay vì để dữ liệu sai bị sửa âm thầm. Bài này dùng JSONL tự tạo, so quantity dạng số với chuỗi và giữ lỗi trường cùng URL nguồn. ProxyVN hướng dẫn cách kiểm trên dữ liệu mẫu.

Pydantic chuẩn hóa dữ liệu crawl ở ranh giới item

Pydantic biểu diễn hợp đồng dữ liệu bằng model và các điều kiện được khai báo. Nó không tải web, không xác minh mọi giá trị theo nguồn và không sửa mọi lỗi parser. Pipeline nên giữ raw item cùng provenance trước khi đưa vào bước validate.

Một item có đủ kiểu vẫn có thể gắn sai giá vào sản phẩm. Model chỉ kiểm những điều đã được định nghĩa. Nếu cần đối chiếu sự thật nguồn, phải giữ snapshot và bộ nhãn riêng, không gọi validation pass là chứng nhận dữ liệu chính xác ngoài thực tế.

Tài liệu Models là nguồn đối chiếu API hiện hành. Bài dùng dòng Pydantic 2 và fixture đã chạy trong môi trường khóa version. Không áp tên hàm của ví dụ sang một bản lớn khác mà không kiểm tương thích.

Tách chuẩn hóa có chủ đích với chuyển kiểu mặc định

Một nguồn có thể trả quantity là chuỗi vì dữ liệu đi từ HTML. Nếu hợp đồng cho phép, bước chuẩn hóa có thể chuyển theo quy tắc rõ. Nhưng nếu ở ranh giới này ứng dụng đã yêu cầu số nguyên, việc tiếp tục nhận chuỗi có thể che lỗi ở bước trước.

Không có một chế độ đúng cho mọi field. Mã hàng cần giữ chữ số đầu, số lượng có miền giá trị, còn giá có biểu diễn thập phân. Chọn kiểu và chính sách theo ý nghĩa, rồi thêm phản ví dụ để xác nhận model thực làm đúng điều đó.

Giữ giá trị raw ở bên ngoài hoặc trong cấu trúc audit phù hợp. Khi output đổi từ chuỗi sang số, người nhận cần biết đó là phép diễn giải. Không bỏ hết bằng chứng gốc rồi gán mọi giá trị chuẩn hóa thành nội dung nguồn đã công bố nguyên dạng.

Pydantic chuẩn hóa dữ liệu crawl với model mẫu

Fixture có SKU, quantity, price và source_url. Quantity yêu cầu int nghiêm ở field, price được parse thành Decimal theo điều kiện không âm. Các lựa chọn này chỉ là hợp đồng của bộ thử, không phải schema đủ cho mọi dữ liệu sản phẩm.

Raw item và model chuẩn hóa

Khai báo rõ điều kiện từng trường

Ví dụ không bật strict cho toàn model; nó chỉ bật ở quantity. Điều này quan trọng vì price vẫn được phép nhận chuỗi thập phân theo cách đã kiểm. Không gọi cả model strict rồi để người đọc suy mọi field có cùng chính sách.

from decimal import Decimal
from pydantic import BaseModel, ConfigDict, Field
class CrawlItem(BaseModel):
    model_config = ConfigDict(extra='forbid')
    sku: str
    quantity: int = Field(strict=True, ge=0)
    price: Decimal = Field(ge=0)
    source_url: str
 
item = CrawlItem.model_validate({
    'sku': 'A', 'quantity': 2, 'price': '12.50',
    'source_url': 'http://lab.invalid/a'})
assert item.quantity == 2
assert item.price == Decimal('12.50')

source_url trong model này là chuỗi để giữ provenance, chưa được kiểm cấu trúc URL bằng một kiểu chuyên biệt. SKU cũng chưa có điều kiện không trắng hoặc danh mục mã hợp lệ. Phạm vi được ghi rõ giúp người đọc không nhận thêm các bảo đảm mà code chưa có.

extra forbid làm field ngoài hợp đồng trở thành lỗi theo cấu hình. Nếu nguồn thêm trường mới, đó có thể là tín hiệu cần đánh giá schema chứ không phải lý do xóa trường âm thầm. Dự án có thể chọn chính sách khác, nhưng phải được version và kiểm.

Giá Decimal và dữ liệu raw

Decimal giúp giữ phép biểu diễn thập phân theo lựa chọn schema. Nó không tự biết currency hoặc cách diễn giải dấu phân cách địa phương. Chuỗi 12.50 trong fixture không đủ để nhận mọi chuỗi giá có dấu phẩy, ký hiệu tiền hoặc khoảng trắng đặc biệt.

Nếu cần làm sạch từ HTML, đặt bước đó trước hoặc trong validator có mục tiêu và giữ raw_price. Một thao tác xóa mọi ký tự không phải số có thể làm mất dấu âm hoặc phần thập phân. Không dùng phép sửa rộng để làm model dễ pass hơn.

Mẫu chưa có currency nên không dùng output của nó cho phép so nhiều đồng tiền. Nếu tác vụ cần, bổ sung field và điều kiện tương ứng. Một schema nhỏ có giới hạn minh bạch tốt hơn lời hứa dữ liệu giá đã được kiểm mọi mặt.

Pydantic chuẩn hóa dữ liệu crawl với coercion và strict

Coercion có thể hữu ích ở ranh giới dữ liệu được phép linh hoạt, nhưng cũng có thể che một lỗi kiểu. Strict cần được chọn ở đúng mức và kiểm theo loại input. Không suy một ví dụ scalar thành quy tắc của mọi kiểu dữ liệu trong thư viện.

So cùng quantity dưới hai hợp đồng

Trong lab, một model chỉ có quantity kiểu int theo chế độ mặc định đã nhận chuỗi 2 và trả số nguyên hai. Model item dùng Field strict đã từ chối cùng kiểu chuỗi ở field quantity. Hai kết quả phản ánh hai hợp đồng khác nhau, không phải một kết quả đúng chung cho mọi nguồn.

Strict Mode là nguồn đối chiếu các mức cấu hình. Khi cần strict ở model hoặc ở một lần gọi, đọc API phiên bản và kiểm lại field liên quan. Không đổi một tham số toàn cục rồi giữ nguyên mọi expected output cũ.

Nếu parser trước đó phải tạo int, một chuỗi xuất hiện bất ngờ là tín hiệu cần xem lại. Nếu nguồn hợp lệ chỉ có chuỗi, có thể chuẩn hóa có chủ đích rồi validate. Quyết định thuộc hợp đồng pipeline, không được chọn theo việc muốn giảm số lỗi.

Kiểm giá trị không âm riêng với kiểu

Một quantity là int đúng nhưng âm sẽ vi phạm ge theo schema. Một quantity là chuỗi hai sẽ vi phạm kiểu strict trước khi được coi là số lượng hợp lệ. Giữ type và loc của lỗi giúp người nhận phân biệt hai nguyên nhân.

Price âm trong fixture tạo lỗi ở field price theo điều kiện không âm. Không tự đổi thành giá dương hoặc số không để tiếp tục pipeline. Record cần đi vào nhánh từ chối hoặc xử lý theo quy tắc nghiệp vụ có bằng chứng.

Một giá trị hợp kiểu nhưng sai nguồn vẫn có thể pass. Ví dụ quantity được lấy từ sản phẩm bên cạnh có thể là int không âm. Vì vậy test mapping nguồn và test schema nên cùng tồn tại, mỗi lớp bảo vệ một điều kiện khác nhau.

Pydantic chuẩn hóa dữ liệu crawl và báo lỗi theo URL

ValidationError chứa thông tin có cấu trúc để báo field không đạt. Pipeline nên nối lỗi với record nguồn trước khi ghi report. Không chỉ in một exception chung rồi bỏ mất URL và vị trí input cần sửa.

Coercion so với quantity strict

Giữ loc type và giá trị có chọn lọc

loc cho biết đường dẫn field theo output lỗi. Với model lồng, nó có thể có nhiều phần nên đừng ép thành một tên cột bằng cách lấy phần cuối tùy tiện. Giữ cấu trúc hoặc cách biểu diễn đã được schema báo cáo định nghĩa.

type hữu ích để nhóm nguyên nhân mà không phụ thuộc toàn bộ thông điệp tiếng Anh. msg giúp người đọc hiểu ca cụ thể. input có thể chứa dữ liệu nhạy cảm, nên chỉ lưu phần cần và che theo chính sách của dự án.

Error Handling giúp đối chiếu định dạng. Một số context có thể chứa kiểu chưa serialize JSON trực tiếp, nên cần một cách xuất report đã kiểm. Không bắt lỗi ghi report rồi bỏ toàn bộ record sai vì như vậy mất bằng chứng.

Không biến mọi exception thành lỗi item

JSON sai cú pháp, file không đọc được và ValidationError của object là các trạng thái khác nhau. Nếu json.loads chưa tạo được dict, model chưa thực hiện kiểm field. Report cần giữ lớp lỗi để người vận hành biết sửa dữ liệu dòng hay môi trường đọc file.

Lỗi lập trình trong validator cũng không nên bị đổi thành record quarantine bình thường rồi chạy tiếp vô hạn. Thiết kế điểm dừng cho lỗi hệ thống và lỗi dữ liệu. Một batch có hàng nghìn record lỗi do code hỏng cần trạng thái khác với vài record nguồn không đạt.

Khi mua proxy cho tầng thu, kiểm tuyến riêng bằng request được phép. Một model không đạt không được sửa bằng thay IP nếu raw item vẫn giữ cùng giá trị. Bộ lab của bài chỉ validate dữ liệu tự tạo, không kiểm gateway thương mại.

Pydantic chuẩn hóa dữ liệu crawl từ JSONL

JSONL phù hợp xử lý từng record nhưng cần giữ số dòng và định danh nguồn. Một dòng sai không nên làm mất khả năng đối soát những dòng còn lại theo chính sách đã chọn. Tuy nhiên việc tiếp tục hay dừng batch phải được định nghĩa trước.

Tách parse JSON và validate object

Đọc từng dòng bằng encoding đã định, parse JSON rồi kiểm object theo model. Nếu input là list hoặc scalar ngoài hợp đồng, ghi lỗi kiểu ở ranh giới phù hợp. Không tự bọc mọi giá trị thành dict để model có vẻ nhận được.

Giữ line_number hoặc input_id bên cạnh source_url. URL có thể thiếu trong chính record lỗi hoặc lặp qua nhiều snapshot. Vị trí dòng giúp tìm lại input trong tệp đã được nhận diện bằng hash mà không đoán từ thông điệp lỗi.

Không bỏ qua dòng trống hay dòng lỗi theo một cách không có báo cáo nếu số lượng cần đối soát. Chính sách có thể cho phép bỏ dòng trống, nhưng tổng phải nói rõ. Một con số input khác output không có lý do sẽ làm batch khó kiểm lại.

Accepted và quarantine là hai đầu ra có schema

Accepted giữ dữ liệu model đã chuẩn hóa cùng provenance cần dùng. Quarantine giữ raw record hoặc tham chiếu nguồn, lỗi và model version theo chính sách. Không chỉ xuất chuỗi msg vì sẽ mất mapping tới field và record.

Tổng input cần bằng các nhóm trạng thái theo chiến lược xử lý. Nếu tách lỗi JSON và lỗi model, báo số lượng riêng. Một record có nhiều field lỗi vẫn là một record không đạt, trong khi bảng error có thể có nhiều dòng.

Nếu ghi output theo batch, dùng tệp tạm và manifest phù hợp để không công bố một phần như đã hoàn tất. Đọc lại JSONL để kiểm các kiểu và giá trị chuẩn hóa còn đúng. Một model pass trong RAM chưa chứng minh dữ liệu cuối đã được ghi đủ.

Pydantic chuẩn hóa dữ liệu crawl và serialization

Object sau validate có thể chứa kiểu Python như Decimal. Cách xuất sang JSON cần được chọn theo API thay vì tự gọi str cho mọi thứ. Nếu không, downstream có thể nhận schema khác điều được mô tả trong model.

JSONL accepted và quarantine

Chọn chế độ xuất phù hợp

Trong lab, model_dump ở chế độ JSON tạo price dưới dạng chuỗi 12.50 theo output đã quan sát. Điều này giữ biểu diễn thập phân của mẫu theo cơ chế thư viện. Nó không có nghĩa mọi người nhận sẽ tự hiểu chuỗi đó là giá kèm currency.

import json
row = item.model_dump(mode='json')
assert row['price'] == '12.50'
line = json.dumps(row, ensure_ascii=False)
assert json.loads(line)['quantity'] == 2

Serialization là nguồn đối chiếu các lựa chọn xuất. Nếu downstream yêu cầu một kiểu khác, định nghĩa schema giao nhận và kiểm đọc lại. Không thay mode hoặc serializer để tránh lỗi mà không xem tác động kiểu dữ liệu.

Tên field hoặc alias khi xuất cũng cần nhất quán. Nếu thêm alias để nhận dữ liệu nguồn, kiểm output dùng tên nào theo cấu hình. Một hệ thống nhận sourceUrl nhưng xuất source_url cần hợp đồng rõ để không làm mất provenance ở bước tiếp.

Giữ vòng kiểm sau khi đọc lại

Đọc lại output bằng parser mà downstream thực sử dụng rồi so các trường quan trọng. Một price bị chuyển sang float hoặc quantity bị thành chuỗi có thể làm bước sau diễn giải khác. Kiểm giao nhận là một phần của nghiệm thu, không chỉ kiểm model đầu vào.

Nếu dùng model_validate_json thay cho json.loads rồi model_validate, đối chiếu ngữ nghĩa theo kiểu và strict mode của phiên bản. Không mặc định hai ranh giới có hành vi giống với mọi kiểu dữ liệu. Ví dụ của bài chọn một đường rõ để expected có thể tái lập.

Khi output bị từ chối downstream, giữ bản serialized và schema giao nhận để điều tra. Đừng chỉ nới model đầu vào vì lỗi có thể phát sinh lúc xuất. Mỗi lần chuyển kiểu cần được nối với một bước cụ thể trong pipeline.

Pydantic chuẩn hóa dữ liệu crawl khi schema thay đổi

Nguồn và yêu cầu nội bộ có thể đổi theo thời gian. Model version giúp ghi rõ record đã được validate theo hợp đồng nào. Không dùng một tên model không đổi để che việc vừa thêm điều kiện bắt buộc hoặc đổi kiểu.

Validate và serialization theo version

Trường mới cần được đánh giá

Với extra forbid, một field mới tạo tín hiệu lỗi theo cấu hình lab. Nó có thể là thay đổi nguồn hợp lệ cần cập nhật mapping, hoặc dữ liệu lạc ngoài hợp đồng. Người vận hành phải xem trước khi quyết định cho phép, không tự xóa để giữ tỷ lệ đạt.

Nếu chọn extra khác trong dự án, ghi rõ cách field ngoài được giữ hoặc bỏ. Một chính sách bỏ trường có thể phù hợp ở ranh giới nào đó nhưng không bảo vệ mục tiêu phát hiện source đổi schema. Chọn theo nhu cầu, không theo mặc định được sao chép.

Khi đổi tên field hoặc alias, chạy fixture cũ và mới theo quy tắc migration. Không lấy dữ liệu đã chuẩn hóa làm nguồn duy nhất nếu raw còn cần để tái diễn giải. Giữ lịch sử phương pháp giúp hiểu vì sao output của cùng snapshot thay đổi.

Bộ ca cần giữ trước bàn giao

Giữ item hợp lệ, quantity chuỗi và price âm như ba ca đã chạy. Thêm field thiếu, field dư, chuỗi trắng và kiểu không được hỗ trợ theo model thực. Mỗi ca cần expected field lỗi, không chỉ expected exception chung.

Nếu thêm model lồng, kiểm loc nhiều thành phần và cách nối nguồn. Nếu dùng URL type, kiểm scheme và giá trị sai theo hợp đồng thư viện. Những nhánh đó chưa được chứng nhận bởi model source_url str nhỏ của bài.

Khi nâng Pydantic, chạy lại cả validate và serialization. So dữ liệu output cùng cấu trúc lỗi mà hệ thống báo cáo đang dùng. Một nâng cấp có thể cần điều chỉnh adapter lỗi dù các record tốt vẫn pass.

Điều kiện nghiệm thu

Ba record lab xác nhận chính sách quantity strict ở field và giá không âm, cùng cách xuất Decimal của mẫu. Chúng không chứng minh mọi dữ liệu sản phẩm đã đúng nguồn hoặc mọi chuỗi giá địa phương được parse. Giữ phạm vi trong ghi chú trước khi đưa vào production.

Gói tái hiện cần model, raw fixture, version, accepted và report lỗi có nguồn. Không đưa token hoặc payload tài khoản thật nếu dữ liệu tự tạo đã đủ thể hiện vấn đề. Một mô hình tốt phải giúp nhìn rõ ranh giới chuyển kiểu, từ chối và dữ liệu đã được nhận.

Pydantic chuẩn hóa dữ liệu crawl qua lỗi trường đã quan sát

Thông tin lỗi nên được đọc từ field đến chính sách, rồi mới quyết định sửa ở đâu. Với record B, URL nguồn là b và loc chỉ quantity. Với record C, URL nguồn là c và loc chỉ price. Sự khác biệt này giúp người nhận truy về hai đầu vào mà không phải tìm trong toàn batch.

Quantity chuỗi không được nhận như số nguyên nghiêm

Record B có quantity là chuỗi hai. Model field strict trả type int_type trong phép thử. Nó chưa phải một lỗi miền số lượng âm, vì vấn đề nằm ở kiểu đầu vào. Nếu parser trước được yêu cầu tạo int, cần sửa hoặc kiểm bước đó thay vì nới schema theo cảm giác.

Model loose riêng trong lab đã chuyển chuỗi hai thành int. Kết quả đó chỉ cho thấy coercion được phép ở hợp đồng kia. Nó không chứng minh nguồn sai hoặc đúng; yêu cầu pipeline mới quyết định có chấp nhận phép chuyển đó ở ranh giới hiện tại hay không.

Khi thay chính sách từ loose sang strict, báo số record bị ảnh hưởng theo nguồn. Một lần deploy có thể làm nhiều chuỗi số trước đây được nhận chuyển sang quarantine. Đây là thay đổi hợp đồng cần đánh giá, không nên chỉ gọi là sửa lỗi thư viện.

Price âm có kiểu lỗi khác

Record C đưa price âm dưới dạng chuỗi. Nhánh price được phép parse theo model, nhưng điều kiện không âm không đạt. Output lỗi chỉ ra field price cùng loại greater_than_equal trong môi trường đã thử. Quantity của record đó vẫn là int phù hợp.

Nếu một record có cả quantity sai kiểu và price âm, báo cáo có thể có nhiều lỗi cùng một input. Đếm record lỗi một lần và giữ danh sách field lỗi riêng. Không nhân bản raw record thành nhiều sản phẩm lỗi chỉ vì có nhiều thông điệp validation.

Context của lỗi có thể chứa ngưỡng theo kiểu Python mà serializer thông thường chưa xử lý. Chọn API xuất lỗi phù hợp hoặc một adapter chỉ chuyển những trường được phép. Không dùng str cho toàn bộ record rồi đánh mất cấu trúc loc và type mà downstream cần nhóm lỗi.

Bool và float cần ca riêng khi yêu cầu int nghiêm

Bộ lab bổ sung quantity là True và quantity là số thực hai chấm không. Field strict đã từ chối cả hai trong các ca đã chạy. Điều này làm rõ yêu cầu của ví dụ là kiểu int ở ranh giới Python, không chỉ một giá trị có thể diễn giải thành số nguyên.

Không suy kết quả này thành quy tắc của mọi field hoặc mọi đường JSON. Khi đổi kiểu hoặc cách gọi validate, đọc tài liệu và chạy phản ví dụ tương ứng. Một hợp đồng ở field đủ rõ sẽ dễ kiểm hơn một câu chung rằng model đang “nghiêm” mà không nói với dữ liệu nào.

Nếu nghiệp vụ chấp nhận số lượng viết dưới dạng số thực nguyên, có thể có một bước chuẩn hóa có chủ đích trước strict field. Bước đó cần giữ input và điều kiện, không được cắt phần thập phân của mọi số. Một giá trị hai chấm năm không nên âm thầm thành hai chỉ để đi qua model.

Pydantic chuẩn hóa dữ liệu crawl với báo cáo có thể sửa

Một báo cáo hữu ích cần cho biết record nào, field nào và hợp đồng nào bị vi phạm. Nó cũng cần giữ trạng thái của file hoặc lượt xử lý. Nếu batch chưa đọc hết, không nên trình bày tổng như mọi input đã được kiểm.

Field dư là tín hiệu schema theo cấu hình

Trong ca bổ sung, model nhận một field unexpected và đã từ chối theo extra forbid. Đây là hành vi được yêu cầu bởi cấu hình, không phải giá trị đó tự nguy hiểm hay vô nghĩa. Người vận hành cần xem nguồn đã thêm dữ liệu gì trước khi quyết định mở schema.

Nếu hợp đồng cho phép một vùng metadata mở, thiết kế vùng đó rõ thay vì nới mọi field ở cấp gốc. Điều này giúp giữ khả năng phát hiện lỗi gõ tên như quanity thay vì quantity. Một field lạ có thể là thay đổi nguồn hoặc lỗi mapping, cần được phân biệt bằng snapshot.

Khi cập nhật model để nhận field mới, đặt version và chạy lại fixture cũ. Output cũ cần được xử lý theo chính sách tương thích mà dự án đã chọn. Không ép dữ liệu lịch sử có field chưa từng được nguồn cung cấp bằng cách điền giá trị suy đoán.

Chọn dữ liệu lỗi được phép ghi

Lỗi có thể mang lại raw input của field, nhưng không phải mọi giá trị đều cần đưa vào log tập trung. Với mẫu tự tạo, chuỗi hai và giá âm không có bí mật. Với nguồn tài khoản thật, giữ tham chiếu input và thông tin lỗi đã giảm dữ liệu theo chính sách.

URL nguồn có query token cần được che trong báo cáo chia sẻ nếu token không cần tái hiện. Tuy nhiên vẫn cần một mã input nội bộ để truy record được phép đọc. Che bí mật và giữ provenance là hai yêu cầu có thể thiết kế cùng nhau, không cần bỏ toàn bộ nguồn.

Một danh sách lỗi JSON có cấu trúc dễ nhóm theo loc và type hơn một traceback dài cho mọi item. Traceback vẫn hữu ích cho lỗi hệ thống, nhưng lỗi dữ liệu dự kiến nên có schema báo cáo riêng. Cách tách giúp người vận hành đọc được phần cần sửa mà không bỏ sót lỗi chương trình.

Kiểm roundtrip ở ranh giới dữ liệu cuối

Record A sau model có price Decimal, còn bản JSON của mẫu giữ price dưới dạng chuỗi. Đọc lại cần giữ quantity là số và price theo schema giao nhận đã chọn. Không yêu cầu mọi output phải giống kiểu Python nội bộ nếu hợp đồng JSON đã định khác có chủ đích.

Sau khi đọc lại, so SKU, quantity, price và source_url theo nhãn của fixture. Một assertion chỉ đếm một dòng accepted không bắt được giá bị đổi hoặc URL bị mất. Kiểm giá trị theo khóa giúp bảo vệ quan hệ dữ liệu qua bước serialize.

Nếu downstream cần validate lại bằng model, chọn đường nhận JSON cùng chính sách strict phù hợp và chạy ca tương ứng. Không sửa output tùy tiện để khớp một model chưa có hợp đồng giao nhận rõ. Mục tiêu là dữ liệu có thể giải thích từ nguồn đến output, kể cả những phép chuyển kiểu được cho phép.

Chọn rõ nơi cho phép coercion và nơi cần strict; validation pass chỉ xác nhận hợp đồng đã viết, không thay đối chiếu nguồ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 Pydantic chuẩn hóa dữ liệu crawl.