А вот служба поддержки разочаровывает 🙃
15 дней на ответ совсем не о том.

P.S. пытаюсь поставить clickhouse-jdbc-bridge на управляемую версию CH от Я.Облака, чтобы писать запросы к другим базам из CH. Хитрый замысел.

Подсказка для тех, кто будет подключаться к Managed Yandex.Clickhouse из DBeaver (или любой JDBC):

1. Установить сертификат

mkdir -p ~/.clickhouse-client /usr/local/share/ca-certificates/Yandex && \
wget "https://storage.yandexcloud.net/cloud-certs/CA.pem" -O /usr
/local/share/ca-certificates/Yandex/YandexInternalRootCA.crt && \
wget "https://storage.yandexcloud.net/mdb/clickhouse-client.conf

2. Использовать порт 8443

3. Сконфигурировать ssl в настройках драйвера

ssl : true
sslrootcert : /usr/local/share/ca-certificates/Yandex/YandexInternalRootCA.crt (путь к сертификату)
socket_timeout : 300000 (5 минут таймаут запроса)

Позже напишу про подключение для dbt

Сижу и где-то час втыкаю, не понимая почему упорно не запускается тест на relationships (foreign keys).
Экспериментировал с наличием и порядком параметров теста, с отступами в yaml 🤨

Особенно будет интересно тем, с кем это смотрели на занятии Data Quality в прошлый четверг - у нас тогда не запустился тест.
Зарекся разобраться – разобрался.

Оказывается всё просто:

Тест relationships затрагивает 2 модели. При запуске тестов только на child, либо только на parent тест не запустится.
А вот при запуске на обе модели - да!

dbt test -m flt_orders_arrays # won't trigger
dbt test -m flt_orders_events # won't trigger
dbt test -m flt_orders_arrays flt_orders_events # triggers!

Описание теста (definition):

    - name: flt_orders_arrays
      columns: 
          - name: request_id
            tests:
              - dbt_utils.relationships_where:
                  to: ref('flt_orders_events')              
                  field: request_id
                  from_condition: get_array_length(events) > 0

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

Потому что именно сегодня словили грабли с пустыми массивами событий на проде.

Общаюсь с ребятами из Amazon - обратил внимание на ряд проблем.

Наш кластер Redshift непроизвольно рестартится несколько раз в сутки. Причина остается невыясненной и способов выяснить это я пока не вижу. В целом это часто аффектит нашу текущую деятельность, прерывая процессы расчета витрин.

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

Рассматриваем в Wheely апгрейд кластера Redshift и в частности переход на ноды 3-го поколения RA3

Основная фишка этих нод – разделение compute & storage (как в Snowflake)
Потенциально, я вижу следующие плюсы в разделении compute/storage:

- Blue/green deployments (first create new schema, then rename it – swap new version)
- Dedicated sandbox schema for each analyst
- Eliminate disk full errors for heavy caculations (full refresh of seances)

Однако есть вопросы по стоимости и ресурсам нод DC2 vs RA3.
Я составил таблицу, из которой видно что вместо кластера на RA3 выгоднее сорать 10 нод DC2.large и получить 20 CPU (вместо 12 на RA3), 150GM RAM (вместо 96 на RA3).

Задал вопрос в Amazon, возможно они пояснят, чем compute RA3 лучше, и почему такой кластер выходит дороже.
У кого-то есть такой опыт?

Начали пылесосить события Github организации Wheely в наше Хранилище.
Интеграция с помощью Webhook:
– PushEvent
– PullRequestEvent
– ReleaseEvent

Пока отталкиваемся от опыта Gitlab – Centralized Engineering Metrics. Интересные метрики:
– MR Rate
– MRs vs Issues
– MRs by team members

Идея – отслеживать метрики и привязывать цели/OKR разработчиков и команд к этим метрикам.

Буду держать в курсе.

#dwh #pipelines

Here's an easy way to generate comprehensive definition (.yml) of your data sources:

dbt run-operation generate_source --args '{"schema_name": "hevo", "generate_columns": "True", "include_denoscriptions": "True"}' > src.yaml

- get the list of attributes for every source table
- include denoscriptions (docs) to be filled

My goals are to:

- Create a single source of truth unifying source data (backend, marketing, events), data marts (DWH), exposures (dashboards, reports) in one place – dbt Docs
- Provide smooth access to docs website via Google SSO / AWS Cognito to whole company
- Cover source tables with freshness and schema tests
- Enable filling in comments and denoscriptions into predefined structure
- Put docs where the code is (version controlled)

I will use the same generator for all the dbt models.

#docs #pipelines #catalog

Long live Telegram
Rest in peace Facebook, WhatsApp, Instagram
Right now 😄

Here's what Github has sent onto our webhook for past 5 days.

Events of most interest:

- Issues & Pull requests (#, who, when, where, how hard)
- Push (commit frequency and complexity by repos, teams)
- Workflows (Actions metrices)
- Checks (Continuous Integration metrices)

Detailed event payload described at Github Docs.

This data is heavy nested, so new SUPER data type (Redshift) comes really handy for this task to unnest and flatten data.

Soon I will build something worthwhile on top of this data.

#dwh #pipelines #github

Did a brief Data Infrastructure overview today during onboarding session for new Product Analysts @ Wheely

Follow-up to share with you all

1. dbtCloud – invitations sent, start exploring
– Docs
– Data Sources
– Jobs definition

2. Redshift credentails sent to PM

3. Access Jupyter Hub via corporate email

4. Read more about dbt:
– dbt basics
– Start with dbtCloud IDE
– Alternatively, install dbt@0.20.2 (use Homebrew on Mac) and use with any local IDE (VSCode, PyCharm)

Shout-out to you guys!

#dataops #onboarding

I have updated Wheely's production workloads to a new version of dbt==0.21.0
Along with major improvements to performance, stability, and speed we now have:

– A dbt build command for multi-resource runs
– Handling for column schema changes in incremental models
– Defining configs in all the places you’d expect

An average prod job definition looks like: dbt seed + dbt run + dbt snapshot + dbt test
Now with single dbt build command its going to be really simplified and convenient, building resource by resource, from left to right across your DAG.

New on_schema_change parameter enables additional control when incremental model columns change. Possible strategies are:
– ignore (default): new column will not appear in your target table.
– fail: Triggers an error message when the source and target schemas diverge .
– append_new_columns: Append new columns to the existing table.
– sync_all_columns: Adds any new columns to the existing table, and removes any columns that are now missing.

But nothing comes all good, I’ve faced with a couple of bugs these days:
– One that broke my materialization macro with new dispatch logic
– Serializable isolation violation (unrelated to dbt)

I will describe them in next posts.

Meanwhile read more about upcoming dbt v1.0 in December 2021 !

#dbt #release