Сразу видно статьи, написанные "далекими от полей" людьми. Где вы видели чтобы AI писал продакшн-код и у компании были десятки AI-агентов? Это только маркетинговый булщит, фантазии продажников и красивые презентации для руководства. В "полях" люди в лучшем случае юзают условный Гигачат или Клод. И не факт что это не просто личная инициатива работника. С внедрением AI в компаниях большие проблемы, причем на всех уровнях. Не надо писать чушь.
Так в портфельном менеджменте нет проблем с кросс-курсами. Как правило, все приводится к базовой валюте (Евро, Баксы, Рубли, Юани и т.п.) - обычно валюте той страны, где "центр жизненных интересов" инвестора. Ему куда более понятны "свои родные деревянные", чем абстрактные "попугаи". Причем а какую валюту не переводи (даже хоть в "абсолютную", как предлагает автор), все суммы будут одинаковы с поправкой на множитель константы. Корме того, математический аппарат портфельных инвестиций вообще инвареантен относительно валюты. При этом если у тебя активы номинированы в разных валютах, то все равно тебе надо считать валютный риск (риск изменения курсов) - это этого ты никуда не денешься. "Природу" колебания курсов валют не обманешь.
Ни в одной из ваших статей на эту тему нет ответа на вопрос - а для чего это? какую ПРОБЛЕМУ вы пытаетесь решить? То, что курсы во всем мире парные - это не проблема. По крайней мере вы не раскрыли тему, почему это проблема? Почему не устраивает приведение всего к опорной валюте? Имея кросс-курсы можно все остальные пересчитать в те же Рубли и получить единую точку отсчета, что, собственно, и делают все.
Согласен, проекция собственного опыта: всегда были более-менее централизованные команды (и/или четкиe SLA по готовности данных, если поставляли их "во вне") и разброс часовых поясов максимум 2-3, поэтомут всегда было удобное "ночное окно".
То есть верно я понял, что по сути у вас множество систем с разными режимом готовности данных, ещё и размазанные по разным часовым поясам, и как следствие, нет того самого единого "технологического окна", которое могло бы быть точкой синхронизации всех процессов? И получается по сути у вас в течении 24 часов непрерывно то одна, то другая система поставляет новые порции данных, которые (учитывая упомянутую выше особенность) надо "добавлять" в отчёты/дашборты в течении "бизнес дня" и ещё готовить некие расчеты на основании поступивших данных для поставки внешним потребителям/системам?
Никогда. Загрузка данных в дата платформу обычно всегда по расписанию в ночное окно (чтобы утром уже все было готово для бизнеса). Все процессы идемпотентны. Грамотно выстроенная оркестрация. Грустно выстроенная стратегия обновления и загрузки данных. Грамотная модель данных. Проверки качества и готовности данных. Платформа данных - это про аналитику, а не операционную работу. По моему опыту, если ACID для платформы данных становиться критичным, то это говорит скорее об архитектурных проблемах платформы и загрузки данных в нее.
Если у вас есть пример обратного, с удовольствием готов предметно обсудить его (даже в личке, если не хотите публично) и даже обрадуюсь, если окажусь неправ.
ACID как раз не накладывает никаких ограничений - то есть транзакция атомарна независимо от того, какие объекты БД и в каком количестве она затрагивает. Классическая СУБД , являясь умной надстройкой над файлам, позволяет по дефолту в рамках одной транзакции оперировать несколькими таблицами. Дельты и Айсберги же - нет
.... парадигма ACID, которая была фундаментальной в Data Warehouse.
ACID фундаментален для реляционных баз данных и транзакционных систем. Для DWH он никогда не был фундаментальным, а пришел просто побочный эффект от реляционных БД, на которых строились долгое время DWH
OTF принес возможность использовать ACID-операции...
Не совсем. Надо добавить, что только в рамках одной таблицы. Ну и кстати, отсутствие ACID в Дата Лейке особо никому не мешало никогда (по моему опыту)
Удалось разделить слои вычисления и хранения...
Было успешно сделано до появления термина Lakehouse
Это связано с тем, что Lakehouse использует опенсорсные технологии ...
Как и ДатаЛейк.
И далее в том же духе, нет смысла весь список приводить. Ещё и ,Data Governance и AI приплели, хотя к архитектурному походу они не имеют никакого отношения. Многовато неточностей и ошибок для директора направления Data Engineering ;)
Не могу сказать. У нас все на англ в компании. Судя по CV он около 5 лет в Германии. Бакалавра получил в Тигеране, а магистра - буквально недавно уже в Германии.
Она же чисто для апи к спарк джабам ... много работал со спарком ...
Вы немного заблуждаетесь. Скала - отдельный самодостаточный ЯП. Даже применительно в Дата Инженерии это не "чисто апи к спарк джобам".
Я просто сам бекендер, который на последнем проекте, не по своей воле
Вот примерно так 7 лет назад в нашей компании начинали строить Дата Платформу :))) Были простые бэкэндеры и фулл-стеки, которых попросили "сделать что-нить на Датабриксе для аналитики", ну они и начали делать :) В итоге через 4 года, когда наняли меня, у меня волосы дыбом встали от сделанного с т.з. архитектуры и от самого кода. То, что минимум 2 раза в неделю что-нибудь да падало на ПРОДе, даже молчу. Мой первый год в компании был посвящен поэтому перестройке и рефакторингу самых больных мест и выстраиванию процессов (от разработки, стандартов и до внедрения CI/CD). Так что хороший разработчик - не значит хороший дата инженер.
Я тут нерелевантен) Когда был мидлом, мне было все новое интересно) Да и сейчас я ничего против не имею, если мне приходится разбираться с чем-то новым, пусть даже используемым весьма ограничено.
Касательно архитектурных решений. Они должны быть долгосрочные и соответствовать бизнес и дата стратегии компании. В частности например, если политика компании "платить в среднем по рынку, незаменимых нет" (знаю кстати примеры таких компаний), то это одна история - тогда, грубо, используем все "самое попсовое", делаем все просто, проблемы решаем экстенсивным увеличением команды за 5 копеек, миримся, что иногда будет "больно" и это будет неожиданно. Если же компания ориентирована на удержание кадров и инвестирование в их развитие, то это другое. Тут имеет смысл использовать что-то менее популярное, но более подходящее вашему бизнесу. ИМХО
Касательно declarative pipeline. Я не сторонник продвигаемых вендорами направо и налево notebook-центричного похода (это делает что Майкрософт, что Датабрикс ...). Полностью понимаю их маркетинговых подход и с этой точки зрения даже не осуждаю - это хорошо продается (развесившим уши "эффективным менеджерам"), выглядит просто и, самое главное, привязывает клиента к твоей экосистеме. Но как архитектор, я стараюсь избегать такого подхода. Конкретно в DBX-воркспейсе нашего юнита (но, к сожалению, не у других) нет ни одного пайплайна, реализованного как notebook. Мой (наш) подход:
все объекты в Unity Catalog создаются через DDL-операции, которые деплоятся как патчи
все пайплайны - только Spark-приложения, упакованные в fat JAR. В случае с Питоном это были бы whl
Если мы говори о Delta Live Tables, то бОльшую часть их функционала доступна так же через SQL-синтаксис, и тогда они деплоятся через DDL-операции как патчи. То есть Питон здесь не нужен. Если же без Питоне в них никак не обойтись, то в 90% это повод задуматься, а действительно ли тут DLT будут хорошим архитектурным решением?
Конкретно этот кандидат утверждал, что знает Скалу, использовал ее на прошлом месте, да и assesment сделал на вполне себе годной Скале. Поэтому вопросы типа "отличие val от var" рассматривались просто как "проверка на вшивость" - мол убедиться, что человек не LLM-ил бездумно и имеет хоть какие-то самые-самые базовые знания о Скале (а остальное - научим, как вы заметили). И подход, ИМХО, оказался верным, так как чел сразу же поплыл, и стало понятно, что знаний и опыта со Скалой у него нет. Потом еще были general-вопросы про организацию загрузки данных, где чел тоже показал себя как джун, действующий по предоставленным ему шаблонам. То есть и сам технический собес и заданные вопросы своей цели достиг - выявить уровень кандидата через призму текущих потребностей команды. Единственное, что по мере найма (и сложностей с поиском Скалистов) приоритеты нанимающего менеджера поменялись, но это уже не относится к самому техническому собеседованию
...за отказ кандидатам по причине overqualified ...Раньше вроде люди примерно с такой периодичностью работу меняли?
Учтите специфику Германии, где люди работают в компаниях десятилетиями) Срок на одном месте меньше 3-5 лет считается уже "минусом" для CV, рекомендуют не меньше 7 %) К тому же только испыталка - полгода, да и первые 3 месяца от нового сотрудника вообще обычно ничего не ждут. Касательно overqualified - я с вами согласен. Но и менеджера понимаю. На его месте, если у меня не "горит", я бы тоже избегал overqualified-сотрудников. У меня перед глазами уже были примеры подобные, когда сотруднику было "тесно" на текущей позиции, но компания по объективным причинам, не могла ничего ему предложить бОльшего в плане проф.развития и задач.
Эх, как бы я не любил Скалу, но вынужден с вами согласиться, что, к сожалению, в Европе Скала превращается в легаси... Но касательно поддержки Скалы Датабриксом не соглашусь с вами. Все, что можно сделать на Питоне, там можно сделать легко и на Скале. Просто про это нет 100500 статей и видео от "условных индусов" на Медиуме и Ютюбе, а надо открыть документацию. Единственно огорчает, и тут вы частично правы, что сам Датабрикс при реализации каких-то Датабрикс-лок фишек сначала выкатывает их для Питона и SQL, и уже попозже - для Скалы. Из последний примеров - тот же Serverless compute. ЗЫ в холиваре Питон/Скала у каждого будет сове мнение и опыт) Я, например, долго был Питонистом, но когда в 2021м впервые был вынужден писать на Скале, достаточно быстро в нее "влюбился". И при следующей смене работы при решении тестовых заданий прям чуть ли не физически "страдал", когда приходилось делать их на Питоне - то, что на Скале было просто и изящно в 1-2 строки, на Питоне было намного "многословнее" и запутаннее и занимало 5-8 строк. Поэтому сейчас с грустью наблюдаю, что в Европе Скала постепенно увядает...
Сразу видно статьи, написанные "далекими от полей" людьми. Где вы видели чтобы AI писал продакшн-код и у компании были десятки AI-агентов? Это только маркетинговый булщит, фантазии продажников и красивые презентации для руководства. В "полях" люди в лучшем случае юзают условный Гигачат или Клод. И не факт что это не просто личная инициатива работника. С внедрением AI в компаниях большие проблемы, причем на всех уровнях. Не надо писать чушь.
Так в портфельном менеджменте нет проблем с кросс-курсами. Как правило, все приводится к базовой валюте (Евро, Баксы, Рубли, Юани и т.п.) - обычно валюте той страны, где "центр жизненных интересов" инвестора. Ему куда более понятны "свои родные деревянные", чем абстрактные "попугаи". Причем а какую валюту не переводи (даже хоть в "абсолютную", как предлагает автор), все суммы будут одинаковы с поправкой на множитель константы. Корме того, математический аппарат портфельных инвестиций вообще инвареантен относительно валюты. При этом если у тебя активы номинированы в разных валютах, то все равно тебе надо считать валютный риск (риск изменения курсов) - это этого ты никуда не денешься. "Природу" колебания курсов валют не обманешь.
Ни в одной из ваших статей на эту тему нет ответа на вопрос - а для чего это? какую ПРОБЛЕМУ вы пытаетесь решить? То, что курсы во всем мире парные - это не проблема. По крайней мере вы не раскрыли тему, почему это проблема? Почему не устраивает приведение всего к опорной валюте? Имея кросс-курсы можно все остальные пересчитать в те же Рубли и получить единую точку отсчета, что, собственно, и делают все.
Ну вы поняли, что я имел в виду;)
DDL на создание 4х таблиц, гордо названный архитектурой - вот текущий уровень статей на хабре(
И как вы решили вопрос консистенции и согласованности данных для скорингов, если у вас тем более Хадуп?
Согласен, проекция собственного опыта: всегда были более-менее централизованные команды (и/или четкиe SLA по готовности данных, если поставляли их "во вне") и разброс часовых поясов максимум 2-3, поэтомут всегда было удобное "ночное окно".
То есть верно я понял, что по сути у вас множество систем с разными режимом готовности данных, ещё и размазанные по разным часовым поясам, и как следствие, нет того самого единого "технологического окна", которое могло бы быть точкой синхронизации всех процессов? И получается по сути у вас в течении 24 часов непрерывно то одна, то другая система поставляет новые порции данных, которые (учитывая упомянутую выше особенность) надо "добавлять" в отчёты/дашборты в течении "бизнес дня" и ещё готовить некие расчеты на основании поступивших данных для поставки внешним потребителям/системам?
Никогда.
Загрузка данных в дата платформу обычно всегда по расписанию в ночное окно (чтобы утром уже все было готово для бизнеса). Все процессы идемпотентны. Грамотно выстроенная оркестрация. Грустно выстроенная стратегия обновления и загрузки данных. Грамотная модель данных. Проверки качества и готовности данных.
Платформа данных - это про аналитику, а не операционную работу. По моему опыту, если ACID для платформы данных становиться критичным, то это говорит скорее об архитектурных проблемах платформы и загрузки данных в нее.
Если у вас есть пример обратного, с удовольствием готов предметно обсудить его (даже в личке, если не хотите публично) и даже обрадуюсь, если окажусь неправ.
Ну и кстати, в своей прокатике многолетней ни разу не встречал, чтобы отсутствие ACID как то мешало в Data Lake / Data Platform.
ACID как раз не накладывает никаких ограничений - то есть транзакция атомарна независимо от того, какие объекты БД и в каком количестве она затрагивает. Классическая СУБД , являясь умной надстройкой над файлам, позволяет по дефолту в рамках одной транзакции оперировать несколькими таблицами. Дельты и Айсберги же - нет
ACID фундаментален для реляционных баз данных и транзакционных систем. Для DWH он никогда не был фундаментальным, а пришел просто побочный эффект от реляционных БД, на которых строились долгое время DWH
Не совсем. Надо добавить, что только в рамках одной таблицы. Ну и кстати, отсутствие ACID в Дата Лейке особо никому не мешало никогда (по моему опыту)
Было успешно сделано до появления термина Lakehouse
Как и ДатаЛейк.
И далее в том же духе, нет смысла весь список приводить. Ещё и ,Data Governance и AI приплели, хотя к архитектурному походу они не имеют никакого отношения. Многовато неточностей и ошибок для директора направления Data Engineering ;)
Крутая идея. Спасибо! Плюсую!
Не могу сказать. У нас все на англ в компании.
Судя по CV он около 5 лет в Германии. Бакалавра получил в Тигеране, а магистра - буквально недавно уже в Германии.
Вы немного заблуждаетесь. Скала - отдельный самодостаточный ЯП. Даже применительно в Дата Инженерии это не "чисто апи к спарк джобам".
Вот примерно так 7 лет назад в нашей компании начинали строить Дата Платформу :))) Были простые бэкэндеры и фулл-стеки, которых попросили "сделать что-нить на Датабриксе для аналитики", ну они и начали делать :) В итоге через 4 года, когда наняли меня, у меня волосы дыбом встали от сделанного с т.з. архитектуры и от самого кода. То, что минимум 2 раза в неделю что-нибудь да падало на ПРОДе, даже молчу. Мой первый год в компании был посвящен поэтому перестройке и рефакторингу самых больных мест и выстраиванию процессов (от разработки, стандартов и до внедрения CI/CD). Так что хороший разработчик - не значит хороший дата инженер.
Иранец
Я тут нерелевантен) Когда был мидлом, мне было все новое интересно) Да и сейчас я ничего против не имею, если мне приходится разбираться с чем-то новым, пусть даже используемым весьма ограничено.
Касательно архитектурных решений. Они должны быть долгосрочные и соответствовать бизнес и дата стратегии компании. В частности например, если политика компании "платить в среднем по рынку, незаменимых нет" (знаю кстати примеры таких компаний), то это одна история - тогда, грубо, используем все "самое попсовое", делаем все просто, проблемы решаем экстенсивным увеличением команды за 5 копеек, миримся, что иногда будет "больно" и это будет неожиданно. Если же компания ориентирована на удержание кадров и инвестирование в их развитие, то это другое. Тут имеет смысл использовать что-то менее популярное, но более подходящее вашему бизнесу. ИМХО
Касательно declarative pipeline.
Я не сторонник продвигаемых вендорами направо и налево notebook-центричного похода (это делает что Майкрософт, что Датабрикс ...). Полностью понимаю их маркетинговых подход и с этой точки зрения даже не осуждаю - это хорошо продается (развесившим уши "эффективным менеджерам"), выглядит просто и, самое главное, привязывает клиента к твоей экосистеме. Но как архитектор, я стараюсь избегать такого подхода.
Конкретно в DBX-воркспейсе нашего юнита (но, к сожалению, не у других) нет ни одного пайплайна, реализованного как notebook. Мой (наш) подход:
все объекты в Unity Catalog создаются через DDL-операции, которые деплоятся как патчи
все пайплайны - только Spark-приложения, упакованные в fat JAR. В случае с Питоном это были бы whl
Если мы говори о Delta Live Tables, то бОльшую часть их функционала доступна так же через SQL-синтаксис, и тогда они деплоятся через DDL-операции как патчи. То есть Питон здесь не нужен. Если же без Питоне в них никак не обойтись, то в 90% это повод задуматься, а действительно ли тут DLT будут хорошим архитектурным решением?
Конкретно этот кандидат утверждал, что знает Скалу, использовал ее на прошлом месте, да и assesment сделал на вполне себе годной Скале. Поэтому вопросы типа "отличие val от var" рассматривались просто как "проверка на вшивость" - мол убедиться, что человек не LLM-ил бездумно и имеет хоть какие-то самые-самые базовые знания о Скале (а остальное - научим, как вы заметили).
И подход, ИМХО, оказался верным, так как чел сразу же поплыл, и стало понятно, что знаний и опыта со Скалой у него нет. Потом еще были general-вопросы про организацию загрузки данных, где чел тоже показал себя как джун, действующий по предоставленным ему шаблонам. То есть и сам технический собес и заданные вопросы своей цели достиг - выявить уровень кандидата через призму текущих потребностей команды.
Единственное, что по мере найма (и сложностей с поиском Скалистов) приоритеты нанимающего менеджера поменялись, но это уже не относится к самому техническому собеседованию
Учтите специфику Германии, где люди работают в компаниях десятилетиями) Срок на одном месте меньше 3-5 лет считается уже "минусом" для CV, рекомендуют не меньше 7 %) К тому же только испыталка - полгода, да и первые 3 месяца от нового сотрудника вообще обычно ничего не ждут.
Касательно overqualified - я с вами согласен. Но и менеджера понимаю. На его месте, если у меня не "горит", я бы тоже избегал overqualified-сотрудников. У меня перед глазами уже были примеры подобные, когда сотруднику было "тесно" на текущей позиции, но компания по объективным причинам, не могла ничего ему предложить бОльшего в плане проф.развития и задач.
Эх, как бы я не любил Скалу, но вынужден с вами согласиться, что, к сожалению, в Европе Скала превращается в легаси...
Но касательно поддержки Скалы Датабриксом не соглашусь с вами. Все, что можно сделать на Питоне, там можно сделать легко и на Скале. Просто про это нет 100500 статей и видео от "условных индусов" на Медиуме и Ютюбе, а надо открыть документацию. Единственно огорчает, и тут вы частично правы, что сам Датабрикс при реализации каких-то Датабрикс-лок фишек сначала выкатывает их для Питона и SQL, и уже попозже - для Скалы. Из последний примеров - тот же Serverless compute.
ЗЫ в холиваре Питон/Скала у каждого будет сове мнение и опыт) Я, например, долго был Питонистом, но когда в 2021м впервые был вынужден писать на Скале, достаточно быстро в нее "влюбился". И при следующей смене работы при решении тестовых заданий прям чуть ли не физически "страдал", когда приходилось делать их на Питоне - то, что на Скале было просто и изящно в 1-2 строки, на Питоне было намного "многословнее" и запутаннее и занимало 5-8 строк. Поэтому сейчас с грустью наблюдаю, что в Европе Скала постепенно увядает...