Я бы внес поправку. "Пилить фичи для отчетности" == "пилить фичи для адекватного продуктового результата" в том случае, если вы работаете в компании с адекватным руководством, нацеленным на объективный результат в продуктиве. Если это условие не выполняется, то данное конкретное место работы необходимо срочно менять. Конечно, можно попытаться постучать в дверь менеджмента и попытаться объяснить, что нужно все изменить, но, как вы понимаете, это приведет к увольнению вашему, а не менеджмента. Проще уйти к адекватному работодателю самому, неадекватные сами покинут рынок со временем. Если вы действительно квалифицированный специалист, вас этот транзит не испугает.
Сегодня синьоры должны заниматься только организацией труда и передачей знаний, потому что их очень мало. Они смогут вернуться к своим обычным задачам, когда окажутся хотя бы в небольшом профиците.
Это путь к резкому падению уровня разработки в компании. Сеньоры должны прежде всего заниматься задачами их уровня сложности и приносить тем самым компании профит. Собственно, для этого они и нужны. Компании, особенно в текущих условиях в РФ (да, думаю, и везде по миру тоже самое), не могут ждать, когда сеньоры подготовят других сеньоров, потом сеньоров станет достаточно много, чтобы наконец-то вплотную занятся продуктовыми задачами. Компания разорится, если будет следовать подобной рекомендации!
Не-не. Кастомные парсеры просто так не пишут. Если автору статьи это было нужно, значит речь идет не о простой проекции диалектов один-в-один, а под конкретные наборы боевых задач фирмы, компонуя что-то более низкого уровня в несколько более высокий. Тут я с автором согласен - надо, значит, надо. Однако, не считаю такой подход универсальным и нужным для всех. Считаю функционал SparkSQL достаточно богатым, а если где-то чего-то не хватает, всегда можно его кастомно расширить добавив собственные функции, где это нужно. Но не целый парсер. Ну разве что, автору нужен был именно парсер - но это все же считаю узкоспециализированным и фирмоориентированным подходом. Кстати, вовсе не ругаю - безусловно интересный опыт и полезный в чем-то. Кому-то, может быть, именно такой расширенный подход будет и оптимален. Во всяком случае любопытно, и читать было интересно и полезно, хотя сам бы я не стал затрудняться, с моей колокольни это избыточная трата усилий.
Спасибо, почитал. Как и все предыдущие части материала. По-прежнему мне кажется, что реализация диалекта заточена под удобство реализации конкретного спектра задач. Я так понял, у вас есть достаточно обширный набор паттернов высокоуровневой обработки данных - стандартные DWH, витрины и прочее, специфическое для вашей фирмы, сильно повторяющиеся в разных задачах, только с разными входными данными? Очень хорошо, если для вашей фирмы это оптимально. У меня задачи очень широкие и обработка данных идет чуть не в каждой задаче нестандартно - ну вот такой у меня генеральный заказчик, он же мой работодатель. Каждая новая задача использует приемы из предыдущих задач разве что по-минимуму самые базовые - очень сложные и неповторяющие связи данных из источников разного типа, с постоянно переменными требованиями. У аналитиков, знаете ли, очень богатая фантазия, а мне эту фантазию нужно реализовать в код, да еще чтобы работал оптимально. И в принципе, я вижу в SparkSQL практически все функции, какие нам знакомы в любом движке DB, юнионы, джойны, оконные функции и так далее, только под капотом все работает несколько иначе, а иногда - совсем иначе. Ну да это все поэтическими словами о прозе жизни. А вопрос конкретно такой - вы сделали еще одну прослойку между базовыми сущностями Spark и потребителем. Даже если ее не делать - все время нужно следить за оптимальным выполнением, не всегда полагаясь на интеллект Catalyst (он не все умеет оптимизировать). Еще одна прослойка - она не маскирует ли дополнительно базовый слой абстракций Spark, заставляя изучить помимо еще одного API (это не самое сложное, я понимаю) еще один набор приемов оптимизации выполнение уже поверх вашей абстракции? Не усложнилась ли оптимизация выполнения? Или вы это как-то учли и выработали собственные приемы, работающие уже с вашими абстракциями? Если да - не могли бы вы написать еще одну-две части материала - продолжение с примерами, как оптимзировать выполнение поверх вашего движка? Мне кажется, что SparkSQL все же прост и понятен в достаточной степени. Конечно, мне приходится работать и со старыми кластерами, например, где Spark 2.3.2 - вот на них приходилось дописывать логику, которой не хватало. Но на Spark 3 и выше ее уже столько добавлено, что мне еще не попадалось задач, для которых мне не хватило функций на новых версиях.
Вопрос к автору. А не могли бы Вы пояснить ваши мотивы, почему понадобилось писать собственный движок? Вот мне обычно хватает типового Spark SQL (хотя, когда приходилось писать для кластера на устаревшем Spark 2, то многих удобных функций не хватало, например, для работы с полями-массивами, и я дописывал свои, замещающие те, что уже есть в Spark 3 или хотя бы в Spark 2.4.0). Я читал часть 1 и Ваши аргументы на эту тему в самом начале. И если я не ошибаюсь, то это делалось для особого рода аналитиков, которые "мы привыкли к этому диалекту SQL и хотим, чтобы у нас было все удобно и как нам хочется"? Не так? Мне кажется, тут дилемма - если аналитики так себе и не понимают базовый универсальный SQL и не могут разобраться в Spark SQL, то они все равно будут Вас теребить постоянно, чтобы вы помогли им составить запрос, какой бы диалект ни использовался, и какой бы инструмент умнейший Вы им ни написали бы, все равно это будет, вас не разгрузят от рутины. А если аналитики хорошие, да покажите им Spark SQL, и они сами все сделают. Что я понял не так?
– Да, но только водой, разложенной на составные элементы, – возразил Смит. – Вероятно, это будет делаться с помощью электричества, которое к тому времени будет мощной и легко используемой силой.
Дополнительно добавляю к этой цитате, чтобы показать насколько она вздорная. Зачем использовать электричество для производства водорода-посредника, чтобы потом сжигать его в двигателе для получения движущего усилия? Потери при производстве + потери при транспортировке + потери кпд в двигателе, одни потери! А не проще ли, если уж у вас достаточно этого самого электричества, сразу подать его на электродвигатель, кпд разных моделей которых может быть где-то между 90 и 100 %? Бизнес, кстати, это очень хорошо понимает, и предпочитает вкладываться более в разработку дешевых и емких электрических аккумуляторов, а не водородной инфраструктуры, опасной, ненадежной, переполненной потерями на всех этапах. А "водородная повестка" - это еще одна ура-компания безграмотных политиканов, не имеющих полноценных знаний по этой теме. Получение водорода из воды для его последующего сжигания в двс - это бред! Убыточное предприятие! Единственно, где можно это использовать - это направления, где эта убыточность не так важна, как другие плюсы - например, в ракетостроении. Но и там технологичнее и безопаснее создавать метановые ракеты, чем водородные.
Минусы технологии. Почему она не получила массового распространения
А почему почти нигде мы не встречаем в такого рода статьях упоминание об очень высокой диффузии водорода в металлах и сплавах? А именно - даже из идеально запаянного или заваренного металлического сосуда водород достаточно быстро просачивается в атмосферу прямо сквозь сами металлические стенки. Поверьте мне, это большая проблема. Когда-то на заре студенчества я работал лаборантом в лаборатории, которая как раз этим и занималась в УПИ (теперь это УГТУ в Екатеринбурге), кое-что припоминаю на эту тему. Никто не хочет обсудить: 1) высокие потери при хранении и транспортировке и, соответственно 2) загрязнение атмосферы чистым водородом в случае начала его массового применения вследствие этих утечек? Неужели эту проблему уже кто-то решил? Что-то не встречал нигде упоминаний об этом. Если не решили, то водородная энергетика экономически абсолютно необоснованна и экологически не менее опасна, чем углеродная, просто это будут опасности другого рода. Так и подмывает спросить: а не затеяли ли политики очередную ненаучную аферу?
Тьюринг также обнаружил первую неразрешимую проблему в программировании — проблему остановки. Он выяснил, что написать программу, которая может проверить правильность другой программы, в общем случае нельзя. В каких-то ограниченных случаях можно, а в общем — нет.
Упс! Немного не в тему статьи, но раз уж упоминается этот прискорбный эпизод, то стоило также упомянуть, что проблему остановки Тьюринг рассматривал, насколько мне известно, в рамках собственной вычислительной модели. А в других моделях? Ставлю математикам новую "теорему тысячелетия" - докажите, что существует неограниченное количество вычислительных моделей (назовем их независимымыми парадигмами), не сводимых к модели Тьюринга. Вторичная теорема - докажите, что в таких моделях неизбежно существуют задачи, неразрешимые в одной модели, но успешно разрешимые в альтернативной. Подсказка - для первой теоремы давно найдены частные решения, но не общее (см. сверхтьюринговые вычисления). Следовательно, вторая теорема может быть верна, хотя общего решения тоже нет, насколько мне известно. Хотя в частных случаях ее верность также очевидна, пример - в квантовых вычислениях существуют решения задач, в принципе неразрешимых в неквантовых. Но это так, к слову, тем кому интересно.
Как дополнение, могу привести "самое простое объяснение" - зачем это делать. Представьте себе, что длинный квантовый алгоритм - это такой черный ящик, внутри которого черт-те-что происходит, но для нас важен набор данных, подаваемых на вход ящика, и набор данных, получаемых не его выходе. (Кстати, это применимо к любым вообще физическим структурам, квантовым, неквантовым, цифровым, аналоговым и прочим компьютерам, и так далее). Понимание того, что происходит внутри ящика дает нам возможность предсказать поведение ящика и использовать его на практике с полезной целью. На самом деле, в мире достаточно специалистов, хорошо умеющих моделировать такие "черные ящики" для квантовых систем. Главная проблема реализации квантовых компьютеров не в поиске и подборе оптимальных алгоритмов - в конце концов, это может сделать даже правильно написанное программное обеспечение. Проблема в том, как правильно загрузить данные и извлечь их из квантового компьютера, не нарушив его работоспособность и не внеся шумовых искажений. С теорией квантовых вычислений проблем нет, есть проблемы с реализациями - работа для инженеров-физиков, программисты без проблем подключатся, когда будет готова база.
И действительно бита достаточно для существования целой Вселенной.
Действительные числа не проецируются на натуральные, масса других видов математематических объектов - "чисел" не проецируются даже на действительные числа, а тем более не проецируются на натуральные. А автор желает всю Вселенную свести к 1 и 0, м-да... поневоле вспоминается анекдот: "Садись, Вовочка, а не то ты мне всю божью науку к х... сведешь"
Вот человечество удивиться-то, когда, наконец, обнаружит, что как раз писателей и композиторов и прочие свободные творческие профессии ИИ заменить сможет легко, а математиков, физиков, программистов и ученых - нет (исключая рутинные алгоритмизируемые задачи)
Вы полагаете, что за 10е30 лет человечество (если оно выживет на гораздо более ранних этапах эволюции) все еще будет зависет от протонов, нейтронов, вообще каких-то элементарных частиц? Развиваясь, цивилизации меняют не только места обитания, но многократно могут искусственно поменять собственную природу. Например, перенести свои сознания на уровень каких-то пока еще нам неизвестных стабильных субмикроскопичиских вакуумных структур, в какую-нибудь структурированную вакуумную пену. И то, что пока что нам кажется бесполезной пустотой, станет для них беспредельной насыщенной жизнью средой обитания. И плевать людям будущего будет и на звезды, и на черные дыры, и на любые элементарные частицы - они будут жить и развиваться на ином уровне бытия. Или не будут. Или не люди. Или даже не наши потомки, а потомки какой-то другой более удачливой и менее агрессивной космической расы разумных, умудрившейся не ухайдакать свою цивилизацию из-за каких-то там нескольких миллиардов баррелей горючей жидкости или газа или "права" одних групп людей управлять жизнью всех остальных.
Поэтому с точки зрения сознания Вигнера лаборатория со всем её содержимым, а также весь окружающий мир, находится в суперпозиции, пока Друг не сообщит ему о результате измерения.
а если друг пытается измерить, жив сам Вигнер или нет, а затем пытается ему сообщить, что он жив? Если Вигнер жив, то друг может сообщить это сознанию Вигнера, и таким образом сознание Вигнера узнает, что он жив. А если Вигнер не жив, то друг уже не может сообщить его сознанию, что он не жив, и таким образом, измерение состояния "не жив" никогда не может быть передано сознанию Вигнера, и сознание Вигнера никогда не может перейти в состояние "не жив" со всей определенностью, что бы под этим не понималось. В итоге - сознание Вигнера никогда не может быть убито никаким способом в Мультивселенной :) Равно как и любого из нас - ergo, наши сознания бессмертны, они просто путешествуют по тем линиям реализации событий в Мультивселенной, вдоль которых наши сознания никогда не умирают сами для себя :)
Судя по текущей политико‑экономической ситуации, расти рынок IT в ближайшие несколько лет однозначно не будет.
Хотя в целом с тезисами статьи согласен, некоторые детали вызвали у меня сомнение. Возможно, автор сознательно вставил в текст несколько сомнительных высказываний просто для того, чтобы было больше реакции на них? Не знаю. В цитате - как раз один из таких сомнительных тезисов. Я бы разделил прогноз на две части - положительную и отрицательную, и реализуются в реальности в скором времени оба сценария параллельно-одновременно. Положительный стрим: 1) будет расти объем и глубина серьезных проектов у серьезных бизнесов, прежде всего в области big data и высококачественного data science (хотя автор их вроде как поругивает) - в том числе в России и прежде всего в России, как бы ее ни ругали (просто потому, что идет мощный процесс "как бы выкрутиться из сложившейся ситуации", то есть именно сейчас тот самый "жареный петух клюнул нас в мягкое место", и нужно реагировать - российский ИТ сектор как раз и реагирует, мы вообще здесь максимально реализуемся, когда у нас начинает подпекать, но раз уж подпекло - только держись, развитие непременно будет!), 2) будет расти и очень быстро и значительно спрос на очень квалифицированных специалистов, в том числе и на узких специалистов-экспертов в какой-то области, как бы ни хвалили пресловутых T-shape специалистов. Отрицательный стрим - вот как раз для низкокачественного бизнеса, финансово неустойчивого (например, я считаю, что рынок мелкого и среднего online retail в РФ заметно перенасыщен плохо работающими и плохо ИТ-оснащенными компаниями, накопившимися у нас за "жирные годы развития экономики", когда можно было работать тяп-ляп и тем не менее оставаться на плаву) - вот этот слабый бизнес будет тонуть, и поэтому слабые и средненькие специалисты будут страдать, для них рынок ИТ действительно будет падать, поскольку именно такого рода слабый и средненький бизнес "пылесосил" их, так как скиллов у подобных специалистов вполне хватало, что обслуживать такого рода бизнес. У тех из средних специалистов, у кого остался запас энергии и решимости перешагнуть через себя и подтянуться до действительно хорошего уровня, чрезмерно тяжелых проблем не будет. У закосневших и не желающих развиваться - будут, и очень большие проблемы. Таким образом, ИТ рынок сейчас раздваивается - для стоящих специалистов он растет и будет расти долго и беспредельно, для слабых - резко падает и падать будет глубоко и долго. Но с точки зрения финансов - в России сейчас идут существенно, на порядки более мощные вливания финансов в ИТ, причем именно с хорошим контролем за результатом, а не просто "на распил", как это бывало раньше. И это не возможно не увидеть даже безо всякого инсайда, просто из открытых источников. Пускай жизнь заставила это делать вынужденно, после мощнейших "пинков от реальности" в виде всяких санкций и прочего - но процесс действительно пошел, и только слепой или ангажированный противоположной точкой зрения человек может этого не замечать. Как ни странно, полагаю, что за пределами РФ идет тот же процесс "очищения ИТ бизнеса от накопившегося неэффективного мусора", хотя характер трудностей там обусловлен несколько другими причинами, но это отдельная тема для обсуждения, останавливаться на ней не стану. В целом все как всегда в истории человечества - чем сложнее обстоятельства в какой-то сфере, тем быстрее эта сфера развивается и прогрессирует.
Можно по большей части кодить на Spark, а можно «эскуэлить». Вот мы из Spark взяли что-то из Kafka, положили в ClickHouse, и там что-то «повертели» SQL’ем.
В большинстве случаев это ненужно и громоздко, "эскуэлить" можно и в самом Spark, например, см. createTempView, createOrTemplateTempView, да и вообще, весь SparkSQL в целом - если у вас уже есть бэкграунд в DB, вы достаточно легко в нем разберетесь. Например, тяжелые вычисления из БД выносим в Spark (в том числе, например, можно пользоваться union, join, window functions и т.п. "отражениями" возможностей SQL в самом Spark), а в DB возвращаем результаты только в тех случаях, когда возможностей самого Spark, чтобы сделать какие-то очень продвинутые дашборды вам не хватает, а ваша DB поддерживает их.
Все, что здесь описано, совершенно замечательно - в рамках старой парадигмы. Давайте, создадим/найдем новые антибиотики, к которым не будет резистентности. Но наш враг - очень маленький, и работает фактически, как этакий коллективный биологический супербыстрый компьютер, устилая погибшими телами нерезистентных собратьев путь тем, кто смог выжить - и возникают новые штаммы, резистентные уже к новым антибиотикам. И так далее - "эта музыка будет вечной, если я заменю батарейку". У этих мелкопакостных врагов огромное преимущество перед антибиотиками - они быстро приспосабливаются. И чтобы переломить тенденцию, нужен именно прорыв, а не бесконечно повторение старых попыток использовать природные механизмы, те же самые, с которых начинался самый первый пенициллин. Нужны нанороботы, которые могут 1) подключаться к библиотеке с базой данных всяких вредоносных гадов - бактерий ли, вирусов ли, еще кого-то 2) уметь сверяться с этой БД и распознавать врага 3) уметь уничтожать врага лицом к лицу чем-то таким, чему биологические сущности противостоять в принципе не могут - импульсом какого-то излучения на наноуровне, сфокусированном на "вражине", механическими наноманипуляторами, разрушающими его безжалостно, чем-то еще неизбежным, как коса в руках мифической старухи. Вот тогда никакой вредоносный биологический микроскопический агент в принципе не сумеет этому противостоять и не сможет приспособиться. Да-да, я говорю именно об искусственном иммунитете - быстром, фатальном, неотвратимом, приспособленном к любым видам старых и новых, еще неизвестных вредителей. Вот это действительно будет прорыв, так прорыв. А пока что то, что вы описали - это еще одна, пусть даже очень неплохая отсрочка перед следующим циклом приспособления-преодоления-борьбы. Работать будет, но только временно.
В целом очень толковая статья. Но есть одна тонкость - поразмыслив тщательно, попавший под эту проблему сотрудник достаточно быстро сообразит, что гораздо проще вместо задушевных бесед с руководством о повышении зарплаты, которая "не в рынке" для старых сотрудников, принять офер от альтернативной компании, не хуже текущей, но чтобы платила "в рынке". То есть - вместо того, чтобы "стучаться лбом в стену, набивать шишек, портить себе нервы и выгорать" - "оседлать коня и воспользоваться ситуацией в свою пользу". Интересно, существуют ли вообще компании, которые, осознав эту проблему, сумели ее переломить на 100% и полностью перестроили политику удержания персонала, сделав ее такой, какой она и должна быть?
А информатика и программирование кажутся более лёгкими для освоения, чем биология, химия, физика или рисование (это, кстати, действительно так).
Ну что тут можно сказать - статью писал менеджер не из числа тех, кто когда-то сам был разработчиком, вероятно? Или кто-то еще, решивший, что вся наша профессия исчерпывается выражениями if-else? Мдаааа.... особенно позабавил финал фразы в кавычках. Рекомендую автору взять программу обучения хотя бы не топового, а просто среднего ИТ вузовского курса, вытащить из нее ИТ предметы для разработчика, далее вытащить ну хотя бы списки литературы для этих предметов, а потом попробовать по диагонали полистать литературку пусть даже выборочно. Как, головушка еще не опухла, или уже пошел взрыв мозга? ))) Не надо торопиться делать поспешные заявления, поспешишь - людей насмешишь.
Я бы внес поправку. "Пилить фичи для отчетности" == "пилить фичи для адекватного продуктового результата" в том случае, если вы работаете в компании с адекватным руководством, нацеленным на объективный результат в продуктиве. Если это условие не выполняется, то данное конкретное место работы необходимо срочно менять. Конечно, можно попытаться постучать в дверь менеджмента и попытаться объяснить, что нужно все изменить, но, как вы понимаете, это приведет к увольнению вашему, а не менеджмента. Проще уйти к адекватному работодателю самому, неадекватные сами покинут рынок со временем. Если вы действительно квалифицированный специалист, вас этот транзит не испугает.
Это путь к резкому падению уровня разработки в компании. Сеньоры должны прежде всего заниматься задачами их уровня сложности и приносить тем самым компании профит. Собственно, для этого они и нужны. Компании, особенно в текущих условиях в РФ (да, думаю, и везде по миру тоже самое), не могут ждать, когда сеньоры подготовят других сеньоров, потом сеньоров станет достаточно много, чтобы наконец-то вплотную занятся продуктовыми задачами. Компания разорится, если будет следовать подобной рекомендации!
Не-не. Кастомные парсеры просто так не пишут. Если автору статьи это было нужно, значит речь идет не о простой проекции диалектов один-в-один, а под конкретные наборы боевых задач фирмы, компонуя что-то более низкого уровня в несколько более высокий. Тут я с автором согласен - надо, значит, надо. Однако, не считаю такой подход универсальным и нужным для всех. Считаю функционал SparkSQL достаточно богатым, а если где-то чего-то не хватает, всегда можно его кастомно расширить добавив собственные функции, где это нужно. Но не целый парсер. Ну разве что, автору нужен был именно парсер - но это все же считаю узкоспециализированным и фирмоориентированным подходом. Кстати, вовсе не ругаю - безусловно интересный опыт и полезный в чем-то. Кому-то, может быть, именно такой расширенный подход будет и оптимален. Во всяком случае любопытно, и читать было интересно и полезно, хотя сам бы я не стал затрудняться, с моей колокольни это избыточная трата усилий.
Спасибо, почитал. Как и все предыдущие части материала. По-прежнему мне кажется, что реализация диалекта заточена под удобство реализации конкретного спектра задач. Я так понял, у вас есть достаточно обширный набор паттернов высокоуровневой обработки данных - стандартные DWH, витрины и прочее, специфическое для вашей фирмы, сильно повторяющиеся в разных задачах, только с разными входными данными? Очень хорошо, если для вашей фирмы это оптимально. У меня задачи очень широкие и обработка данных идет чуть не в каждой задаче нестандартно - ну вот такой у меня генеральный заказчик, он же мой работодатель. Каждая новая задача использует приемы из предыдущих задач разве что по-минимуму самые базовые - очень сложные и неповторяющие связи данных из источников разного типа, с постоянно переменными требованиями. У аналитиков, знаете ли, очень богатая фантазия, а мне эту фантазию нужно реализовать в код, да еще чтобы работал оптимально. И в принципе, я вижу в SparkSQL практически все функции, какие нам знакомы в любом движке DB, юнионы, джойны, оконные функции и так далее, только под капотом все работает несколько иначе, а иногда - совсем иначе. Ну да это все поэтическими словами о прозе жизни. А вопрос конкретно такой - вы сделали еще одну прослойку между базовыми сущностями Spark и потребителем. Даже если ее не делать - все время нужно следить за оптимальным выполнением, не всегда полагаясь на интеллект Catalyst (он не все умеет оптимизировать). Еще одна прослойка - она не маскирует ли дополнительно базовый слой абстракций Spark, заставляя изучить помимо еще одного API (это не самое сложное, я понимаю) еще один набор приемов оптимизации выполнение уже поверх вашей абстракции? Не усложнилась ли оптимизация выполнения? Или вы это как-то учли и выработали собственные приемы, работающие уже с вашими абстракциями? Если да - не могли бы вы написать еще одну-две части материала - продолжение с примерами, как оптимзировать выполнение поверх вашего движка? Мне кажется, что SparkSQL все же прост и понятен в достаточной степени. Конечно, мне приходится работать и со старыми кластерами, например, где Spark 2.3.2 - вот на них приходилось дописывать логику, которой не хватало. Но на Spark 3 и выше ее уже столько добавлено, что мне еще не попадалось задач, для которых мне не хватило функций на новых версиях.
Вопрос к автору. А не могли бы Вы пояснить ваши мотивы, почему понадобилось писать собственный движок? Вот мне обычно хватает типового Spark SQL (хотя, когда приходилось писать для кластера на устаревшем Spark 2, то многих удобных функций не хватало, например, для работы с полями-массивами, и я дописывал свои, замещающие те, что уже есть в Spark 3 или хотя бы в Spark 2.4.0). Я читал часть 1 и Ваши аргументы на эту тему в самом начале. И если я не ошибаюсь, то это делалось для особого рода аналитиков, которые "мы привыкли к этому диалекту SQL и хотим, чтобы у нас было все удобно и как нам хочется"? Не так? Мне кажется, тут дилемма - если аналитики так себе и не понимают базовый универсальный SQL и не могут разобраться в Spark SQL, то они все равно будут Вас теребить постоянно, чтобы вы помогли им составить запрос, какой бы диалект ни использовался, и какой бы инструмент умнейший Вы им ни написали бы, все равно это будет, вас не разгрузят от рутины. А если аналитики хорошие, да покажите им Spark SQL, и они сами все сделают. Что я понял не так?
Дополнительно добавляю к этой цитате, чтобы показать насколько она вздорная. Зачем использовать электричество для производства водорода-посредника, чтобы потом сжигать его в двигателе для получения движущего усилия? Потери при производстве + потери при транспортировке + потери кпд в двигателе, одни потери! А не проще ли, если уж у вас достаточно этого самого электричества, сразу подать его на электродвигатель, кпд разных моделей которых может быть где-то между 90 и 100 %? Бизнес, кстати, это очень хорошо понимает, и предпочитает вкладываться более в разработку дешевых и емких электрических аккумуляторов, а не водородной инфраструктуры, опасной, ненадежной, переполненной потерями на всех этапах. А "водородная повестка" - это еще одна ура-компания безграмотных политиканов, не имеющих полноценных знаний по этой теме. Получение водорода из воды для его последующего сжигания в двс - это бред! Убыточное предприятие! Единственно, где можно это использовать - это направления, где эта убыточность не так важна, как другие плюсы - например, в ракетостроении. Но и там технологичнее и безопаснее создавать метановые ракеты, чем водородные.
https://12factor.net/ru/
А почему почти нигде мы не встречаем в такого рода статьях упоминание об очень высокой диффузии водорода в металлах и сплавах? А именно - даже из идеально запаянного или заваренного металлического сосуда водород достаточно быстро просачивается в атмосферу прямо сквозь сами металлические стенки. Поверьте мне, это большая проблема. Когда-то на заре студенчества я работал лаборантом в лаборатории, которая как раз этим и занималась в УПИ (теперь это УГТУ в Екатеринбурге), кое-что припоминаю на эту тему. Никто не хочет обсудить: 1) высокие потери при хранении и транспортировке и, соответственно 2) загрязнение атмосферы чистым водородом в случае начала его массового применения вследствие этих утечек? Неужели эту проблему уже кто-то решил? Что-то не встречал нигде упоминаний об этом. Если не решили, то водородная энергетика экономически абсолютно необоснованна и экологически не менее опасна, чем углеродная, просто это будут опасности другого рода. Так и подмывает спросить: а не затеяли ли политики очередную ненаучную аферу?
Упс! Немного не в тему статьи, но раз уж упоминается этот прискорбный эпизод, то стоило также упомянуть, что проблему остановки Тьюринг рассматривал, насколько мне известно, в рамках собственной вычислительной модели. А в других моделях? Ставлю математикам новую "теорему тысячелетия" - докажите, что существует неограниченное количество вычислительных моделей (назовем их независимымыми парадигмами), не сводимых к модели Тьюринга. Вторичная теорема - докажите, что в таких моделях неизбежно существуют задачи, неразрешимые в одной модели, но успешно разрешимые в альтернативной. Подсказка - для первой теоремы давно найдены частные решения, но не общее (см. сверхтьюринговые вычисления). Следовательно, вторая теорема может быть верна, хотя общего решения тоже нет, насколько мне известно. Хотя в частных случаях ее верность также очевидна, пример - в квантовых вычислениях существуют решения задач, в принципе неразрешимых в неквантовых. Но это так, к слову, тем кому интересно.
Как дополнение, могу привести "самое простое объяснение" - зачем это делать. Представьте себе, что длинный квантовый алгоритм - это такой черный ящик, внутри которого черт-те-что происходит, но для нас важен набор данных, подаваемых на вход ящика, и набор данных, получаемых не его выходе. (Кстати, это применимо к любым вообще физическим структурам, квантовым, неквантовым, цифровым, аналоговым и прочим компьютерам, и так далее). Понимание того, что происходит внутри ящика дает нам возможность предсказать поведение ящика и использовать его на практике с полезной целью. На самом деле, в мире достаточно специалистов, хорошо умеющих моделировать такие "черные ящики" для квантовых систем. Главная проблема реализации квантовых компьютеров не в поиске и подборе оптимальных алгоритмов - в конце концов, это может сделать даже правильно написанное программное обеспечение. Проблема в том, как правильно загрузить данные и извлечь их из квантового компьютера, не нарушив его работоспособность и не внеся шумовых искажений. С теорией квантовых вычислений проблем нет, есть проблемы с реализациями - работа для инженеров-физиков, программисты без проблем подключатся, когда будет готова база.
Действительные числа не проецируются на натуральные, масса других видов математематических объектов - "чисел" не проецируются даже на действительные числа, а тем более не проецируются на натуральные. А автор желает всю Вселенную свести к 1 и 0, м-да... поневоле вспоминается анекдот: "Садись, Вовочка, а не то ты мне всю божью науку к х... сведешь"
Вот человечество удивиться-то, когда, наконец, обнаружит, что как раз писателей и композиторов и прочие свободные творческие профессии ИИ заменить сможет легко, а математиков, физиков, программистов и ученых - нет (исключая рутинные алгоритмизируемые задачи)
Вы полагаете, что за 10е30 лет человечество (если оно выживет на гораздо более ранних этапах эволюции) все еще будет зависет от протонов, нейтронов, вообще каких-то элементарных частиц? Развиваясь, цивилизации меняют не только места обитания, но многократно могут искусственно поменять собственную природу. Например, перенести свои сознания на уровень каких-то пока еще нам неизвестных стабильных субмикроскопичиских вакуумных структур, в какую-нибудь структурированную вакуумную пену. И то, что пока что нам кажется бесполезной пустотой, станет для них беспредельной насыщенной жизнью средой обитания. И плевать людям будущего будет и на звезды, и на черные дыры, и на любые элементарные частицы - они будут жить и развиваться на ином уровне бытия. Или не будут. Или не люди. Или даже не наши потомки, а потомки какой-то другой более удачливой и менее агрессивной космической расы разумных, умудрившейся не ухайдакать свою цивилизацию из-за каких-то там нескольких миллиардов баррелей горючей жидкости или газа или "права" одних групп людей управлять жизнью всех остальных.
а если друг пытается измерить, жив сам Вигнер или нет, а затем пытается ему сообщить, что он жив? Если Вигнер жив, то друг может сообщить это сознанию Вигнера, и таким образом сознание Вигнера узнает, что он жив. А если Вигнер не жив, то друг уже не может сообщить его сознанию, что он не жив, и таким образом, измерение состояния "не жив" никогда не может быть передано сознанию Вигнера, и сознание Вигнера никогда не может перейти в состояние "не жив" со всей определенностью, что бы под этим не понималось. В итоге - сознание Вигнера никогда не может быть убито никаким способом в Мультивселенной :) Равно как и любого из нас - ergo, наши сознания бессмертны, они просто путешествуют по тем линиям реализации событий в Мультивселенной, вдоль которых наши сознания никогда не умирают сами для себя :)
Хотя в целом с тезисами статьи согласен, некоторые детали вызвали у меня сомнение. Возможно, автор сознательно вставил в текст несколько сомнительных высказываний просто для того, чтобы было больше реакции на них? Не знаю. В цитате - как раз один из таких сомнительных тезисов. Я бы разделил прогноз на две части - положительную и отрицательную, и реализуются в реальности в скором времени оба сценария параллельно-одновременно. Положительный стрим: 1) будет расти объем и глубина серьезных проектов у серьезных бизнесов, прежде всего в области big data и высококачественного data science (хотя автор их вроде как поругивает) - в том числе в России и прежде всего в России, как бы ее ни ругали (просто потому, что идет мощный процесс "как бы выкрутиться из сложившейся ситуации", то есть именно сейчас тот самый "жареный петух клюнул нас в мягкое место", и нужно реагировать - российский ИТ сектор как раз и реагирует, мы вообще здесь максимально реализуемся, когда у нас начинает подпекать, но раз уж подпекло - только держись, развитие непременно будет!), 2) будет расти и очень быстро и значительно спрос на очень квалифицированных специалистов, в том числе и на узких специалистов-экспертов в какой-то области, как бы ни хвалили пресловутых T-shape специалистов. Отрицательный стрим - вот как раз для низкокачественного бизнеса, финансово неустойчивого (например, я считаю, что рынок мелкого и среднего online retail в РФ заметно перенасыщен плохо работающими и плохо ИТ-оснащенными компаниями, накопившимися у нас за "жирные годы развития экономики", когда можно было работать тяп-ляп и тем не менее оставаться на плаву) - вот этот слабый бизнес будет тонуть, и поэтому слабые и средненькие специалисты будут страдать, для них рынок ИТ действительно будет падать, поскольку именно такого рода слабый и средненький бизнес "пылесосил" их, так как скиллов у подобных специалистов вполне хватало, что обслуживать такого рода бизнес. У тех из средних специалистов, у кого остался запас энергии и решимости перешагнуть через себя и подтянуться до действительно хорошего уровня, чрезмерно тяжелых проблем не будет. У закосневших и не желающих развиваться - будут, и очень большие проблемы. Таким образом, ИТ рынок сейчас раздваивается - для стоящих специалистов он растет и будет расти долго и беспредельно, для слабых - резко падает и падать будет глубоко и долго. Но с точки зрения финансов - в России сейчас идут существенно, на порядки более мощные вливания финансов в ИТ, причем именно с хорошим контролем за результатом, а не просто "на распил", как это бывало раньше. И это не возможно не увидеть даже безо всякого инсайда, просто из открытых источников. Пускай жизнь заставила это делать вынужденно, после мощнейших "пинков от реальности" в виде всяких санкций и прочего - но процесс действительно пошел, и только слепой или ангажированный противоположной точкой зрения человек может этого не замечать. Как ни странно, полагаю, что за пределами РФ идет тот же процесс "очищения ИТ бизнеса от накопившегося неэффективного мусора", хотя характер трудностей там обусловлен несколько другими причинами, но это отдельная тема для обсуждения, останавливаться на ней не стану. В целом все как всегда в истории человечества - чем сложнее обстоятельства в какой-то сфере, тем быстрее эта сфера развивается и прогрессирует.
В большинстве случаев это ненужно и громоздко, "эскуэлить" можно и в самом Spark, например, см. createTempView, createOrTemplateTempView, да и вообще, весь SparkSQL в целом - если у вас уже есть бэкграунд в DB, вы достаточно легко в нем разберетесь. Например, тяжелые вычисления из БД выносим в Spark (в том числе, например, можно пользоваться union, join, window functions и т.п. "отражениями" возможностей SQL в самом Spark), а в DB возвращаем результаты только в тех случаях, когда возможностей самого Spark, чтобы сделать какие-то очень продвинутые дашборды вам не хватает, а ваша DB поддерживает их.
Его продают в обычных аптеках без рецепта. Подтверждаю - сам лечился им.
Все, что здесь описано, совершенно замечательно - в рамках старой парадигмы. Давайте, создадим/найдем новые антибиотики, к которым не будет резистентности. Но наш враг - очень маленький, и работает фактически, как этакий коллективный биологический супербыстрый компьютер, устилая погибшими телами нерезистентных собратьев путь тем, кто смог выжить - и возникают новые штаммы, резистентные уже к новым антибиотикам. И так далее - "эта музыка будет вечной, если я заменю батарейку". У этих мелкопакостных врагов огромное преимущество перед антибиотиками - они быстро приспосабливаются. И чтобы переломить тенденцию, нужен именно прорыв, а не бесконечно повторение старых попыток использовать природные механизмы, те же самые, с которых начинался самый первый пенициллин. Нужны нанороботы, которые могут 1) подключаться к библиотеке с базой данных всяких вредоносных гадов - бактерий ли, вирусов ли, еще кого-то 2) уметь сверяться с этой БД и распознавать врага 3) уметь уничтожать врага лицом к лицу чем-то таким, чему биологические сущности противостоять в принципе не могут - импульсом какого-то излучения на наноуровне, сфокусированном на "вражине", механическими наноманипуляторами, разрушающими его безжалостно, чем-то еще неизбежным, как коса в руках мифической старухи. Вот тогда никакой вредоносный биологический микроскопический агент в принципе не сумеет этому противостоять и не сможет приспособиться. Да-да, я говорю именно об искусственном иммунитете - быстром, фатальном, неотвратимом, приспособленном к любым видам старых и новых, еще неизвестных вредителей. Вот это действительно будет прорыв, так прорыв. А пока что то, что вы описали - это еще одна, пусть даже очень неплохая отсрочка перед следующим циклом приспособления-преодоления-борьбы. Работать будет, но только временно.
В целом очень толковая статья. Но есть одна тонкость - поразмыслив тщательно, попавший под эту проблему сотрудник достаточно быстро сообразит, что гораздо проще вместо задушевных бесед с руководством о повышении зарплаты, которая "не в рынке" для старых сотрудников, принять офер от альтернативной компании, не хуже текущей, но чтобы платила "в рынке". То есть - вместо того, чтобы "стучаться лбом в стену, набивать шишек, портить себе нервы и выгорать" - "оседлать коня и воспользоваться ситуацией в свою пользу". Интересно, существуют ли вообще компании, которые, осознав эту проблему, сумели ее переломить на 100% и полностью перестроили политику удержания персонала, сделав ее такой, какой она и должна быть?
Ну что тут можно сказать - статью писал менеджер не из числа тех, кто когда-то сам был разработчиком, вероятно? Или кто-то еще, решивший, что вся наша профессия исчерпывается выражениями if-else? Мдаааа.... особенно позабавил финал фразы в кавычках. Рекомендую автору взять программу обучения хотя бы не топового, а просто среднего ИТ вузовского курса, вытащить из нее ИТ предметы для разработчика, далее вытащить ну хотя бы списки литературы для этих предметов, а потом попробовать по диагонали полистать литературку пусть даже выборочно. Как, головушка еще не опухла, или уже пошел взрыв мозга? ))) Не надо торопиться делать поспешные заявления, поспешишь - людей насмешишь.