Eksportowanie danych z Firebase Crashlytics do BigQuery

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Dane Firebase Crashlytics możesz wyeksportować do pliku BigQuery, aby przeanalizować je dokładniej. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy usług w chmurze oraz wykorzystywanie do wizualizacji i paneli niestandardowych w Studiu danych Google.

Włącz eksport do usługi BigQuery

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Połącz.

3. Aby umożliwić eksportowanie do BigQuery, postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

   Jeśli chcesz mieć dostęp do danych Crashlytics w BigQuery w czasie zbliżonym do rzeczywistego, rozważ użycie eksportu strumieniowego.

Co się dzieje, gdy włączysz eksport?

• Wybierasz lokalizację zbioru danych. Po utworzeniu zbioru danych jego lokalizacji nie można już zmienić. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub ręcznie przenieść (ponownie utworzyć) zbiór danych w innej lokalizacji. Więcej informacji znajdziesz w artykule Zmienianie lokalizacji dotychczasowych eksportów.

  Ta lokalizacja dotyczy tylko danych eksportowanych do BigQuery. Nie ma wpływu na lokalizację danych przechowywanych do użycia w panelu Crashlytics konsoli Firebase ani w Android Studio.

• Domyślnie wszystkie aplikacje w projekcie są połączone z poziomem BigQuery, a wszystkie aplikacje, które dodasz później do projektu, zostaną automatycznie połączone z poziomem BigQuery. Możesz określić, które aplikacje mają wysyłać dane.

• Firebase konfiguruje codzienną synchronizację danych z usługą BigQuery.

  • Po połączeniu projektu zwykle musisz poczekać do następnej synchronizacji, aby pierwszy zestaw danych został wyeksportowany do BigQuery.

  • Codzienna synchronizacja odbywa się raz dziennie, niezależnie od harmonogramu eksportu BigQuery. Pamiętaj, że czas i długość działania zadania synchronizacji mogą się zmienić, więc nie zalecamy planowania dalszych operacji ani zadań na podstawie określonego czasu eksportu.

• Firebase eksportuje kopię Twoich dotychczasowych danych do usługi BigQuery. Początkowa propagacja danych na potrzeby eksportu może potrwać do 48 godzin.

  • W przypadku każdej połączonej aplikacji ten eksport obejmuje tabelę zbiorczą z danymi z codzienniej synchronizacji.

  • Możesz ręcznie zaplanować uzupełnianie danych w tabeli zbiorczej do ostatnich 30 dni lub do ostatniej daty, w której włączono eksport do BigQuery (w zależności od tego, która z tych dat jest najnowsza).

  Pamiętaj, że jeśli eksport danych Crashlytics został włączony przed połową października 2024 r., możesz też uzupełnić dane z 30 dni poprzedzających dzień włączenia eksportu.

• Jeśli włączysz eksport strumieniowy Crashlytics do BigQuery, wszystkie połączone aplikacje będą też mieć tabelę w czasie rzeczywistym z ciągle aktualizowanymi danymi.

Aby dezaktywować eksport do usługi BigQuery, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do BigQuery?

Dane Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics. Domyślnie w przypadku każdej aplikacji w projekcie zostaną utworzone osobne tabele w zbiorze danych Crashlytics. Firebase nadaje nazwy tabelom na podstawie identyfikatora aplikacji, przy czym kropki są zamieniane na podkreślenia, a na końcu dodawana jest nazwa platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test będą znajdować się w tabeli o nazwie com_google_test_ANDROID. Ta tabela zbiorcza jest aktualizowana raz dziennie. Jeśli włączysz eksport strumieniowy Crashlytics do tabeli BigQuery, dane Crashlytics będą również przesyłane strumieniowo w czasie rzeczywistym do tabeli o nazwie com_google_test_ANDROID_REALTIME.

Każdy wiersz w tabeli odpowiada zdarzeniu, które wystąpiło w aplikacji, m.in. awariom, niekrytycznym błędom i zgłoszeniom ANR.

