Pull to refresh
51
0
Alexey Evdokimov @PastorGL

Software engineer. Practicioner, not a theorist.

Я такое делал. Более того, вот в этой статье 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М сочетаний) потянет.

Какой-то странный у автора взгляд. SQL != RDBMS уж тыщу лет как, и даже NoSQL хранилища мутировали в NewSQL.


Эх, жаль оригинал за пэйволом, а то б неплохо было потыкать его на предмет а чё ж он сказать-то хотел.

эк вас жёстко триггернуло. спокойнее надо быть.


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


проблема была системная.


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


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

да ладно бы золото.


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


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

именно!


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


и ещё так совпало, что резкое усложнение техпроцессов выпало на постбрежневские/предперестроечные времена, когда общая мотивация личного состава ИТР была уже ниже всякого плинтуса.

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


под конец перестройки смогли даже 286-й интел сэмулировать (100% клон так и не вышло сделать), но процент выхода годных чипов на тонких техпроцессах был такой поганый, что стоили они как крыло от самолёта.

ну, в совке ведь целые НИИ занимались реверсингом и копипиздингом западных образцов. у меня мать почти десяток лет проработала программистом в такой шарашке, занимавшейся как раз копированием всякой вычислительной техники. со схемотехникой и софтом проблем не было, но вот с кремнием, который в 80-х стал переходить на всё более тонкие техпроцессы — ещё какие.

Аналитика — это не моя область экспертизы. Я делаю инструменты для автоматизации работы аналитиков, но не занимаюсь ею сам. И описываемый проект покрывает только ETL процессы, но не более того.


Впрочем, если выдать мне white paper с описанием алгоритма расчёта какой-то метрики, я могу покумекать, и чё-нить имплементировать. Правда, имплементация будет на жабе. А чтобы вытащить её в уровень DSL, нужная серьёзная работа по генерализации задачи.

Это что-то из рубрики «ненормальное программирование»? Не, у нас в этот раз рубрика другая.

Information

Rating
3,500-th
Location
Ижевск, Удмуртия, Россия
Registered
Activity

Specialization

Specialist
Lead