Как написать Bigquery в новой схеме с заменой event_dim в старой схеме из аналитики Firebase?

Question

Запущен старый скрипт схемы BigQuery Export. Он приведен ниже.Но я хочу повторить этот код и написать его в соответствии с новой схемой экспорта, поскольку наша схема Bigquery была изменена.Пожалуйста, помогите, потому что в новой схеме экспорта BigQuery Я не нашел другой соответствующей записи для event_dim (event_dim соответствует старой схеме экспорта BigQuery).

Вот ссылка на схему экспорта BigQuery: нажмите здесь

 SELECT user_dim.app_info.app_instance_id
          , (SELECT MIN(timestamp_micros) FROM UNNEST(event_dim)) min_time
          , (SELECT MAX(timestamp_micros) FROM UNNEST(event_dim)) max_time,
                event.name,
                params.value.int_value engagement_time
        FROM `xxx.app_events_*`,
        UNNEST(event_dim) as event,
        UNNEST(event.params) as params,
        UNNEST(user_dim.user_properties) as user_params
        where (event.name = "user_engagement" and params.key = "engagement_time_msec")
        and
                (user_params.key = "access" and user_params.value.value.string_value = "true") and
                PARSE_DATE('%Y%m%d', event.date) >= date_sub("{{upto_date (yyyy-mm-dd)}}", interval {{last n days}} day) and
                PARSE_DATE('%Y%m%d', event.date) <= "{{upto_date (yyyy-mm-dd)}}"

Попробовал запрос ниже, но я хочу, чтобы app_instance, min_time, max_time, event_name, engagement_time в одном SELECTзаявление.И так как я использую 'group by', я не могу получить все эти данные (app_instance, min_time, max_time, event_name, engagement_time) одновременно.Пожалуйста, помогите.

 SELECT user_pseudo_id
     , MIN(event_timestamp) AS min_time
      ,MAX(event_timestamp) AS max_time
    FROM `xxx.app_events_*` as T,
       T.event_params,
       T.user_properties,
       T.event_timestamp
    where (event_name = "user_engagement" and event_params.key = "engagement_time_msec")
    and
            (user_properties.key = "access" and user_properties.value.string_value = "true") and
            PARSE_DATE('%Y%m%d', event_date) >= date_sub("{{upto_date (yyyy-mm-dd)}}", interval {{last n days}} day) and
            PARSE_DATE('%Y%m%d', event_date) <= "{{upto_date (yyyy-mm-dd)}}"
    group by 1

Answer 1

Поскольку я считаю мой предыдущий ответ предоставляет некоторые общие идеи для Сообщества , я оставлю его и напишу новый, чтобы он был более конкретным для вашего варианта использования.

СначалаВ общем, я хотел бы уточнить, что для того, чтобы адаптировать запрос (как вы и просите нас), необходимо иметь четкое понимание утверждения, цели запроса, ожидаемых результатов и данных дляиграть с .Поскольку это не так, с ним трудно работать, даже с учетом того, что есть некоторые функции, которые не ясны из запроса, например: чтобы получить «min_time» и «max_time» для каждого события,вы принимаете значения min и max для нескольких событий, что не имеет для меня особого смысла (это может, в зависимости от вашего варианта использования, объяснить причину, по которой я предположил, что это будетлучше, если бы вы могли предоставить больше деталей или больше работать над запросом самостоятельно).Более того, новая схема «выравнивает» события таким образом, что каждое событие записывается в отдельной строке (вы можете легко проверить это, запустив SELECT COUNT(*) FROM 'table_with_old_schema' и сравнив его с SELECT COUNT(*) FROM 'table_with_new_schema'; выувидим, что во втором есть еще много строк), поэтому ваш запрос больше не имеет смысла, поскольку события больше не группируются , и тогда вы не можете выбрать минимум и максимум между вложенными полями.

Это уточняется и удаляет некоторые поля, которые нельзя напрямую адаптировать к новой схеме (возможно, вы сможете адаптировать это с вашей стороны, но это потребует некоторых дополнительных усилий и понимания того, что эти поля значат для васв вашем предыдущем запросе), здесь есть два запроса, которые дают абсолютно одинаковые результаты при выполнении с одной и той же таблицей с другой схемой:

Запрос к таблице со старой схемой:

SELECT
  user_dim.app_info.app_instance_id,
  event.name,
  params.value.int_value engagement_time