Eksport strumieniowy Crashlytics do BigQuery

Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery. Możesz go używać do dowolnego celu wymagającego danych na żywo, np. do prezentowania informacji w panelu na żywo, obserwowania wdrażania na żywo lub monitorowania problemów z aplikacją, które powodują alerty i niestandardowe przepływy pracy.

Gdy włączysz eksport strumieniowy Crashlytics do BigQuery, oprócz tabeli zbiorczej będziesz mieć też tabelę w czasie rzeczywistym. Oto różnice między tymi tabelami, o których musisz pamiętać:

Tabela zbiorcza jest idealna do długoterminowej analizy i określania trendów na przestrzeni czasu, ponieważ zdarzenia są trwało przechowywane przed zapisaniem i można je uzupełnić w tabeli przez maksymalnie 30 dni*. Gdy zapisujemy dane w tabeli czasu rzeczywistego, zapisujemy je też natychmiast w tabeli BigQuery. Dzięki temu tabela ta doskonale nadaje się do paneli na żywo i alertów niestandardowych. Aby korzystać z zalet obu tych tabel, możesz połączyć je za pomocą zapytania łączącego.

Domyślny czas ważności partycji tabeli w czasie rzeczywistym wynosi 30 dni. Aby dowiedzieć się, jak to zmienić, zapoznaj się z sekcją Ustawianie daty wygaśnięcia partycji w dokumentacji BigQuery.

^{* Więcej informacji o obsługiwaniu danych zapasowych znajdziesz w artykule Przejście na nową infrastrukturę eksportu.}

Włącz eksport strumieniowy Crashlytics do BigQuery

1. W konsoli Firebase otwórz stronę Integracje.

2. Na karcie BigQuery kliknij Zarządzaj.

3. Zaznacz pole wyboru Uwzględnij strumieniowanie.

To działanie umożliwia strumieniowanie w przypadku wszystkich połączonych aplikacji.

Co można zrobić z wyeksportowanymi danymi?

Dane eksportowane do pliku BigQuery zawierają nieprzetworzone dane o awariach, w tym typ urządzenia, system operacyjny, wyjątki (aplikacje na Androida) lub błędy (aplikacje na urządzenia Apple), a także pliki dziennika Crashlytics oraz inne dane.

W dalszej części tej strony możesz sprawdzić, jakie dokładnie dane Crashlytics są eksportowane, oraz schemat tabeli.

Używanie szablonu Studia danych

Aby włączyć dane w czasie rzeczywistym w szablonie Studia danych, postępuj zgodnie z instrukcjami podanymi w artykule Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych.

Tworzenie widoków

Zapytania możesz przekształcać w widoki za pomocą interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w dokumentacji BigQuery dotyczącej tworzenia widoków.

Uruchamianie zapytań

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na danych Crashlytics, aby generować raporty, które agregują dane o zdarzeniach awarii w bardziej zrozumiałe podsumowania. Ponieważ tego typu raporty nie są dostępne w panelu Crashlytics konsoli Firebase, mogą one uzupełniać Twoją analizę i pomóc w rozumiewaniu danych o wypadkach.

Przykład 1. Błędy a dzień

Po wyeliminowaniu jak największej liczby błędów uważasz, że Twój zespół jest gotowy do uruchomienia nowej aplikacji do udostępniania zdjęć. Zanim to zrobisz, chcesz sprawdzić liczbę awarii dziennie w ciągu ostatniego miesiąca, aby upewnić się, że dzięki spotkaniu poświęconemu wyeliminowaniu błędów aplikacja jest stabilniejsza.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Przykład 2. Znajdowanie najczęściej występujących awarii

Aby prawidłowo ustalić priorytety planów produkcyjnych, musisz znaleźć 10 najczęstszych przyczyn awarii w aplikacji. W tym celu tworzysz zapytanie, które zawiera odpowiednie punkty danych.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 3. 10 najczęściej zawieszających się urządzeń

