Любопытно. Всегда думал, что скоростной трейдинг и анализ по умолчанию пишется на C, так как идёт борьба за каждую миллисекунду.
Как сейчас атмосфера внутри банков? Может так получиться, что в ближайшие пару лет совсем сложно им будет зарабатывать независимо от качества моделей. Если рынки снижаются по всему спектру, а скоро ещё и property может скорость набрать.
Потому что компания, которая не может исправить проблему с клавиатурой в течение четырёх лет, и не должна была так расти.
Ок, если чуть серьёзнее, то LIBOR растёт всё выше и выше. Деньги больше не такие дешёвые, как раньше, что напрямую транслируется в цену активов. Думаю, это только начало.
А сколько сейчас примерно данных в QIWI в терабайтах? Есть ли какие-то наработки, чтобы считать модели параллельно на большом количестве ядер или серверов? Есть ли в этом необходимость?
О, спасибо. Пропустил оригинальную статью про нормализацию, хоть и слышал об этом голосом. Почитал с удовольствием.
Ещё один вопрос: верно ли, что при таком подходе очень заметно увеличиваются требования к I/O? Ведь нужно намного больше и писать, и читать:
При импорте обязательный lookup на каждый атрибут, чтобы понять, нужно ли создавать новую запись;
Много дополнительных суррогатных ключей и полей «load_date», которых не было бы в других моделях;
По две проекции на «ties»-таблицы — храним двойной объём данных;
Насколько я помню, Vertica обычно читает HDD на select-запросы, и они конкурируют за ресурсы с ETL. А значит, при честной anchor-модели база намного быстрее упрётся в диски при увеличении нагрузки на том же оборудовании, чем в более «обычных» случаях.
Понравилась форма изложения. Кратко, по делу, информативно. Мне бы на то же самое понадобилось несколько статей.
Чуть-чуть вопросов:
События только в Vertica лежат, или есть ещё cold storage для старых событий?
Разные версии одного события приземляются в одну таблицу или в разные?
Можно ли запустить запрос, затрагивающий несколько событий, и сделать между ними JOIN? Например, построить произвольный funnel (событие А, затем B, затем C или D)?
Общие для всех событий «заголовки» (окружение, версия приложения, session_id, device_id) хранятся в одной таблице вместе с телом события или лежат отдельно?
Эта идея вполне справедлива и для больших проектов, у которых сотни терабайт данных. Особенно если SQL хорошо масштабируется, позволяет сделать десяток произвольных JOIN'ов и отдаёт ответы за секунды или, максимум, минуты.
Последнее принудительное обновление стало тем самым последним пинком, благодаря которому мы скайп наконец-то дропнули. Давно пора было это сделать, спасибо за MS напоминание и мотивацию.
Не пробовали Exasol? Если используете много сложных JOIN'ов (десятки-сотни в одном запросе), то рискну утверждать, что по производительности это наилучшее решение на текущий момент.
Их SQL очень близок к Oracle, изменения будут минимальными. До 1Tb raw данных бесплатно, далее очень дёшево (в моём понятии). Особенно учитывая большую экономию на железе, потому что его нужно меньше на ту же нагрузку.
Единственное, нет «настоящей» реалтайм-аналитики, потому что есть ACID, и нужно всё же делать батчи и commit'ы. Но никто не мешает делать импорт раз в 5-10 минут.
В текущих координатах пенсионная система ничем не сможет помочь тем, кому сейчас меньше 40-45 лет. Какие бы цифры, доходности и планы вам сегодня ни рисовали — не верьте.
Никаких «накоплений» давно нет. Бюджет пенсионных фондов дефицитный. Все ваши вложения уходят на выплаты нынешним пенсионерам. И государству ещё сверху приходится добавлять из других источников, чтобы хоть как-то баланс свести.
У «частных» фондов всё вложено в раздутый до космических пропорций рынок акций (в лучшем случае) или в какой-нибудь заведомый неликвид (в худшем). Живых денег там минимум, только пустые обещания.
Это проблема не только в России. В «развитых» странах обязательств намного больше, а дефицит в абсолютных и относительных цифрах — выше. Где-то обязательно порвётся, и до людей начнёт доходить наконец, что соотношение 1.25-1.50 работающих на 1.00 пенсионера просто не может работать, какие воздушные замки ни рисуй.
— Но шанс нормально жить на пенсии у нас есть. Он просто не в экономике и нынешнем варианте денег, а в технологиях.
Если человечество сможет использовать очень дешёвый источник энергии, в сочетании с автоматизацией деньги просто будут не нужны. Можно будет накормить и укрыть всех стариков, просто потому что это стало очень дёшево и не ложится больше тяжким грузом на работающих.
Но если этого не произойдёт, то будущих пенсионеров ждёт очень-очень-очень незавидная судьба. Слишком много их будет в относительных цифрах.
Думаю, что тут нечего ждать и не на что надеяться. Microsoft — не благотворительная организация. Они наверняка будут отбивать эти «инвестиции» и монетизировать github. Ничем хорошим это не может закончиться.
Сообществу нужно как можно быстрее выбирать (или создавать) альтернативу и мигрировать. Open source это не стадо овец, которых можно собрать в кучку и продать за 5 миллиардов.
1) В 2018 году практически весь важный трафик шифруется.
2) Ключи операторам отдавать никто не собирается.
3) Без ключей хранение такого трафика мало чем отличается от хранения случайного набора байт.
Я тогда слишком молод был, поэтому точно не помню. Может быть и плохо!) Сам автоматически перестал использовать диски, когда появились доступные флешки на 4Gb+. Насколько же с ними удобнее было.
Действительно, когда увидел новые маки, то долго не мог понять, зачем Apple всё сами испортили. Пользуюсь предыдущим поколением, с USB, магнитной зарядкой, нормальной клавиатурой, без непонятных touch bar — проблем никаких. Надеюсь, подольше проживёт.
Кстати, с iOS такая же история. До сих пор держу iPad с iOS 6. Отличный дизайн, удобно, не тормозит, ничего лишнего в глаза не лезет. Оригинальное приложение VK до сих пор прекрасно работает, удобное, позволяет скачивать музыку в кеш, никакой рекламы.
Все эти последние «улучшения» повсеместные… большой вопрос, есть ли от них реальный толк.
А можно ли вообще не делать сложной логики внутри Airflow, а вместо этого делать параллельную загрузку и все проверки внутри Python скрипта?
DAG при этом будет выглядеть так:
START -> export_from_all_shards_and_action -> FINISH
Внутри скрипта запускаем 3-6-10-400-1000 потоков и загружаем данные. Сразу после загрузки проверяем результат и, если были фатальные ошибки, то отправляем на рестарт. Иначе делаем какое-то полезное действие.
Со временем образуется 5-7 стандартных загрузчиков из принципиально разных источников. И можно эту логику в отдельные классы вынести, и просто запускать с разными параметрами.
Логика ETL склонна усложнятся со временем. Есть риск, что через годик во всех хитросплетениях и костыликах уже сложно будет разобраться.
Как сейчас атмосфера внутри банков? Может так получиться, что в ближайшие пару лет совсем сложно им будет зарабатывать независимо от качества моделей. Если рынки снижаются по всему спектру, а скоро ещё и property может скорость набрать.
Ок, если чуть серьёзнее, то LIBOR растёт всё выше и выше. Деньги больше не такие дешёвые, как раньше, что напрямую транслируется в цену активов. Думаю, это только начало.
Спасибо.
Интересно было бы почитать, как ДНК из молекулы попадает в базу данных исследователей. Вроде очень большой прогресс наметился в этой области.
Ещё один вопрос: верно ли, что при таком подходе очень заметно увеличиваются требования к I/O? Ведь нужно намного больше и писать, и читать:
Насколько я помню, Vertica обычно читает HDD на select-запросы, и они конкурируют за ресурсы с ETL. А значит, при честной anchor-модели база намного быстрее упрётся в диски при увеличении нагрузки на том же оборудовании, чем в более «обычных» случаях.
Верно ли это?
Чуть-чуть вопросов:
Спасибо :)
Их SQL очень близок к Oracle, изменения будут минимальными. До 1Tb raw данных бесплатно, далее очень дёшево (в моём понятии). Особенно учитывая большую экономию на железе, потому что его нужно меньше на ту же нагрузку.
Единственное, нет «настоящей» реалтайм-аналитики, потому что есть ACID, и нужно всё же делать батчи и commit'ы. Но никто не мешает делать импорт раз в 5-10 минут.
Никаких «накоплений» давно нет. Бюджет пенсионных фондов дефицитный. Все ваши вложения уходят на выплаты нынешним пенсионерам. И государству ещё сверху приходится добавлять из других источников, чтобы хоть как-то баланс свести.
У «частных» фондов всё вложено в раздутый до космических пропорций рынок акций (в лучшем случае) или в какой-нибудь заведомый неликвид (в худшем). Живых денег там минимум, только пустые обещания.
Это проблема не только в России. В «развитых» странах обязательств намного больше, а дефицит в абсолютных и относительных цифрах — выше. Где-то обязательно порвётся, и до людей начнёт доходить наконец, что соотношение 1.25-1.50 работающих на 1.00 пенсионера просто не может работать, какие воздушные замки ни рисуй.
— Но шанс нормально жить на пенсии у нас есть. Он просто не в экономике и нынешнем варианте денег, а в технологиях.
Если человечество сможет использовать очень дешёвый источник энергии, в сочетании с автоматизацией деньги просто будут не нужны. Можно будет накормить и укрыть всех стариков, просто потому что это стало очень дёшево и не ложится больше тяжким грузом на работающих.
Но если этого не произойдёт, то будущих пенсионеров ждёт очень-очень-очень незавидная судьба. Слишком много их будет в относительных цифрах.
Сообществу нужно как можно быстрее выбирать (или создавать) альтернативу и мигрировать. Open source это не стадо овец, которых можно собрать в кучку и продать за 5 миллиардов.
1) В 2018 году практически весь важный трафик шифруется.
2) Ключи операторам отдавать никто не собирается.
3) Без ключей хранение такого трафика мало чем отличается от хранения случайного набора байт.
Ну то есть все эти деньги в канализацию, по сути.
Переход с CD-дисков был очевидным улучшением, он произошёл быстро и естественно. Новшества от Apple такими очевидными улучшениями не являются.
Кстати, с iOS такая же история. До сих пор держу iPad с iOS 6. Отличный дизайн, удобно, не тормозит, ничего лишнего в глаза не лезет. Оригинальное приложение VK до сих пор прекрасно работает, удобное, позволяет скачивать музыку в кеш, никакой рекламы.
Все эти последние «улучшения» повсеместные… большой вопрос, есть ли от них реальный толк.
Для японцев нужно всё отдельно делать.
twitter.com/sasha_ItaCafe
Они вдвоём весь японский рынок порвут только так :)
DAG при этом будет выглядеть так:
START -> export_from_all_shards_and_action -> FINISH
Внутри скрипта запускаем 3-6-10-400-1000 потоков и загружаем данные. Сразу после загрузки проверяем результат и, если были фатальные ошибки, то отправляем на рестарт. Иначе делаем какое-то полезное действие.
Со временем образуется 5-7 стандартных загрузчиков из принципиально разных источников. И можно эту логику в отдельные классы вынести, и просто запускать с разными параметрами.
Логика ETL склонна усложнятся со временем. Есть риск, что через годик во всех хитросплетениях и костыликах уже сложно будет разобраться.