Русский
Русский
English
Статистика
Реклама

Работа с данными

Recovery mode COVID-19 Модель параметрического предсказания эпидемии

12.07.2020 22:04:29 | Автор: admin

Действительно, за последние месяцы тема анализа эпидемии covid-19 уже порядком достала, звуча из всех утюгов, кофеварок и лыж. Да и сама тема уже практически (очень зря) потеряла свою актуальность.
Однако, как раз сейчас, у нас накопился достаточный объем данных по которому мы можем посмотреть как именно развивалась эпидемия и проверить модели, которые использовались в бою.


Введение


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


Вместо этого мы:


  • Рассмотрим некоторые моменты, подходы и идеи в обработке данных, которые пригодятся при построении модели.
  • Построим объемную модель эпидемии.
  • И оценим как изменение некоторых параметров может влиять на ход эпидемии.

Disclaimer 1:
В этой статье будет довольно сильный уклон в сторону анализа ситуации по России в целом, и Нижнего Новгорода в частности.

Disclaimer 2:
Все модели исходят из официальных данных указанных стран и регионов.

Disclaimer 3:
Говоря о России и её регионах, мы сознательно будем убирать последние данные (начиная, примерно, с 15 мая) из-за целого ряда причин. Кратко опишем это как: Изменение методики подсчета заболевших. Однако, это тема для отдельной статьи и мы не будем вдаваться в эти дискуссии сегодня.

Данные


Ну, начнем от печки. Данные по миру, странам с достаточным объемом статистики и их регионам можно найти тут CSSEGISandData, а по России и российским регионам тут стопкоронавирус.рф. Автоматически выгружаем данные из этих источников и формируем удобный датасет.


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


Поэтому сложно предсказывать дальнейшее развитие эпидемии в конкретной стране, опираясь только на страны со схожей динамикой распространения вируса. (Как минимум, из-за существенного отличия тренда Российской статистики и статистики других стран в пересчете на единицу населения.)
source



Еще одна проблема, на которой стоит заострить внимание, методология сбора и обработки статистики по смертности. Учитываются ли люди, умершие от сопутствующих заболеваний, в то время как они были заражены COVID-19? Учитываются ли умершие с аналогичной симптоматикой, но без проведенного тестирования? Тем более что в России подход к учету статистики драматически менялся без пересмотра уже опубликованных данных.


Можно посмотреть отчет ВОЗ, где рассказывается про различие смерти с коронавирусом и смерти от коронавируса: "crude mortality ratio" и "infection mortality rate". (Для более подробной сводки по смертности можно посмотреть две статьи на habr: раз & два ).


Также, стоит брать во внимание намеренную или случайную неточность данных. И простой факт: чем больше хороших тестов проводится (с малой ошибкой первого рода), тем больше в стране будет выявленно заболевших.


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


Синдром выходного дня в разных странах



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



С Россией все несколько сложнее. В целом, если постараться, можно разглядеть этот синдром вплоть до, примерно, 11 Мая. (См. Disclaimer 3).


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



Это легко объясняется продолжительным временем развития первых симптомов у зараженных, отсутствием тестирования в первые дни и простым общечеловеческим раздолбайством. Этот факт понятен визуально, однако, почти любая модель будет довольно сильно "сбиваться" от такого долгого периода застоя. Поэтому далее все данные проходят предобработку и эпидемия будет рассматриваться с момента наличия 300 заболевших для страны и 50 для регионов (если не указано обратное).


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


Долгосрочная модель


Вот мы наконец-то и подобрались к основному разделу этой статьи и к самой точной модели, которая, забегая немного вперед, дает довольно адекватные предсказания.


Важным моментом в построении модели является возможность интерпретировать параметры модели и сравнивать адекватность полученных значений параметра с общемировыми (если во всех странах заразность составила около 20%, а в одной конкретной стране почему-то 3%, то что-то тут не то).


Да, можно использовать модель SIR/SEIR, которая уже стала классической за последние месяцы. Однако, эта модель слабо интерпретируемая и зависит от предпринимаемых государством мер, уровнем соблюдения изоляции, вероятностью передачи от асимптотических и количеством бессимптомных, да и просто необнаруженных, больных. Все эти параметры можно вбить в модель SEIR железным костылем, но обучение такой модели существенно затруднено. (Пример анализа вариантов развития эпидемии от мер на основе имитационного моделирования такой модели можно посмотреть в красивых видео в нашей прошлой статье)


В основу этой статьи легла публикация китайских ученых "Risk estimation and prediction by modeling the transmission of the novel coronavirus (COVID-19) in mainland China excluding Hubei province", которая была переработана и адаптированна под российские реалии.


Краткое описание исходной статьи

В этой статье предложена усовершенствованная модель SEIAR, обобщенная и расширенная дополнительными переменными (о них немного позже). Модель обучалась на статистических данных о заражении в материковом Китае, не включая провинцию Хубэй. (Её исключили на основании того, что здравоохранение было критически не готово к эпидемии, в отличии от остальной части страны, куда вирус дошел позже. Однако, модель с некоторыми оговорками можно экстраполировать и на весь Китай.). Сами дифференциальные уравнения решались с использованием цепей Маркова, а если быть точным, то использовать Markov chain Monte Carlo.


Сама модель хороша тем, что учитываем момент не намеренного занижения статистики когда просто физически невозможно учесть всех заболевших в симптомных и бессимптомных формах.


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


Если кратко, то модель может быть представлена так:



Давайте забежим немного вперед и уже наконец покажем вам картиночку с прогнозом.



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


Запись от 14 мая: Хорошо видно, что пик эпидемии наблюдается прямо вот сейчас. Сейчас самое время всем выйти гулять! (САРКАЗМ)


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


Формальное описание


Итак, под капотом модели работает набор диффуров:


Собственно, 11 диффуров


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


Описание всех параметров модели может быть найдено ниже:


Описание константных параметров (что подбираем)
Обозначение: Описание: Используемые границы начальных значений:
phi
Показатель скорости развития симптомов у зараженных
от 1/15 1/4
(то есть от 4 до 15 дней)
mu
Показатель длительности самоизоляции
(скорости выхода здоровых людей из самоизоляции)

от 0 1/6
(то есть от 6 дней)
с_0
Среднее число контактов в день на человека, значение на начало периода
от 30 до 45 человек в день
beta
Вероятность заболевания после контакта с инфицированным
от 0.05 до 0.6
theta
Вероятность проявления симптомов у зараженного (доля симптомных больных среди всех зараженных)
от 0.35 до 0.8
eta

Показатель госпитализированных из числа находящихся на обсервации (скорости госпитализации)
от 0 до 1
gamma_I
Доля выздоровевших среди симптомных больных
от 0 до 1
gamma_A
Доля выздоровевших среди бессимптомных больных
от 0 до 1
gamma_H

Доля выздоровевших среди госпитализированных больных
от 0 до 1
d
Доля общего числа смертей, вызванных вирусом, из общего числа заболевших за весь период
от 0.001 до 0.15
epsilon

Поправочный коэффициент для вероятности передачи от бессимптомных больных
от 0.6 до 0.9 -
q_1
Коэффициент, определяющий меры по ограничению контактов
q_2
Меры по выявлению инфицированных (тестирование)
от 0.1 до 0.9
q_3
Меры по отслеживанию перемещений заболевших
от 0 до 30
sigma
Снижение частоты контактов с кумулятивным ростом случаев заражения (определяет экспоненциальное убывание доли контактов с ростом опубликованных случаев инфекции)

от 0 до 0.001

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


А аппроксимировать и предсказывать мы будем следующие величины:


Описание переменных временных рядов (что предсказываем)
Обозначение: Описание: Используемые границы начальных значений:
S(t)
Уязвимые
E(t)
Зараженные в стадии инкубационного периода
[0, 1e+4]
I(t)
Симптомные больные
[0, 1e+4]
A(t)
Бессимптомные больные
[0, 1e+4]
Si(t)
Изолированные уязвимые
[0, 1e+4]
Q(t)
Зараженные на карантине
H(t)
Госпитализированные зараженные
R(t)
Выздоровевшие
Rh(t)
Выздоровевшие из госпиталя
D(t)
Кумулятивное число смертей в госпитале
T(t)
Общее число подтвержденных случаев

В изначальной статье авторы предлогают использовать метод Марковских цепей Монте-Карло (MCMC). Но этот метод решает предложенные дифуры непозволительно долго и нестабильно. Поэтому мы используем другой метод. Всю эту сложную систему будем решать вполне классическими методами BDF мы пошагово аппроксимируем производную функции. Метод, конечно, не идеален и имеет много как плюсов как и минусов. Да, можно было решить и очень сложно и красиво, но, совсем не факт, что это дало бы какие-либо значимые результаты.


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


Эксперименты


Проведем моделирование для России. (Еще раз сошлемся на дисклеймер вначале, что мы НЕ рассматриваем статистику начиная с последнего времени из-за полного изменения методики учета)


Если мы считаем, что пик прошел в середине мая ровно в момент обращения президента и конца нерабочих дней.




Найденные параметры
phi mu c_0 beta theta eta gamma_I gamma_A gamma_H d epsilon q_2 q_3 sigma
Russia 0,064 0,004 30,889 0,064 0,410 0,182 0,793 0,208 0,020 0,001 0,642 0,900 12,387 0,000007

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


Важно учесть, что тут мы именно берем официальную статистику за ground truth и строим предсказания исходя из этого.


Графики количества подтвержденных случаев в других странах



Параметры найденные для этих стран
phi mu c_0 beta theta eta gamma_I gamma_A gamma_H d epsilon q_2 q_3 sigma
Canada 0,063 0,049 32,453 0,071 0,783 0,137 0,735 0,443 0,028 0,004 0,750 0,843 0,047 1,63E-05
Germany 0,078 0,033 33,262 0,092 0,838 0,024 1,000 0,100 0,059 0,001 0,773 0,746 23,883 3,42E-05
Italy 0,063 0,083 33,837 0,129 0,531 0,004 0,736 0,486 0,023 0,005 0,741 0,602 8,119 1,36E-05

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


Так же видно, что в Германии происходит Немецкое Чудо (система здравоохранения работает практически идеально, смертность очень низкая) поэтому некоторые параметры для Германии показывают экстремальные значения.


В целом эта модель горааааздо устойчивее к флуктуациям в статистике, хотя и не идеальна и иногда проваливается в локальные минимумы, хоть и близкие к глобальным. Можно так же заметить, что данные везде, кроме России, почти во всех странах подвержены "синдрому выходного дня", о котором упоминалось выше.


Влияние изменения параметров


Попробуем немного поиграться с параметрами и посмотрим, как вводимые меры влияют на итоговое количество переболевших. При этом остальные параметры оставим фиксированными, как они были подобраны для текущего региона (вероятность передачи, количество бессимптомные больных и прочее). (В таком формате ст.8)