Jesień to czas na nowe telefony. Twoja firma wie, że oznacza to również nowy sezon problemów związanych z urządzeniami, zwłaszcza z Androidem. Aby uniknąć problemów z kompatybilnością, tworzysz zapytanie, które wskazuje 10 urządzeń, które w ostatnim tygodniu (168 godzin) najczęściej ulegały awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 4. Filtrowanie według klucza niestandardowego

Jesteś deweloperem gier i chcesz wiedzieć, na którym poziomie gry najczęściej występują awarie.

Aby śledzić tę statystykę, możesz ustawić niestandardowy klucz Crashlytics o nazwie current_level i aktualizować go za każdym razem, gdy użytkownik osiągnie nowy poziom.

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Gdy masz ten klucz w eksporcie do BigQuery, możesz napisać zapytanie, aby zgłosić rozkład wartości current_level powiązanych z każdym zdarzeniem awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Przykład 5. Wyodrębnianie identyfikatora użytkownika

Masz aplikację na Androida w ramach wcześniejszego dostępu. Większość użytkowników ją uwielbia, ale u 3 z nich wystąpiła nietypowa liczba awarii. Aby dojść do sedna problemu, możesz utworzyć zapytanie, które pobiera wszystkie zdarzenia awarii dla tych użytkowników, korzystając z ich identyfikatorów.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id
 

Przykład 6. Znajdowanie wszystkich użytkowników, którzy mają problem z określonym błędem powodującym zamykanie aplikacji

Twój zespół przypadkowo udostępnił krytyczny błąd grupie beta-testerów. Twój zespół mógł użyć zapytania z tego przykładu „Znajdowanie najczęściej występujących awarii”, aby zidentyfikować konkretny identyfikator problemu awarii. Twój zespół chce teraz wykonać zapytanie, aby pobrać listę użytkowników aplikacji, których dotyczył ten błąd.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

Przykład 7. Liczba użytkowników, których dotyczy problem z awarią, według kraju

Podczas wdrażania nowej wersji nasz zespół wykrył błąd krytyczny. Aby znaleźć konkretny identyfikator problemu z zawieszeniami, możesz użyć zapytania z powyższego przykładu „Znajdowanie najczęściej występujących awarii”. Nasz zespół chciałby teraz sprawdzić, czy ten błąd występuje u użytkowników w różnych krajach na całym świecie.

Aby utworzyć to zapytanie, Twój zespół musi wykonać te czynności:

1. Włącz eksport danych Google Analytics do usługi BigQuery. Zobacz artykuł Eksportowanie danych projektu do BigQuery.

2. Zaktualizuj aplikację, aby przekazywać identyfikator użytkownika do obu pakietów SDK: Google Analytics i Crashlytics.

   Swift

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Objective-C

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. Napisz zapytanie, które za pomocą pola identyfikatora użytkownika złączy zdarzenia ze zbioru danych Google Analytics z awariami ze zbioru danych Crashlytics.

   Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
   INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
   WHERE
     c.issue_id = "ISSUE_ID"
     AND a._TABLE_SUFFIX BETWEEN '20190101'
     AND '20200101'
   GROUP BY
     c.issue_id,
     a.geo.country,
     c.user.id

Przykład 8. 5 głównych problemów dzisiaj

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Przykład 9. Najważniejsze problemy od DATY, w tym dzisiaj

Możesz też połączyć tabele zbiorcze i w czasie rzeczywistym za pomocą zapytania łączącego, aby dodać informacje w czasie rzeczywistym do wiarygodnych danych zbiorczych. Ponieważ event_id jest kluczem głównym, możesz używać DISTINCT event_id do usuwania duplikatów wspólnych zdarzeń z obu tabel.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Schemat Crashlytics w pliku BigQuery

Gdy skonfigurujesz eksport danych Crashlytics do BigQuery, Firebase będzie eksportować ostatnie zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z okresu do 2 dni przed połączeniem, z opcją uzupełniania danych z okresu do 30 dni.

