CSV so với JSON

Các định dạng thực sự biểu diễn điều gì

CSV sắp xếp các trường thành các bản ghi, thường có một dòng tiêu đề đặt tên cho các cột. Mô tả định dạng CSV ghi lại các quy tắc trích dẫn cho dấu phẩy, ngắt dòng và dấu ngoặc kép bên trong. CSV vẫn là một họ các phương ngữ thực tế, nên bên tạo dữ liệu cần công bố dấu phân cách, mã hóa và quy ước tiêu đề.

JSON biểu diễn các giá trị với cú pháp xác định, bao gồm đối tượng, mảng, chuỗi, số, boolean và null. Đặc tả trao đổi JSON định nghĩa các kiểu này mà không gán cho các trường nghiệp vụ của bạn một schema. Một đối tượng hợp lệ về mặt cú pháp vẫn có thể bỏ sót một định danh bắt buộc hoặc đặt chuỗi ở chỗ ứng dụng của bạn cần một số.

Hãy xét một sản phẩm có nhiều gói chào bán. JSON có thể giữ một mảng offers bên trong sản phẩm. CSV buộc phải quyết định: lặp lại sản phẩm trên từng hàng offer, tạo một bảng liên quan khác, hoặc mã hóa danh sách trong một trường. Mỗi lựa chọn đều làm thay đổi cách bên tiêu thụ phải diễn giải đầu ra.

Schema khiến các trường văn bản trở nên có thể diễn giải được

Schema cung cấp các ý nghĩa mà tên tệp không thể biểu đạt. Các trường CSV cần được khai báo kiểu dữ liệu, đơn vị, giá trị bắt buộc và khóa. The W3C tabular data model mô tả các bảng cùng với siêu dữ liệu, bao gồm các cột và quan hệ. Điều này làm cho hạn chế trở nên cụ thể: cú pháp CSV và ngữ nghĩa bảng là hai lớp tách biệt.

Đối với một bản xuất kết quả tìm kiếm, hãy coi một URL kết quả là văn bản, một vị trí là số nguyên trong một loại kết quả được định nghĩa, và thời điểm ghi nhận là một giá trị với múi giờ đã được thống nhất. Lưu trữ định danh dưới dạng chuỗi khi các số 0 ở đầu quan trọng. Cơ chế tự động nhận diện kiểu dữ liệu của bảng tính không nên quyết định hợp đồng nguồn.

JSON cũng cần các ràng buộc rõ ràng. Hãy quyết định liệu một khóa thiếu và một khóa có giá trị null có nghĩa giống nhau hay không. Chỉ rõ liệu một mảng rỗng có nghĩa là không có bản ghi liên quan hay quan hệ không khả dụng. Việc xác thực nên từ chối một kiểu trường bị thay đổi trước khi nó lặng lẽ đi vào bảng điều khiển.

Ghép phẳng các kết quả lồng nhau đòi hỏi một hạt hàng

Một bản xuất CSV cần một câu trả lời rõ ràng cho việc mỗi hàng biểu diễn điều gì. Nếu một phản hồi tìm kiếm chứa kết quả tự nhiên, câu hỏi liên quan và các mô-đun khác, các tập hợp đó có thể mô tả những thực thể khác nhau. Ghép phẳng chúng thành một bảng duy nhất với cột vị trí dùng chung có thể tạo ra các so sánh gây hiểu lầm.

Chọn một đơn vị hạt (grain), chẳng hạn như một kết quả organic cho mỗi truy vấn, thị trường và lần thu thập. Lưu truy vấn và ngữ cảnh trên mỗi hàng được xuất hoặc gắn chúng thông qua một mã nhận dạng lần thu thập ổn định. Giữ các bộ sưu tập kết quả khác trong các bảng riêng khi các trường và thứ tự của chúng có ý nghĩa khác nhau. Điều này giữ nguyên mối quan hệ mà không phải bịa ra tính tương đương giữa các module.

Nếu một mảng được bung rộng thành các hàng, hãy ghi lại phép nhân này. Một sản phẩm với nhiều offer sẽ tạo ra nhiều bản ghi offer, không phải nhiều sản phẩm khác nhau. So sánh số lượng sản phẩm bằng khóa sản phẩm và số lượng offer bằng khóa offer. Nếu không, một bước chuyển đổi xuất dữ liệu tưởng như vô hại có thể làm phình to tổng số liệu kinh doanh và bóp méo các báo cáo độ bao phủ.

Giá trị thiếu, số và văn bản cần các quy tắc có chủ đích

Tính thiếu vắng (missingness) là một trong những nguồn gây lỗi chuyển đổi phổ biến nhất. CSV không định nghĩa một giá trị null có kiểu dùng chung, vì vậy một trường trống có thể nghĩa là một chuỗi rỗng hoặc một giá trị vắng mặt tùy theo hợp đồng của bạn. Dành riêng một cách biểu diễn rõ ràng và xác nhận rằng bộ phân tích (parser) phía nhận đang sử dụng cách đó.

JSON có null, nhưng null không giải thích được tại sao một giá trị không khả dụng. Hãy dùng một trường trạng thái bổ sung khi lý do ảnh hưởng tới cách diễn giải. Một mức giá không có trong nguồn khác với một mức giá không thể phân tích cú pháp. Giữ lại giá trị gốc hoặc một thông tin chẩn đoán đã được che để bạn có thể điều tra những trường hợp đó khi cần.

