Následující doporučené postupy vám poskytnou techniky pro vyvíjení dotazů respektujících soukromí, které přitom zůstanou výkonné.
Soukromí a přesnost dat
Vyvíjejte dotazy na datech v izolovaném prostoru
Doporučený postup: Dotazy spouštějte na produkční data jen v produkčním prostředí.
Během vývoje dotazů používejte data v izolovaném prostoru, kdykoli je to možné. Úlohy, které používají data v izolovaném prostoru, nevytvářejí další příležitosti pro kontroly rozdílů při filtrování výsledků dotazu. Vedle toho dotazy na izolovaném prostoru nepotřebují spouštět kontroly na ochranu soukromí, takže běží rychleji a lze tak rychleji postupovat v iteracích při vývoji dotazu.
Pokud musíte své dotazy vyvíjet na skutečných datech (například při používání identifikačních tabulek), zvolte pro každou iteraci dotazu rozsahy dat a další parametry, u kterých není pravděpodobný překryv, aby byla menší šance, že se řádky budou překrývat. Na závěr spusťte svůj dotaz na požadovaný rozsah dat.
Pečlivě zvažujte historické výsledky
Doporučený postup: Snižte pravděpodobnost, že se sady výsledků mezi nedávno spuštěnými dotazy budou překrývat.
Pamatujte na to, že míra změny mezi výsledky dotazu bude mít dopad na to, jak pravděpodobné bude zahození těchto výsledků později z důvodu kontrol ochrany soukromí. Druhá sada výsledků, která se hodně podobá nedávno vrácené sadě, bude pravděpodobně zahozena.
Namísto toho upravte klíčové parametry ve svém dotazu, například období nebo ID kampaní, abyste snížili šanci, že se budou vrácené výsledky významně překrývat.
Nespouštějte dotazy na data z dnešního dne
Doporučený postup: Nespouštějte více dotazů, u kterých je koncové datum dnešek.
Spuštění více dotazů s koncovým datem nastaveným na dnešek povede často k tomu, že budou nějaké řádky odfiltrovány. Toto doporučení platí i pro spouštění dotazů na včerejší data krátce po půlnoci.
Nespouštějte dotazy na stejná data více, než je nutné
Doporučené postupy:
- Vyberte pevně daná data zahájení a data ukončení.
- Namísto spouštění dotazů na data překrývajících se období spusťte dotazy na oddělené sady dat a následně agregujte výsledky v BigQuery.
- Využívejte uložené výsledky namísto opětovného spouštění vašeho dotazu.
- Vytvářejte dočasné tabulky pro každé období, na které spustíte dotaz.
Ads Data Hub omezuje, kolikrát celkem můžete spustit dotaz na stejná data. Proto byste se měli snažit omezit, kolikrát budete přistupovat k dané sadě dat.
Nepoužívejte ve stejném dotazu více agregací, než je nutné
Doporučené postupy:
- Minimalizujte počet agregací v dotazu
- Přepište dotazy, aby kombinovaly agregace, kdykoli je to možné
Ads Data Hub omezuje počet agregací napříč uživateli, které lze použít v dílčím dotazu, na 100. Proto doporučujeme psát dotazy, jejichž výstupy mají více řádků s klíči soustředěného seskupování a jednoduché agregace, a ne více sloupců s klíči širokého seskupování a komplexní agregace. Vyhněte se následujícímu vzoru:
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
Dotazy, které počítají události na základě stejného souboru polí, by měly být přepsány příkazem GROUP BY.
SELECT
field_1,
field_2,
COUNT(1) AS cnt
FROM
table
GROUP BY
1, 2
Výsledek může být agregován stejným způsobem v BigQuery.
Dotazy, které vytvářejí sloupce z pole a následně je agregují, by měly být přepsány, aby se tyto kroky sloučily.
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)
Předchozí dotaz může být přepsán jako:
SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1
Dotazy, které používají různé kombinace polí v různých agregacích, lze přepsat do více soustředěných dotazů.
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
Předchozí dotaz lze rozdělit do:
SELECT
field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1
a
SELECT
field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1
Tyto výsledky můžete rozdělit do samostatných dotazů, vytvářet a spojovat tabulky do jednoho dotazu nebo je kombinovat pomocí příkazu UNION, pokud jsou schémata kompatibilní.
Optimalizujte a rozumějte operacím join
Doporučený postup: Použijte LEFT JOIN
namísto INNER JOIN
k propojení kliknutí nebo konverzí se zobrazeními.
Ne všechna zobrazení jsou spjatá s kliknutími nebo konverzemi. Když tedy provedete INNER JOIN
pro kliknutí nebo konverze u zobrazení, zobrazení bez vazby na kliknutí nebo konverze budou z vašich výsledků odfiltrována.
Konečné výsledky spojte v BigQuery
Doporučený postup: Vyhýbejte se dotazům Ads Data Hub, které spojují agregované výsledky. Namísto toho napište 2 samostatné dotazy a pak spojte jejich výsledky v BigQuery.
Řádky, které nebudou odpovídat požadavkům agregace, budou z vašich výsledků odfiltrovány. Pokud váš dotaz spojí dostatečně agregovaný řádek s nedostatečně agregovaným řádkem, bude výsledný řádek odfiltrován. A kromě toho mají dotazy s více agregacemi v Ads Data Hub nižší výkon.
Můžete spojit výsledky (v BigQuery) z více agregačních dotazů (z Ads Data Hub). Výsledky vypočítané s použitím společných dotazů budou sdílet finální schémata.
Následující dotaz vezme individuální výsledky Ads Data Hub (campaign_data_123
a campaign_data_456
) a spojí je v 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)
Používejte souhrny filtrovaných řádků
Doporučený postup: Přidejte do svých dotazů souhrny filtrovaných řádků.
Souhrny filtrovaných řádků obsahují součty dat z řádků odfiltrovaných kvůli ochraně soukromí. Data z filtrovaných řádků jsou sečtena a přidána do souhrnného řádku. Odfiltrovaná data nelze dále analyzovat, představují ale souhrn toho, jaké množství dat bylo z výsledků odfiltrováno.
Počítejte s vynulovanými ID uživatelů
Doporučený postup: Ve svých výsledcích počítejte s vynulovanými ID uživatelů.
ID koncových uživatelů mohou být změněna na 0 z řady důvodů, mezi které patří třeba odhlášení od personalizované inzerce, požadavky zákonných předpisů atd. V důsledku toho mohou být data od více uživatelů spojena s user_id
hodnoty 0.
Pokud chcete porozumět celkovým hodnotám v datech, například celkovému počtu kliknutí nebo zobrazení, měli byste tyto události zahrnout. Tato data nicméně nebudou užitečná pro vyvozování poznatků o zákaznících, proto byste je měli pro takové analýzy odfiltrovat.
Tato data můžete z výsledků vyloučit, když do svých dotazů přidáte WHERE user_id != "0"
.
Výkon
Vyhněte se reagregaci
Doporučený postup: Vyhněte se více úrovním agregace napříč uživateli.
Dotazy kombinující výsledky, které už byly agregovány, což může být příklad dotazu s více GROUP BY
nebo s vnořenou agregací, vyžadují při zpracování více zdrojů.
Často lze dotazy s více úrovněmi agregace rozdělit a zlepšit tak výkon. Měli byste usilovat o to, abyste během zpracování zachovali řádky na úrovni události nebo uživatele, a pak je zkombinovat pomocí jedné agregace.
Vyhněte se následujícím vzorům:
SELECT SUM(count)
FROM
(SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)
Dotazy, které používají více vrstev agregace. Ty byste měli přepsat, aby používaly jednu vrstvu agregace.
(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )
Dotazy, které lze snadno rozdělit, byste měli rozdělit. Výsledky můžete spojit v BigQuery.
Optimalizujte pro BigQuery
Obecně platí, že dotazy, které toho dělají méně, mají lepší výkon. Když vyhodnocujete výkon dotazu, objem požadované práce dotazu závisí na následujících faktorech:
- Vstupní data a zdroje dat (I/O): Kolik bajtů váš dotaz čte?
- Komunikace mezi uzly (přesuny dat): Kolik bajtů předává váš dotaz do další fáze?
- Výpočty: Kolik práce procesoru vyžaduje váš dotaz?
- Výstupy (materializace): Kolik bajtů váš dotaz zapisuje?
- Nevhodné postupy v dotazu:: Řídí se vaše dotazy doporučenými postupy pro SQL?
Pokud provádění dotazu neodpovídá vaší smlouvě o úrovni poskytovaných služeb nebo narážíte na chyby z důvodu vyčerpání zdrojů nebo vypršení časového limitu, zvažte využití níže uvedených možností:
- Použití výsledků z předchozích dotazů namísto jejich opětovného počítání. Například celkový počet za týden lze vypočítat tak, že v BigQuery sečtete souhrnné výsledky ze 7 dotazů pro jednotlivé dny.
- Rozložení dotazů na logické poddotazy (například rozložením více operací join do více dotazů) nebo omezení rozsahu zpracovávané sady dat jiným způsobem. Výsledky z individuálních úloh pak můžete zkombinovat do jedné sady dat v BigQuery. Toto může pomoci s problémem vyčerpání zdrojů, ale může to váš dotaz zpomalit.
- Pokud v BigQuery narážíte na chyby překročení objemu dostupných zdrojů, zkuste použít dočasné tabulky a rozdělit váš dotaz do více dotazů BigQuery.
- Odkazování na méně tabulek v jednom dotazu, protože odkazování na tabulky využívá velké množství paměti a může způsobit selhání dotazu.
- Přepsání dotazů takovým způsobem, aby spojovaly méně tabulek uživatelů.
- Přepsání dotazů takovým způsobem, aby nedocházelo ke spojení stejné tabulky zpět na sebe samu.
Rádce pro tvorbu dotazů
Pokud je kód SQL vašeho dotazu platný, ale mohl by vést k rozsáhlému filtrování, nabídne vám rádce pro tvorbu dotazů během vývoje dotazu praktické rady, aby vám pomohl se nežádoucím výsledkům vyhnout.
Může to nastat například v těchto situacích:
- spojování agregovaných poddotazů,
- spojování agregovaných dat s potenciálně odlišnými uživateli,
- rekurzivně definované dočasné tabulky.
Rádce pro tvorbu dotazů můžete využít takto:
- Uživatelské rozhraní: Doporučení se zobrazí v editoru dotazů nad textem dotazu.
- Rozhraní API: Použijte metodu
customers.analysisQueries.validate
.