Тут мы не будем концентрироваться на статистике как таковой, а только косвенно описаться на неё при проверке адекватности вариаций параметра.


Заразность



Подробнее про Заразность заболевания

beta вероятность передачи вируса через контакт с инфицированным, при дистанции в полтора метра. Эту вероятность можно уменьшить путем соблюдения мер предосторожности и использования средств защиты, таких как перчатки, маски, антисептики. Кроме того, чем больше магазинов, транспорта дезинфицирует свои помещения и поверхности, тем вероятность beta, предположительно, меньше.



Видно, что это довольно эффективные меры, которыми можно сильно повлиять на ситуацию в целом.
Соблюдая меры предосторожности, можно растянуть пик эпидемии, освобождая медицинскую систему от нагрузки, и, в конце концов, серьезно снизить количество заболевших.


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


Дополнение

Отдельные авторы пишут, что отказ от антисептиков может повышать риск ОРЗ как минимум в 1,3 раза. Оценка повышения вероятности передачи при отказе от ношения перчаток пока оценено довольно плохо. Но однозначно известно, что ослабление карантина (в разных его формах) повышает эту вероятность из-за более халатного отношения к дистанции. Социальное дистанцирование примерно в 2-3 раза снижает вероятность.


Коэффициент Страха



Подробнее про Коэффициент опасения населения

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



Игнорирование мер изоляции и базовых правил предосторожности ведут к увеличению количества заболевших.


Самые очевидные меры по предотвращению снижения значения данного параметра: оповещение в СМИ, в соцсетях, закрытие предприятий и так далее.


Роль бессимптомных зараженных



Подробнее про Роль бессимптомных зараженных

А теперь проверим, как изменяется характер эпидемии при изменении доли бессимптомных больных. Границы этого параметра мы можем изначально оценить только приблизительно, потому что для уверенного заявления нужно массовое тестирование (см. Норвегию/Корею)



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


А теперь перейдем к самому интересному параметры, которые напрямую зависят от мер, введенных конкретным государством.


Массовое тестирование



Подробнее про Массовое тестирование

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



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


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


Большой Брат



Подробнее про Контроль за перемещением граждан

На этом месте самое время вспомнить Большого Брата из романа 1984 и его жгучее желание отслеживать контакты и перемещения всех и каждого.


Введение похожих мер во многих странах оправдывается "заботой о людях" и соблюдением карантинных мер. К сожалению, государственные организации не могут предоставить конкретных данных по работе Рос-[Контроля] в этой сфере. Однако, посмотрев на колебания данного параметра, мы можем получить качественную оценку, показывающую полную неэффективность мер такого рода.



Тут можно сделать простой вывод: отследить все контакты потенциальных больных физически невозможно (см пациент 31 из Южной Кореи). Да, Google & Apple разработывают систему, но она лишь увеличит количество людей, которые захотят провериться, но не сможет уберечь их от заражения.


Область сценариев


Попробуем оценить насколько же разными может быть исход эпидемии в стране и регионе. Методика оценивания основывалась на умных книжках (например, Nonlinear Parameter Estimation Yonathan Bard). В рамках этой статьи мы не будем залезать в матан, а только посмотрим на примерные картинки.


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


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


Здесь применимы все стандартные средства матстата и статистического анализа.


Для Нижнего Новгорода было получено:



На графике, кроме интервала наиболее вероятных сценариев, так же изображено наиболее вероятное (для используемой статистики) предсказание.
Видно, что тренд может сильно меняться из-за недостаточной точности данных и большого шума в данных по регионам. Однако, прогнозы укладываются в нашу область.



Краткие выводы


Веря официальной статистике, переболеет небольшая часть населения, при условии соблюдения мер. Еще один вывод, вытекающий из предыдущего, что "русский менталитет" помогает существенно снизить заразность вируса. Особенно в последнюю половину мая.


Для COVID-19 инкубационный период составляет от 2 до 14 дней (чаще всего 5-6), латентный период практически равен инкубационному. Поэтому, даже если вы чувствуйте себя отлично равно как и ваши друзья, с которыми вы хотите встретиться, то это не ограничит вас на 100% от заражения. А нарушением самоизоляции вы повысите beta уровень заразности вируса в стране.


Очень сильно итоговая ситуация зависит от уровня изоляции жителей. Это связано с сознательностью, введением карантина, помощью государства, возможностью работать из дома и многим другим.


Мем

Тогда как прямая слежка за перемещением от государства практически не влияет на ход эпидемии.


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


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


Отдельная благодарность kblack, pixml и keysloss за помощь в написании статьи и построении модели.

Подробнее..

Облегчаем себе жизнь с помощью BeautifulSoup4

01.03.2021 16:18:41 | Автор: admin
Приветствую всех. В этой статье мы сделаем жизнь чуточку легче, написав легкий парсер сайта на python, разберемся с возникшими проблемами и узнаем все муки пайтона что-то новое.

Статья ориентирована на новичков, таких же как и я.

Начало


Для начала разберем задачу. Взял я малоизвестный сайт новостей об Израиле, так как сам проживаю в этой стране, и хочется читать новости без рекламы и не интересных новостей. И так, имеется сайт, на котором постятся новости: есть новости помеченные красным, а есть обычные. Те что обычные не представляют собой ничего интересного, а отмеченные красным являются самым соком. Рассмотрим наш сайт.



