до определенного объема схема всему голова, но когда объем подрастает такой подход становится жопой всему.
у нас на хадупе примерно такой подход опробовали. сначала «документы» хранили в habse, начало тормозить на сканах, переделали на развесистые avro объекты в parquet. теперь жопа. источников все больше, бизнес требует реалтаймы и джоины с новыми источниками на лету. аналитики требую полноценные таблицы, которые можно скармливать нормальным инструментам анализа, типа sas dataminer.
т.е. полная жопа в итоге.
странный бредогенератор. каждую строчку хочется оспорить. напоминает трындеж стариков на лавочке, что отнесли пенсии в МММ, а теперь рассуждает о дебилизации общества.
Выводя продукт на «рынок», вы выводите его «в люди». Делая коммерческое предложение корпорации, вы обращаетесь к конкретным людям.
что за далекая страна, где не видели тендера серьезной западной компании? влияние людей там сведено к нулю и делая предложение необходимо иметь набор бумажек, а не связи с людьми.
Подведем промежуточный итог. Люди – сущность практически неизменная. Успех связан, главным образом, с людьми. Деньги есть только у людей.
основные фин потоки устраивают роботы. их успех в скорости пинга, люди там вообще не причем.
Сравните современного менеджера, например, с даймё древней японской провинции. Ему служит клан с династиями самураев. Он знает про каждого своего подчиненного практически все. Многих самураев он видел, когда они еще пешком под стол ходили. Знает их отцов и дедов, с полным перечнем заслуг и неудач.
сомневаюсь, что он знал хотя бы 25% от того что знает о подчиненных типичный манагер, просматривая фейсбуки и инстаграммы. у москвичей мне кажется уже каждая съеденная тарелка выставлена в инстаграм.
Стриминг выступает ключевым компонентом BI-платформы ФАСТЕН РУС. Real-time данные используются командой дата анализа для построения оперативных отчетов.
глупый вопрос — а как с S3 данные оперативно в BI платформы попадают?
где бы послушать сбербанк и его рассказ как они построили ignite кластер на 2000 узлов и планировали заместить оракл. и собственно почему не получилось?
т.е. датасет на каждом узле кластера поднимает тучи параллельных воркеров в каждом свои копии моделей и вся обработка в параллель. при этом jpmml и данные в едином jvm процессе. нет оверхеда с копированием данных в соседний процесс или чего хуже на соседний сервер с парсингом json + rest.
но у вас с Дмитрием похоже другой юзкейс. вам надо не миллионы прожувать за минуты, а один один за миллисекунды. тут мне кажется спарк ничем не поможет особо.
там 3 часа видео, тяжко что-то выудить бегло. но если датасета не было, то видимо то был у вас один единственный процесс, который кормили. конечно так будет очень медленно. внутри датасета JPPML в нечто типа спарковой редюс функции превращается и кормит модель в параллель.
а вы как jppml запускали? как полагается, внутри спаркового датасета? а то я смотрю многие рисуют рест сервисы и долбят по рест, удивляясь чего так медленно.
скорее дилетантство сомневаться. спарк читает данные в jvm, что бы отдать интерпретатору питона придется каждый байт прокачать через не быстрый интерфейс, распарсить, превратить в объект. глупо сомневаться что этот бесполезный труд не затормозит процесс во многие разы.
что-то напрямую, что-то нет. но как минимум обратиться к поставщику напрямую вообще не проблема.
так что у вас в РФ в договоре. реально прописывают пункт о том что оборудование поставляется как есть и вы отказываетесь от каких-либо претензий в случае проблем?
чем крупнее компания, тем тяжелей понять чего там на самом деле. мы вот тоже типа удовлетворены fujutsu, потому, что решает на сколько я удовлетворен чудик из того лимузина. и от этой «удовлетворенности» зависит его бонус в $10 млн. со всеми вытекающими.
что касается суждений, то ваш инцидент показал всю цепочку и работу всех служб в совокупности. в вашем случае это вполне нормально делать выводы.
ну вот посмотрите на свой CloudY, процессы толком не выстроены — тестер сунул пользователя в шаблон виртуалки и это пошло все стадии проверок и ушло клиентам. когда пошли взломы квалификации супорта и безопастников не хватило, что бы понять в чем дело. поверьте, вы еще десяток лет будите отлаживать свои процедуры и растить кадры.
и не рассказывайте, что такой «сервис» под под определенную задачу.
лично я сравниваю компании по зрелости процессов. пока вижу что даже с возможностями гугла все печально.
у меня нормально с шансами. и недополученную прибыль отсудить шансы есть. в РФ может оно и по другому, но чуть западней с шансами все ок.
а все потому что поставщиком я не обязан подписывать отказ от подобных претензий.
так на поставщика оборудования я в суд могу подать с требованием компенсировать убытки, а облако требует согласиться, что в случае факапа компенсироваться будет лишь стоимость услуги. и что еще самое приятное, пока ты рассказываешь, этим накосячившим капают твои деньги за каждую строчку. супорт то за деньги. при этом сами они ничего не видят и не мониторят.
пару месяцев назад, например, Cloud4Y не увидел проблем, даже когда клиент прямо пожаловался на левак в виртуалках.
был. и пр этом с лучшими из лучших. вовлечен в проект с переездом в облако fujitsu. ~20k сотрудников, переезжают сотни серверов. все очень плохо. процессы толком не налажены даже по базовым вещам, типа регистрации пользователя в домене, бэкап или запись в днс.
так же поимел опыт с гуглом. их гугловый mysql полная хрень, человек на супорте толком не понимает что такое план запроса и ISAM структуру, не имеет никаких инструментов посмотреть на файлы и проблему. а общение с супортом — платное. т.е. у себя я бы проблем не знал, а тут я трачу свое время и деньги, что бы объяснить им как работает их же хрень.
и это лучшие из лучших. у вас еще десятилетия уйдут до их уровня.
ключевое тут то что бизнес в этой сделке рискует миллионами, сервис $5 за поездку. т.е. накосячив с одним клиентом, у сервиса трагедии не приключится. и они косячат…
конечно своя. ведь вы не пришлете полноценного водителя с такси, вы пришлете таджика, который разобьет со мной машину и я попаду в больницу. при этом вы не будете компенсировать расходы на операцию, лечение, реабилитацию. вы выплатите стоимость поездки. аж $5.
ога. особливо в российских реалиях, когда какое-нибудь облако развернет тебе с виртуалкой левого пользователя со слабым паролем и угробит к чертям весь бизнес. а потом «ответит» по закону — компенсировов стоимость копеешной вирталки.
конкурент дрэгону — легкий союз+прогресс, никак не тяжелая дельта. и конкурент доставляет для роскосмоса те самые 2.6 тонны за $50-60 млн, с наса роскосмос драл порядка $80 млн. $228 ничего не меняет т.к. нифига не конкурентоспособно на фоне технологии из 60х.
еще раз, дельта — тяжелая ракета, играет в другой лиге. спейсикс же толкается с легким союзом, доставляя 2.6 тонн груза на мкс.
деньги, людей, стартовые площадки у наса макс брал с обещанием дешевых пусков.
у нас на хадупе примерно такой подход опробовали. сначала «документы» хранили в habse, начало тормозить на сканах, переделали на развесистые avro объекты в parquet. теперь жопа. источников все больше, бизнес требует реалтаймы и джоины с новыми источниками на лету. аналитики требую полноценные таблицы, которые можно скармливать нормальным инструментам анализа, типа sas dataminer.
т.е. полная жопа в итоге.
что за далекая страна, где не видели тендера серьезной западной компании? влияние людей там сведено к нулю и делая предложение необходимо иметь набор бумажек, а не связи с людьми.
основные фин потоки устраивают роботы. их успех в скорости пинга, люди там вообще не причем.
сомневаюсь, что он знал хотя бы 25% от того что знает о подчиненных типичный манагер, просматривая фейсбуки и инстаграммы. у москвичей мне кажется уже каждая съеденная тарелка выставлена в инстаграм.
глупый вопрос — а как с S3 данные оперативно в BI платформы попадают?
А какой пинг нужен до облака для стрелялок?
т.е. датасет на каждом узле кластера поднимает тучи параллельных воркеров в каждом свои копии моделей и вся обработка в параллель. при этом jpmml и данные в едином jvm процессе. нет оверхеда с копированием данных в соседний процесс или чего хуже на соседний сервер с парсингом json + rest.
но у вас с Дмитрием похоже другой юзкейс. вам надо не миллионы прожувать за минуты, а один один за миллисекунды. тут мне кажется спарк ничем не поможет особо.
так что у вас в РФ в договоре. реально прописывают пункт о том что оборудование поставляется как есть и вы отказываетесь от каких-либо претензий в случае проблем?
что касается суждений, то ваш инцидент показал всю цепочку и работу всех служб в совокупности. в вашем случае это вполне нормально делать выводы.
и не рассказывайте, что такой «сервис» под под определенную задачу.
лично я сравниваю компании по зрелости процессов. пока вижу что даже с возможностями гугла все печально.
а все потому что поставщиком я не обязан подписывать отказ от подобных претензий.
пару месяцев назад, например, Cloud4Y не увидел проблем, даже когда клиент прямо пожаловался на левак в виртуалках.
так же поимел опыт с гуглом. их гугловый mysql полная хрень, человек на супорте толком не понимает что такое план запроса и ISAM структуру, не имеет никаких инструментов посмотреть на файлы и проблему. а общение с супортом — платное. т.е. у себя я бы проблем не знал, а тут я трачу свое время и деньги, что бы объяснить им как работает их же хрень.
и это лучшие из лучших. у вас еще десятилетия уйдут до их уровня.
еще раз, дельта — тяжелая ракета, играет в другой лиге. спейсикс же толкается с легким союзом, доставляя 2.6 тонн груза на мкс.
деньги, людей, стартовые площадки у наса макс брал с обещанием дешевых пусков.