Od tego momentu do momentu dezaktywacji eksportu Firebase będzie codziennie eksportować zdarzenia Crashlytics. Po każdym eksporcie dane mogą być dostępne w BigQuery dopiero po kilku minutach.

Zbiory danych

Crashlytics tworzy w BigQuery nowy zbiór danych dla danych Crashlytics. Zbiór danych obejmuje cały projekt, nawet jeśli zawiera on wiele aplikacji.

Tabele

Crashlytics tworzy tabelę w zbiorze danych dla każdej aplikacji w Twoim projekcie, chyba że zrezygnujesz z eksportowania danych z tej aplikacji. Firebase nadaje nazwy tabelom na podstawie identyfikatora aplikacji, przy czym kropki są zastępowane przez znaki podkreślenia, a na końcu dodawana jest nazwa platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test będą się znajdować w tabeli o nazwie com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli są włączone) – w tabeli o nazwie com_google_test_ANDROID_REALTIME.

Tabele zawierają standardowy zestaw danych Crashlytics oraz wszystkie niestandardowe klucze Crashlytics zdefiniowane przez Ciebie w aplikacji.

Wiersze

Każdy wiersz w tabeli odpowiada błędowi, na który napotkała aplikacja.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, niekrytycznych błędów i błędów ANR. Jeśli masz włączony eksport strumieniowy Crashlytics do tabeli BigQuery, tabela w czasie rzeczywistym będzie miała te same kolumny co tabela zbiorcza. Pamiętaj, że w wierszach mogą się znajdować kolumny, które reprezentują zdarzenia bez ścieżek wywołania.

Kolumny w ramach eksportu są wymienione w tej tabeli:

Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych

Studio danych Google przekształca Twoje zbiory danych Crashlytics w BigQuery w raporty, które są łatwiejsze do odczytania i udostępnienia oraz w pełni konfigurowalne.

Aby dowiedzieć się więcej o korzystaniu ze Studia danych, zapoznaj się z poradnikiem Witamy w Studiu danych.

Używanie szablonu raportu Crashlytics

W Data Studio znajdziesz przykładowy raport Crashlytics, który zawiera obszerny zbiór wymiarów i danych z wyeksportowanego schematu Crashlytics BigQuery. Jeśli masz włączone Crashlytics eksportowanie danych strumieniowych BigQuery, możesz wyświetlić te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć tego pliku jako szablonu, aby szybko tworzyć nowe raporty i wizualizacje na podstawie nieprzetworzonych danych o awariach z Twojej aplikacji:

1. Otwórz Crashlyticsszablon panelu Studia danych.

2. W prawym górnym rogu kliknij Użyj szablonu.

3. W menu Nowe źródło danych kliknij Utwórz nowe źródło danych.

4. Na karcie BigQuery kliknij Wybierz.

5. Wybierz tabelę z wyeksportowanymi danymi Crashlytics: Moje projekty > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   Tabela zbiorcza jest zawsze dostępna do wyboru. Jeśli masz włączony eksport Crashlytics strumieniowy do BigQuery, możesz zamiast tego wybrać tabelę w czasie rzeczywistym.

6. W sekcji Konfiguracja ustaw wartość Crashlytics Poziom szablonu na Domyślny.

7. Aby utworzyć nowe źródło danych, kliknij Połącz.

8. Aby wrócić do szablonu Crashlytics, kliknij Dodaj do raportu.

9. Na koniec kliknij Utwórz raport, aby utworzyć kopię szablonu Crashlytics panelu Studia danych.

Przejście na nową infrastrukturę eksportu

W połowie października 2024 r. Crashlytics wprowadziła nową infrastrukturę do eksportu zbiorczego danych Crashlytics do usługi BigQuery.

Możesz przeprowadzić uaktualnienie do nowej infrastruktury, ale upewnij się, że tabele zbiorcze BigQuery spełniają wymagania wstępne.

Sprawdzanie, czy korzystasz z nowej infrastruktury