Как видно сайт достаточно большой и есть много ненужной информации, а ведь нам нужно использовать лишь контейнер новостей. Давайте использовать мобильную версию сайта,
чтобы сэкономить себе же время и силы.



Как видите, сервер отдал нам красивый контейнер новостей (которых, кстати, больше чем на основном сайте, что нам на руку) без рекламы и мусора.

Давайте рассмотрим исходный код, чтобы понять с чем мы имеем дело.



Как видим каждая новость лежит по-отдельности в тэге 'a' и имеет класс 'lenta'. Если мы откроем тэг 'a', то заметим, что внутри есть тэг 'span', в котором находится класс 'time2', либо 'time2 time3', а также время публикации и после закрытия тэга мы наблюдаем сам текст новости.

Что отличает важную новость от неважной? Тот самый класс 'time2' или 'time2 time3'. Новости помеченые 'time2 time3' и являются нашими красными новостями. Раз уж суть задачи понятна, перейдем к практике.

Практика


Для работы с парсерами умные люди придумали библиотеку BeautifulSoup4, в которой есть еще очень много крутых и полезных функций, но об этом в следующий раз. Нам также понадобиться библиотека Requests позволяющая отправлять различные http-запросы. Идем их скачивать.

(убедитесь, что стоит последняя версия pip)

pip install beautifulsoup4 

pip install requests

Переходим в редактор кода и импортируем наши библиотеки:

from bs4 import BeautifulSoupimport requests

Для начала сохраним наш URL в переменную:

url = 'http://mignews.com/mobile'

Теперь отправим GET()-запрос на сайт и сохраним полученное в переменную 'page':

page = requests.get(url)

Проверим подключение:

print(page.status_code)

Код вернул нам статус код '200', значит это, что мы успешно подключены и все в полном порядке.

Теперь создадим два списка (позже я объясню для чего они нужны):

new_news = []news = []

Самое время воспользоваться BeautifulSoup4 и скормить ему наш page, указав в кавычках как он нам поможет 'html.parcer':

soup = BeautifulSoup(page.text, "html.parser")

Если попросить его показать, что он там сохранил:

print(soup)

Нам вылезет весь html-код нашей страницы.

Теперь воспользуемся функцией поиска в BeautifulSoup4:

news = soup.findAll('a', class_='lenta')

Давайте разберём поподробнее, что мы тут написали.

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



Как видите, вместе с текстом новостей вывелись теги 'a', 'span', классы 'lenta' и 'time2', а также 'time2 time3', в общем все, что он нашел по нашим пожеланиям.

Продолжим:

for i in range(len(news)):    if news[i].find('span', class_='time2 time3') is not None:        new_news.append(news[i].text)

Тут мы в цикле for перебираем весь наш список новостей. Если в новости под индексом [i] мы находим тэг 'span' и класc 'time2 time3', то сохраняем текст из этой новости в новый список 'new_news'.

Обратите внимание, что мы используем '.text', чтобы переформатировать строки в нашем списке из 'bs4.element.ResultSet', который использует BeautifulSoup для своих поисков, в обычный текст.

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

Выведем наши данные:

for i in range(len(new_news)):    print(new_news[i])

Вот что мы получаем:



Мы получаем время публикации и лишь интересные новости.

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

Надеюсь эта статья поможет новичкам понять, что можно делать с помощью парсеров и поможет им немного продвинуться вперед с обучением.

Спасибо за внимание, был рад поделиться опытом.
Подробнее..

Моделирование данных зачем оно нужно и какие преимущества дает бизнесу

14.04.2021 12:16:12 | Автор: admin

Когда маркетологам нужно получить новый отчет или изменить существующий, они вынуждены обращаться к аналитикам и ждать, пока те подготовят данные. Аналитики строят отчеты с помощью SQL. Со временем таких SQL запросов становится все больше, а логика в них все сложнее. В результате маркетологи теряют время и упускают возможности, а аналитикам приходится заниматься рутиной вместо интересных задач. Как трансформация и моделирование данных могут существенно облегчить жизнь и тем, и другим читайте под катом.

Что такое трансформация и моделирование данных?

Чтобы ответить на этот вопрос, разберемся с основными терминами, которые вы встретите в этой статье.

Модель данных это описание объектов и их свойств; связей между объектами и ссылок на источники данных. Связь между объектами реализуется через специальные свойства ключи.

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

Схема данных описывает некую предметную область, например, электронную коммерцию. В ней есть заказы, пользователи, сессии. У SaaS-бизнесов могут быть дополнительные сущности, например, подписка или тарифный план. У телеком компаний и банков подтвержденные заявки и т.д.

Как выглядит модель данных пример для Ecommerce:

Трансформация данных это процесс преобразования данных из одной структуры в другую.

Моделирование данных это трансформация данных в структуру, соответствующую требованиям модели.

Какую проблему решает моделирование данных?

Если представить основные этапы работы с данными в виде графика...

...можно увидеть, что на между этапами Preparation Reporting (Подготовка данных Создание отчетов) и возникает больше всего проблем.

Когда маркетологу нужно: получить данные для отчета в новой структуре; добавить колонку в готовый отчет; изменить логику объединения данных в готовом отчете он вынужден обращаться к аналитику и ждать.

Когда аналитику нужно: приджойнить в готовый отчет дополнительные данные; обновить логику расчета определенной метрики; заменить источник данных на источник с другой структурой он тратит значительное время на понимание и рутинное изменение надцати SQL-запросов.

