Спасибо, что отметили, Terraform упустили. Обновил в статье таблицу :)
Вы правы, каждый инструмент хорош по-своему, более того, я считаю, что нет идеального инструмента, выбирать надо всегда то, что лучше всего ложится на конкретный процесс.
В нашем случае Ansible прекрасно ложится на наши процессы – позволяет укладывать всё описание инфраструктуры в код и развернуть необходимые компоненты DWH за короткие сроки. Проблем с SSH в нашей практике не было, он есть на каждой машине по умолчанию и не требует ставить сначала агенты на каждую машину.
У Вас богатый опыт работы с Ansible :) Вы правы, Ansible иногда бывает слишком гибок :) Эти проблемы с гибкостью решаются конвенциями по написанию кода, как и в любом другом процессе, когда код использует команда, а не один человек.
Bash хорош, не спорю, но его скорее надо сравнивать не с решениями для оркестрации инфраструктуры, как Ansible и другие, а с другими скриптовыми языками вроде питона.
В нашем случае плейбуки выполняются по несколько минут, потому что главная задача, которую выполняет Ansible – это первичное развертывание инфраструктуры. Мы так быстро не обедаем :)) Другие задачи мы решаем другими инструментами, и об этом будут новые статьи :)
С какими, например, трудностями вы сталкивались? Буду рад увидеть описание кейсов, обмен опытом всегда полезен.
У Ansible, как и у любого инструмента, есть свои ограничения. При выборе той или иной системы управления конфигурациями важно четко сформулировать, какие задачи вам предстоит решать, заранее протестировать инструменты.
В нашем случае Ansible справляется с тем уровнем задач, которые мы перед ним ставим. У нас проекты не завязаны на стеке, потому что считаем, что главное – не ПО, а экспертиза и гибкость. Если Ansible перестанет справляться – перейдем на другой инструмент :)
В данном случае мы не критикуем сам MsSQL как инструмент. Мы критикуем решение при отсутствии у команды соответствующего опыта выбрать более сложную в настройке и эксплуатации технологию, что в итоге вылилось в неспособность решения обеспечить потребности бизнеса.
Dagster предоставляет хорошую документацию по данным (описание, поля, ограничения, метрики), удобный интерфейс, более простую разработку трансформаций на Python за счет применения io_manager'ов. Особенно приятно им пользоваться, если нет возможности развернуть отдельный инструмент для метаданных (Datahub.io, OpenMetadata), в таких случаях Dagster блистает.
Airbyte хорош, если там есть источники, которые вам нужны. Если же мы разрабатываем выгрузки тех данных, которых в нем нет, то используем обычные asset'ы, так проще поддерживать и разрабатывать.
В целом, они очень неплохо сочетаются, работают стабильно, многие вещи можно настроить очень быстро.
Вообще, в идеальном варианте, всегда лучше иметь собственную компетентную команду разработки, чем привлекать подрядчиков. Но формирование у себя такой команды требует времени, денег и собственной экспертизы бизнеса.
При самостоятельном развитии DWH направления сильно отодвигается результат, а это убытки/недополученная прибыль. Накопление компетенций в DWH - это всегда дорого, вы либо находите специалиста с опытом за очень большие деньги, либо растите сами, платя ему зарплату и отодвигая время запуска проекта.
Вариант найма сотрудников из сторонней компании - хороший, но тоже может быть рискованным. При таком подходе, как и при полной передаче проекта подрядчику, стоит внимательно подходить к выбору компании для сотрудничества, чтобы не оказаться в ситуации, когда работы оплачиваются, но результат не гарантирован, и провести промежуточную проверку некому. Предложить вам качественных специалистов смогут только подрядчики с опытом и знаниями в проектировании и внедрении хранилищ.
Не соглашусь с вами в употреблении термина "зависимость". Долгосрочное сотрудничество всегда выгодно не только подрядчику, но и клиенту, потому что по итогу экономит затраты на поддержку и сопровождение, содержание собственного штата и позволяет решать возникающие вопросы в реальном времени.
1. Вопросы, поднимаемые в статье, скорее предостерегают заказчика от мнения, что можно сделать DWH своими силами дешево и быстро. По поводу выбора подрядчика - заказчик, пришедший к мысли о создании DWH - это уже не ИП Березка, а устоявшийся бизнес, который сам смог дорасти до этой идеи. А значит, предполагается, что такая компания в состоянии выбирать подрядчиков, которые не приведут ее к краху.
2. Есть такая поговорка: "С дуру можно и кочергу погнуть". Выбор инструмента - это не главная причина кривых КХД, значительно большее влияние тут у методологии и процессов разработки (документирование, соблюдение регламентов, метаданные). Но, если допущена ошибка в выборе инструмента, то придется делать всю разработку заново, т.к. на других решениях и подходы другие.
3. Проблема в том, что даже чтобы собрать свою команду с компетенциями потребуется много времени и денег. Менеджмент не может самостоятельно определить экспертизу специалистов DWH, для этого он сам должен в этом хорошо разбираться. Отсутствие опыта приводит или к найму "пустышек", или к обращению в компании по подбору персонала. Все это приносит временные и финансовые затраты, да и людей, которые с нуля могут не просто спроектировать КХД, но также наладить производственные процессы в команде и менеджменте, на рынке очень мало.
Касаемо первого вашего вопроса: cпасибо, что заметили неточность в материале) И отвечу на второй вопрос. Да, вы правы, включение в реестр не может дать 100% гарантию безопасности, это, в первую очередь, ответственность разработчиков ПО. Мы заинтересованы в долгосрочных отношениях с нашими клиентами и в положительном имидже компании на рынке, поэтому в наших же интересах было разработать безопасный и надежный продукт.
К тому же, чтобы попасть в реестр, нужно пройти проверку о соответствии ПО требованиям Минцифры, в том числе, требованиям безопасности. Если бы конвертер нес потенциальную угрозу, его бы не включили в реестр.
Полностью согласен с вами в том, что "сбор обезличенных данных по всем, до кого можно дотянуться" - это путь в никуда. В статье я как раз хотел сделать акцент именно на управлении информацией, а не обладании ею. Речь о качестве, а не о количестве данных.
Спасибо, что отметили, Terraform упустили. Обновил в статье таблицу :)
Вы правы, каждый инструмент хорош по-своему, более того, я считаю, что нет идеального инструмента, выбирать надо всегда то, что лучше всего ложится на конкретный процесс.
В нашем случае Ansible прекрасно ложится на наши процессы – позволяет укладывать всё описание инфраструктуры в код и развернуть необходимые компоненты DWH за короткие сроки. Проблем с SSH в нашей практике не было, он есть на каждой машине по умолчанию и не требует ставить сначала агенты на каждую машину.
У Вас богатый опыт работы с Ansible :) Вы правы, Ansible иногда бывает слишком гибок :) Эти проблемы с гибкостью решаются конвенциями по написанию кода, как и в любом другом процессе, когда код использует команда, а не один человек.
Bash хорош, не спорю, но его скорее надо сравнивать не с решениями для оркестрации инфраструктуры, как Ansible и другие, а с другими скриптовыми языками вроде питона.
В нашем случае плейбуки выполняются по несколько минут, потому что главная задача, которую выполняет Ansible – это первичное развертывание инфраструктуры. Мы так быстро не обедаем :)) Другие задачи мы решаем другими инструментами, и об этом будут новые статьи :)
С какими, например, трудностями вы сталкивались? Буду рад увидеть описание кейсов, обмен опытом всегда полезен.
У Ansible, как и у любого инструмента, есть свои ограничения. При выборе той или иной системы управления конфигурациями важно четко сформулировать, какие задачи вам предстоит решать, заранее протестировать инструменты.
В нашем случае Ansible справляется с тем уровнем задач, которые мы перед ним ставим. У нас проекты не завязаны на стеке, потому что считаем, что главное – не ПО, а экспертиза и гибкость. Если Ansible перестанет справляться – перейдем на другой инструмент :)
В данном случае мы не критикуем сам MsSQL как инструмент. Мы критикуем решение при отсутствии у команды соответствующего опыта выбрать более сложную в настройке и эксплуатации технологию, что в итоге вылилось в неспособность решения обеспечить потребности бизнеса.
Добрый день! Опыт положительный.
Dagster предоставляет хорошую документацию по данным (описание, поля, ограничения, метрики), удобный интерфейс, более простую разработку трансформаций на Python за счет применения io_manager'ов. Особенно приятно им пользоваться, если нет возможности развернуть отдельный инструмент для метаданных (Datahub.io, OpenMetadata), в таких случаях Dagster блистает.
Airbyte хорош, если там есть источники, которые вам нужны. Если же мы разрабатываем выгрузки тех данных, которых в нем нет, то используем обычные asset'ы, так проще поддерживать и разрабатывать.
В целом, они очень неплохо сочетаются, работают стабильно, многие вещи можно настроить очень быстро.
Вообще, в идеальном варианте, всегда лучше иметь собственную компетентную команду разработки, чем привлекать подрядчиков. Но формирование у себя такой команды требует времени, денег и собственной экспертизы бизнеса.
При самостоятельном развитии DWH направления сильно отодвигается результат, а это убытки/недополученная прибыль. Накопление компетенций в DWH - это всегда дорого, вы либо находите специалиста с опытом за очень большие деньги, либо растите сами, платя ему зарплату и отодвигая время запуска проекта.
Вариант найма сотрудников из сторонней компании - хороший, но тоже может быть рискованным. При таком подходе, как и при полной передаче проекта подрядчику, стоит внимательно подходить к выбору компании для сотрудничества, чтобы не оказаться в ситуации, когда работы оплачиваются, но результат не гарантирован, и провести промежуточную проверку некому. Предложить вам качественных специалистов смогут только подрядчики с опытом и знаниями в проектировании и внедрении хранилищ.
Не соглашусь с вами в употреблении термина "зависимость". Долгосрочное сотрудничество всегда выгодно не только подрядчику, но и клиенту, потому что по итогу экономит затраты на поддержку и сопровождение, содержание собственного штата и позволяет решать возникающие вопросы в реальном времени.
Большие объемы данных и необходимая заказчику детализация не позволили использовать этот инструмент.
Добрый день! Спасибо за ваше мнение.
Прокомментирую по абзацам:
1. Вопросы, поднимаемые в статье, скорее предостерегают заказчика от мнения, что можно сделать DWH своими силами дешево и быстро. По поводу выбора подрядчика - заказчик, пришедший к мысли о создании DWH - это уже не ИП Березка, а устоявшийся бизнес, который сам смог дорасти до этой идеи. А значит, предполагается, что такая компания в состоянии выбирать подрядчиков, которые не приведут ее к краху.
2. Есть такая поговорка: "С дуру можно и кочергу погнуть". Выбор инструмента - это не главная причина кривых КХД, значительно большее влияние тут у методологии и процессов разработки (документирование, соблюдение регламентов, метаданные). Но, если допущена ошибка в выборе инструмента, то придется делать всю разработку заново, т.к. на других решениях и подходы другие.
3. Проблема в том, что даже чтобы собрать свою команду с компетенциями потребуется много времени и денег. Менеджмент не может самостоятельно определить экспертизу специалистов DWH, для этого он сам должен в этом хорошо разбираться. Отсутствие опыта приводит или к найму "пустышек", или к обращению в компании по подбору персонала. Все это приносит временные и финансовые затраты, да и людей, которые с нуля могут не просто спроектировать КХД, но также наладить производственные процессы в команде и менеджменте, на рынке очень мало.
Касаемо первого вашего вопроса: cпасибо, что заметили неточность в материале)
И отвечу на второй вопрос. Да, вы правы, включение в реестр не может дать 100% гарантию безопасности, это, в первую очередь, ответственность разработчиков ПО. Мы заинтересованы в долгосрочных отношениях с нашими клиентами и в положительном имидже компании на рынке, поэтому в наших же интересах было разработать безопасный и надежный продукт.
К тому же, чтобы попасть в реестр, нужно пройти проверку о соответствии ПО требованиям Минцифры, в том числе, требованиям безопасности. Если бы конвертер нес потенциальную угрозу, его бы не включили в реестр.
Полностью согласен с вами в том, что "сбор обезличенных данных по всем, до кого можно дотянуться" - это путь в никуда. В статье я как раз хотел сделать акцент именно на управлении информацией, а не обладании ею. Речь о качестве, а не о количестве данных.