Pull to refresh
14
0

Data Engineer

Send message

Обратите внимание на оригинальную формулировку, особенно на дату в ней:

This includes sanctions by the EU prohibiting the sale or transfer of EU securities issued after April 12, 2022 to Russian or Belarusian nationals or those located in Russia or Belarus.

Может, не всё так страшно?

Ну а даже если заблокируют EU акции, то кому они нужны, по большому счёту? За редким исключением, там особо нечего ловить в плане роста.

Это достаточно частая история для OLAP DWH. Из-за того, как они устроены внутри, проверка PRIMARY KEY обычно потребует обход всех блоков или микро-партиций. Скорость импорта упадет в несколько раз. Есть разные хитрые решения, вроде ReplacingMergeTree в ClickHouse, но это скорее исключение.

А главное, предположим, что нашли дубль при вставке новых данных. Какие наши действия? Упасть с ошибкой и лежать? Удалить старый ряд в таблице? Почистить входящие данные?

Всё это можно сделать через MERGE со вложенным COPY INTO, и тонко настроить его под конкретный use case. Отсутствие constraints enforcement - это немного неудобно после работы с OLTP DWH, но не критично.

Любопытно, но поле "invalid" можно увидеть у команды SHOW MATERIALIZED VIEWS, но не у обычной SHOW VIEWS. Судя по всему, в текущей модели Snowflake сам точно не знает, какие стандартные VIEW стали невалидны до первого запроса к ним. Надеюсь, со временем это исправят.

Цепочку зависимостей посмотреть можно, но дьявол в деталях:

  1. Табличная функция GET_OBJECT_REFERENCES(), показывает не всё, требует активный WAREHOUSE и тратит деньги.

  2. View OBJECT_DEPENDENCIES, обновляется с задержкой до 3ч (!), тратит деньги.

После перебора всех вариантов получается, что проверка всех VIEW через .describe() - самое простое и дешёвое решение на текущий момент.

Со Snowflake работаю недавно, но очень много опыта с другими DWH на больших объёмах. Уже знаю, на что смотреть, и почему не стоит слепо доверять документации и советам вендора. :)

SELECT * - это скорее самый доступный пример того, что может сломать VIEW. Действительно, лучше избегать этой конструкции, независимо от СУБД.

На практике чаще видим ситуации, когда есть цепочка из нескольких VIEW, и ломается что-то посередине. Например, переименовали таблицу / колонку / функцию, поменяли тип данных.

Конкретно в Python на Windows и Unix это, похоже, не проблема. Документация говорит следующее:

time.time() → float

Return the time in seconds since the epoch as a floating point number. The specific date of the epoch and the handling of leap seconds is platform dependent. On Windows and most Unix systems, the epoch is January 1, 1970, 00:00:00 (UTC) and leap seconds are not counted towards the time in seconds since the epoch. This is commonly referred to as Unix time. To find out what the epoch is on a given platform, look at gmtime(0).

Про другие платформы стоит подумать в будущем. Действительно, любопытная история.

Как раз на днях тестировал UUIDv7 в контексте использования в Snowflake. Всё работает, как и ожидалось - partition pruning улучшается радикально. Особенно по сравнению с UUIDv4, который, по сути, всегда вызывает full scan.

Пример того, как его можно сгенерировать на Python:

import random
import time
import uuid


def uuid7(unix_ts_ms: int = None):
    """
    UUIDv7 description: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-03#section-5.2
    UUIDv7 example: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-03#appendix-B.2
    """
    if unix_ts_ms is None:
        unix_ts_ms = time.time_ns() // 1000000

    ver = 7
    variant = 2

    rand_a = random.getrandbits(12)
    rand_b = random.getrandbits(62)

    # Offsets:
    #
    #   unix_ts_ms = 128 - 48 = 80
    #   ver        =  80 -  4 = 76
    #   rand_a     =  76 - 12 = 64
    #   variant    =  64 -  2 = 62
    #   rand_b     =  62 - 62 = 0

    return uuid.UUID(int=(unix_ts_ms << 80) + (ver << 76) + (rand_a << 64) + (variant << 62) + rand_b)