Чтобы понять, как именно моделирование данных решает эти проблемы, рассмотрим подробнее процесс подготовки данных. Его можно разбить на три этапа:

1. Моделирование. На этом этапе аналитик задается вопросами: Как собранные данные соотносятся с бизнес-сущностями?, Какие способы объединения данных допустимы?.

Моделирование достаточно универсальная задача. Например, когда маркетолог спрашивает у аналитика: А мы вообще сможем объединить данные из источников X и Y?. Это задача моделирования.

2. Виртуализация. На этом этапе решается вопрос: Какая структура и вариант объединения данных нужны для конкретного отчета?. Структура может быть получена с помощью разных вариантов объединения, но какой нам нужен в данном случае? Нам нужны источники последней сессии или всех? Одну и ту же структуру мы можем получить разными способами. Для виртуализации аналитик должен ответить на эти вопросы и создать такой SQL-запрос, который эти данные вернет.

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

3. Трансформация. На этом этапе аналитик решает, в какой структуре необходимо подготовить данные для их объединения в отчете. Готовит данные: занимается дедупликацией, отсеиванием всплесков, нормализацией. То есть это все манипуляции с входным потоком для того, чтобы потом эти данные можно было использовать.

Задача трансформации достаточно нетривиальна. Потому что у каждого бизнеса есть уникальные требования. Она в целом менее универсальная и используется как минимум на этапе запуска. То есть мы сделали какой-то отчет и один раз как минимум определили правила трансформации.

Маркетологи зависят от аналитиков, потому что у них нет готового продукта, который решал бы задачу виртуализации. Из-за этого для каждого нового отчета, когда нужно добавить колонку, аналитик трансформирует данные снова и снова. Чтобы этого избежать, нужно решение, которое позволит трансформировать данные и хранить их в структуре, пригодной для многократного использования. Таким решением может выступать связка dbt + Google BigQuery.

Какое преимущество дает бизнесу моделирование данных?

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

Как сейчас выглядит построение отчетов? Маркетолог рассказал аналитику, что нужно сделать. Тот написал SQL-запросы и построил на их результатах дашборд. Нашли расхождения, добавили условия в запросы, сделали пару итераций, получили обратную связь и таким образом довели отчет до ума. Но все решения были в контексте отчета. Это значит, что когда понадобится другой отчет с другими источниками, новыми колонками, несколькими срезами данных операцию проверки сходимости данных, валидацию нужно будет проходить заново.

С трансформацией и моделированием данных эта задача решается до того, как строится отчет. Когда мы еще не знаем, какие нам понадобятся отчеты. Но ответ на вопрос, что такое сессия, пользователь, расходы, мы сформулировали на уровне модели. То есть трансформация это преобразование данных в структуру, которая соответствует требованиям модели. Она позволяет строить отчеты, не тратя время на очередную обработку данных. При этом вы будете уверены, что отчеты построены на сходимых данных.

Способы трансформации данных для моделирования

Есть встроенный механизм регулярных запросов, которые выполняются в Google BigQuery, Scheduled Queries и AppScript. Их легко можно освоить, потому что это привычный SQL, но проводить отладку в Scheduled Queries практически нереально. Особенно, если это какой-то сложный запрос или каскад запросов.

Есть специализированные инструменты для управления SQL-запросами, например, dbt и Dataform.

dbt (data build tool) это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести

элемент программной инженерии в процесс анализа данных. Он помогает оптимизировать работу с SQL-запросами: использовать макросы и шаблоны JINJA, чтобы не повторять в сотый раз одни и те же фрагменты кода.

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

Сравнение способов трансформации данных:

Если вы хотите получать больше пользы от своих данных, рекомендуем уже сейчас осваивать dbt или Dataform. Они помогут значительно упростить и ускорить создание отчетов для вашей компании.

Подробнее..

Hadoop мертв, да зравствует Hadoop! Или что новенького в Cloudera?

22.02.2021 18:08:55 | Автор: admin

Привет, Хабр! Меня зовут Кирилл, я инженер по решениям в Cloudera, и сегодня мне выпала честь представлять всю команду, работающую с регионом СНГ. Мы очень рады, что наконец-то можем делиться полезными материалами и новинками мира больших данных с вами. В последнее время у нас появилось много нового, поэтому начиная писать эту статью волновались, как бы она не превратилась в неподъемный лонгрид. Постарались собрать ниже только самое основное и, к сожалению, в этой статье не будет много технической информации, но мы быстро это исправим.

Что новенького в Cloudera?

Пожалуй, начнём немного издалека для тех, кто не так активно следит за развитием проектов экосистемы Hadoop: компании Hortonworks и Cloudera объединились в 2019 году под общим названием Cloudera. С этого момента началась новая ветка в истории развития дистрибутива Hadoop, так как усилиями уже общей команды стартовала работа над новой сборкой, которая включила в себя всё лучшее из обоих миров. В 2019 году состоялся первый релиз нового дистрибутива Cloudera Data Platform (дальше - CDP), в который вошло более 50 лучших в своем классе инструментов с открытым исходным кодом для работы с большими данными.

Так что же такого интересного предлагает Cloudera Data Platform? В рамках платформы мы предоставляем корпоративное облако данных для данных любого типа, в любой инстраструктуре, от периферии до ИИ. CDP работает в различных средах: локальной, в частном и публичном облаке, или в гибридном варианте архитектуры.

