Комментарии 12
Ваши слова "Waterfall, в разработке ПО обычно считается плохим подходом."
Конечно, на просторах этой платформы это обсуждалось уже не раз, но истинной waterfall уже не существует лет 30, а часть её не только здесь нужна - она нужна везде! И при разработке архитектуры софта, и основной модели данных и инфраструктуру без этого не создать. Потом, когда боллее менее всё на ногах стоит, вот тогда можно и на агиль переходить. Но почти всегда забивают многие на такой тщательный подход и потом - и фундамент не выдеживает нагороженное и база данных не может перелопатить правильно и быстро все данные, всё везде тормозит итд.
Извините, это так походу. За статью же спасибо.
Конвейер либо завершён, либо бесполезен
Развёртывание частично готового конвейера в продакшене не принесёт пользы клиенту
У меня по опыту это очень часто не так.
Во-первых частично рабочий конвейер данных тестируется в боевых условиях под нагрузкой и вылазят многие интересные нюансы.
Во-вторых частично рабочий конвейер может позже значительно упростить, а то и вообще избавить от проблемы миграции данных (очень часто старые данные более чем за какой-то срок неактуальны).
пользовательские истории заменяются задачами, например, «создать API-коннектор» и «построить логику потребления», что неизбежно превращает доску Scrum в инструмент микроменеджмента.
Для меня это отдельные задачи, которые могут делаться разными людьми, причем обычно в параллель. Не понимаю почему это микроменеджмент.
Разработку конвейера невозможно распараллелить
Прямо сейчас у нас конвейер есть, которые изначально собирает данные из нескольких источников по разным правилам (где-то ходим и собираем данные, где-то к нам приходят)-эти задачи делаются в параллель.
При желании и правильном проектировании конвейер можно разбить на очень маленькие задачи, но обычно делать последовательно проще, поэтому имеет смысл делать только до определенного предела.
Любой инженер предпочёл бы «сделать всё правильно с первого раза» и минимизировать число деплоев в продакшен.
Если процесс деплоя не вызывает боль (например когда много ручных действий или нужно 2 недели собирать аппрувы) то я бы хотел делать деплои как можно чаще.
Модульные тесты, необходимые для проверки ограниченной, самостоятельной логики преобразования, сложнее самого кода, поскольку от разработчика требуется создать репрезентативные тестовые данные, а также ожидаемые выходные данные. Это много работы, которая не повысит значительно уверенность в правильном функционировании конвейера
Когда есть пользовательский ввод то вариативность гораздо больше. Но задача тестов не покрыть все возможно варианты входных данных, обычно задача-зафиксировать текущее поведение, чтобы кто-то несломал то что уже работает.
какой-то сборник мифов.
Все лень развенчивать, распишу первый: "Конвейер данных нельзя разрабатывать малыми итерациями с возрастающей потребительской ценностью. У конвейера нет MVP-эквивалента — он либо создаёт необходимый потребителю датасет, либо нет. "
Типичные итерации конвеера с возрастающей ценностью:
1-я итерация: Делаем простой full load всего сорса в стейджинг, дальше вьюхи на сырых данных - вуаля витрины готовы, минимум времени и уже потребители могут работать с данными
2-я итерация: Заменяем full load на инкрементальный - скорость загрузки увеличивается в разы, можем быстрее и чаще рефрешить данные - потребительская ценность повышается
3-я итерация: Добавляем в середину нормализованный слой хранения - появляется внятная модель данных с ключами и ссылочной целостностью, ей удобно пользоваться с помощью adhoc запросов - потребительская ценность повышается
4-я итерация: Переписываем вьюхи на таблицы или мат.вью - запросы выполняются быстрее - - потребительская ценность повышается
5-я итерация: Добавляем историчность данных аля scd2 - можно отслеживать историю состояний в прошлом - - потребительская ценность повышается
И так далее... там и логи и DQ checks и оптимизация стоимости хранения и 100500 других итераций
Так что:
Hidden text
2-я итерация: Заменяем full load на инкрементальный - скорость загрузки увеличивается в разы, можем быстрее и чаще рефрешить данные - потребительская ценность повышается
И в любой момент времени у вас нормальное состояние для чтения? Вы удаляли когда-нибудь 10 млн. строчек? Или загружали инкрементально 10 млн. строчек? Никто не будет спорить с Вами, что ваш план нереализуем. В каком-то частном случае - конечно-же.
Но то, что Вы описываете - это больше prototyping - где собирается методом проб и ошибок первый опыт. Но без тщательной продумки архитектуры вам никак. Приведу малюсенький пример - для распределённой бызы данных генератор инкрементального ID не поможет. Надо что-то по-серьёзнее, например GUID - он подходит, но для больших обьёмов может быть по весу чуточку больше, чем хотелось бы итд.
Ещьё один маленький пример. Вы когда-нибудь изменяли структуру таблицы, когда в ней залито 100 млн. строчек? Если нет - попробуйте и не удивляйтесь, сколько часов ваша таблица не будет ни на какие запросы на чтение отвечать. А в вашем случае - только этим вы и будете заниматься.
Ваше развенчивание мифов мне напомнило "хер..к, хер.к и в продакшн" и потом с продакшн делать типа что хочешь.И стабильнось ни на грам не изменится! Ага, знаю я такой подход.
В любом проекте, например и по строительству моста через реку всегда есть фазы, которые надо тщательно продумать, но есть и куча под-заданий, где итеративно можно свою креативность выжимать и не ограничивать себя ничем. Надо только правильно понять, где какие?
"Или загружали инкрементально 10 млн. строчек? " еще как загружал. Про структуру кстати тут все продумано, ни в одной из описанных итераций не надо менять структуру фактов наживую.
p.s. Про генератор инкрементального ID не понял. Видимы вы что-то другое имеете ввиду нежели возможность получать только последние изменные данные из базы источника.
p.p.s Все вышепреведенное не из пальца высосано, а из собственного опыта, нескольких десятков крупных DWH проектов разного вида, размера, технологий и сфер бизнеса
Про структуру кстати тут все продумано, ни в одной из описанных итераций не надо менять структуру фактов наживую.
Ну как не надо?! Если из таблицы с сырыми данными будете делать различные Relations - вы ведь убираете колонку с текстовым значением в таблице, заменяете её на числовую, где новые ИД стоять будут. Потом надо будет ETL-Процесс изменять, потому что в эту таблицу уже оригинальные данные не полезут, а надо будет ключи из других таблиц брать итд. Короче ваше описание не подходит к реальности.
Многие системы создаются в попыхах, а потом выходит, что нужно паралелльное сохранение и обработка данных или разбиение таблицы на виртуальные партиции итд. Автор правильно указал, что тщательно разработанный концепт архитектуры может стать стабильным фундаментом на года. На коленке собранная и без основательного продумывания - имеет большую вероятность через кое-какое кол-во итераций встать или быть неподходящей или требующей фундаментального редизайна.
ведь убираете колонку с текстовым значением в таблице, заменяете её на числовую, где новые ИД стоять будут.
О чем вы? В первой итерации таблиц фактов вообще не было. В третьей они появились (появились а не поменялись), и мы переделываем вьюхи витрин на их использование - но вьюхи не хранят данные (если вы не знали) - изменить вьюху не требует ресурсов.
В четвертой итерации заменили вью, на матвью например - но структуру при этом не меняли
В пятой итерации прикручиваем scd2 к дименшенам ( а не к фактам кстати) ну и опять же - добавить scd2 историчность к таблице не требует её перестройки
p.s. может вам книгу какую почитать по построению аналитический систем, классику например аля: "The Data Warehouse Toolkit".
а из собственного опыта, нескольких десятков крупных DWH проектов разного вида, размера, технологий и сфер бизнеса
..и что - во всех никогда не задумывались, а сразу выстраивали всю цепочку, а уж только потом доводили моделирование до правильного конца. Не знаю, я в первую очередь оговариваю и обдумываю многие вещи, перед тем, как первые данные вообще поимеют статут - продуктивные. Как будут сохранятся медленные и как например быстрые данные, как история их изменения, нужна-ли она, получаю я её из вне или должен сам делать, или name conventions - при кол-ве 10 таблиц можно их и их поля обзывать по сокращённым, но всё равно по имени, при количестве 25 тысяч - человеческих названий не хватит итд. Без этих и многих других архитектурных продумываний начинать - это курам на смех что получиться.
Вы отвергаете роль и задачи архитектора, а я наоборот - уверен в том, что без этой роли получиться мало чего хорошего. Это не отменяет, что не имея статуса архитектора вы думаете как архитектор, но ведь эти задачи должны быть кем-то обозначены.
Ну например это " как история их изменения, нужна-ли она" в теории круто конечно знать это заранее, а на практике никто из стейкхолдеров потребителей данных не знает на 100% до начала проекта - какая история изменений, как детально и где нужна. Это по-любому итерационный процесс, где в 95% случаев СНАЧАЛА данные начинают использовать, а ПОТОМ понимают нужна ли им история или нет.
Ну а закладывать историчность во ВСЕ - это оверхед большой, хотя например архитектура Anchor Modeling такое предусматривает, вся история всего, но это слишком специфичная модель и большой оверхед всего, на который идти надо ТОЧНО зная что он нужен, а это опять повторюсь будет известно только ПОСЛЕ выхода в прод и начала полноценной работы с данными
Вы отвергаете роль и задачи архитектора,
Ровно наоборот, моя роль как архитектора - заложить модель РАСШИРЯЕМУЮ и гибкую, которую можно расширять и улучшать итерациями, в различных направлениях, в зависимости от потребностей, которые в реальной жизни возникают не ДО начала проекта, а ПОСЛЕ
Инженерия данных != инженерия ПО