Pull to refresh

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 предоставляет хорошую документацию по данным (описание, поля, ограничения, метрики), удобный интерфейс, более простую разработку трансформаций на Python за счет применения io_manager'ов. Особенно приятно им пользоваться, если нет возможности развернуть отдельный инструмент для метаданных (Datahub.io, OpenMetadata), в таких случаях Dagster блистает.

Airbyte хорош, если там есть источники, которые вам нужны. Если же мы разрабатываем выгрузки тех данных, которых в нем нет, то используем обычные asset'ы, так проще поддерживать и разрабатывать.

В целом, они очень неплохо сочетаются, работают стабильно, многие вещи можно настроить очень быстро.

Критика решений ms sql как не могущих в высокую нагрузку и масштабирование звучит так себе.

В данном случае мы не критикуем сам MsSQL как инструмент. Мы критикуем решение при отсутствии у команды соответствующего опыта выбрать более сложную в настройке и эксплуатации технологию, что в итоге вылилось в неспособность решения обеспечить потребности бизнеса.

Разве MSSQL, который имеет хороший оптимизатор и тянет сложные квери сложнее, чем юзать noSql где все те же сложные квери а аналитику надо писать вручную?

Хотя да, лопата проще бульдозера

Sign up to leave a comment.

Articles