FROM
  `DATASET.app_events_YYYYMMDD`,
  UNNEST(event_dim) AS event,
  UNNEST(event.params) AS params,
  UNNEST(user_dim.user_properties) AS user_params
WHERE
  (event.name = "user_engagement"
    AND params.key = "engagement_time_msec")
  AND (user_params.key = "plays_quickplay"
    AND user_params.value.value.string_value = "true")
ORDER BY 1, 2, 3

Запрос к той же таблице с новой схемой:

SELECT
  user_pseudo_id,
  event_name,
  params.value.int_value engagement_time
FROM
  `DATASET.events_YYYYMMDD`,
  UNNEST(event_params) AS params,
  UNNEST(user_properties) AS user_params
WHERE
  (event_name = "user_engagement"
    AND params.key = "engagement_time_msec")
  AND (user_params.key = "plays_quickplay"
    AND user_params.value.string_value = "true")
ORDER BY 1, 2, 3

Опять же дляЯ использую следующую таблицу из общедоступного набора данных: firebase-public-project.com_firebase_demo_ANDROID.app_events_YYYYMMDD, поэтому мне пришлось изменить некоторые фильтры и удалить некоторые другие, чтобы он мог получить ощутимые результаты для этой таблицы.Поэтому не стесняйтесь изменять или добавлять те, которые вам нужны, чтобы они были полезны для вашего варианта использования.

Answer 2

Это правда, что произошла смена схемы в Google Analytics для Firebase BigQuery Export .Хотя не существует четкого сопоставления старых полей по сравнению с новыми, SQL-запрос, предоставленный в документации для переноса существующих наборов данных BQ из старой схемы в новую , дает некоторые подсказкикак эти поля изменились.

Я разделяю SQL-запрос migration_script.sql ниже, просто для справки, но позвольте мне указать наиболее важные изменения для вашего варианта использования:

• event_dim отображается как событие в запросе SQL, но не имеет окончательного представления в схеме, поскольку event_dim больше не является вложенным полем: UNNEST(event_dim) AS event
• event_dim.timestamp_micros отображается как event_timestamp : event.timestamp_micros AS event_timestamp
• event_dim.name отображается как event_name : event.name AS event_name
• event_param.value.int_value отображается как event_params.value.int_value : event_param.value.int_value AS int_value
• user_dim.user_properties отображается как user_properties , и все его вложенные значения имеют одинаковую структуру:UNNEST(user_dim.user_properties) AS user_property) AS user_properties

Итак, в целом, изменение схемы было сфокусировано на простоте развертывания нескольких полей таким образом, что, например, вместо необходимости доступа к event_dim.name (что потребовало бы отмены и усложнения запроса), вы можете запросить непосредственно поле event_name.

Имея это в виду, я уверен, что вы сможете адаптировать свой запрос к этой новой схеме, и он будетвозможно, это выглядит намного проще, учитывая, что вам не придется разбирать столько полей.

---

Просто для пояснения, позвольте мне поделиться с вами парой примеров запросов BQ, сравнивающих старую и новую схемы (они используют публичные таблицы Firebase, поэтому вы должны иметь возможность запускать их из коробки):

# Old Schema - UNNEST() required because there are nested fields
SELECT
  user_dim.app_info.app_instance_id,
  MIN(event.timestamp_micros) AS min_time,
  MAX(event.timestamp_micros) AS max_time,
  event.name
FROM
  `firebase-public-project.com_firebase_demo_ANDROID.app_events_20180503`,
  UNNEST(event_dim) AS event
WHERE
  event.name = "user_engagement"
GROUP BY
  user_dim.app_info.app_instance_id,
  event.name

По сравнению с:

# New Schema - UNNEST() not required because there are no nested fields
SELECT
  user_pseudo_id,
  MIN(event_timestamp) AS min_time,
  MAX(event_timestamp) AS max_time,
  event_name
FROM
  `firebase-public-project.analytics_153293282.events_20180815`
WHERE
  event_name = "user_engagement"
GROUP BY
  user_pseudo_id,
  event_name

Эти запросы эквивалентны, но ссылаясь на таблицы wiСтарая и новая схемы.Обратите внимание, что, поскольку ваш запрос более сложный, вам может понадобиться добавить UNNEST (), чтобы получить доступ к оставшимся вложенным полям в таблице.

