Спасибо огромное за такую обширную статью про Camel, где чётко описаны его плюсы-минусы и особенности. Прям реклама получилась :)
Ну и дебаты... Ох уж эта мантра, чтоб "аналитики" и проды сами без разработчика могли сделать то, что им нужно. Если б бабушка была дедушкой и т. д. и т. п. А тут ещё и ИИ подоспел! В том-то весь и фокус, что все находятся на своём месте и такова природа вещей. И основная проблемы не в том, что аналитик не знает пары дополнительных шагов, а в том, что он мыслит по-другому. Его логика может сильно отличаться от вашей. Да, хороший аналитик должен быть связующим звеном между бизнесом и исполнителя и, но он оперирует другими категориям - кубиками.
Мы участвовали в одном крупном проекте, где одна из идей была возможность через UI настраивать мэппинг простому пользователю. UI был сделан и продукт в проде много лет. Но основная проблема была выявлена через 3 года активной разработки и использования - обычные люди мыслят нелогично! И их нужно этому учить
Одна из основных проблем фронтэнда не в количестве, а качестве пакетов, точнее его отсутствии. Намедни, собрали реакт проект из стабильных библиотек: 8 критических ошибок по секьюрити, 14 с высоким приоритетом, 9 со средним и 73 с низким. Естественно никто такое не пропустит и начинается поиск костылей и переделок. И это помимо исправлений типа "я художник, я так вижу". Сколько было проектов: бэк взяли шаблон проекта на Spring Boot, добавили что нужно - пару недель максимум. На одном проекте фронтари побили все рекорды. 3 месяца договаривались о библиотеках и структуре проекта.
А основная проблема фронта - низкая квалификация. Почему-то считается, что фронт писать легче, поэтому никаких паттернов знать не обязательно. Смотришь на сам реакт и плакать хочется от этой дичи. Да, на нем тоже можно писать нормально, но если нет понимания правильной композиции, то и выходит нечто, т.к. сам инструмент не дисциплинирует. А потом те несколько состояний кнопки, конечно, превращаются в проблему. А drug n drop вообще вызывает параллельный мир.
Аж итересно было узнать чем же этот новый Spec Driven Development отличается от лампового дизайна по требованиям, которого все гнобили в угоду аджайлу. Но так ничего и не показали.
Я такое наблюдал в одной толстой мировой компании. Они реально 18 месяцев не могли прийти к единому мнению, т.к. всем было удобно ничего не делать, а главное не брать на себя ответственность. Слили нам и давай расказывать как нужно делать (при том без дизайна, на пальцах), ревью с пристрастием и покрытием тестами 100%. И все нужно за месяц. На вопрос "почему тогда сами не сделали" обиделись. В результате вылелось в месяцев 9.
Сам переводил базы в одном крупном международном банке и большой ретэйл корпорации. Не скажу, что с пол пинка, т.к. Postres всегда шел заменой Oracle, а не MSSQL. T-SQL приходится адаптировать, точность данных в MSSQL ниже, казалось бы не страшно, но находятся умельцы, которые и к этому привязываются. С нагрузками никаких проблем нет, но нужно тюнить начиная с операционки или использовать готовый облачный БД сервис.
Windows NT - это содранная почти полностью IBM OS/2. И учитывая, что мама Гейтса была в совете директоров IBM это не удивительно.
В OS/2 реальное микро ядро, которое могло полностью загружать все, что нужно по сетке. Тогда как NT до такого уровня так и доросла и нужна была полная инсталляция.
Неужели никого не смущает выбор S3 (бинарного хранилища общего назначения) в качестве аналитического хранилища? Оно ж само по себе не предназначено для этого. Конечно, потом наворачивается вся эта лабуда, изобретаются велосипеды с квадратными колесами и потаемся выжать из железа максимум. Да, беда. Опыт предыдущих поколений фф топку!
Просто диву даешься как можно было собрать все грабли построения базы данных в одном флаконе! Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании. А то потом героически преодолеваем трудности, хотя их могло и не быть изначально выбери другой подход.
весь наш ETL изначально жил внутри SQL-движка
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый. Значительно удобней вынести в отдельные сервисы и не грузить саму базу.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
В следующей статье серии мы подробнее поговорим о сторидже и о том, как объектное хранилище из фонового компонента архитектуры превратилось в один из ключевых факторов, определяющих ограничения, проблемы и инженерные решения Lakehouse-платформы.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Как-то не дает покое ощущение, по описанию, что DWH и весь процесс ETL построен неоптимально или Vertica используется некорректно, поэтому и присутствуют все проблемы. Например, говорится о таблицах с сотнями колонок, но у column-based баз, как Vertica, нет таких таблиц физически. Там хранилище организовано по-другому. Или например, низкая скорость вставки. Да, если вставлять по одной записи скорость будет относительно низкая, причем, и в реляционной базе тоже, т.к. перестройка индексов занимает львиную долю времени и чем больше индексов (колонок, измерений), тем больше времени.
Еще смущает такое количество витрин. Какие критерии используются: по отраслям, направлениям и т.д.? Похоже как агрегация производится "в лоб". Если такое количество нужно постоянно переиндексировать, то рано или поздно любая база не справится.
Вот реально, только расслабился и опять по новой! Только отвык руками иксы конфигурить с кучей настроек и держать отдельные профайлы, а тут с другого бока засада :(
Спасибо, что поправили. Неудачно попытался избежать узкого термина. Конечно, в рамках партиции, т.к. в рамках группы (в терминах Кафки) не может быть очередности в силу природы топика
К сожалению, считается, что ИТ - это молодая и уникальная область. И этот миф культивируется уже который десяток лет, что позволяет иметь постоянный заработок. 99% автоматизируемых задач просто копирует человеческое поведение и решение, чаще всего не инженерное и не оптимальное, а в лоб. Даже ребят с инженерных специальностей и прикладным опытом это быстро расхолаживает.
Наверное, единственная вменяемая статья за все годы существования Аджаил. Обычно все сводится к "Вы неправильно его готовите, мы сейчас вам все расскажем и Фсё будет Аджаил!" И он наступает, полный Аджаил! Чаще всего сталкиваешься с тем, что нет ни готовности ни желания ни понимания, да и необходимости, т.к. проблема в другом, но обещали это поможет.
У вас 48 ядер. Количество активных запросов - ~1000 (я на MySQL видел 24 ядра и 4,5+ тыс активных запросов, обнулили кэши nginx на нагруженном проекте, как же давно это было!). У вас в подобной ситуации запросы за процессорные такты будут драться, а не за блокировки.
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.
Читаешь, прям как о нашем проекте. К сожалению, манагеры везде одинаковые 😀
Спасибо огромное за такую обширную статью про Camel, где чётко описаны его плюсы-минусы и особенности. Прям реклама получилась :)
Ну и дебаты... Ох уж эта мантра, чтоб "аналитики" и проды сами без разработчика могли сделать то, что им нужно. Если б бабушка была дедушкой и т. д. и т. п. А тут ещё и ИИ подоспел! В том-то весь и фокус, что все находятся на своём месте и такова природа вещей. И основная проблемы не в том, что аналитик не знает пары дополнительных шагов, а в том, что он мыслит по-другому. Его логика может сильно отличаться от вашей. Да, хороший аналитик должен быть связующим звеном между бизнесом и исполнителя и, но он оперирует другими категориям - кубиками.
Мы участвовали в одном крупном проекте, где одна из идей была возможность через UI настраивать мэппинг простому пользователю. UI был сделан и продукт в проде много лет. Но основная проблема была выявлена через 3 года активной разработки и использования - обычные люди мыслят нелогично! И их нужно этому учить
Одна из основных проблем фронтэнда не в количестве, а качестве пакетов, точнее его отсутствии. Намедни, собрали реакт проект из стабильных библиотек: 8 критических ошибок по секьюрити, 14 с высоким приоритетом, 9 со средним и 73 с низким. Естественно никто такое не пропустит и начинается поиск костылей и переделок. И это помимо исправлений типа "я художник, я так вижу". Сколько было проектов: бэк взяли шаблон проекта на Spring Boot, добавили что нужно - пару недель максимум. На одном проекте фронтари побили все рекорды. 3 месяца договаривались о библиотеках и структуре проекта.
А основная проблема фронта - низкая квалификация. Почему-то считается, что фронт писать легче, поэтому никаких паттернов знать не обязательно. Смотришь на сам реакт и плакать хочется от этой дичи. Да, на нем тоже можно писать нормально, но если нет понимания правильной композиции, то и выходит нечто, т.к. сам инструмент не дисциплинирует. А потом те несколько состояний кнопки, конечно, превращаются в проблему. А drug n drop вообще вызывает параллельный мир.
Аж итересно было узнать чем же этот новый Spec Driven Development отличается от лампового дизайна по требованиям, которого все гнобили в угоду аджайлу. Но так ничего и не показали.
Я такое наблюдал в одной толстой мировой компании. Они реально 18 месяцев не могли прийти к единому мнению, т.к. всем было удобно ничего не делать, а главное не брать на себя ответственность. Слили нам и давай расказывать как нужно делать (при том без дизайна, на пальцах), ревью с пристрастием и покрытием тестами 100%. И все нужно за месяц. На вопрос "почему тогда сами не сделали" обиделись. В результате вылелось в месяцев 9.
А можно по-подробней? У меня, наоборот, уменьшение ресурсов. Какая версия Оракла и Слона, операционка и т.п.?
Сам переводил базы в одном крупном международном банке и большой ретэйл корпорации. Не скажу, что с пол пинка, т.к. Postres всегда шел заменой Oracle, а не MSSQL. T-SQL приходится адаптировать, точность данных в MSSQL ниже, казалось бы не страшно, но находятся умельцы, которые и к этому привязываются. С нагрузками никаких проблем нет, но нужно тюнить начиная с операционки или использовать готовый облачный БД сервис.
Сейчас линуховый драйвер отличный для старых Canon сканеров, только Wifi, вроде, не поддерживает.
Windows NT - это содранная почти полностью IBM OS/2. И учитывая, что мама Гейтса была в совете директоров IBM это не удивительно.
В OS/2 реальное микро ядро, которое могло полностью загружать все, что нужно по сетке. Тогда как NT до такого уровня так и доросла и нужна была полная инсталляция.
К сожалению, как никто не мог в одной строчке поток обработать корректно с регулярками кроме перла, так и не может.
Да, появились новые и расширились старые утилиты, но все равно какие-то свои особенности в синтаксисе регулярок
Неужели никого не смущает выбор S3 (бинарного хранилища общего назначения) в качестве аналитического хранилища? Оно ж само по себе не предназначено для этого. Конечно, потом наворачивается вся эта лабуда, изобретаются велосипеды с квадратными колесами и потаемся выжать из железа максимум. Да, беда. Опыт предыдущих поколений фф топку!
Просто диву даешься как можно было собрать все грабли построения базы данных в одном флаконе! Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании. А то потом героически преодолеваем трудности, хотя их могло и не быть изначально выбери другой подход.
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый. Значительно удобней вынести в отдельные сервисы и не грузить саму базу.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Как-то не дает покое ощущение, по описанию, что DWH и весь процесс ETL построен неоптимально или Vertica используется некорректно, поэтому и присутствуют все проблемы. Например, говорится о таблицах с сотнями колонок, но у column-based баз, как Vertica, нет таких таблиц физически. Там хранилище организовано по-другому. Или например, низкая скорость вставки. Да, если вставлять по одной записи скорость будет относительно низкая, причем, и в реляционной базе тоже, т.к. перестройка индексов занимает львиную долю времени и чем больше индексов (колонок, измерений), тем больше времени.
Еще смущает такое количество витрин. Какие критерии используются: по отраслям, направлениям и т.д.? Похоже как агрегация производится "в лоб". Если такое количество нужно постоянно переиндексировать, то рано или поздно любая база не справится.
Может в другой части раскроите больше деталей?
Вот реально, только расслабился и опять по новой! Только отвык руками иксы конфигурить с кучей настроек и держать отдельные профайлы, а тут с другого бока засада :(
Спасибо за статью и готовое решение для стресс-тестирования. Очень важно, что база работает, но очень медленно. Хорошая эмуляция!
Спасибо, что поправили. Неудачно попытался избежать узкого термина. Конечно, в рамках партиции, т.к. в рамках группы (в терминах Кафки) не может быть очередности в силу природы топика
В рамках группы она была всегда.
К сожалению, считается, что ИТ - это молодая и уникальная область. И этот миф культивируется уже который десяток лет, что позволяет иметь постоянный заработок. 99% автоматизируемых задач просто копирует человеческое поведение и решение, чаще всего не инженерное и не оптимальное, а в лоб. Даже ребят с инженерных специальностей и прикладным опытом это быстро расхолаживает.
Наверное, единственная вменяемая статья за все годы существования Аджаил. Обычно все сводится к "Вы неправильно его готовите, мы сейчас вам все расскажем и Фсё будет Аджаил!" И он наступает, полный Аджаил! Чаще всего сталкиваешься с тем, что нет ни готовности ни желания ни понимания, да и необходимости, т.к. проблема в другом, но обещали это поможет.
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.