Вы бы хоть между отдельными вопросами перевод строки ставили. Но я попробую расчленить и ответить. Не обессудьте, если неправильно их пойму.
Да, у нас есть набор хорошо упакованных и параметризованных алгоритмов, которые могут работать с похожими данными из разных источников.
Мы не занимаемся аналитикой над данными в сыром виде, и вообще я много раз подчёркиваю, что задачи повторить SparkSQL изначально не стояло (да и зачем такой ерундой заниматься?). Аналитика вся производится над данными, которые уже подготовлены, и в инструменты аналитиков я лично не лезу. Что у них там кроме pandas, не моё дело.
У нас нет отдельного слоя абстракции, который надо было бы изучать. Есть простая система типов, и это всё, что есть user-facing.
Нечего оптимизировать. В отличие от аналитических БД с декларативными SQL, где ты пишешь ЧТО хочешь получить, и оптимизатор сам тебе выбирает КАК (и где чаще всего зарыта собака), в ETL процессах ты непосредственно пишешь КАК тебе надо получить ЧТО-то, а оптимизатора у тебя нет от слова совсем.
Примеры вряд ли будут показательными, они очень уж сильно завязаны на конкретные бизнес-кейсы нашего проекта. Большая часть из них вообще под NDA. Мы же продаём услугу по аналитике тем, кто не умеет ею заниматься...
Если останутся ещё вопросы, я на них с удовольствием отвечу.
(БТВ, если вам всего хватает в имеющихся инструментах, вам остаётся только позавидовать. В реальной жизни кейсы намного разнообразнее, чем вам кажется. В качестве подсказки — в бизнесе деньги решают всё. Иногда весьма неочевидный путь ОЧЕНЬ сильно дешевле.)
Я такое делал. Более того, вот в этой статье https://habr.com/ru/articles/330366/ заглавный скриншот сгенерирован именно таким баш-скриптом, дёрнутым через CGI. Точнее, даже несколькими скриптами.
Написал за два дня, и оно какое-то время держалось в проде, но с учётом того, что на каждый вызов дёргалось овердофига процессов, с ростом обрабатываемого объёма начало нещадно тормозить. Переписал в итоге на PHP.
В качестве упражнения для разминки мозгов делать подобное весьма неплохо.
Если мне не изменяет склероз, для ухода за пределы УФ достаточно где-то 17 кВ. 40 и более это уже жёсткий рентген. И я не про светить на зрителя (там стекло достаточно толстое), а про то, что уходит вбок, вниз и во все остальные стороны.
Мде. Такая труба нехило так светит в рентгене, особенно в тех местах, где луч попадает на стекло, а не на люминофор. Использовать её в качестве дисплея без толстенного металлического корпуса... Ну, каждый взрослый человек сам способен ценить своё здоровье. Или не ценить.
Автор статьи сетует на то, что а) кроме spark internals ничего про нижний уровень толком не найти, и б) впрочем, даже и его всё равно никто не читает перед собеседованием.
Я же иронизирую над ситуацией (очевидно же, что проценты придуманы от балды), чего вы, по всей видимости, не выкупаете. Какое ещё высокомерие? Какое нафиг пижонство? Расслабьтесь, тут нет никакого наезда.
С учётом того факта, что для 97.78% пользователей Spark он ограничивается Spark SQL, очень странно к ним взывать.
Если хочется залезть поглубже — ну так берёшь и залазишь в исходники. Они открыты ведь. Но внутренний уровень Spark, кроме разработчиков чего-то кастомного на нижнем уровне API, никому не интересен. Мне вот нужен, так что можете мои статьи посмотреть, например. Но таких, как я, совсем мало.
Большинству же, работающему с SQL, это всё незачем. Потому они и не знают, что .reparttition это .coalece(shuffle = true).
Я б тоже с удовольствием посмотрел на чужие юзкейсы. Особенно, кейсы из промышленной эксплуатации en masse, а не всякие разовые исследования гениальных консалтеров, из которых делаются далеко идущие выводы с интерполяцией на всю индустрию.
Каких только проектов нет у наших заказчиков... И про недвигу, и про аутдор адвертайземент, я даже понятия не имею какие именно, потому что данными не занимаюсь. Я инструменты для аналитиков делаю, чтобы они могли «относительно быстро» и дёшево это всё безобразие считать.
И поэтому могу сказать, что индексы в постгресе — шляпа. И вообще, постгрес с деривативами (гринплам, редшифт, и т.п.) для бигдаты сам по себе чудовищно медленная и гораздо более дорогая шляпа, чем спарк.
Увы, я не могу рассказать больше, чем уже рассказал, потому что это уже под NDA. Могу только с некоторой грустью добавить, что кроме нас в мире никто из коммерсов за похожие задачи в таких масштабах не берётся, и в общем-то правильно делает. (Рисёрчеры и научники — делают, но у них иная экономика.)
Касательно эффективности: спарк не про утилизацию железа на 100%, и даже не про скорость, а про саму возможность посчитать сумасшедшие объёмы даты на относительно слабом и дешёвом виртуализованном железе в облаке. «Проще» не означает «экономически эфффективно», и наоборот.
Ну, GIST эт такое себе индексирование, для геометрий его натянули примерно как сову понятно на что. Плавали, знаем как оно внутри устроено.
BTW, мы тоже ведь начинали 6 лет назад именно с PostGIS, и для считанных сотен тыщ точек использовать тамошние ST_ функции было ещё нормально. Проблемы начались, когда точек стали миллионы, и постгря перестала справляться с такими запросами. Вот тогда и мигрировали на Spark, поначалу с разбиениями по полигонам и/или по Вороному. А к решениям, позволяющим работать с миллиардами точек, и требующим нормальное геометрическое индексирование типа того же H3, мы пришли за несколько лет.
Для больших данных ST_DWithin (и вообще георасширения любой СУБД) не подошло бы, да и вообще, слишком уж это медленно и неэффективно — сравнивать в лоб все сочетания пар POI из двух наборов. Но для ~300 станций и ~100к домов (≅ 30М сочетаний) потянет.
Автор мыслит в другой парадигме.
Process vs. state.
Schema-less vs. INFORMATION_SCHEMA.
Flow control vs. DAG.
Ну и так далее. Достаточно отличий в идеологии. Но SQL тем не менее остаётся SQL, так как он тупо удобен для конечных пользователей.
Очень сложно парсить ваши комментарии :\
Вы бы хоть между отдельными вопросами перевод строки ставили. Но я попробую расчленить и ответить. Не обессудьте, если неправильно их пойму.
Да, у нас есть набор хорошо упакованных и параметризованных алгоритмов, которые могут работать с похожими данными из разных источников.
Мы не занимаемся аналитикой над данными в сыром виде, и вообще я много раз подчёркиваю, что задачи повторить SparkSQL изначально не стояло (да и зачем такой ерундой заниматься?). Аналитика вся производится над данными, которые уже подготовлены, и в инструменты аналитиков я лично не лезу. Что у них там кроме pandas, не моё дело.
У нас нет отдельного слоя абстракции, который надо было бы изучать. Есть простая система типов, и это всё, что есть user-facing.
Нечего оптимизировать. В отличие от аналитических БД с декларативными SQL, где ты пишешь ЧТО хочешь получить, и оптимизатор сам тебе выбирает КАК (и где чаще всего зарыта собака), в ETL процессах ты непосредственно пишешь КАК тебе надо получить ЧТО-то, а оптимизатора у тебя нет от слова совсем.
Примеры вряд ли будут показательными, они очень уж сильно завязаны на конкретные бизнес-кейсы нашего проекта. Большая часть из них вообще под NDA. Мы же продаём услугу по аналитике тем, кто не умеет ею заниматься...
При том, что инструмент, построенный вокруг интерпретатора данного диалекта, используется для ETL.
И много ли вы знаете кастомных парсеров, которые, например, геометрические объекты и произвольный JSON поддерживают прямо в базовом синтаксисе?
Впрочем, предыдущие статьи вы, очевидно, даже не пытались читать.
Прочитайте предыдущую статью с FAQ https://habr.com/ru/articles/762862/
Если останутся ещё вопросы, я на них с удовольствием отвечу.
(БТВ, если вам всего хватает в имеющихся инструментах, вам остаётся только позавидовать. В реальной жизни кейсы намного разнообразнее, чем вам кажется. В качестве подсказки — в бизнесе деньги решают всё. Иногда весьма неочевидный путь ОЧЕНЬ сильно дешевле.)
Я бы тоже с удовольствием юзал какой-нибудь готовый инструмент, но увы.
Чем больше движущихся частей, тем выше вероятность отказа. И тем дороже стоимость владения.
Вот и я о том же.
А какие гарантии, что российский хостинг вдруг не свалится, как мтс-овское облако?
Я такое делал. Более того, вот в этой статье https://habr.com/ru/articles/330366/ заглавный скриншот сгенерирован именно таким баш-скриптом, дёрнутым через CGI. Точнее, даже несколькими скриптами.
Написал за два дня, и оно какое-то время держалось в проде, но с учётом того, что на каждый вызов дёргалось овердофига процессов, с ростом обрабатываемого объёма начало нещадно тормозить. Переписал в итоге на PHP.
В качестве упражнения для разминки мозгов делать подобное весьма неплохо.
Если мне не изменяет склероз, для ухода за пределы УФ достаточно где-то 17 кВ. 40 и более это уже жёсткий рентген. И я не про светить на зрителя (там стекло достаточно толстое), а про то, что уходит вбок, вниз и во все остальные стороны.
Мде. Такая труба нехило так светит в рентгене, особенно в тех местах, где луч попадает на стекло, а не на люминофор. Использовать её в качестве дисплея без толстенного металлического корпуса... Ну, каждый взрослый человек сам способен ценить своё здоровье. Или не ценить.
Вот именно, что когда данные не строго структурированные, тогда и начинается всё самое интересное.
Но таких кейсов на порядок меньше, чем со схемой, вот и выросло поколение, которое не умеет в интересное, потому как оно ему не нужно.
Автор статьи сетует на то, что а) кроме spark internals ничего про нижний уровень толком не найти, и б) впрочем, даже и его всё равно никто не читает перед собеседованием.
Я же иронизирую над ситуацией (очевидно же, что проценты придуманы от балды), чего вы, по всей видимости, не выкупаете. Какое ещё высокомерие? Какое нафиг пижонство? Расслабьтесь, тут нет никакого наезда.
https://t.me/hadoopusers — почти 5к участников. Уровень разный, есть очень опытные товарищи. Если хотите аудиторию, начните оттуда.
С учётом того факта, что для 97.78% пользователей Spark он ограничивается Spark SQL, очень странно к ним взывать.
Если хочется залезть поглубже — ну так берёшь и залазишь в исходники. Они открыты ведь. Но внутренний уровень Spark, кроме разработчиков чего-то кастомного на нижнем уровне API, никому не интересен. Мне вот нужен, так что можете мои статьи посмотреть, например. Но таких, как я, совсем мало.
Большинству же, работающему с SQL, это всё незачем. Потому они и не знают, что .reparttition это .coalece(shuffle = true).
Я б тоже с удовольствием посмотрел на чужие юзкейсы. Особенно, кейсы из промышленной эксплуатации en masse, а не всякие разовые исследования гениальных консалтеров, из которых делаются далеко идущие выводы с интерполяцией на всю индустрию.
Каких только проектов нет у наших заказчиков... И про недвигу, и про аутдор адвертайземент, я даже понятия не имею какие именно, потому что данными не занимаюсь. Я инструменты для аналитиков делаю, чтобы они могли «относительно быстро» и дёшево это всё безобразие считать.
И поэтому могу сказать, что индексы в постгресе — шляпа. И вообще, постгрес с деривативами (гринплам, редшифт, и т.п.) для бигдаты сам по себе чудовищно медленная и гораздо более дорогая шляпа, чем спарк.
Увы, я не могу рассказать больше, чем уже рассказал, потому что это уже под NDA. Могу только с некоторой грустью добавить, что кроме нас в мире никто из коммерсов за похожие задачи в таких масштабах не берётся, и в общем-то правильно делает. (Рисёрчеры и научники — делают, но у них иная экономика.)
Касательно эффективности: спарк не про утилизацию железа на 100%, и даже не про скорость, а про саму возможность посчитать сумасшедшие объёмы даты на относительно слабом и дешёвом виртуализованном железе в облаке. «Проще» не означает «экономически эфффективно», и наоборот.
Бабло решает, короче.
Ну, GIST эт такое себе индексирование, для геометрий его натянули примерно как сову понятно на что. Плавали, знаем как оно внутри устроено.
BTW, мы тоже ведь начинали 6 лет назад именно с PostGIS, и для считанных сотен тыщ точек использовать тамошние ST_ функции было ещё нормально. Проблемы начались, когда точек стали миллионы, и постгря перестала справляться с такими запросами. Вот тогда и мигрировали на Spark, поначалу с разбиениями по полигонам и/или по Вороному. А к решениям, позволяющим работать с миллиардами точек, и требующим нормальное геометрическое индексирование типа того же H3, мы пришли за несколько лет.
Неплохое упражнение в аналитике small data :)
Для больших данных ST_DWithin (и вообще георасширения любой СУБД) не подошло бы, да и вообще, слишком уж это медленно и неэффективно — сравнивать в лоб все сочетания пар POI из двух наборов. Но для ~300 станций и ~100к домов (≅ 30М сочетаний) потянет.