Теперь более подробно о названиях всех вариантах дистрибутива. Версия для традиционной локальной инсталляции на железо называется CDP Private Cloud Base. Она является фундаментом для расширения локальной архитектуры до частного облака (поэтому и имеет такое название). Полноценная же архитектура частного облака, куда входит часть Base (уровень хранилища) и аналитические приложения на Kubernetes (уровень вычислений), называется CDP Private Cloud Plus/Max. С версией для публичных облаков всё проще - CDP Public Cloud. При этом это полноценный PaaS, тесно интегрированный с нативными сервисами большой тройки: AWS, Azure и GCP.

Благодаря единой панели управления, фреймворку Cloudera SDX (Shared Data Experience) и неизменному набору сервисов, работа с платформой выглядит одинаково, независимо от среды развёртывания, что позволяет реализовать полноценную гибридную архитектуру. При этом набор доступных сервисов позволяет работать сданными любого типа от периферии до ИИ с обеспечением безопасности корпоративного уровня (шифрование данных в пути и покое, полная керберизация кластера) и data governance:

Также в самом наборе инструментов появились интересные новинки:
- С декабря 2020 года для всех пользователей CDP стал доступен Spark 3.0, а добавление 3.1 запланировано на первую половину 2021.
- В конце лета прошлого года в дистрибутив был добавлен доработанный и готовый к работе в продуктиве Apache Ozone - S3 совместимое объектное хранилище, своего рода преемник HDFS, который закрывает многие из его слабых мест и позволяет делать гораздо более плотные конфигурации узлов (мы тестировали 350TB на узел - стабильная работа всех нагрузок).
- После приобретения компании Arcadia Data в стеке появился полноценный BI компонент Cloudera Data Visualization, работающий со всеми основными движками аналитики данных: Hive/Impala, Solr, Druid.
- Приобретение компании Eventador в 2020 году позволило добавить функционал аналитики потоковых данных с помощью SQL на базе Flink - теперь с потоками данных из Кафка можно работать как со стандартными таблицами в СУБД и создавать материализованные представления для, например, передачи трансформированных потоков обратно в Кафку.
- В начале этого года Cloudera объявила о включении проекта Apache Iceberg в дистрибутив, что позволит ещё более гибкоработать с огромными наборами данных благодаря снапшотам, поддержке эволюции схемы и возможностям откатов к предыдущим версиям по времени.

Изначально архитектура частного облака поддерживалась только на базе платформы Red Hat OpenShift, но в ближайшее времявыходит CDP Private Cloud Plus с поддержкой встроенного ванильного кубернетеса, что значительно упростит инсталляцию и ускорит внедрение гибридной архитектуры. Пользователи смогут быстрее начинать работу с данными, получат все преимущества облачной инфраструктуры, и при этом данные будут храниться в локальном ЦОДе.

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

Есть ли бесплатная версия дистрибутива, как это было раньше с HDP/CDH?
Выпуск бесплатной версии для коммерческого использования дистрибутива CDP не планируется. На данный момент можно скачать триальную версию с сайта или получить временную лицензию через аккаунт менеджера, а также рассматривается возможный выпуск версии для образовательных целей в будущем.

А что же со всеми любимыми сборками HDP/CDH?

Эти дистрибутивы не будут обновляться и постепенно заканчивают свой жизненный цикл поддержки (HDP2x/CDH5x уже закончили с концом 2020 года, такая же судьба настигнет HDP3/CDH6в скором времени). Более того, репозитории даже этих версий уже не доступны для публичного доступа - для этого теперь также требуется лицензия.

В тексте упоминался ИИ, что платформа предлагает для работы с моделями МО кроме Zeppelin?

В дистрибутиве есть дополнительный компонент - Cloudera Machine Learning (также известный как Cloudera Data Science Workbench), отвечающий за организацию полного цикла работы над моделями МО. Это полноценная MLOps платформа на кубере с центральным репозиторием метаданных, версионированием моделей, возможностью совместной работы в любом IDE (Jupyter Lab/Notebook включён по умолчанию) и любыми библиотеками, безопасным соединением с основным кластером и возможностью внедрения готовых моделей как функций в бизнес-процессы через REST API.


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

Подробнее..

Учебный день Microsoft основы работы с данными

09.03.2021 10:13:46 | Автор: admin

22 марта и 23 марта, 11.00-14.20 (GMT+3)

Изучите основные концепции баз данных в облачной среде. Присоединяйтесь к нам на мероприятии Microsoft Azure Virtual Training Day: основы данных, чтобы получить базовые знания об облачных сервисах обработки данных. Изучите предложения для работы с реляционными и нереляционными данными, а также решения для аналитики больших данных и современных хранилищ данных в Azure.

Подробности и регистрация.

Посетите это учебное мероприятие, чтобы:

  • Изучить роли, задачи и обязанности, связанные с управлением данными в облачной среде.

  • Получить основные навыки работы с облачными сервисами данных в Azure, используемыми для обработки реляционных и нереляционных данных, включая подготовку и развертывание реляционных и нереляционных баз данных.

  • Изучить средства обработки данных, используемые при создании решений для аналитики данных, включая Azure Synapse Analytics, Azure Databricks и Azure HDInsight.

После завершения этого бесплатного обучающего курса вы сможете сдатьсертификационный экзамен Основы работы с данными в Microsoft Azureбесплатно.

Вот, что мы вам предлагаем:

Часть 1

Часть 2

Введение

Введение

Изучите основные концепции данных

Изучите нереляционные данные в Azure (сегмент 1 из 2)

Перерыв 10минут

Перерыв 10минут