Судя по дате первой статьи, у вас уже большой опыт. :) Сейчас в Лондоне / в UK живёте или уже в другое место переехали?
Восхитительное обилие деталей. Думаю, автор много времени потратил на исследование этой темы, снимаю шляпу.

Но что, если те же самые усилия ушли бы на создание / поиск социального круга, в котором вопрос «пить или не пить» просто не стоял бы изначально? Таких людей мало, но они есть. И когда получается найти с ними точки соприкосновения без помощи алкоголя, это совершенно другой уровень.

Да, это непросто. Но даже если пока не выходит, лучше уж ещё потренироваться или одному «с паяльником посидеть», чем вот эти все круги ада, которые в статье описаны.
Если не ошибаюсь, обычный dict уже сохраняет порядок примерно с версии 3.6.
Хорошая статья. Есть немного неточностей, но ничего критичного.

Дополнения:

  • В настоящий момент Tech Nation требует три основных рекомендательных письма, не два. Изменение вступило в силу осенью этого года, совсем недавно.
  • При подаче из UK к стоимости визы стоит добавить Super Priority Service и платный слот на сдачу биометрии. Это добавляет порядка 1000 фунтов сверху на каждого человека. Да, без этого можно обойтись, но есть большой риск, что application зависнет на несколько месяцев. И в ходе этого срока нельзя будет выезжать из UK. Для многих это критично.
  • Главный плюс визы в том, что можно свободно организовывать своё время и даже параллельно совмещать несколькими занятий. Можно поменять направление в любой момент без сбора документов и подачи на новую визу. Это освобождает много мыслительных ресурсов, которые иначе заняты продумыванием «плана Б».
Конкретно в случае с Tech Nation и IT-специальностями образование не играет роли. Проверено на личном опыте.

С возрастом интереснее. В теории, он не должен влиять на результат (это же UK). Но, если человек подаётся на Exceptional Promise в 20-35 лет, это легче понять, чем когда такое происходит в 50+, когда карьера уже «состоялась».

В целом, Tech Nation открыты к людям с необычными историями, поэтому и просят написать Personal Statement.
Любопытно, что нравится KotoR. Первая часть вышла в возрасте 6 лет. Old school.

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

Удачи и здоровья вам.
Плюсую. За три поездки по японским «деревням» могу сказать, что поговорить с кем-то на английском — большая удача.

Конверсия немного повышается, если начинать обращение со слова: «Sumimasen». Вам отвечают: «Hai». И после этого можно попробовать спросить на английском. Если сразу начать с «Hello» или «Excuse me», то некоторые просто зависают или убегают в панике.
Если ехать в Фукуоку, то нужно уже и весь остальной Кюсю брать. Это дней 6-10, причём очень плотных, интересных и разнообразных.
Сколько у вас данных примерно? Насколько они структурированы? Не думали попробовать Snowflake?

Скорее всего, получится подешевле, чем Redshift, а вопросы оптимизации отодвинутся ещё на два порядка.
Думаю, в какой-то момент в будущем ИИ научится побеждать людей с честным обзором и низким APM. Просто на психологии.

Вот тогда будет страшно.
Просто не покупаю эти позорные «новинки». Телефоны без наушников не нужны точно так же, как и ноутбуки с ужасными клавиатурами, гигантскими тачпадами и бесполезными тачбарами.

Последние нормальные продукты вышли примерно в 2015. С тех пор взять нечего.
Мы запускаем по 800 потоков, и с волосами у DBA всё хорошо… пока ^^
Спасибо.

Думаю, вы и сами хорошо подходите на эту роль. Если можете так детально проверить данные, то и трансформация не должна составлять проблем.
Любопытно. Если можно, два вопроса:

1. Зачем динамически строить SQL в Excel, когда можно делать это ещё лучше на чистом SQL на базе системных вьюшек?

SELECT ', count(' || column_name || ') AS ' || column_name
FROM columns
WHERE ...


2. С какой целью ETL выделен в отдельную команду? Почему нельзя импортировать все данные из старой базы в отдельные схемы в новой, а затем делать трансформации и сравнения на SQL?

Получаем возможность делать прямые JOIN'ы между «было -> стало», а также экономим время на коммуникациях и неизбежных ошибках в логике ETL.

Information

Rating
Does not participate
Location
England - London, Великобритания
Date of birth
Registered
Activity