Как стать автором
Обновить

Комментарии 16

Как много сложных терминов и серьезных технологий. Глядишь, когда-нибудь разработчики изучат технологию Cookies и смогут сохранять выбранную пользователем локацию на сайте! Берегу жирный плюс к статье где об этом будет рассказываться =)

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

Ну хоть за несколько лет смогли ФИАС подключить, а то свой адрес доставки существующий несколько десятилетий не мог указать, только соседей, при том что адрес пер.ХХХХХХ дом 1.

Git вообще-то это самое сложное​

Интересно как у вас при отгрузке товара умудряются брать не то что заказано когда везде налеплен штрих код. Денег так и не вернули за неправильные трубы... Особенно забавна СМС о "обещании сообщить решение" в течении 5 дней от 1го июля..

А Metabase по каким параметрам не подошел?

В первую очередь он на тестах ощутимо медленнее работал с GP. Плюс разработка на Clojure+JS, а нас опыта с питоном намного больше. Ну и, насколько поняли, синхронизация с AD(LDAP) - только в платной версии.

А вы из Flink льете в S3 и оттуда забираете через CH и GP? Или одной рукой льете в S3 для CH, а второй вставляете в GP? Если второе, то в GP у вас вставка через координатор, или вы написали свой коннектор под GP для вставки через сегменты?

Пока одной рукой льем в S3, второй вставляем в GP через мастер в AO h-store таблицы. Максимальная скорость вставки порядка 5-6 гигабайт в минуту, нам пока этого хватает. Постепенно уходим от этого, есть решение, когда мы раз в час с помощью PXF с сегментов подтягиваем данные из S3, несколько источников уже так проинтегрированы, скорость ощутимо выше.

Я просто сильно удивился фразе «что на GreenPlum считалось часами, мы могли уже считать на потоке с помощью Flink, еще и в режиме near-realtime». У меня возникло подозрение, что причина была именно заливке данных через координатор, которая крайне медленно работает и сильно утилизирует ресурсы кластера. Я правильно понимаю, что вы добавили Flink и свертку данных на нем, чтобы координатор не захлебывался (меньше льем)? И так вам было сделать проще, чем научить сегменты забирать данные из Кафки?

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

Одна из главных болячек GP - невозможность настроить его так, чтобы и ETL работал и пользователи не жаловались. Все потому что под разные вижу нагрузки надо создавать разное количество сегментов на сегмент-хосте. Для пользовательских активностей больше сегментов, но сами сегменты мельче, а для ETL меньше сегментов и сегменты жирнее по ресурсам. Поэтому большинство крупных аккаунтов разделяют ETL и user ad-hoc + BI кластера, как то решая задачу репликации данных.

Вопрос - почему именно флинк, а не например кафка стримс? По каким критериям выбрали флинк?

А за какие ресурсы идет конкуренция, что приходится делать два кластера и экспортировать из ETL в пользовательский кластер? На первый взгляд, если это ЦПУ, то есть ресурсные группы. Если диск, то вы можете разносить схемы сырых данных и витрин по разным табличным пространствам на разные диски. Память тоже делится через менеджер памяти (настраивается через те же ресурсные группы). Нехватка соединений решается пулером.

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

А если как в этом случае 2000 BI пользователей, то это относительно короткие запросы с очень высокой конкуренцией. В этом вся и разница.

И все же, какого ресурса вам не хватает (ЦПУ, диск, память)?

Количество сегментов обычно увеличивают, если недостаточно утилизирован ЦПУ. В вашем же случае (ETL и пользователи), вряд ли вы недостаточно его утилизируете. Вообще единственная причина, почему на одном хосте более одного сегмента в GP - это отсутствие хорошо работающего параллельного сканирования в рамках одного сегмента. В PG для этого поднимаются фоновые процессы, GP использует пул соединений от координатора к сегменту. Если научить GP хорошо утилизировать ЦПУ при сканировании, получится уйти от кучи сегментов на хосте. Но повторюсь, недостаточная утилизация - явно не ваш случай.

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

Случай явно не мог :) Я тут мимо проходил вообще то :)

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

Насчет сегментов соглашусь. GP не имеем intra segment параллелизма как класс. И при этом сам архаичный движок не имеет средств оптимизации сканирования в виде storage индексов, при которых не нужные данные пропускаются на этапе сканирования. Поэтому единственная причина его более менее заставить быстро работать - больше дисков и желательно твердотельных и распараллелить процессы, распилив сегмент на большее кол-во worker'ов со своими независимыми маунтами дисков.

А пилят кластера по двум причинам

1 Разделение нагрузки при повышении конкуренции все равно не гарантирует SLA со временем регламентных процессов тн пользовательская нагрузка бывает весьма непредсказуемой и несмотря на все рес пулы бывает больно

2 Условный DR нужен в кровавом ентерпрайзе. Простаивать ему грешновато. Тут уже на что руки выросли. Если носить данные, прости господи, штатными средствами, то кол-во сегментов должно совпадать.

Со временем все крупные инсталляции к этому приходят. Ребята из ЛМ решили на старте делать in-house сами и постепенно соберут все шишки и опыт.

Дмитрий, добрый день. Мы с коллегами уже более 2-х лет занимаемся развитием платформы Superset во ВкусВилл. Мы, также как и вы, остановили свой выбор именно на этом решении за его открытый код, гибкость и дружелюбность к пользователю. Как вы заметили, платформа очень динамично развивается, но часть функционала пришлось реализовывать самостоятельно (например выгрузка таблиц в excel или локализация). Может быть вы тоже столкнулись с необходимостью как-то "допиливать" Superset под свои нужды?

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