Jeśli masz włączony eksport zbiorczy od połowy października 2024 r. lub później, Twój projekt Firebase automatycznie korzysta z nowej infrastruktury eksportu.

Możesz sprawdzić, z jakiej infrastruktury korzysta Twój projekt: otwórz konsolę Google Cloud i sprawdź, czy konfiguracja transferu danych ma etykietę Firebase Crashlytics with Multi-Region Support. Jeśli tak, Twój projekt korzysta z nowej infrastruktury eksportu.

Ważne różnice między starą a nową infrastrukturą eksportu

• Nowa infrastruktura obsługuje Crashlytics lokalizacje zbiorów danych poza Stanami Zjednoczonymi.

  • Eksportowanie włączone przed połową października 2024 r. i ulepszone o nową infrastrukturę eksportu – teraz możesz opcjonalnie zmienić lokalizację eksportu danych.

  • Eksportowanie zostało włączone w połowie października 2024 r. lub później – podczas konfiguracji wyświetlono prośbę o wybranie lokalizacji na potrzeby eksportu danych.

• Nowa infrastruktura nie obsługuje uzupełniania danych z czasu, gdy eksport był wyłączony.

  • Stara infrastruktura obsługiwała uzupełnianie danych do 30 dni przed datą włączenia eksportu.

  • Nowa infrastruktura obsługuje uzupełnianie danych z ostatnich 30 dni lub z najnowszej daty włączenia eksportu do BigQuery (zależnie od tego, co jest najnowsze).

• Nowa infrastruktura nazywa tabele zbiorczych za pomocą identyfikatorów ustawionych dla Twoich aplikacji Firebase w projekcie Firebase.BigQuery

  • Stara infrastruktura zapisywała dane do tabel zbiorczych o nazwach opartych na identyfikatorach pakietów lub nazwach pakietów w konfiguracji Firebase w kodzie źródłowym aplikacji.

  • Nowa infrastruktura zapisuje dane w tabeli zbiorczej o nazwach opartych na identyfikatorach pakietów lub nazwach pakietów zdefiniowanych dla zarejestrowanych aplikacji Firebase w Twoim projekcie Firebase.

Krok 1. Warunek wstępny przenoszenia

1. Sprawdź, czy istniejące tabele zbiorczych BigQuery używają identyfikatorów pasujących do identyfikatorów pakietów lub nazw pakietów zdefiniowanych w Twoim projekcie Firebase dla zarejestrowanych aplikacji Firebase. Jeśli się nie zgadzają, może to spowodować zakłócenia w eksportowanych danych. Większość projektów będzie w odpowiednim i zgodnym stanie, ale przed uaktualnieniem warto to sprawdzić.

   • Wszystkie aplikacje Firebase zarejestrowane w Twoim projekcie Firebase znajdziesz w konsoli Firebase: otwórz settings Ustawienia projektu, a potem przewiń do karty Twoje aplikacje, aby wyświetlić wszystkie aplikacje Firebase i ich informacje.

   • Wszystkie tabele zbiorcze BigQuery znajdziesz na stronie BigQuery w konsoli Google Cloud.

   Oto na przykład idealne stany, w których nie będziesz mieć problemów z aktualizacją:

   • Masz tabelę zbiorczą o nazwie com_yourcompany_yourproject_IOS oraz aplikację Firebase na iOS+ z identyfikatorem pakietu com.yourcompany.yourproject zarejestrowaną w Twoim projekcie Firebase.

   • Masz tabelę zbiorczą o nazwie com_yourcompany_yourproject_ANDROID i aplikację Firebase na Androida o nazwie pakietu com.yourcompany.yourproject zarejestrowaną w projekcie Firebase.

2. Jeśli masz nazwy tabel zbiorczych, które nie pasują do identyfikatorów ustawionych dla zarejestrowanych aplikacji Firebase, przed ręcznym uaktualnieniem wykonaj czynności opisane poniżej, aby uniknąć przerw w eksportowaniu zbiorczym.