Độ chính xác số học cũng vượt qua ranh giới hệ thống. Một mã định danh dài được biểu diễn dưới dạng số JSON có thể bị diễn giải bởi một bên tiêu thụ với độ chính xác số học hạn chế. Hãy biểu diễn các mã định danh dạng chuỗi khi không cần tính toán số học. Với giá trị tiền tệ, hãy định nghĩa rõ đơn vị tiền và cách xử lý phần thập phân thay vì dựa vào chuyển đổi số thực dấu chấm động theo mặc định của trình đọc.

Truyền (streaming) và kích thước tệp phụ thuộc vào cách biểu diễn

CSV có thể được xử lý từng bản ghi, nhưng một trường có dấu ngoặc kép có thể chứa xuống dòng. Vì vậy đọc từng dòng vật lý một lần không tạo nên một bộ phân tích CSV hoàn chỉnh. Hãy dùng một parser hiểu rõ “dialect” được khai báo và phân biệt được ranh giới bản ghi với dấu xuống dòng bên trong một trường.

Một mảng JSON lớn cũng có thể được tiêu thụ dần với một parser phù hợp. JSON phân dòng (newline-delimited JSON) là một quy ước hữu ích khác cho các bản ghi độc lập, nhưng nó cần được mô tả rõ ràng thay vì bị nhầm với một tài liệu JSON thông thường. Bên tạo và bên tiêu thụ phải thống nhất về khuôn khung (framing) trước khi bất kỳ bên nào có thể truyền (stream) một cách an toàn.

Tránh các tuyên bố kích thước mang tính phổ quát. JSON lặp lại tên trường, trong khi CSV thường chỉ ghi một lần, nhưng việc lồng nhau, trường bị bỏ qua, trích dẫn và nén đều ảnh hưởng tới kết quả. Hãy so sánh các bản xuất đại diện bằng cùng bản ghi, mã hóa và thiết lập nén. Tệp nhỏ nhất không phải lúc nào cũng là tệp dễ kiểm tra hoặc tích hợp nhất.

Giữ riêng phản hồi nguồn và tệp xuất để phân tích

Một quy trình tìm kiếm tin cậy có thể giữ lại phản hồi nguồn có cấu trúc và tạo ra một bảng được thiết kế riêng cho phân tích. Scrapeless Google Search API cung cấp JSON có cấu trúc; bước chuyển đổi của bạn sẽ định nghĩa trường nào trở thành cột CSV và ngữ cảnh nào đi kèm với chúng. Tệp CSV là một góc nhìn phục vụ phân tích chứ không phải bản thay thế cho mọi trường trong nguồn.

Quy trình search-result CSV analysis workflow cho thấy lý do tại sao ngữ cảnh truy vấn và danh mục kết quả cần được tính tới trong kế hoạch xuất. Giữ lại mã nhận dạng lần thu thập, ngữ cảnh nguồn và các quy tắc ánh xạ để nhà phân tích có thể lần ngược một hàng về sự kiện thu thập của nó.

Giữ thông tin đăng nhập và chi tiết tài khoản ra khỏi cả hai định dạng. Chỉ giữ lại tài liệu nguồn cần thiết cho nhiệm vụ và chính sách lưu trữ của bạn. Sử dụng Scrapeless pricing hiện tại cho việc lập kế hoạch thu thập, và đo chi phí chuyển đổi, lưu trữ tách biệt với các yêu cầu đã tạo ra dữ liệu.

Chọn định dạng dựa trên hợp đồng và bên tiêu thụ

Chọn CSV khi hệ thống nhận kỳ vọng một bảng hình chữ nhật, các cột ổn định và người dùng cần việc rà soát bằng bảng tính một cách đơn giản. Chọn JSON khi một dịch vụ cần quan hệ lồng nhau, các tập hợp tùy chọn hoặc các giá trị vô hướng có kiểu trong một phản hồi có cấu trúc. Dùng cả hai khi một định dạng là bản ghi nguồn và định dạng kia là một phép chiếu có chủ đích.

Trước khi giao, hãy phân tích (parse) đầu ra bằng trình tiêu thụ dự kiến. Kiểm tra số bản ghi ở đúng đơn vị hạt, việc giữ nguyên mã định danh, văn bản không phải ASCII, dấu ngoặc kép, xuống dòng và giá trị thiếu. Đưa một ví dụ lồng nhau hoặc đa giá trị vào tập dữ liệu nghiệm thu để quá trình chuyển đổi không thể “vượt qua” chỉ bằng cách xử lý các hàng đơn giản.

Đặt phiên bản cho schema khi ý nghĩa thay đổi. Thêm một cột có thể tương thích với một bộ nhập nhưng gây gián đoạn cho bộ nhập khác. Thay đổi ý nghĩa của một cột hiện có có thể còn tệ hơn thay đổi tên cột. Hãy ghi lại ánh xạ và xác thực nó tại ranh giới nơi tệp được nhận.

Kết luận

CSV so với JSON nên đi theo hình dạng bản ghi và nhu cầu của bên tiêu thụ. Hãy định nghĩa kiểu và khóa, chọn đơn vị hạt của hàng trước khi làm phẳng, và kiểm tra tệp đã xuất trong hệ thống nhận. Giữ nguyên JSON nguồn khi bạn cần chi tiết lồng nhau, và tạo các góc nhìn CSV mang đủ ngữ cảnh cần thiết cho phân tích chính xác.

Tài liệu tham khảo

• Kết quả có cấu trúc của Google Search API
• Scrapeless Google Search API
• Lập kế hoạch một tập dữ liệu CSV cho kết quả tìm kiếm