Изучите реляционные данные в Azure (сегмент 1 из 2)

Изучите нереляционные данные в Azure (сегмент 2 из 2)

Перерыв 10минут

Перерыв 10минут

Изучите реляционные данные в Azure (сегмент 2 из 2)

Изучите средства аналитики современных хранилищ данных в Azure

Завершающий сеанс вопросов и ответов

Завершающий сеанс вопросов и ответов

Подробности и регистрация.

Подробнее..

Перевод DBT новый способ трансформации данных в The Telegraph

17.05.2021 12:14:39 | Автор: admin

В заключительной статье о DBT хочу поделиться переводом кейса Стефано Солимито, в котором он рассказал о своем опыте использования этого инструмента в компании The Telegraph.

Предыдущие мои статьи на тему DBT:

The Telegraph это компания с 164-летней историей, в которой данные всегда играли центральную роль. С появлением облака и необходимостью обрабатывать огромное количество данных в 2015 году мы начали создавать нашу платформу на основе Google Cloud и на протяжении многих лет продолжаем ее улучшать.

Задача

В течение последних 4 лет у меня было несколько дискуссий о том, как организовать трансформирмацию данных или, в более широком смысле, процессы извлечения, преобразования и загрузки (ETL). Количество инструментов на рынке огромно, и выбор неправильной технологии может негативно повлиять на качество данных и решений, принимаемых на их основе.

В The Telegraph озеро данных создано на основе Cloud Storage и BigQuery. По мнению Google, естественным выбором для выполнения ETL в таком случае должен быть Dataflow (Apache Beam). Это может быть правдой для большинства компаний. Но если вы выйдете за пределы общих вариантов использования, представленных в справке, и столкнетесь с проблемами реального мира, то выбор может оказаться не таким уж и простым.

В нашем случае внедрение Apache Beam оказалось не самым простым решением по следующим причинам:

  • Java SDK пользуется гораздо большей поддержкой, чем Python SDK. Большая часть нашей команды имеет опыт работы с Python, а с Java нет. Кроме того, наши data scientists работают только на Python, а это означает наличие кодовых баз на нескольких языках, что затруднит ротацию инженеров в разных проектах.

  • Большинство наших потоков данных структурированы так, чтобы быть просто серией запросов, запускаемых в BigQuery. Учитывая это, Apache Beam не добавляет большой ценности процессу ETL.

  • Dataflow действительно хорошо взаимодействует с продуктами Google, но в 2015 году количество коннекторов было ограничено, и нам нужно было взаимодействовать с AWS, локальными серверами и т.д.

  • Наши аналитики и специалисты по обработке данных, как правило, говорят на языке SQL, и с ними намного проще сотрудничать, если в инженерии нам не нужно переводить создаваемую ими логику SQL на Java или Python.

Примечание: мы все-таки используем Apache Beam, но только для потоков данных в реальном времени.

Если вы используете Google Cloud Platform (GCP), вторым продуктом, который стоит рассмотреть, может быть Dataproc. Если у вас уже есть кластер Spark или Hadoop и вы хотите перейти на GCP, было бы разумно выбрать этот вариант. Но у нас был только небольшой кластер Hadoop, и переписать логику работающих там потоков данных не составило труда.

Третий продукт, который мы рассматривали и даже какое-то время использовали это Talend (бесплатная версия). Если ваша компания готова купить его корпоративную версию, это отличный выбор, но если вы решите перейти на бесплатную версию, то можете столкнуться с некоторыми проблемами:

  • Трудно применить контроль версий к вашим потокам данных.

  • Вы должны придумать свой собственный CI/CD, а тестируемость ваших артефактов ограничена.

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

  • Вам нужно найти экспертов по Talend, которые смогут управлять разработкой.

  • Если решение о внедрении инструмента для выполнения ETL не будет доведено до сведения всей компании, вы можете получить разрозненный набор технологий, которые придется поддерживать в течение нескольких лет.

Поэтому мы решили создать собственную Python ETL библиотеку в качестве оболочки для функций, предоставляемых Google и AWS, чтобы облегчить взаимодействие с основными сервисами обоих облаков. Даже этот подход оказался далек от совершенства. Проектирование и разработка собственной библиотеки, техническое обслуживание, необходимое для ее обновления и добавления новых функций, требуют немалых усилий. Мы начали искать что-то, что могло бы хорошо интегрироваться с этим подходом и уменьшить объем библиотеки.

В 2019 году мы начали тестировать DBT для трансформации данных с идеей продолжать выполнять извлечение и загрузку с помощью библиотеки Python и полагаться на Apache Beam для обработки данных в реальном времени.

Что такое DBT

DBT (Data Building Tool) это инструмент командной строки, который позволяет аналитикам и инженерам данных преобразовывать данные в своих хранилищах, используя операторы выбора.

DBT отвечает за T (трансформацию) в ETL-процессе, но не выполняет операции извлечения (E) и загрузки (L). Он позволяет компаниям трансформировать данные с помощью запросов и более эффективно их организовывать. В настоящее время с DBT работают более 280 компаний, и The Telegraph входит в их число.

Единственная функция DBT взять код, скомпилировать его в SQL-запрос, а затем выполнить его к вашей базе данных.

Инструмент поддерживает несколько баз данных, в том числе:

  • Postgres

  • Redshift

  • BigQuery

  • Snowflake

  • Presto

