Comments 11
Ну да, сделали сами и криво, вывод очевиден, вроде бы - нанять компанию и тогда все будет правильно. Нет, не будет, делали сами из экономии, компанию найдут самую дешёвую, с самыми дешёвыми специалистами, если они там вообще есть, чаще всего и нет у этих компаний никого. Больше половины компаний - бодишопы, получив контракт и обманув заказчика, наврав с три коробки про доступные и качественные ресурсы, они ломятся на хедхантер в поисках специалистов. А по факту у них 1 работает а 10 делают вид, что о они этим управляют.
Теперь решили везде пихать гринплюм, нужен он или не нужен, все ставят и мы будем ставить. Очередная таблетка от всех проблем. Фигня все это, сижу в банке и вижу кривое ХД на этом самом гринплюме.
Проблема на самом верху в менеджменте, ну нет у нас Илонов Масков, нет их, у нас на всех уровнях критины с бошьшими амбициями. А рецепт один - не жадничай на зарплате и относись к специалистам с уважением к их опыту и труду подобающим образом и дай им свободу, они горы свернут.
Добрый день! Спасибо за ваше мнение.
Прокомментирую по абзацам:
1. Вопросы, поднимаемые в статье, скорее предостерегают заказчика от мнения, что можно сделать DWH своими силами дешево и быстро. По поводу выбора подрядчика - заказчик, пришедший к мысли о создании DWH - это уже не ИП Березка, а устоявшийся бизнес, который сам смог дорасти до этой идеи. А значит, предполагается, что такая компания в состоянии выбирать подрядчиков, которые не приведут ее к краху.
2. Есть такая поговорка: "С дуру можно и кочергу погнуть". Выбор инструмента - это не главная причина кривых КХД, значительно большее влияние тут у методологии и процессов разработки (документирование, соблюдение регламентов, метаданные). Но, если допущена ошибка в выборе инструмента, то придется делать всю разработку заново, т.к. на других решениях и подходы другие.
3. Проблема в том, что даже чтобы собрать свою команду с компетенциями потребуется много времени и денег. Менеджмент не может самостоятельно определить экспертизу специалистов DWH, для этого он сам должен в этом хорошо разбираться. Отсутствие опыта приводит или к найму "пустышек", или к обращению в компании по подбору персонала. Все это приносит временные и финансовые затраты, да и людей, которые с нуля могут не просто спроектировать КХД, но также наладить производственные процессы в команде и менеджменте, на рынке очень мало.
Первая попытка построения хранилища была реализована на SQL Server + SSIS (SQL Server Integration Services) и по сути являлась скорее импровизированной базой данных, нежели полноценным DWH, из-за ограничений SQL с точки зрения запросов и обработки данных.
Я так понял, SSAS - нет, не слышал?
Хорошо, что не указана конкретная компания с опытом разработки корпоративных хранилищ :-)
В целом, не согласен с мнением о необходимости обращения в другую компанию с опытом хранилищ. Хорошей альтернативой может служить найм работников из подобной компании на время реализации проекта, как правило, это 1-2 года. В случае успешной реализации проекта эти сотрудники могут не вернуться обратно, поэтому стоимость таких специалистов сильно завышают, чтобы заказчик их сам поскорее отправил обратно.
Попытки самостоятельного построения хранилищ являются экономически обоснованными и абсолютно верными. Данные - это и есть процессы, при обращении в стороннюю компанию нужно сначала её посвятить в интимные подробности своего бизнеса. Далее создаётся зависимость от сторонней компании, технологий и инфраструктуры, цена на которые растёт быстрее, чем можно себе представить.
Вся эта история с хранилищами, а особенно с их корпоративными вариантами, является удобным механизмом введения компаний в зависимость. Такая зависимость имеет преимущество, если технологии и всё с ними связанное создаются в этом же регионе, т.е. создаётся замкнутый круг производства и потребления в пределах города-области-страны. В противном случае и как это чаще всего бывает - начало построения корпоративного хранилища является сигналом к скорой продаже бизнеса другому хозяину.
Вообще, в идеальном варианте, всегда лучше иметь собственную компетентную команду разработки, чем привлекать подрядчиков. Но формирование у себя такой команды требует времени, денег и собственной экспертизы бизнеса.
При самостоятельном развитии DWH направления сильно отодвигается результат, а это убытки/недополученная прибыль. Накопление компетенций в DWH - это всегда дорого, вы либо находите специалиста с опытом за очень большие деньги, либо растите сами, платя ему зарплату и отодвигая время запуска проекта.
Вариант найма сотрудников из сторонней компании - хороший, но тоже может быть рискованным. При таком подходе, как и при полной передаче проекта подрядчику, стоит внимательно подходить к выбору компании для сотрудничества, чтобы не оказаться в ситуации, когда работы оплачиваются, но результат не гарантирован, и провести промежуточную проверку некому. Предложить вам качественных специалистов смогут только подрядчики с опытом и знаниями в проектировании и внедрении хранилищ.
Не соглашусь с вами в употреблении термина "зависимость". Долгосрочное сотрудничество всегда выгодно не только подрядчику, но и клиенту, потому что по итогу экономит затраты на поддержку и сопровождение, содержание собственного штата и позволяет решать возникающие вопросы в реальном времени.
Увидел у вас в стеке Dagster и Airbyte. Поделитесь опытом в продуктиве с ними?
Добрый день! Опыт положительный.
Dagster предоставляет хорошую документацию по данным (описание, поля, ограничения, метрики), удобный интерфейс, более простую разработку трансформаций на Python за счет применения io_manager'ов. Особенно приятно им пользоваться, если нет возможности развернуть отдельный инструмент для метаданных (Datahub.io, OpenMetadata), в таких случаях Dagster блистает.
Airbyte хорош, если там есть источники, которые вам нужны. Если же мы разрабатываем выгрузки тех данных, которых в нем нет, то используем обычные asset'ы, так проще поддерживать и разрабатывать.
В целом, они очень неплохо сочетаются, работают стабильно, многие вещи можно настроить очень быстро.
Критика решений ms sql как не могущих в высокую нагрузку и масштабирование звучит так себе.
В данном случае мы не критикуем сам MsSQL как инструмент. Мы критикуем решение при отсутствии у команды соответствующего опыта выбрать более сложную в настройке и эксплуатации технологию, что в итоге вылилось в неспособность решения обеспечить потребности бизнеса.
Вредные советы: как самостоятельно внедрить DWH и потратить впустую деньги и время