Если мне не изменяет склероз, для ухода за пределы УФ достаточно где-то 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М сочетаний) потянет.
я, кстати про тупость работавших в совковых шарашках людей ни слова ни сказал. потому что люди там работали отнюдь не тупые. и моя матушка была отличным для своего времени специалистом, код писала вполне ничего такой. даже спустя 30 лет, будучи руководителем в веб-студии, она по старой памяти ещё вполне нормально ревьюила то, что программисты на пхп в прод выкатывали. так что не гоните.
проблема была системная.
государство — это плохой собственник, и ещё худший управленец. частник копирует продукт на уровне идеи, и творчески улучшает его, чтобы снизить себестоимость. чипы от амд, выпущенные как копия интела, были доработанными — даже самые ранние, в которых кремний был 1:1, имели другую корпусировку, оптимизированный техпроцес, и повышенные частоты. а более поздние — это всегда уже собственный продукт на основе официально полученной лицензии.
советское государство же, особенно в его поздние годы, не имело цели ни снижать себестоимость, ни возможности улучшать скопированный продукт. и куча талантливых людей занималась откровенно бесполезной работой, потому что была большая нужда, а мотивации нормальной — не было.
с завода или из нии было принято тащить всё, что только можно вынести через чёрный ход.
даже магнитную ленту от накопителей, блин, чтобы на огороде помидоры подвязывать. а что, удобно, под весом куста она не рвётся. последнюю бобину, которая уже рассыпаться начала, я только несколько лет назад выбросил...
проблемы с производством на сложных техпроцессах были в основном от общего разгильдяйства и низкой производственной культуры.
и ещё так совпало, что резкое усложнение техпроцессов выпало на постбрежневские/предперестроечные времена, когда общая мотивация личного состава ИТР была уже ниже всякого плинтуса.
и документацию, и само железо получали вполне по-шпионски, через подставные фирмы в третьих странах. из фрг через гдр, из японии через таиланд и вьетнам.
под конец перестройки смогли даже 286-й интел сэмулировать (100% клон так и не вышло сделать), но процент выхода годных чипов на тонких техпроцессах был такой поганый, что стоили они как крыло от самолёта.
ну, в совке ведь целые НИИ занимались реверсингом и копипиздингом западных образцов. у меня мать почти десяток лет проработала программистом в такой шарашке, занимавшейся как раз копированием всякой вычислительной техники. со схемотехникой и софтом проблем не было, но вот с кремнием, который в 80-х стал переходить на всё более тонкие техпроцессы — ещё какие.
Аналитика — это не моя область экспертизы. Я делаю инструменты для автоматизации работы аналитиков, но не занимаюсь ею сам. И описываемый проект покрывает только ETL процессы, но не более того.
Впрочем, если выдать мне white paper с описанием алгоритма расчёта какой-то метрики, я могу покумекать, и чё-нить имплементировать. Правда, имплементация будет на жабе. А чтобы вытащить её в уровень DSL, нужная серьёзная работа по генерализации задачи.
Если мне не изменяет склероз, для ухода за пределы УФ достаточно где-то 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М сочетаний) потянет.
Какой-то странный у автора взгляд. SQL != RDBMS уж тыщу лет как, и даже NoSQL хранилища мутировали в NewSQL.
Эх, жаль оригинал за пэйволом, а то б неплохо было потыкать его на предмет а чё ж он сказать-то хотел.
эк вас жёстко триггернуло. спокойнее надо быть.
я, кстати про тупость работавших в совковых шарашках людей ни слова ни сказал. потому что люди там работали отнюдь не тупые. и моя матушка была отличным для своего времени специалистом, код писала вполне ничего такой. даже спустя 30 лет, будучи руководителем в веб-студии, она по старой памяти ещё вполне нормально ревьюила то, что программисты на пхп в прод выкатывали. так что не гоните.
проблема была системная.
государство — это плохой собственник, и ещё худший управленец. частник копирует продукт на уровне идеи, и творчески улучшает его, чтобы снизить себестоимость. чипы от амд, выпущенные как копия интела, были доработанными — даже самые ранние, в которых кремний был 1:1, имели другую корпусировку, оптимизированный техпроцес, и повышенные частоты. а более поздние — это всегда уже собственный продукт на основе официально полученной лицензии.
советское государство же, особенно в его поздние годы, не имело цели ни снижать себестоимость, ни возможности улучшать скопированный продукт. и куча талантливых людей занималась откровенно бесполезной работой, потому что была большая нужда, а мотивации нормальной — не было.
да ладно бы золото.
с завода или из нии было принято тащить всё, что только можно вынести через чёрный ход.
даже магнитную ленту от накопителей, блин, чтобы на огороде помидоры подвязывать. а что, удобно, под весом куста она не рвётся. последнюю бобину, которая уже рассыпаться начала, я только несколько лет назад выбросил...
именно!
проблемы с производством на сложных техпроцессах были в основном от общего разгильдяйства и низкой производственной культуры.
и ещё так совпало, что резкое усложнение техпроцессов выпало на постбрежневские/предперестроечные времена, когда общая мотивация личного состава ИТР была уже ниже всякого плинтуса.
и документацию, и само железо получали вполне по-шпионски, через подставные фирмы в третьих странах. из фрг через гдр, из японии через таиланд и вьетнам.
под конец перестройки смогли даже 286-й интел сэмулировать (100% клон так и не вышло сделать), но процент выхода годных чипов на тонких техпроцессах был такой поганый, что стоили они как крыло от самолёта.
ну, в совке ведь целые НИИ занимались реверсингом и копипиздингом западных образцов. у меня мать почти десяток лет проработала программистом в такой шарашке, занимавшейся как раз копированием всякой вычислительной техники. со схемотехникой и софтом проблем не было, но вот с кремнием, который в 80-х стал переходить на всё более тонкие техпроцессы — ещё какие.
Аналитика — это не моя область экспертизы. Я делаю инструменты для автоматизации работы аналитиков, но не занимаюсь ею сам. И описываемый проект покрывает только ETL процессы, но не более того.
Впрочем, если выдать мне white paper с описанием алгоритма расчёта какой-то метрики, я могу покумекать, и чё-нить имплементировать. Правда, имплементация будет на жабе. А чтобы вытащить её в уровень DSL, нужная серьёзная работа по генерализации задачи.
Это что-то из рубрики «ненормальное программирование»? Не, у нас в этот раз рубрика другая.
Схема нигде не описывается, так как её нет. В первом же требовании — we're flying schema-less.
Если на что-то надо ссылаться, имена указываются ad hoc. Если не надо, то и имена не нужны. Тем более типы.
Таблиц, кстати, тоже нет. Есть наборы данных, они объектные. Об этом тоже прямо говорится много раз.