в бы в дата саентисты пошел, пусть меня научат

[АццкоМото]

Ну вот, а ты говоришь что я ничего не знаю.
Я сейчас за столом сижу на дне рождения и рюмки налиты. Извиняйте, изчезаю из эфира.

Ну, про облака и капельки - что-то из уроков природоведения осталось, да.

ЗЫ. Рюмки наполнены, пойло разлито. Что такое "рюмки налиты" - хз. Это из серии гуманитарной логики.

[Физик-Лирик]

Я сейчас за столом сижу на дне рождения и рюмки налиты. Извиняйте, изчезаю из эфира.

Судя по всему день рождения автоматически перешел в проводы старго года и встречу нового. Когда ожидать встречи в эфире?

Тем не менее, всех с Новым Годом!!!

А завтра снова на работу ...

[zVlad]

Я сейчас за столом сижу на дне рождения и рюмки налиты. Извиняйте, изчезаю из эфира.

Судя по всему день рождения автоматически перешел в проводы старго года и встречу нового. Когда ожидать встречи в эфире?

Тем не менее, всех с Новым Годом!!!

А завтра снова на работу ...

С Новым Годом! Я в эфире уже давно, но тема, наверное, исчерпала себя уже. Сколько не сотрясай воздух вещи будут идти своим чередом и будут забываться и снова изобретаться в ИТ новые способы получения своей доли общего пирога от экономики. Причем не трудно догадаться что чем менее еффективные технологии применять, чем больше находить причин для переделок уже работающего, тем больше будет эта доля пирога. Поэтому реально эффективные технологии (mainframe) будут предаваться забвению в первую очередь и с наибольшей энергией.

P.S. Это, кстати, даже IBM уже делает - отворачивается от mainframe фактически. Их используют только там где другие подходы настолько далеки от удовлетворения требованиям что альтернативой быть не могут.

[iDesperado]

люди, не уподобляйтесь zVlad и его примитивными познаниями протухшими в 70х. фишка клауда не в виртуалках, виртуалки были и до эпохи клауда. да, я могу в амазоне заказать тучу виртуалок и развернуть клоудеровский бигдата кластер, но новизны тут не будет. шаг вперед это SaaS, т.е. у меня нет моих виртуалок, за которыми я должен следить, патчить и мониторить. я запускаю job (spark job например), где и на каких контитентах, 100 нод или 1000 нод будет задействовано мне даже не сообщают. вот это шаг вперед, а виртуалки любой хостинг выдать может.

[zVlad]

Статья в Википедии про SaaS первый абзац раздела "History" вот такой:

Centralized hosting of business applications dates back to the 1960s. Starting in that decade, IBM and other mainframe providers conducted a service bureau business, often referred to as time-sharing or utility computing. Such services included offering computing power and database storage to banks and other large organizations from their worldwide data centers.

Вы, iDesperado, остаетесь верны себе - упорно защищаете концепсии являющиеся реинкарнациями давно существовавших в практике компьютеров.
Я охотно с Вами соглашусь, тем не менее, что виртуальные машины в клаудах не есть главное. О том же толкует уважаемый АццкоМото.
Я объясню почему это так. Потому что серверов и софта которые бы тянули значимые количества виртуалок не существует. Поэтому используется схема автоматического распределения нагрузки на физические сервера, которых много и они не супермощные - блэйды.
Поэтому даже для среднего уровня работ задействуются десятки, сотни нодов, входящих в кластеры, и есть софт способный этим муравейником управлять. Все это называют клауд.
А есть сервера на которых могут сотни виртуалок выполняться притом что для выполнения высокой нагрузки на надо объединять виртуалки в кластера, одиночные виртуалки могут быть достаточно мощны, поскольку под ними большие мощности имеются, чтобы справиться без кластеризации с большой нагрузкой. Это тоже клауд, только вертикально масштабируемый в отличии от Вашего - горизонтального.
Но можно обойтись и без виртуалок и без кластеров на блэйдах. Это тоже будет в современной терминологии клауд. Основой такого клауда может быть zOS, предоставляющий SaaS.

[zVlad]

Немножко пооффтоплю с вашего разрешения. Сегодня гостей не было, читал историю отечественной компьютеризации. К концу 50х, начале 60х наши (школа С.А. Лебедева) создали систему ПРО (систем А) где использовались самые мощные в мире компьютеры - М-40 и противоракеты сбивали баллистические ракеты. На основе этой школы мы могли вырваться вперед, но тормознулись на копировании IBM S/360, S/370.
Проблема была в том что самые крупные и талантливые специалисты были задействованы на секретной военной тематике, а в программу ЕС ЭВМ (несколько лет решался вопрос о том на какой основе ее реализовывать и Лебедев был против копирования) попали спецы менее квалифицированные и опытные. Вот мы и приплыли туда куда приплыли.
Вот пример:
http://www.computer-museum.ru/histussr/5e26.htm

Начало 60х, восьми-машинный комплекс:

http://www.famhist.ru/famhist/sprn/0024105d.htm

[iDesperado]

Вы, iDesperado, остаетесь верны себе - упорно защищаете концепсии являющиеся реинкарнациями давно существовавших в практике компьютеров.

Влад, ну не тебе, путающему ядро с процессором и плавающем в SQL рассуждать об инкорнациях. по факту ничего похожего на амазоновский S3 раньше не было. все всегда было централизованно и управлялось единым центром, тут же (в S3) нет никаких виртуалок и ровно противоположная идеология. как и у блочейна. единого центра нет, есть чудовищная избыточность хранения и эта избыточность позволяет масштабировать и избавиться от единого центра.
можно изображать дурачка и искать недостатки но то что идеология куда движется клауд противоположна МФ и zOS факт железобетонный. раньше софт строили по идеологии центра и оптимизации хранения, теперь сумашедшая избыточность хранения и отсутствия центра. некой предтечей этого подхода можно вспомнить репликации субд, но и там красой нитью везде проходила оптимизация. а zOS это смешно, там даже кластера нет, то что есть лишь иммитация. та же db2/zOS кластерезуется через parallel sysplex - железке где живет единая область памяти с блокировками. это не кластер, это все та же централиозованная система с централизованной байдой.

[zVlad]

Вы, iDesperado, остаетесь верны себе - упорно защищаете концепсии являющиеся реинкарнациями давно существовавших в практике компьютеров.

Влад, ну не тебе, путающему ядро с процессором и плавающем в SQL рассуждать об инкорнациях. по факту ничего похожего на амазоновский S3 раньше не было. все всегда было централизованно и управлялось единым центром, тут же (в S3) нет никаких виртуалок и ровно противоположная идеология. как и у блочейна. единого центра нет, есть чудовищная избыточность хранения и эта избыточность позволяет масштабировать и избавиться от единого центра.
можно изображать дурачка и искать недостатки но то что идеология куда движется клауд противоположна МФ и zOS факт железобетонный. раньше софт строили по идеологии центра и оптимизации хранения, теперь сумашедшая избыточность хранения и отсутствия центра. некой предтечей этого подхода можно вспомнить репликации субд, но и там красой нитью везде проходила оптимизация. а zOS это смешно, там даже кластера нет, то что есть лишь иммитация. та же db2/zOS кластерезуется через parallel sysplex - железке где живет единая область памяти с блокировками. это не кластер, это все та же централиозованная система с централизованной байдой.

Давай ка я тебя, по давней дружбе и хорошему настроению, немного подучу.

1.Избыточность и масштабирование это две разные вещи удовлетворяющие двум разным целям. Избыточность вообще не имеет отношения к масштабированию. Даже наоборот, избыточность заставляет масштабироваться энергичнее чем без нее.

2. Идеология клауд - это максимальное абстрагирование от структурной и технической имплементации различных видов сервисов - не только software, как ты считаешь. Под эту идеологию можно любую платформу подогнать и среди этих любых mainframe, zVM и (особенно) zOS наилучшие хотя бы потому что на них клауд делаться начал еще в 70-е годы. Наилучшие не только потому что давно, но и потому что для них специального ПО (S3, blockchain, hadoop) практически не нужно - все есть в стандартной комплектации.

3. Решения цнтаризованных по сути задач оптимально только на централизованных платформах. Такие как ты, неучи, знающие только то что может работать через распределенность уродуетесь через дурную избыточность (есть еще нормальная избыточность, но ты о ней не знаешь) чтобы заткнуть те множество дыр, которыми истыкана распределенная архитектура.

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

Главная твоя беда уважаемый (все таки уважаемый, несмотря на твое постоянное xамство), iDesperado, это то что ты в упор не понимаешь что даже если ты все разбросал на много узлов и если это представляет собой нечто единое целое, то ты все равно будешь вынужден решать проблему поддержания целостности с помощью ли "централизованной байды" или с помощию постоянного обмена изменениями и их синхронизации, или хранения всей информации на каждом узле (blockchain). В S3 тоже есть нечто центральное. Может помнишь обсуждали проблему с когда они сервер/репозиторий S3 перезапускали и это взяло очень много времени в течении которого все лежало? Если мы говорим о клауд используя одно слово в единственном числе то и там есть некий центальный управляющий элемент к которому все пользователи клауд обращаются когда им нужно что-нибудь поменять/добавить/убавить в конфигурации своей "капли". Должна быть также возможность отслеживать что все "капли" в наличии и "вода" в них не закончилась. Это все о централизованном управлении.
Но ты этого, похоже, никогда не поймешь.

[iDesperado]

любому другому я бы посоветовал что нибудь почитать, прежде чем нести чепуху, но в твоем случае Влад это бесполезно. я даже уверен, что ты уже что-то лихорадочно пытался прочесть, но мы знаем, это бесполезно.
реально в S3 и прочих сервисах нет ничего центрального, а уродливо и смешно выглядит человек которому я недавно объяснял, что такое sql plan, но рассуждающий об архитектуре.
МФ никогда не пытались масштабироваться за счет избычточности хранения и децентрализации вычислений, все это сравнительно новые веяния именно эпохи клауда, и в контексте этого спора не важна цена и элегантность. а МФ, МФ мертв и IBM уже давно строит свои бигдата облака на хадупах и x86 серверах, понимая что zOS не конкурент и может масштабироваться до потребностей времени.

[fruit6]

- Почему списали ваш МФ?
- Потому что он самый эффективный!

[zVlad]

.
реально в S3 и прочих сервисах нет ничего центрального ...

Что ж тогда там недавно привело к outage? В результате ошибки оператора. Объясни если сам хоть что-то понял из той истории с Амазон что мы обсуждали где-то весной. Я тебе намекал повспоминать, мог бы и перечетать тот топик. Но ты видно как тогда ничего не понял так и сейчас не можешь.

[iDesperado]

Что ж тогда там недавно привело к outage? В результате ошибки оператора. Объясни если сам хоть что-то понял из той истории с Амазон что мы обсуждали где-то весной. Я тебе намекал повспоминать, мог бы и перечетать тот топик. Но ты видно как тогда ничего не понял так и сейчас не можешь.

вот обсуждение
viewtopic.php?f=2&t=207099
вот официальное заявление
https://aws.amazon.com/message/41926/

никаких намеков на какую-либо централизацию ни там, ни там нет. наоборот в официальном заявлении четко и ясно

S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact.

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

что произошло всем кроме тебя ясно. оператор вырубил сервера билинг подсистемы, получая ошибки с билинг подсистемы остановились связанные с ним еще две подсистемы от S3. аварийная остановка index subsystem потребовала вызова креш рекаваери процедуры на многие петабайты, перед возвращеним сервиса в нормальное состояние. валидация индексов заняло больше время, чем все могли представить.

[Easbayguy]

Что ж тогда там недавно привело к outage? В результате ошибки оператора. Объясни если сам хоть что-то понял из той истории с Амазон что мы обсуждали где-то весной. Я тебе намекал повспоминать, мог бы и перечетать тот топик. Но ты видно как тогда ничего не понял так и сейчас не можешь.

вот обсуждение
viewtopic.php?f=2&t=207099
вот официальное заявление
https://aws.amazon.com/message/41926/

никаких намеков на какую-либо централизацию ни там, ни там нет. наоборот в официальном заявлении четко и ясно

S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact.

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

что произошло всем кроме тебя ясно. оператор вырубил сервера билинг подсистемы, получая ошибки с билинг подсистемы остановились связанные с ним еще две подсистемы от S3. аварийная остановка index subsystem потребовала вызова креш рекаваери процедуры на многие петабайты, перед возвращеним сервиса в нормальное состояние. валидация индексов заняло больше время, чем все могли представить.

У нас в четвертом квартале в самый пик, пришлось два раза 80% траффика перенаправлять обратно в датацентр из Amazona на пару самых напряженных недель. Network laterncy внутри знаменитого клауда ложили site на раз два. Инженеры/саппорт Амазоновские чесали репу.

[zVlad]

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

что произошло всем кроме тебя ясно. оператор вырубил сервера билинг подсистемы, получая ошибки с билинг подсистемы остановились связанные с ним еще две подсистемы от S3. аварийная остановка index subsystem потребовала вызова креш рекаваери процедуры на многие петабайты, перед возвращеним сервиса в нормальное состояние. валидация индексов заняло больше время, чем все могли представить.

Кроме index subsystem вырубилась также placement subsystem (whatever it is). И из-за этих двух подсистем вся s3 региона была недоступна 11 часов. Подчеркиваю для тебя специально слово вся. Т.е. не какое-то количество узлов пользователей, с которыми как раз все было в порядке и с ними можно было бы работать, а весь регион со многоими приложениям и сервисами были недоступны. Недоступны из-за аварии двух подсистем. Вот эти то подсистемы и есть то что делает всю s3 по сути (а не по тому что тебе или кому другому хочется или не хочется) централизованной. Хуже того, этот важный центр оказался и без дизастер рековери и без файловер планов (иначе работа s3 была бы востановленна либо так либо по другому) и Амазон тупо сидели и ждали пока эти две подсистемы не запустятся. А не запускались они долго потому что "Amazon hasn't fully restarted those systems in its larger regions for several years, and S3 has experienced massive growth in the intervening time. Rebooting those subsystems took longer than expected, which added to the length of the outage.".
Да, они могут потерять либую часть кластера и "продолжать работу", но если они теряют упомянутые выше две подсистемы то продолжать работу они не могут, что и есть указание на наличие центра, или если хотите single point of failure для которого у них нет ни redundency, ни failover ни disaster recovery.
Конечно они провели работу над ошибками: "The tool that was responsible for causing the outage has been modified to take down servers more slowly and to block operations that will take capacity below safety check levels. AWS is also evaluating its other tools to make sure they have similar safety systems in place." и снова в такую ситуацию по такой причине (ошибка оператора) они не попадут, но не исключено что по какой-нибудь другой причине попадут. Гарантии нет.
Этот пример наглядно показывает наличие в, я бы сказал, любой комплексной распределенной системе некоего центра управления (индексами в данном случае и placement-ами) недоступность которого приводит к недоступности всей системы в целом.
Это даже интуитивно понятно что без такого центра что-нибудь да работать в рапределенной системе либо не будет либо будет работать неприемлемо медленно (как в этом случае по всей видимости, коль скоро речь идет об индексации).
Такой центр должен быть и в хадупе потому что коль скоро большое пространство хранения создано из множества небольших хранилищ то где-то вся эта большая информация так или иначе организованная должна "собираться" и передаваться в установленном порядке тому кто ее запросил. Случай когда хадуп выдавал бы большой массив данных в произвольном порядке и/или частично (только то что смог или успел) я не расматриваю как не имеющий практического применения. Собственно вот : "In a larger cluster, HDFS nodes are managed through a dedicated NameNode server to host the file system index, and a secondary NameNode that can generate snapshots of the namenode's memory structures, thereby preventing file-system corruption and loss of data. Similarly, a standalone JobTracker server can manage job scheduling across nodes."

[iDesperado]

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

[zVlad]

Все ноды у Амазона не были зашатдауны. Не в этом вовсе была причина 11 часового простоя S3.
Твоя беда, в том числе, в том что ты ищешь аппаратное проявление "центра" и если такового нет то ты не видишь по сути дела централизованную архитектуру. Центр может быть как аппаратным так и программым. В данном случае ты прикрыл свою ж..пу неуместной ссылкой на webservices. Другое модное словечко, которое тебе нравится? Да хоть унитазом называй, но если без некоторой компоненты вся система недоступна это уже архитектура централизованная, сколько бы ты не повторял чур-меня, чур-меня.

[oshibka_residenta]

У нас в четвертом квартале в самый пик, пришлось два раза 80% траффика перенаправлять обратно в датацентр из Amazona на пару самых
напряженных недель. Network laterncy внутри знаменитого клауда ложили site на раз два. Инженеры/саппорт Амазоновские чесали репу.

маленькую latency никто не обещал. Latency - плата за reliability. Мы jump through hoops big time чтобы была маленькая latency и reliability. Периодически кто-то нибудь спрашивает: нельзя ли попроще? А нет, нельзя.

[Easbayguy]

У нас в четвертом квартале в самый пик, пришлось два раза 80% траффика перенаправлять обратно в датацентр из Amazona на пару самых
напряженных недель. Network laterncy внутри знаменитого клауда ложили site на раз два. Инженеры/саппорт Амазоновские чесали репу.

маленькую latency никто не обещал. Latency - плата за reliability. Мы jump through hoops big time чтобы была маленькая latency и reliability. Периодически кто-то нибудь спрашивает: нельзя ли попроще? А нет, нельзя.

На вашу не маленькую latency, накладываются наши знатоки микросервисов! Блин было небольшое количество middle tier серверов и пару баз, checkout занимал 3 секунды на все. Перевели в Amazon, накрутили по самое не могу, 30 секунд без нагрузки!

[oshibka_residenta]

У нас в четвертом квартале в самый пик, пришлось два раза 80% траффика перенаправлять обратно в датацентр из Amazona на пару самых
напряженных недель. Network laterncy внутри знаменитого клауда ложили site на раз два. Инженеры/саппорт Амазоновские чесали репу.

маленькую latency никто не обещал. Latency - плата за reliability. Мы jump through hoops big time чтобы была маленькая latency и reliability. Периодически кто-то нибудь спрашивает: нельзя ли попроще? А нет, нельзя.

На вашу не маленькую latency, накладываются наши знатоки микросервисов! Блин было небольшое количество middle tier серверов и пару баз, checkout занимал 3 секунды на все. Перевели в Amazon, накрутили по самое не могу, 30 секунд без нагрузки!

Это не наша latency. Я не в Amazone. Имел в виду, что вместо того, чтобы записывать в какой-нибудь distributed storage, мы пишем в локальный storage и потом делаем replication. В результате latency маленькая (за 30 секунд нам яйца оторвут) , но надо что-делать в случае если юзеры обращаются в другой датацентр до того, как replication завершится.

По поводу микросервисов - I feel your pain.

[zVlad]

У нас в четвертом квартале в самый пик, пришлось два раза 80% траффика перенаправлять обратно в датацентр из Amazona на пару самых
напряженных недель. Network laterncy внутри знаменитого клауда ложили site на раз два. Инженеры/саппорт Амазоновские чесали репу.

маленькую latency никто не обещал. Latency - плата за reliability. Мы jump through hoops big time чтобы была маленькая latency и reliability. Периодически кто-то нибудь спрашивает: нельзя ли попроще? А нет, нельзя.

На вашу не маленькую latency, накладываются наши знатоки микросервисов! Блин было небольшое количество middle tier серверов и пару баз, checkout занимал 3 секунды на все. Перевели в Amazon, накрутили по самое не могу, 30 секунд без нагрузки!

Это не наша latency. Я не в Amazone. Имел в виду, что вместо того, чтобы записывать в какой-нибудь distributed storage, мы пишем в локальный storage и потом делаем replication. В результате latency маленькая (за 30 секунд нам яйца оторвут) , но надо что-делать в случае если юзеры обращаются в другой датацентр до того, как replication завершится.

По поводу микросервисов - I feel your pain.

Шаманство какое. Пляски с бубном.

[Сабина]

https://dzone.com/articles/important-ma ... algorithms

[Сабина]

In this post I’d like to talk about some of the myths I’ve seen on various blogs, my reviews and other machine learning boards.

Let’s jump right in.

Myth: Machine learning engineers spend all day building deep learning and other kinds of machine learning models.

Reality: A recent Kaggle poll found that most machine learning is cleaning dirty day. Most respondents, regardless of their position (machine learning engineer, data scientist) said that 70% of their day involved massaging data into a shape it could be modeled.

Myth: You must know how deep learning models are designed to use them.

Reality: I’ve been driving for over 30 years and can’t tell you how an engine works. It’s the same in the machine learning space. The majority of data scientists and machine leaning engineers don’t author any kind of models. They use really well-designed frameworks that already exist. They use Keras on TensorFlow or SciKit-Learn.

Myth: You can get a job without any experience just be taking some online courses.

Reality: Online courses will show you the basics, the frameworks, modeling but the end to end machine learning process will take experience. If you aren’t in IT right now, take any position involving data. You can learn machine learning engineering while you are learning data manipulation.

Myth: I can get a job as a machine learning engineer if I know R.

Reality: Almost all applied machine learning is Python. A recent Kaggle poll showed that 80% of those working in the applied space use Python as their core language for model building and data wrangling.

Myth: You can participate in Kaggle and if you do well you’ll get a job.

Reality: Again, since most real-world machine learning is data wrangling you’ll need to know how to wrangle data before you get hired. Model building alone won’t get you a job.

Myth: The model is the most important aspect of machine learning process.

Reality: As Sift Science CTO Fred Sadaghiani puts it, “data is orders of magnitude more important than the algorithm you use or any technique that you’re applying.” In terms of data, think both quantity and quality. The more data you provide the system, the better results you’ll get. And providing the right data is equally (or even more) important.

Myth: The laptop I have is big enough to build real world models.

Reality: Laptops are great for learning machine learning and data science using toy data sets. There’s no laptop in the world that can run most real world deep learning models. These are run in a cloud or on large servers.

Myth: I need to be a math wizard to learn machine learning

Reality: You need a solid foundation in math, especially statistics and eventually linear algebra. You don’t need to have a master’s in computational mathematics to do this job.

[Мальчик-Одуванчик]

Myth: I need to be a math wizard to learn machine learning

Reality: You need a solid foundation in math, especially statistics and eventually linear algebra. You don’t need to have a master’s in computational mathematics to do this job.

То есть твердое знание тервера и статистики всё-таки требуется.
А вот с этим у бывших DBA-ев большой напряг.