Кроме того, вы можете захотеть взглянуть на эти примеры , которые могут помочь вам с некоторыми идеями о том, как писать запросы с новой схемой.

---

РЕДАКТИРОВАТЬ 2

Насколько я понимаю, запрос, подобный приведенному ниже, должен позволять запрашивать все поля в одном выражении.Я группирую по всем неагрегированным / отфильтрованным полям, но в зависимости от вашего варианта использования (это, безусловно, вам нужно работать самостоятельно), вы можете применить другую стратегию, чтобы иметь возможность запрашивать несгруппированные поля (т. е. используйте фильтр MIN / MAX и т. д.).

SELECT
  user_pseudo_id,
  MIN(event_timestamp) AS min_time,
  MAX(event_timestamp) AS max_time,
  event_name,
  par.value.int_value AS engagement_time
FROM
  `firebase-public-project.analytics_153293282.events_20180815`,
  UNNEST(event_params) as par
WHERE
  event_name = "user_engagement" AND par.key = "engagement_time_msec"
GROUP BY
  user_pseudo_id,
  event_name,
  par.value.int_value

---

ПРИЛОЖЕНИЕ

migration_script.sql:

  SELECT
  @date AS event_date,
  event.timestamp_micros AS event_timestamp,
  event.previous_timestamp_micros AS event_previous_timestamp,
  event.name AS event_name,
  event.value_in_usd  AS event_value_in_usd,
   user_dim.bundle_info.bundle_sequence_id AS event_bundle_sequence_id,
  user_dim.bundle_info.server_timestamp_offset_micros as event_server_timestamp_offset,
  (
  SELECT
    ARRAY_AGG(STRUCT(event_param.key AS key,
        STRUCT(event_param.value.string_value AS string_value,
          event_param.value.int_value AS int_value,
          event_param.value.double_value AS double_value, 
          event_param.value.float_value AS float_value) AS value))
  FROM
    UNNEST(event.params) AS event_param) AS event_params,
  user_dim.first_open_timestamp_micros AS user_first_touch_timestamp,
  user_dim.user_id AS user_id,
  user_dim.app_info.app_instance_id AS user_pseudo_id,
  "" AS stream_id,
  user_dim.app_info.app_platform AS platform,
  STRUCT( user_dim.ltv_info.revenue AS revenue,
    user_dim.ltv_info.currency AS currency ) AS user_ltv,
  STRUCT( user_dim.traffic_source.user_acquired_campaign AS name,
      user_dim.traffic_source.user_acquired_medium AS medium,
      user_dim.traffic_source.user_acquired_source AS source ) AS traffic_source,
  STRUCT( user_dim.geo_info.continent AS continent,
    user_dim.geo_info.country AS country,
    user_dim.geo_info.region AS region,
    user_dim.geo_info.city AS city ) AS geo,
  STRUCT( user_dim.device_info.device_category AS category,
    user_dim.device_info.mobile_brand_name,
    user_dim.device_info.mobile_model_name,
    user_dim.device_info.mobile_marketing_name,
    user_dim.device_info.device_model AS mobile_os_hardware_model,
    @platform AS operating_system,
    user_dim.device_info.platform_version AS operating_system_version,
    user_dim.device_info.device_id AS vendor_id,
    user_dim.device_info.resettable_device_id AS advertising_id,
    user_dim.device_info.user_default_language AS language,
    user_dim.device_info.device_time_zone_offset_seconds AS time_zone_offset_seconds,
    IF(user_dim.device_info.limited_ad_tracking, "Yes", "No") AS is_limited_ad_tracking ) AS device,
  STRUCT( user_dim.app_info.app_id AS id,
    @firebase_app_id  AS firebase_app_id,
    user_dim.app_info.app_version AS version,
    user_dim.app_info.app_store AS install_source ) AS app_info,
  (
  SELECT
    ARRAY_AGG(STRUCT(user_property.key AS key,
        STRUCT(user_property.value.value.string_value AS string_value,
          user_property.value.value.int_value AS int_value,
          user_property.value.value.double_value AS double_value,
          user_property.value.value.float_value AS float_value,
          user_property.value.set_timestamp_usec AS set_timestamp_micros ) AS value))
  FROM
    UNNEST(user_dim.user_properties) AS user_property) AS user_properties
FROM
  `SCRIPT_GENERATED_TABLE_NAME`,
  UNNEST(event_dim) AS event