Các phương pháp hay nhất sau đây sẽ cung cấp cho bạn các kỹ thuật để phát triển các truy vấn hiệu quả và tập trung vào quyền riêng tư.
Quyền riêng tư và độ chính xác của dữ liệu
Phát triển truy vấn trên dữ liệu hộp cát
Phương pháp hay nhất: Chỉ truy vấn dữ liệu chính thức khi bạn đang ở chế độ chính thức.
Sử dụng dữ liệu hộp cát trong quá trình phát triển truy vấn bất cứ khi nào có thể. Công việc sử dụng dữ liệu hộp cát không tạo thêm cơ hội để kiểm tra sự khác biệt nhằm lọc kết quả truy vấn. Ngoài ra, do không có quy trình kiểm tra quyền riêng tư, các truy vấn hộp cát chạy nhanh hơn, cho phép lặp lại nhanh hơn trong quá trình phát triển truy vấn.
Nếu bạn phải phát triển truy vấn trên dữ liệu thực tế (chẳng hạn như khi sử dụng bảng so khớp), để giảm khả năng trùng lặp hàng, hãy chọn phạm vi ngày và các tham số khác không có khả năng trùng lặp cho mỗi lần lặp lại truy vấn. Cuối cùng, hãy chạy truy vấn trên phạm vi dữ liệu mong muốn.
Xem xét kỹ kết quả trước đây
Phương pháp hay nhất: Giảm khả năng tập hợp kết quả trùng lặp giữa các truy vấn đã chạy gần đây.
Xin lưu ý rằng tốc độ thay đổi giữa các kết quả truy vấn sẽ ảnh hưởng đến khả năng các kết quả bị bỏ qua sau này do quy trình kiểm tra quyền riêng tư. Tập hợp kết quả thứ hai rất giống với tập hợp kết quả được trả về gần đây có thể bị loại bỏ.
Thay vào đó, hãy sửa đổi các tham số chính trong truy vấn, chẳng hạn như phạm vi ngày hoặc mã chiến dịch để giảm khả năng trùng lặp đáng kể.
Không truy vấn dữ liệu hôm nay
Phương pháp hay nhất: Đừng chạy nhiều truy vấn có ngày kết thúc là hôm nay.
Việc chạy nhiều truy vấn có ngày kết thúc bằng ngày hôm nay thường sẽ dẫn đến việc các hàng bị lọc. Hướng dẫn này cũng áp dụng cho việc chạy truy vấn ngay sau nửa đêm trên dữ liệu của ngày hôm qua.
Không truy vấn cùng một dữ liệu nhiều hơn mức cần thiết
Các phương pháp hay nhất:
- Chọn ngày bắt đầu và ngày kết thúc liên kết chặt chẽ với nhau.
- Thay vì truy vấn các khoảng thời gian trùng lặp, hãy chạy truy vấn trên các tập dữ liệu không liên kết, sau đó tổng hợp kết quả trong BigQuery.
- Sử dụng kết quả đã lưu thay vì chạy lại truy vấn.
- Tạo bảng tạm thời cho từng phạm vi ngày mà bạn đang truy vấn.
Trung tâm dữ liệu quảng cáo hạn chế tổng số lần bạn có thể truy vấn cùng một dữ liệu. Do đó, bạn nên cố gắng giới hạn số lần truy cập vào một phần dữ liệu nhất định.
Không sử dụng nhiều phép tổng hợp hơn mức cần thiết trong cùng một truy vấn
Các phương pháp hay nhất
- Giảm thiểu số lượng phép tổng hợp trong một truy vấn
- Viết lại truy vấn để kết hợp các phép tổng hợp khi có thể
Ads Data Hub giới hạn số lượng phép tổng hợp trên nhiều người dùng được phép sử dụng trong một truy vấn phụ ở mức 100. Do đó, tổng thể, bạn nên viết các truy vấn trả về nhiều hàng hơn bằng khoá nhóm tập trung và phép tổng hợp đơn giản, thay vì nhiều cột hơn bằng khoá nhóm rộng và phép tổng hợp phức tạp. Bạn nên tránh sử dụng mẫu sau:
SELECT
COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
table
Bạn nên viết lại các truy vấn đếm sự kiện tuỳ thuộc vào cùng một nhóm trường bằng cách sử dụng câu lệnh GROUP BY.
SELECT
field_1,
field_2,
COUNT(1) AS cnt
FROM
table
GROUP BY
1, 2
Bạn có thể tổng hợp kết quả theo cách tương tự trong BigQuery.
Bạn nên viết lại các truy vấn tạo cột từ một mảng rồi tổng hợp các cột đó sau đó để hợp nhất các bước này.
SELECT
COUNTIF(a_1) AS cnt_1,
COUNTIF(a_2) AS cnt_2
FROM
(SELECT
1 IN UNNEST(field) AS a_1,
2 IN UNNEST(field) AS a_2,
FROM
table)
Bạn có thể viết lại truy vấn trước đó như sau:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Bạn có thể viết lại các truy vấn sử dụng nhiều kiểu kết hợp trường trong nhiều phép tổng hợp thành một số truy vấn tập trung hơn.
SELECT
COUNTIF(field_1 = a_1) AS cnt_a_1,
COUNTIF(field_1 = b_1) AS cnt_b_1,
COUNTIF(field_2 = a_2) AS cnt_a_2,
COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table
Truy vấn trước đó có thể được chia thành:
SELECT
field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1
và
SELECT
field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1
Bạn có thể chia các kết quả này thành các truy vấn riêng biệt, tạo và kết hợp các bảng trong một truy vấn duy nhất hoặc kết hợp các bảng này với UNION nếu các giản đồ tương thích.
Tối ưu hoá và hiểu về các mối liên kết
Phương pháp hay nhất: Sử dụng LEFT JOIN
thay vì INNER JOIN
để kết hợp lượt nhấp hoặc lượt chuyển đổi với lượt hiển thị.
Không phải lượt hiển thị nào cũng được liên kết với lượt nhấp hoặc lượt chuyển đổi. Do đó, nếu bạn INNER JOIN
lượt nhấp hoặc lượt chuyển đổi trên lượt hiển thị, thì những lượt hiển thị không liên quan đến lượt nhấp hoặc lượt chuyển đổi sẽ bị lọc ra khỏi kết quả.
Kết hợp một số kết quả cuối cùng trong BigQuery
Phương pháp hay nhất: Tránh các truy vấn Ads Data Hub kết hợp kết quả tổng hợp. Thay vào đó, hãy viết 2 truy vấn riêng biệt và kết hợp kết quả trong BigQuery.
Các hàng không đáp ứng yêu cầu tổng hợp sẽ bị lọc ra khỏi kết quả. Do đó, nếu truy vấn của bạn kết hợp một hàng chưa được tổng hợp đầy đủ với một hàng đã được tổng hợp đầy đủ, thì hàng kết quả sẽ được lọc. Ngoài ra, các truy vấn có nhiều phép tổng hợp sẽ hoạt động kém hiệu quả hơn trong Ads Data Hub.
Bạn có thể kết hợp kết quả (trong BigQuery) từ nhiều truy vấn tổng hợp (từ Trung tâm dữ liệu quảng cáo). Kết quả được tính toán bằng các truy vấn phổ biến sẽ chia sẻ giản đồ cuối cùng.
Truy vấn sau đây lấy từng kết quả riêng lẻ của Trung tâm dữ liệu quảng cáo (campaign_data_123
và campaign_data_456
) rồi hợp nhất các kết quả đó trong BigQuery:
SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)
Sử dụng bản tóm tắt về hàng đã lọc
Phương pháp hay nhất: Thêm bản tóm tắt hàng đã lọc vào truy vấn.
Tóm tắt hàng đã lọc tính tổng dữ liệu đã được lọc do các quy trình kiểm tra quyền riêng tư. Dữ liệu từ các hàng đã lọc được tổng hợp và thêm vào một hàng tổng hợp. Mặc dù không thể phân tích thêm dữ liệu đã lọc, nhưng dữ liệu này cung cấp thông tin tóm tắt về lượng dữ liệu đã được lọc ra khỏi kết quả.
Tính đến mã nhận dạng người dùng bằng 0
Phương pháp hay nhất: Tính đến mã nhận dạng người dùng bằng 0 trong kết quả.
Mã nhận dạng của người dùng cuối có thể được đặt thành 0 vì một số lý do, bao gồm: chọn không sử dụng tính năng cá nhân hoá quảng cáo, lý do theo quy định, v.v. Do đó, dữ liệu bắt nguồn từ nhiều người dùng sẽ được khoá thành user_id
bằng 0.
Nếu muốn biết tổng dữ liệu, chẳng hạn như tổng số lượt hiển thị hoặc lượt nhấp, bạn nên thêm các sự kiện này. Tuy nhiên, dữ liệu này sẽ không hữu ích để rút ra thông tin chi tiết về khách hàng và bạn nên lọc dữ liệu này nếu đang thực hiện phân tích như vậy.
Bạn có thể loại trừ dữ liệu này khỏi kết quả bằng cách thêm WHERE user_id != "0"
vào truy vấn.
Hiệu suất
Tránh tổng hợp lại
Phương pháp hay nhất: Tránh nhiều lớp tổng hợp trên người dùng.
Các truy vấn kết hợp các kết quả đã được tổng hợp, chẳng hạn như trong trường hợp truy vấn có nhiều GROUP BY
hoặc tổng hợp lồng nhau, sẽ cần nhiều tài nguyên hơn để xử lý.
Thông thường, các truy vấn có nhiều lớp tổng hợp có thể được chia nhỏ để cải thiện hiệu suất. Bạn nên cố gắng giữ các hàng ở cấp sự kiện hoặc cấp người dùng trong khi xử lý, sau đó kết hợp với một phép tổng hợp duy nhất.
Bạn nên tránh các mẫu sau:
SELECT SUM(count)
FROM
(SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)
Bạn nên viết lại các truy vấn sử dụng nhiều lớp tổng hợp để sử dụng một lớp tổng hợp duy nhất.
(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )
Bạn nên tách những truy vấn có thể dễ dàng tách ra. Bạn có thể kết hợp các kết quả trong BigQuery.
Tối ưu hoá cho BigQuery
Nhìn chung, các truy vấn ít hoạt động hơn sẽ có hiệu suất tốt hơn. Khi đánh giá hiệu suất truy vấn, lượng công việc cần thiết phụ thuộc vào các yếu tố sau:
- Dữ liệu đầu vào và nguồn dữ liệu (I/O): Truy vấn của bạn đọc bao nhiêu byte?
- Giao tiếp giữa các nút (đánh xáo): Truy vấn của bạn truyền bao nhiêu byte đến giai đoạn tiếp theo?
- Tính toán: Truy vấn của bạn cần bao nhiêu công việc của CPU?
- Kết quả (thực thể hoá): Truy vấn của bạn ghi bao nhiêu byte?
- Cấu trúc truy vấn không phù hợp: Truy vấn của bạn có tuân theo các phương pháp hay nhất về SQL không?
Nếu việc thực thi truy vấn không đáp ứng thoả thuận mức độ dịch vụ hoặc bạn gặp lỗi do hết tài nguyên hoặc hết thời gian chờ, hãy cân nhắc:
- Sử dụng kết quả của các truy vấn trước đó thay vì tính toán lại. Ví dụ: tổng số hàng tuần có thể là tổng số được tính toán trong BigQuery của 7 truy vấn tổng hợp trong một ngày.
- Phân ly truy vấn thành các truy vấn con logic (chẳng hạn như chia nhiều mối nối thành nhiều truy vấn) hoặc hạn chế tập dữ liệu đang được xử lý. Bạn có thể kết hợp kết quả của từng công việc vào một tập dữ liệu trong BigQuery. Mặc dù việc này có thể giúp giải quyết tình trạng hết tài nguyên, nhưng có thể làm chậm truy vấn của bạn.
- Nếu bạn gặp lỗi vượt quá tài nguyên trong BigQuery, hãy thử sử dụng bảng tạm thời để chia truy vấn của bạn thành nhiều truy vấn BigQuery.
- Tham chiếu ít bảng hơn trong một truy vấn, vì việc này sẽ sử dụng nhiều bộ nhớ và có thể khiến truy vấn của bạn không thành công.
- Viết lại các truy vấn để chúng kết hợp với ít bảng người dùng hơn.
- Viết lại truy vấn để tránh việc nối cùng một bảng với chính nó.
Cố vấn truy vấn
Nếu SQL của bạn hợp lệ nhưng có thể kích hoạt quá trình lọc, thì trình tư vấn truy vấn sẽ hiển thị lời khuyên hữu ích trong quá trình phát triển truy vấn để giúp bạn tránh kết quả không mong muốn.
Trình kích hoạt bao gồm các mẫu sau:
- Kết hợp các truy vấn phụ tổng hợp
- Kết hợp dữ liệu chưa tổng hợp với nhiều người dùng
- Bảng tạm được xác định đệ quy
Cách sử dụng trình tư vấn truy vấn:
- Giao diện người dùng. Các đề xuất sẽ xuất hiện trong trình chỉnh sửa truy vấn, phía trên văn bản truy vấn.
- API. Sử dụng phương thức
customers.analysisQueries.validate
.