Покопался в Lakehouse RT поглубже и … скорее разочарование от контраста обещаний со сцены и реальности. Писал у себя в линкедине недавно… А ваше мнение - ?
Отдельный вопрос по качеству работы рекрутеров: ожидание ответов от них по две недели, холодные сообщения даже без предварительного просмотра профиля кандидата (то есть предлагают совершенно нерелевантные позиции)… что интересно, даже когда такое холодное сообщение мне кажется интересно, и я оперативно на него отвечаю, то получаю реакцию все равно через неделю а то и больше. И если это были бы единичные случаи, ничего бы не говорил. Но таких – процентов 80
Специалистов, которые нам нужны, попросту не хватает. Дефицит по стране — около 1.5 млн человек по оценке АСИ.
Согласен с пред комментатором. “У нас дефицит высококвалифицированной низкооплачиваемой рабочей силы”:))) Сам за последний год несколько раз сталкивался, когда мне писали в личку с предложением работы (хотя я её не ищу), предлагая B2B контракт на сумму, которую я сейчас имею в найме (поясню – при B2B контракте сумма должна быть как минимум в полтора раза выше найма, мои личные подсчеты с учётом всех отпусков, потенциальных больничных, соц пакета, рабочего оборудования и рисков, а также накладных расходов, вообще показывают коэффициент 1.9). Или другой случай из первых уст – компании был нужен высококвалифицированный специалист уровня архитектор на технологию, которые очень редка в России сейчас. Решили искать среди релокантов, но при этом зарплату предлагали даже ниже чем в России – стратегия поиска строилась на том, что кандидату, сидящему в условной Грузии или подобных странах будет деваться некуда, и он согласится.
Хороший обзор. Кроме того созвучен с моими мыслями.
Вообще заметил, что последнее время (в последние годы) ДатаБрикс очень сильно вкладывается в маркетинг, при этом оставляет достаточно много гапов в текущем функционале. И отдельно стоит выделить просто гигантские маркетинговые попытки пересадить всех на свои вендор лок фреймворки
… Но на реальныо больших объемах, вы тоже предлагаете все посчитать силами SQL?
Что вы имеете в виду под “посчитать силами SQL”? SQL - это ЯЗЫК, а считает - ДВИЖОК. В вашем же примере ДБТ - это фреймворк который просто снижает накладные расходы (плюс ещё фишки) и упрощает работу с SQL и может потом этот SQL отравлять на разные execution engine. Или вы не понимаете то, что сами спроектировали?)
Сам факт того, что бизнес впустил государство в свою учетную систему говорит о высоком уровне доверия.
Вот тут насмешили)))) Это не доверие, это “предложение от которого нельзя отказаться”. Делал проект по налоговыму мониторингу для крупной (очень крупной) организации когда его ещё пилотировали…
Потому что просторы интернета завалены говно-статьями с пересказом документации и прочих банальностей и нейрослопом от индусов, которые очень активно начали писать в последние несоклько лет. Даже знаю из первых рук зачем - качание собственного бренда, а иногда даже получение визы таланта США (реально знаю несколько кейсов). Ценность этих статей - ноль. Зато шум создают…
Spark — движок для распределённой обработки данных и трансформаций.
dbt — тоже про трансформации данных, только декларативно через SQL.
ClickHouse — аналитическая СУБД, которая сама умеет выполнять довольно тяжёлые трансформации.
В итоге возникает вопрос: где именно должна жить бизнес-логика? Через год никто не понимает, где искать ошибку.
Ну и подерживать такой зоопарк накладно. Все эти компоненты имеют разные модели эксплуатации: зависимости, мониторинг, деплой, права доступа, CI/CD и т.п.
У вас про это в обосновании не написано. Кроме того, обоснование апеллирует к невалидному утверждению.
Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект. Явный овер инжениринг. При этом обоснование его необходимости не приведено (но не спорю, что иногда оно может быть)
В целом согласен, но все же поправлю: Bronze это Stage, а ODS - это Operational Data Store - то есть силы для получения операционной отчётности(его в Медальонной Архитектуре вообще не заявлено), а не сырые данные
ПыСы тоже имею зуб на Датабрикс за то, что угоду маркетингу попали ребрендинг и присвоили себе “азбуку”
Вам не кажется, что это оверинжениринг и ваше обоснование неверное? Кликхаус изначально заточен на аналитические нагрузки и может горизонтально масштабироваться. Для Спарка же вам нужна отдельная инфраструктура и этого доп Косты, плюс вы гоняйте данные туда-сюда между двумя системами - в случае больших данных это дополнительные затраты на сеть как минимум (нередко это самая узкое место). Особенно забавно то, что в итоге все равно все ваши преобразования - это обычный SQL.
Вот этот абзац рекомендую самому прочитать и исправить - перечитал три раза и ничего не понял: такое ощущение, что слеплен из двух примеров, но середина потерялась
У вас нет самого главног - отказоустойчивости. А значит это никакой не NAS. Вам на это уже указали в предыдущем комментарии. Нужен RAID и специальные диски, которые могут работать 24/7 на протяжении многих лет. Обычные диски от ноутбука к таким режимам не приспособлены. Согласен с предыдущим комментарием, что куда проще было сделать то же самое на роутере с USB к которому подключён внешний диск. Надёжность такая же, а гемора меньше, и не дороже
И второй вопрос. Разве google play требует юрлицо и т.п. для доступности приложения в других странах? По крайней мере в AppStore ты спокойно можешь опубликовать приложение без каких-либо страновых ограничений вне зависимости от того где ты находишься и какой твой статус. Можете пояснить этот момент?
Я опирался на ту доступную инфу, что есть на сайте Датабрикса. Ок. Поделись потом плз выводами!
Покопался в Lakehouse RT поглубже и … скорее разочарование от контраста обещаний со сцены и реальности. Писал у себя в линкедине недавно… А ваше мнение - ?
Напишу отдельным комментарием.
Отдельный вопрос по качеству работы рекрутеров: ожидание ответов от них по две недели, холодные сообщения даже без предварительного просмотра профиля кандидата (то есть предлагают совершенно нерелевантные позиции)… что интересно, даже когда такое холодное сообщение мне кажется интересно, и я оперативно на него отвечаю, то получаю реакцию все равно через неделю а то и больше. И если это были бы единичные случаи, ничего бы не говорил. Но таких – процентов 80
Согласен с пред комментатором. “У нас дефицит высококвалифицированной низкооплачиваемой рабочей силы”:))) Сам за последний год несколько раз сталкивался, когда мне писали в личку с предложением работы (хотя я её не ищу), предлагая B2B контракт на сумму, которую я сейчас имею в найме (поясню – при B2B контракте сумма должна быть как минимум в полтора раза выше найма, мои личные подсчеты с учётом всех отпусков, потенциальных больничных, соц пакета, рабочего оборудования и рисков, а также накладных расходов, вообще показывают коэффициент 1.9). Или другой случай из первых уст – компании был нужен высококвалифицированный специалист уровня архитектор на технологию, которые очень редка в России сейчас. Решили искать среди релокантов, но при этом зарплату предлагали даже ниже чем в России – стратегия поиска строилась на том, что кандидату, сидящему в условной Грузии или подобных странах будет деваться некуда, и он согласится.
Файлов с правилами, описаниями и просьбами больше чем кода)))
Хороший обзор. Кроме того созвучен с моими мыслями.
Вообще заметил, что последнее время (в последние годы) ДатаБрикс очень сильно вкладывается в маркетинг, при этом оставляет достаточно много гапов в текущем функционале. И отдельно стоит выделить просто гигантские маркетинговые попытки пересадить всех на свои вендор лок фреймворки
Удачи! Хороший проект!
В это статичный сайт или есть мониторинг изменений периодически?
Что вы имеете в виду под “посчитать силами SQL”? SQL - это ЯЗЫК, а считает - ДВИЖОК. В вашем же примере ДБТ - это фреймворк который просто снижает накладные расходы (плюс ещё фишки) и упрощает работу с SQL и может потом этот SQL отравлять на разные execution engine. Или вы не понимаете то, что сами спроектировали?)
Вот тут насмешили)))) Это не доверие, это “предложение от которого нельзя отказаться”. Делал проект по налоговыму мониторингу для крупной (очень крупной) организации когда его ещё пилотировали…
ПыСы статья ни о чем, сорри, тема не раскрыта
Потому что просторы интернета завалены говно-статьями с пересказом документации и прочих банальностей и нейрослопом от индусов, которые очень активно начали писать в последние несоклько лет. Даже знаю из первых рук зачем - качание собственного бренда, а иногда даже получение визы таланта США (реально знаю несколько кейсов). Ценность этих статей - ноль. Зато шум создают…
В дополнении в пред комменаторию.
Перекрытие ролей:
Spark — движок для распределённой обработки данных и трансформаций.
dbt — тоже про трансформации данных, только декларативно через SQL.
ClickHouse — аналитическая СУБД, которая сама умеет выполнять довольно тяжёлые трансформации.
В итоге возникает вопрос: где именно должна жить бизнес-логика? Через год никто не понимает, где искать ошибку.
Ну и подерживать такой зоопарк накладно. Все эти компоненты имеют разные модели эксплуатации: зависимости, мониторинг, деплой, права доступа, CI/CD и т.п.
У вас про это в обосновании не написано. Кроме того, обоснование апеллирует к невалидному утверждению.
Ну и вообще, мешать в одном проекте clickhouse, spark и дбт - совсем не тянет на эталонный проект. Явный овер инжениринг. При этом обоснование его необходимости не приведено (но не спорю, что иногда оно может быть)
В целом согласен, но все же поправлю: Bronze это Stage, а ODS - это Operational Data Store - то есть силы для получения операционной отчётности(его в Медальонной Архитектуре вообще не заявлено), а не сырые данные
ПыСы тоже имею зуб на Датабрикс за то, что угоду маркетингу попали ребрендинг и присвоили себе “азбуку”
Вам не кажется, что это оверинжениринг и ваше обоснование неверное? Кликхаус изначально заточен на аналитические нагрузки и может горизонтально масштабироваться. Для Спарка же вам нужна отдельная инфраструктура и этого доп Косты, плюс вы гоняйте данные туда-сюда между двумя системами - в случае больших данных это дополнительные затраты на сеть как минимум (нередко это самая узкое место). Особенно забавно то, что в итоге все равно все ваши преобразования - это обычный SQL.
Вот этот абзац рекомендую самому прочитать и исправить - перечитал три раза и ничего не понял: такое ощущение, что слеплен из двух примеров, но середина потерялась
У вас нет самого главног - отказоустойчивости. А значит это никакой не NAS. Вам на это уже указали в предыдущем комментарии. Нужен RAID и специальные диски, которые могут работать 24/7 на протяжении многих лет. Обычные диски от ноутбука к таким режимам не приспособлены. Согласен с предыдущим комментарием, что куда проще было сделать то же самое на роутере с USB к которому подключён внешний диск. Надёжность такая же, а гемора меньше, и не дороже
Даже если это open source проект без своей инфраструктуры? Не совсем понимаю если честно. Или у вас есть серверная часть, которая не open source?
И второй вопрос. Разве google play требует юрлицо и т.п. для доступности приложения в других странах? По крайней мере в AppStore ты спокойно можешь опубликовать приложение без каких-либо страновых ограничений вне зависимости от того где ты находишься и какой твой статус. Можете пояснить этот момент?
Верно ли я понимаю, что раз он в Rustore - значит выполняет все требования закона яровой и подобное?