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 tập trung vào quyền riêng tư và hiệu quả hơn. Để biết các phương pháp hay nhất dành riêng cho chạy truy vấn ở chế độ nhiễu, hãy xem các phần trên được hỗ trợ và không được hỗ trợ các mẫu truy vấn khác trong tính năng Chèn tiếng ồn.
Quyền riêng tư và độ chính xác của dữ liệu
Phát triển truy vấn về dữ liệu hộp cát
Phương pháp hay nhất: Chỉ truy vấn dữ liệu sản xuất khi bạn đang trong quá trình sản xuất.
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ể. Những công việc sử dụng dữ liệu hộp cát không mang đến thêm cơ hội để kiểm tra sự khác biệt để lọc kết quả truy vấn. Ngoài ra, do thiếu chế độ kiểm tra để đảm bảo quyền riêng tư, nên các truy vấn hộp cát sẽ 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 các truy vấn trên dữ liệu thực tế của mình (chẳng hạn như khi sử dụng bảng so khớp), để giảm khả năng bạn chồng chéo 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 của bạn. Cuối cùng, chạy truy vấn của bạn trên phạm vi dữ liệu mong muốn.
Xem xét kỹ các 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.
Lưu ý rằng tốc độ thay đổi giữa các kết quả truy vấn sẽ có ảnh hưởng đến khả năng kết quả bị bỏ qua sau này do các bước kiểm tra để đảm bảo quyền riêng tư. Nhóm kết quả thứ hai gần giống với nhóm kết quả được trả về gần đây có thể sẽ bị loại bỏ.
Thay vào đó, hãy sửa đổi các thông số chính trong truy vấn của bạ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 của ngày hôm nay
Phương pháp hay nhất: Khô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 hàng bị lọc. Hướng dẫn này cũng áp dụng cho các truy vấn đang chạy ngay sau nửa đêm của 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 có liên quan chặt chẽ.
- Thay vì truy vấn các cửa sổ chồng chéo, hãy chạy truy vấn của bạn trên các tập dữ liệu rời rạc, 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 của bạn.
- Tạo bảng tạm thời cho từng phạm vi ngày mà bạn đang truy vấn.
Ads Data Hub 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 dữ liệu 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 tập hợp trong một truy vấn
- Viết lại truy vấn để kết hợp các dữ liệu tổng hợp khi có thể
Ads Data Hub giới hạn số lượng dữ liệu tổng hợp trên nhiều người dùng được phép sử dụng trong một truy vấn con là 100. Do đó, về tổng thể, bạn nên viết các truy vấn đưa ra nhiều hàng hơn với các khoá nhóm tập trung và dữ liệu tổng hợp đơn giản, thay vì nhiều cột hơn với các khoá nhóm rộng và dữ liệu tổng hợp phức tạp. Bạn nên tránh 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
Những truy vấn tính số sự kiện phụ thuộc vào cùng một nhóm trường phải được viết lại bằ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.
Những truy vấn tạo cột từ một mảng rồi tổng hợp chúng sau đó phải được viết lại để 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)
Có thể viết lại truy vấn trước đó thành:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Những truy vấn sử dụng các tổ hợp trường khác nhau trong các dữ liệu tổng hợp khác nhau có thể được viết lại thành một số truy vấn có trọng tâm cụ thể 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 tách 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 những 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 chúng với một UNION nếu giản đồ tương thích.
Tối ưu hoá và hiểu rõ về cách kết hợp
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 tất cả các lượt hiển thị đều liên quan đến 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 số lượt nhấp hoặc lượt chuyển đổi sẽ bị lọc khỏi kết quả của bạn.
Tham gia 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 với 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 các 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 khỏi kết quả. Do đó, nếu truy vấn của bạn kết hợp với một hàng được tổng hợp không đủ với một hàng được tổng hợp đủ, thì hàng tổng hợp đó sẽ bị lọc. Ngoài ra, các truy vấn có nhiều dữ liệu 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ừ Ads Data Hub). Những 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 các kết quả riêng lẻ từ Ads Data Hub (campaign_data_123
và campaign_data_456
) rồi kết hợp 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 tóm tắt hàng đã lọc
Phương pháp hay nhất: Thêm nội dung tóm tắt hàng đã lọc vào truy vấn của bạn.
Thông tin tóm tắt hàng đã lọc kiểm đếm dữ liệu đã được lọc nhờ các bước kiểm tra để đảm bảo quyền riêng tư. Dữ liệu từ các hàng đã lọc được tính tổng 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 tính năng này cung cấp thông tin tóm tắt về lượng dữ liệu đã được lọc khỏi kết quả.
Tài khoản chứa mã nhận dạng người dùng được tạo bằng 0
Phương pháp hay nhất: Tính đến các mã nhận dạng người dùng có số 0 trong kết quả của bạn.
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, chẳng hạn như: 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ó giá trị là user_id
là 0.
Nếu muốn biết dữ liệu tổng cộng, chẳng hạn như tổng số lượt hiển thị hoặc số lượt nhấp, bạn nên đưa những sự kiện này vào. Tuy nhiên, dữ liệu này sẽ không hữu ích để lấy thông tin chi tiết về khách hàng. Do đó, bạn nên lọc dữ liệu này nếu 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 của mình.
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 giữa nhiều người dùng.
Các truy vấn kết hợp kết quả đã được tổng hợp, chẳng hạn như trong trường hợp một truy vấn có nhiều GROUP BY
hoặc dữ liệu 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ể bị chia nhỏ, từ đó 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 dữ liệu 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)
Những truy vấn sử dụng nhiều lớp tổng hợp phải được viết lại để 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 chia nhỏ những truy vấn có thể dễ dàng chia nhỏ. Bạn có thể kết hợp các kết quả trong BigQuery.
Tối ưu hoá cho BigQuery
Nhìn chung, những cụm từ tìm kiếm ít mang lại hiệu quả cao hơn. Khi đánh giá hiệu suất truy vấn, lượng công việc cần thực hiện 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?
- Trao đổi thông tin giữa các nút (xáo trộn): Truy vấn của bạn sẽ chuyển bao nhiêu byte sang giai đoạn tiếp theo?
- Tính toán: Truy vấn của bạn yêu cầu bao nhiêu công việc của CPU?
- Đầu ra (hiện thực hoá): Truy vấn của bạn ghi bao nhiêu byte?
- Truy vấn chống mẫu: 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 quá trình thực thi truy vấn không đáp ứng thoả thuận mức độ cung cấp dịch vụ, hoặc bạn đang gặp lỗi do tài nguyên cạn hoặc hết thời gian chờ, hãy cân nhắc việc:
- Sử dụng kết quả từ 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 được tính toán trong BigQuery của các cụm từ tìm kiếm tổng hợp trong 7 ngày.
- Phân tách các truy vấn thành các truy vấn con logic (chẳng hạn như chia nhiều kết hợp 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ả từ từng công việc thành một tập dữ liệu duy nhất trong BigQuery. Mặc dù việc này có thể giúp làm cạn kiệt tài nguyên, nhưng nó có thể làm chậm tốc độ truy vấn của bạn.
- Nếu bạn gặp phải lỗi tài nguyên vượt quá giới hạn trong BigQuery, hãy thử sử dụng bảng tạm thời để chia truy vấn của mình 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 truy vấn của bạn để chúng tham gia ít bảng người dùng hơn.
- Viết lại các truy vấn của bạn để tránh kết hợp lại cùng một bảng.
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 quá mức, truy vấn cố vấn đưa ra lời khuyên thiết thực 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.
Điều kiện 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 được tổng hợp với những người dùng có thể khác nhau
- bảng tạm thời được xác định đệ quy
Cách sử dụng trình cố vấn truy vấn:
- Giao diện người dùng. Nội dung đề 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
.