DBT можно легко установить с помощью pip (установщики пакетов Python). Он доступен в двух версиях: консоль (CLI) и пользовательский интерфейс (UI). Приложение DBT написано на Python и имеет открытый исходный код, что предполагает гибкую настройку под ваш проект.

CLI версия предлагает набор функций для преобразования данных: запуск тестов, компиляция, создание документации и т.д.

UI версия не дает возможности изменить ваши потоки данных и используется в основном для документирования.

На рисунке ниже показано, как в пользовательском интерфейсе DBT проиллюстрировано формирование таблиц. Это помогает быстро понять, какие источники данных участвуют в определенной трансформации. Такая визуализация может облегчить общение с коллегами, которые технически менее подкованы, но хотят получить общее представление.

Запустить проект в DBT очень просто: запуск dbt init в командной строке автоматически создает для вас структуру проекта. Это гарантирует, что все data-инженеры будут работать с одним и тем же шаблоном.

DBT также предлагает максимальную гибкость. Если созданная структура проекта не соответствует вашим потребностям, можно отредактировать файл конфигурации проекта (dbt_project.yml), чтобы изменить порядок папок по своему усмотрению.

Одним из важных понятий в DBT является модель. Каждая модель это оператор выбора, который должен быть согласован с другими моделями, чтобы преобразовать данные желаемым образом. Каждая модель написана с помощью языка запросов вашего хранилища данных (DW). Его можно расширить с помощью Jinja2, что позволит вам:

  • Писать более аккуратные параметризованные запросы.

  • Прописать повторяющиеся фрагменты SQL в макросах, которые можно использовать в качестве функций в ваших запросах.

  • Скрыть сложность трансформации, чтобы читатель мог сосредоточиться на самой логике.

Ниже приведен пример модели, использующей синтаксис BigQuery Standard SQL.

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

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

В data-driven компаниях качество данных, используемых для принятия решений, всегда имеет первостепенное значение. DBT позволяет выполнять различные типы тестов, что помогает получить качественные данные.

Простые тесты можно проводить с помощью синтаксиса YAML, поместив тестовый файл в ту же папку, что и ваши модели.

В этом конкретном примере проведены следующие тесты:

  • sk_interaction, bk_source_driver принимают уникальные значения и никогда не равны нулю.

  • count_interactions никогда не бывает нулевым

  • fk_interaction_detail не равно нулю, принимает уникальные значения, и все внешние ключи fk_interaction_detail могут соединяться с суррогатными ключами sk_interaction_detail. Это называется тестом ссылочной целостности и помогает убедиться, что ваша звездообразная схема построена надлежащим образом.

  • fk_interaction_text имеет аналогичные критерии тестирования.

  • Performance_band может принимать только определенный массив значений.

Более продвинутое тестирование может быть реализовано с использованием синтаксиса SQL.

Приведенный ниже запрос гарантирует, что в поле bk_source_driver из модели fact_interaction не более 5% значений, установленных как NULL.

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

В примере ниже показано, как можно определить источник в Sharded BigQuery Tables. Также можно использовать переменные для динамического выбора желаемого сегмента. В этом конкретном случае переменная execution_date передается на входе в DBT и определяет, какие сегменты используются в процессе трансформации.

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

Макрос в примере ниже используется для объединения нескольких ежедневных сегментов одной и той же таблицы в зависимости от переданной переменной execution_date и количества прошлых сегментов, которые мы хотим принять во внимание.

Выводы

Команда разработчиков Telegraph тестировала DBT (базовую версию) в течение двух месяцев. Он оказался отличным инструментом для всех проектов, требующих трансформации данных. Подводя итог нашему опыту, вот список плюсов и минусов этого инструмента.

Плюсы:

  • Это открытый исходный код, доступный для настройки.

  • Легко применять контроль версий.

  • Документация живет вместе с вашим проектом DBT и автоматически генерируется из вашей кодовой базы.

  • Не требуется никаких специальных навыков. Если ваши инженеры знакомы с SQL и имеют базовые знания Python, этого достаточно, чтобы приступить к DBT.

  • Шаблон каждого проекта создается автоматически при запуске DBT. Это обеспечивает соблюдение стандарта для всех наших потоков данных.

  • Вся вычислительная работа перекладывается на ваше хранилище данных. Это позволяет достичь высокой производительности при использовании технологий, подобных BigQuery или Snowflake.

  • Из-за вышеизложенного для организации DBT проекта требуются минимальные ресурсы.

  • Он позволяет тестировать данные (тесты схемы, тесты ссылочной целостности, пользовательские тесты) и обеспечивает качество данных.

  • Упрощает отладку сложных цепочек запросов. Их можно разделить на несколько моделей и макросов, которые можно протестировать отдельно.

  • Это хорошо задокументировано, и кривая обучаемости не очень крутая.

Минусы:

  • Инструмент на основе SQL: он может предложить меньшую читабельность по сравнению с инструментами с интерактивным пользовательским интерфейсом.

  • Пользовательский интерфейс предназначен только для документации. Это помогает визуализировать процесс трансформации, но ваши инженеры по обработке данных должны поддерживать аккуратность и понятность проекта DBT. Наличие интерактивного UI, который позволяет визуально видеть поток данных и изменять запросы, может быть полезным, особенно когда речь идет о сложных конвейерах данных.

  • Создание документации для BigQuery занимает много времени из-за плохой реализации, которая сканирует все сегменты в наборе данных.

  • DBT охватывает только T в ETL, поэтому вам потребуются другие инструменты для выполнения извлечения и загрузки данных в хранилище.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru