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

[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-ев большой напряг.