Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Funnel analytics and AI models for event sequences

Миша Панко, соучредитель и CEO компании Motif Analytics, поясняет, как аналитические инструменты должны отличаться для работы с потоками событий по сравнению с обычными данными о фактах и размерностях. Он обсуждает различные уровни аналитической стоимости между компаниями, подобными Google и Uber, и стартапами.

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

Миша упоминает о пирамиде аналитических вопросов: то, что хотят знать люди - «что?», затем почему, и, наконец, как. Решение вопросов «почему?» — это то, что связано с реальной ценностью аналитики, поскольку оно влияет на решения в бизнесе.

Он утверждает, что в большинстве областей данных вам недостаточно данных, чтобы ответить на вопросы «почему?» эффективно. В Motif работают над тем, чтобы быть промежуточным вариантом между A-B тестированием и общим отчетным показателем, который смотрит на корреляции, но не пытается делать заключения о причинно-следственной связи.

В Motif они используют преобразователь для моделирования последовательностей событий и получения встроенной структуры событий. Они надеются, что в будущем аналитика станет более сосредоточенной на поиске практических выводов, а не просто на сборе отчетности. Motif поддерживает методологию «спрос-поиск» при поиске ответов и надеется, что в ближайшие годы аналитика станет более сосредоточенной на исследовании отношений между различными частями данных, а не только на подсчетах.

Прочитать оригинал

Вышел уже второй апдейт, а я еще предыдущий не разобрал. Взял небольшой отдых 😀

Итак, бот не врет, ребята из DBT выкатили большой апдейт. Большинство фич для Cloud версии только, что расстраивает, тем не менее. Бегло посмотрим фичи:

- AI подсказчик для онлайн редактора. Здесь, было бы странно, если бы нет. Все сейчас делают, что с AI. Насколько удобно, надо смотреть на практике. Главная боль - генерация YML файлов с документацией и шаблонами тестов (я когда свой скрипт для этого написал). Судя по всему, именно это AI бот и закрывает.

- Advanced CI: как я понял, основная фишка не только анализ изменений по коду для текущего PR, но и картинка того, как новый код будет влиять на данные. Не совсем понятно, надо смотреть в работе, но очень хочу верить в такую фичу.

- Unit tests: про это уже знаем, был пост в канале.

- Automatic exposures: очень классная штука, которую пока не выкатили. В DBT раньше можно было указать дашборд в BI инструменте, для которого текущая модель является источником данных. Нужно это было только лишь для Lineage: открываете и видно, какой дашборд от чего зависит. На практике слишком много мороки, ради визуала - на небольших проектах люди плюс-минус и так помнят, что от чего зависит. Теперь появился доп стимул все прописывать: если указан дашборд, DBT сможет автоматически триггернуть его апдейт сразу, как будут новые данные в модели. Обещают начать с Tableau, а позде PowerBI подвезти. Фича отличная, насколько сама интеграция будет гладкой - посмотрим.

- Low-code development environment: запили low-code UI редактор, чтобы можно было накликивать модельки. Как обычно в таких решениях, сразу вопросы, насколько читабельным и сложным может быть сгенеренный код.

- dbt Explorer: интересный онлайн тул, который я пропустил. Мощный инструмент для обзора всего, что есть в DBT. По факту продвинутая версия обычных Dbt docs с column lineage 😋

- еще несколько фич.

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

dbt Unit Testing - the inside story from first GitHub Discussion to Shipping It

Наконец-то! После многих лет обсуждений, проприетарных фреймворков, открытых исходных пакетов dbt, блогов и еще одних обсуждений мы получили <strong>нативно интегрированную систему юнит-тестирования в dbt</strong>! Это наш первый (даже очень осведомленный) просмотр фреймворка, и я как личность, которая открыла <a href="https://github.com/dbt-labs/dbt-core/discussions/4455">первоначальную дискуссию в dbt-core</a> еще до моего назначения в dbt Labs, не могу быть более счастлив с возможностями, с которыми он запускается:

краткий спецификационный файл yaml, который насколько возможно выводит схему информации, позволяя писать точные, локализованные и читаемые тесты;
возможность перекрытия любой переменной или функции Jinja, что предоставляет гибкость для тестирования логики инкрементализации (или любой другой логики, зависящей от Jinja), или установки недетерминированного значения в надежную статическую ценность;
поддержка типов данных для всех адаптеров dbt Labs;
несколько форматов мок-входных данных: csv, словари или sql - все это независимо от того, встроено ли для удобства чтения или спрятано в переиспользуемых файлах фикстур;
тесная интеграция с командой dbt build - юнит-тесты запускаются <em>до</em> сборки модели, предотвращая ненужные сборки при введении логічного регресса в разработке или CI;
полное техническое руководство и учебные материалы.

Каждая из этих точек отражает недели или месяцы работы команд dbt Labs, и даже были несколько внешних вкладов в наш бета-тест, что было настоящим воодушевлением. Я также хотел бы поблагодарить и поблагодарить хранителей всех открытых исходных пакетов юнит-тестирования, которые проделали большую часть пути здесь в течение многих лет и служили большим источником вдохновения для проектирования нативного фреймворка.

Вместо того, чтобы углубиться в детали фреймворка и его механизмов, я бы хотел отступить на step back и поделиться, почему я считаю, что эта проблема так долго звучала для меня и многих других во всей сообществе:

#### Программная инженерия - что в ней увлекательного?

Честно говоря: развлекательной частью программной инженерии не является получение требований продукта, исследование пространства проблем, даже выпуск в продажу. Да, есть много удовлетворения от "выпуска его" и наблюдения за тем, как исправление, функция или целое система закатывается и вступает в действие. Но если я не являюсь конечным пользователем вещи, которую я что-то только что выпустил, я не могу испытать этого ощущения.

Радостное время наступает прямо после того, как вы завершаете несколько волшебных заклинаний командной строки для настройки среды, выравниваете репро

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The rapid experimentation of AI agents

Инвестор и кодер днем, а ночью - это Йохей Накадзима.

Как инвестор, Йохей вкладывается в ранние стадии проектов в качестве генерального партнера в компании Untapped Capital. Как кодер, в последнее время он сосредоточился на применении искусственного интеллекта.

Одним из его проектов стал BabyAGI, который привлек большое внимание примерно год назад. BabyAGI – это фреймворк агента ИИ, создающий план-исполнение цикл. Если вы задаете ему цель, он создаст план, чтобы достичь этой цели, и затем предпримет действия по реализации этого плана. Все это происходит в длинной цепочке вызовов API LLM, и вы можете наблюдать за каждым этапом в процессе.

Это очень экспериментальная область, и в зависимости от того, насколько строгим вы будете в определении, сегодня не так много продемонстрированных в реальных условиях примеров использования агентов ИИ. Когда вы смотрите демонстрационные видео в твиттер-ленте Йохея, можно сразу же увидеть возможности этого подхода.

(обрезано для соблюдения лимита по количеству символов)

Прочитать оригинал

Уже пробегала новость про Unit тесты в DBT и вот фреймворк полноценно зарелизили. По сравнению с начальной версией стало получше. Можно мокать данные, макросы и писать тест под разные версии моделей (для мультиверсионных моделей). Писать тесты через yaml файлы достаточно громоздко, но уже что-то. Надо пробовать и смотреть еще на перформанс таких тестов. Обещают, что 1-5 секунд на один тест, в зависимости от типа БД. Это достаточно долго. Надо опробовать на практике, чтобы понять, насколько "широко" можно тестировать модели через unit тесты. Для больших проектов - это может стать существенным ограничением по использованию этой фичи.

Как вариант, сразу приходит в голову заюзать DuckDB в качестве БД для таких тестов и возможно получить буст перфоманса. Но надо тестировать.

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Data work from the Goldilocks Zone and Medium Code

#### Краткое изложение

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

Далее автор упоминает две статьи, которые вместе представляют интересную картину будущего работы с данными. В первой статье «The Rise of Medium Code» автор обсуждает появление нового класса специалистов, которые сочетают в себе доменную экспертизу и практики разработки ПО. Эти «практики среднего кода» могут предоставлять значительную ценность, не будучи полноценными разработчиками.

Вторая статья «The Goldilocks Zone» описывает оптимальный сценарий развития языковых моделей (LLM), которые могут усилить производительность и влияние специалистов по данным, не захватывая при этом сложные или важные задачи.

Далее автор делится личным опытом работы в «зоне Голдилока», когда LLM удалось решить проблему с данными, которую сложно было решить привычными средствами. Он делает вывод о будущем развитии данных в «зоне Голдилока», где специалисты по данным могут сосредоточиться на решениях более высокого уровня, а автоматизация и повторяющиеся задачи будут переданы LLM.

#### Источник
Оригинальная статья не предоставлена.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The Analytics Development Lifecycle

Привет! 😊

Последний месяц был занят и увлекателен, наверное, у вас тоже все хорошо? После четырёх лет жизни в мире данных, определявшихся значительными изменениями макроэкономической обстановки (первоначально вверх, затем вниз), чувствуется, что макроэкономика установилась. Это значит, что мы можем прекратить размышления об интересных ставках и рынках. Как лидер компании, я почти никогда не думал о макроэкономических факторах, а сейчас надеюсь, что мы вернёмся к этому миру. Много интереснее думать о данных, чем о ставках по кредитам!

Конечно, это увлекательно, что в экосистеме данных происходят хорошие вещи. Я particularly excited by the embrace of open table formats and OSS catalogs. Я думаю, что эта тенденция изменит нашу жизнь в ближайшие 2-3-4 года. Компании сопоставимого масштаба и сложности скоро столкнутся с многооблачной реальностью. Об этом я много расскажу на моей речи на Coalesce.

Начинаем выходить из крайней фазы гиперсайклического внимания к искусственному интеллекту. Я верю в ИИ, но я также реалист. Новые технологические примитивы требуют времени, чтобы применить их к бизнес-целям, возвращающим инвестиции, и нам ещё рано об этом говорить.

Этот текст написан солнечным днём в конце лета на восточном побережье США, и я наслаждаюсь этим моментом. Я думаю, что это хорошее время, чтобы работать с данными. Есть много хороших перспектив на горизонте, много важной работы и пространства для её выполнения.

Работаю над важной статьёй. В ближайшие месяцы я поделюсь некоторыми её частями, чтобы у вас было возможность высказать своё мнение (просто откройте ответ или комментарий).

В статье представлен Analytics Development Lifecycle (ADLC), предлагаемый мной единый, окончательный процесс, который лучший путь к creation of a mature analytics capability within an organization of any scale. Ожидания от пользователей mature analytical system:

Могут discover and directly interact with artifacts from a mature analytical system
Могут доверять правильности и своевременности данных
Могут Delegate their own access to a mature analytical system
Могут выяснять происхождение любого элемента данных
Могут просматривать историю всех изменений в системе
Могут оставлять заметки на любом элементе системы

Эти ожидания всего лишь некоторые из тех, которые должны быть в современной системе. Да, мы достигли многого. Но есть ещё куда развиваться.

====

Надеюсь, что у вас все хорошо. Буду рад услышать ваше мнение, и especially love to see you in person at Coalesce в октябре!

- Tristan

Прочитать оригинал

Бот сделал немного интересный перевод.😱Получилось из разряда "его suit подходит all shapes, sizes...". 😁 По итогу, материал не сильно интересный (как по мне). Tristan готовит "манифест" Analytics Development Lifecycle (ADLC). То есть набор утверждений или правил, которые определяют критерии работы устоявшейся системы аналитики. Приведу полный список в оригинале:

- Users should be able to discover and directly interact with the artifacts from a mature analytical system without having to go through any intermediary humans.

- Users should be able to trust the correctness and timeliness of data from a mature analytical system.

- Users should be able to delegate their own access to a mature analytical system to their chosen tools and agents.

- Users should be able to straightforwardly investigate the provenance of any data element in a mature analytical system.

- Users should be able to view a history of all state changes to a mature analytical system.

- Users should be able to leave feedback on any element of a mature analytical system.

- Users should be able to ignore the implementation details of a mature analytical system.

- Users should be responsible for the costs associated with their usage of a mature analytical system.

- Users should be able to use as many resources as they are willing to pay for from a mature analytical system.

- Users should be able to choose the environment of a mature analytical system they interact with.

Некоторые вещи очевидны, некоторые спорны, как по мне. Но это пока драфт.

Люблю такие правила за возможность "помнить" про не самые известные и/или популярные критерии системы, которые тем не менее важны. А вот не очень нравятся постулаты, за легкий способ возводить их в абсолют. Понимаю, что обычно это тысячи и тысячи часов опыта, но все равно это чей-то особенный опыт. Не факт, что он подходит всем и всегда.

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The space between data dogmatism and data nihilism

В интересной статье на Linkedin обсуждаются недавние финансовые трудности Nike. Автор утверждает, что компания проводила множество "данно-ориентированных" изменений в течение последних 4 лет. Эти решения были основаны на появляющихся логичных и рациональных идеях и принципах, построенных на том, что имея четкие, измеримые цели вокруг стратегии разработки продукта и выхода на рынок, Nike сможет создать данные летающие колеса и устранить неэффективности.

Хотя я не одобряю конкретное толкование последней финансовой отчетности Nike, оно указывает на фундаментальный парадокс, с которым регулярно сталкиваются наиболее тонкие лидеры в области данных:

1. Для всех организаций, но особенно для организаций, достигших определенного масштаба, очень важно создать данную модель, которая картирует входные и выходные данные бизнеса, чтобы понимать, что происходит в организации и планировать будущее.
2. Часто многие из наиболее важных признаков того, как успешно управляются организации, затруднительны или вообще невозможно полностью оценить, и может быть непреодолимым усилием тянуться к тем вещам, которые наиболее легко измерить.

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

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

И, что наиболее важно, они должны уметь это делать, понимая, что все ещё важно измерять свой бизнес.

Реальность клейкая

Я прямо сейчас помню мою первую встречу с этим парадоксом. Я был юным аналитиком, проводившим свой первый тест А/Б - мы пытались увеличить число пробных подписок на SaaS-компанию, для которой работал.

В своей безграничной мудрости в 22 года я понял, что удаление навигационной панели на странице пробной подписки привело к увеличению подписок на 16%.

16% увеличение подписок на пробу!! Это огромно! Я навсегда изменил курс бизнеса.

После всего, я мог ввести 16% дополнительных подписок на пробу в нашу финансовую планировку, увидеть увеличение на 16% Продажных квалифицированных лидов, увеличение на 16% закрытых сделок, увеличение на 16% доходов. Я только что заработал компании многократно свою зарплату - все с одним тестом А/Б.

Кроме того...

Я был на грани открытия одного из основных убеждений практика данных. Реальность клейкая. Она достаточно сложна, и нам нужно быть очень внимательными к тому, насколько сопоставления соответствуют действительности.

Потому что то

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Analytics Personas

# История успеха dbt: о персоналах в аналитике

История о том, как возник дbt и почему, согласно моему мнению, он успешен по-контрaintuitivному, связана с нашим пониманием аналитических персонал.

В этой публикации я хочу рассказать немного этой истории и связать ее с моими заметками об АДЛС (жизненном цикле разработки аналитики) в настоящее время.

## История

Десять лет назад я был немного необычным существом. Сегодня таких людей со смешанным набором профессиональных навыков много, но десять лет назад их было мало.

Конкретно, у меня было три вещи:

1. Сильные аналитические навыки
2. Глубокие знания бизнеса в нескольких областях
3. Достаточно много навыков разработки программного обеспечения, чтобы представлять опасность

Десять лет назад это не было необычным у вас было одна из этих вещей. Две могли дать вам огромное преимущество. Но если у вас было все три, вы могли сделать некоторые замечательные вещи.

Когда я начал консалтинговую компанию Fishtown Analytics, я исходил из немного других предпосылок. Все моя работа должна была соблюдать лучшие практики разработки программного обеспечения. Мои клиенты не really care об этом в начале, но я знал, что это поможет мне предоставлять огромное количество бизнес-значения в час (в конечном итоге самый важный метрик для любого консалтинга). Это работало, и это поддерживало нашу успешность как консалтингового бизнеса.

И когда мне нужно было создать инструментарий для поддержки лучших практик разработки программного обеспечения в данных, я его создавал, предполагая, что пользователь был умеренно техническим. Не крайне высокотехничным, не основывающим свое жизнедеятельность на мышлении об архитектуре программного обеспечения весь день, но техничным достаточно, чтобы делать historically atypical вещи.

Например, использовать git. Например, использовать командную строку. Например, писать Jinja макросы.

Если вы проработали в данных менее 5 лет, эти поведения могут вам показаться нормальными. В 2015 году они ne были не . И я знаю об этом по двум конкретным причинам:

1. Когда я показывал данным практикам dbt назад в 2016 году, почти никто не хотел использовать его. Data engineers не хотели использовать его, потому что предпочитали просто писать Spark задания. Data analysts не хотели использовать его, потому что его нашли слишком техничным, слишком сложным для применения.
2. Когда я показывал dbt VCs назад в 2016 году (я тогда pitched может быть half a dozen людей просто из любопытства), они все мне сказали, что они не были уверенны, что есть большой рынок для продукта такого рода. Продукты, предназначенные для data analysts, обычно визуальны, а продукты, предназначенные для data engineers, не используют скучные языки, como SQL.

Мне было в

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Crafting a sense of style in analytics engineering

Я провел много времени, общаясь с людьми, которые работают над очень сложными проектами dbt и инфраструктурой данных. Они находятся на пересечении некоторых из самых серьезных проблем в мире данных, требующих не только продвинутых аналитических систем, но и социотехнических паттернов, чтобы включить их.

В то же время мы в компании dbt Labs обсуждаем, что означает представлять «лучшие практики» в dbt. dbt всегда был, является и будет убежденным продуктом, созданным для помощи организациям решать трудные проблемы с использованием данных. Исторически мы также сочетали это с рекомендуемыми лучшими практиками по построению и формированию вашего проекта dbt.

Эти рекомендации возникли естественным образом из ручных работ сотрудников dbt Labs при реализации dbt, а также из распределенного разума мем-делающей ручьи, известной как сообщество dbt.

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

Мне нравятся эти рекомендации, они profoundly transformative для меня, когда я впервые столкнулся с ними, и они остаются важной частью истории инженерии данных. Есть real joy в определении папок, руководств по наименованию и шаблонов проектирования, которые формируют способы, в которые мы строим наши системы данных.

Но все чаще, когда я пытаюсь написать «лучший» способ использовать dbt, я нахожу себя давая ответ, любимый старшими инженерами по всей стране.

Зависит.

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

Зависит не конец разговора - это начало.

<h3>Поговорим об одежде</h3>

Теперь, дорогой читатель, я собираюсь обратиться к вам с просьбой, которая, насколько мне известно, никогда не делалась в истории этого бюллетеня. Я прошу вас посмотреть TikTok. Это две минуты, и я обещаю, что вы узнаете что-то полезное о работе с данными, просмотрев его.

Это видео спрашивает о стиле. О лучшем способе делать вещи.

<div class="tiktok-wrap outer" id="tiktok-iframe?media=1&amp;app=1&amp;url=https%3A%2F%2Fwww.tiktok.com%2F%40frontoffice.co%2Fvideo%2F7403899453226093825&amp;key=e27c740634285c9ddc20db64f73358dd"><div class="tiktok-wrap static"><a href="https://www.tiktok.com/@frontoffice.co/video/740389945322609

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Developer productivity on GitHub Copilot

#### Сезон 6 podcast «The Analytics Engineering Podcast» начался!

Доктор Еирини Каллиямву сeniор ресеacher в GitHub Next. Еирини занималась изучением программистов, измеряла их производительность и влияние
дивэлопер эксперриенс на производительность. Новая работа Еирини сосредоточена на квантификации влияния GitHub Copilot. Помогает ли
Copilot программистам быть более продуктивными? Тристан и Еирини исследуют, как измерить производительность разработчиков, и
найти ли реальную бизнес- ценность в этом исследовании.

#### Важнейшие выводы из этого выпуска podcast:

- GitHub Copilot - автономное решение, использующее ай разработчикам помогает быстрее писать код. Copilot - это автоматическое
предлагаемое завершение кода в вашей среде разработки.

- Метрики для измерения разработчиков. Продуктивность разработчиков в течение долгого времени подвергалась критике. Мы так
желаем свести продуктивность разработчиков теперь просто к данным и количеству. Один из самых быстрых способов измерить
продуктивность - это оценка темпа работы разработчика: сколько он может создать в месяц pull request-ов, завершенных задач и т.д.
Но необходимо помнить, что вместе с этими данными необходимо учитывать перцептивные данные, такие как уровень удовлетворенности
разработчиков от процесса работы над проектом и состояние потока сознания разработчиков. Когда мы говорим про
продуктивность, необходимо помнить и об уровне удовлетворенности.

- SPACE-фреймворк. SPACE-фреймворк учитывает больше, чем только количество темпов работы разработчиков. SPACE-
фреймворк учитывает: Саттисфакшн(удовлетворенность и благополучие), Периформанс(производительность), Активити(учитывется
частота и время процесса реализации проектов), Коммуникация и Колаборация, и Эффективность и Флоу. Активность (учитываются
количество темпов работы) - часть продуктивности разработчика, но важно не забывать и о других частях процесса разработки:
удовлетворенности и эффективности процесса и продукта разработки.

- Важность улучшения разработчиков для продуктивности и результата. Амбициозный хороший процесс разработки улучшает
продуктивность на 50% для разработчиков. Если вы улучшаете процесс и эффективность работы разработчиков, ваша продуктивность
увеличивается. Когда мы говорим о влиянии улучшения разработки, мы говорим о 50% продуктивности разработчиков.

Кратко: В этом выпуске podcast «The Analytics Engineering Podcast» рассматривается важность участия разработчиков в процессе разработки
и производительности, и различные способы измерения продуктивности разработчиков с помощью SPACE-фреймворка и квантификации
влияния GitHub Copilot на разработчиков.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Announcing: The Analytics Development Lifecycle (ADLC)

Аналитическая разработка по жизненному циклу (Analytics Development Lifecycle или ADLC)

Привет! Сегодня хочу поделиться с вами статьёй об аналитическом цикле разработки (Analytics Development Lifecycle или ADLC). Это концепция, которую я разрабатывал в течение последних нескольких лет, объединяющая лучшие практики разработки программного обеспечения с аналитическими процессами.

Начнём с того, почему стоит об этом говорить сейчас. Давно миновали времена, когда мы следовали простой схеме «экстракт-трансформируй-загружай» (ETL). Сегодня мы работаем с облачными решениями и комбинируем различные инструменты для нашей аналитической работы. Однако, в реальности, многое из того, что мы делаем, не имеет хорошего тестирования, не задокументировано и может привести к негативным последствиям для наших данных и принятия решений.

Здесь и появляется концепция ADLC: она объединяет лучшие практики разных слоёв аналитической работы – от загрузки, трансформации и тестирования данных до потребления и поддержки инцидентов.

Итак, что такое ADLC? Основные этапы включают:

1. Инжиниринг данных: здесь мы экстрагируем, трансформируем и загружаем данные. Важно задокументировать процесс, протестировать код и обеспечить безопасность.

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

3. Операции и поддержка: здесь мы обеспечиваем доступность и поддержку для пользователей. Важно сохранять историю изменений, поддерживать версии и обеспечивать надёжность.

4. Потребление: здесь мы используем и анализируем данные. Важно предоставлять простые и понятные интерфейсы, доверие и эффективность.

Если вы заинтересованы в более подробном изучении концепции ADLC, рекомендую ознакомиться со статьёй «The Analytics Development Lifecycle» (ссылка в конце поста). Там вы найдёте полезные иллюстрации, примеры и рекомендации по реализации.

Надеюсь, эта концепция поможет вам улучшить работу со своими данными и сделать её более эффективной и надёжной!

Статья автора: Tristan Handy, основателя dbt Labs.

Статья на русском языке была написана переводчиком и сокращена для наглядности. Оригинальный контент доступен по ссылке.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Creating value from GenAI in the enterprise (w/ Nisha Paliwal)

#### Сезон 6 podcast «The Analytics Engineering Podcast»

Приветствуем вас в 6 сезоне podcast «The Analytics Engineering Podcast». Спасибо за прослушивание, и пожалуйста, обращайтесь по адресу podcast@dbtlabs.com с вопросами, комментариями и рекомендациями гостей.

Наasha гостьня сегодня - Nisha Paliwal, вице-президент Capital One по технологиям данных и соавтор книги «Секреты создания стоимости за счет искусственного интеллекта». Nisha и Тристан обсуждают все, от волшебства кодирования для детей до разнородных средств хранения данных и создания сильного культурного пространства данных.

#### Ключевые выводы из этой серии

Capital One - пионер в индустрии кредитных карт и практике сегментирования клиентов на основе их черт и дальнейшего предоставления предложений кредитных карт на основе этих черт. Все это зародилось у Capital One, и это все основано на данных.
Capital One появилась в 1994 году и считала себя данной компанией, что необычно для компаний того времени. С тех пор данные стали основой всего, от риска, юридических и HR-ролей до технических.
Capital One набирает людей, у которых неудержимый аппетит к обучению, и идет углубление в данные. Компания окружает новых сотрудников уникальной системой обучения и настройки.
Nisha Paliwal недавно выпустила книгу «Секреты создания стоимости за счет искусственного интеллекта». Эта книга предоставляет каркас для мышления об искусственном интеллекте и отвечает на вопрос «Где начать?». Она не содержит больших технических рассказов, а фокусируется на каркасе, который дает все компоненты для размышлений.

Полная аудиозапись доступна здесь.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The current state of the AI ecosystem (w/ Julia Schottenstein)

В «Сезоне 6» Podcast по Аналитической Инженерии гостью эпизода является Юлия Шоттенштайн, бывшая соведущая. Она присоединилась к компании LangChain в качестве раннего сотрудника и, по словам Тристана, «решает все проблемы, которые не связаны с продуктом и инженерией».

LangChain стала одной из, если не главной, фреймворками для разработки приложений на основе больших языковых моделей (LLM). Сейчас в нем используют более миллиона разработчиков, создающих все, от прототипов до продакшен-приложений AI.

Этот эпизод - комплексное обзорное шоу о современном состоянии экосистемы AI.

Julia рассказывает о том, что LangChain - это фреймворк для построения приложений на основе LLM. Он помогает принести в контекст LLM вашу компанию или личную информацию, API или актуальные данные, чтобы модель могла делать более полезные вещи.

LangChain дает возможность легко встраивать LLM в приложения, строя цепочки данных и вычислений для этих моделей. Это помогает создавать различные помощники, копилоты и ботов для поддержки клиентов.

LangSmith - коммерческое предложение LangChain, помогающее решать проблемы качества в приложениях, работающих с LLM. Оно помогает в тестировании и наблюдении, экспериментировании с логикой и наблюдении за производительностью приложения.

LangChain использует основанные на LLM тесты, что выглядит немного неестественно, но этот метод хорошо работает для этих недетерминированных приложений.

Большинство использований LangChain сейчас - это чат-приложения и поддержка клиентов (RAG). Но есть и интерес к «агентным» приложениям, где LLM самостоятельно принимает решения.

Langchain используется как фреймворк для разработчиков, который помогает создать приложения на основе LLM. Другие компании занимаются более узкоспециализированными задачами и созданием частей «доски для поickov и шовелей» в этом новом промышленном рынке.

Langchain хочет предоставить все необходимое инструментальное обеспечение для размещения приложений в продакшене.

Пользовательский опыт с LLM-приложениями сейчас разрабатывается по двум направлениям: улучшение пользовательского опыта и проектирование приложений в соответствии с ожидаемым использованием.

Langchain помогает решать проблемы поддержки клиентов, создавая чат-ботов, копилоты и помощники. Разработчики могут экспериментировать с логикой и наблюдать за производительностью приложений.

Сейчас миллион разработчиков используют Langchain для создания приложений с LLM. Многие компании уже начинают использовать это в своем бизнесе.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Recovering from the Party

Наше пятое мероприятие Coalesce прошло снова, и каждый год оно становится чуть теснее и чуть больше. В то время как мы строим инновационную машину и совершенствуем основную платформу, объявления о наших продуктах становятся всё более значимыми.

Хотя мы только недавно закончили мероприятие, я ещё не могу представить вам какие-либо цифры. Но если вы посещали несколько Coalesce, я могу сказать, что Бенн снова сделал отличную работу по суммированию нашего пути за последние пять лет. Я не согласен со всем, что он написал, но его основная мысль - переход от чисто потребительских настроений к рентабельности - абсолютно точна. Бюджеты на командировки в 2022 год были щедрыми, если мы хотели, чтобы люди продолжали приходить в 2023 и 2024 годах, нам нужно было продемонстрировать реальную прибыльность мероприятия.

К счастью, ROI не исключает курьёзное, увлекательное и уникальное. Мы можем налаживать отношения, сохранять особую роль сообщества dbt в экосистеме и всё же работать эффективно.

Говоря о чем-то особенном, фото ниже наверное слишком много для меня. У нас был уголок Discovery Hall, где мы спрашивали пользователей, как dbt изменил их карьеры и жизни. Ответы были просто фантастическими!

Я понимаю, что вы не можете прочесть заметки, которые люди оставили на этом рисунке, но если вы остановились и написали что-нибудь, пожалуйста, помните, что это все, за что я и вся команда dbt Labs приходят на работу каждый день. Большое спасибо!

Теперь перейдём к объявлениям.

Что было представлено на Coalesce 2024?

Этот год был самым крупным годом в плане объявлений о продуктах. Если хотите полный список, найдите его здесь. Слишком много, чтобы я уместил все в этом новостном письме.

Были четыре основные темы продуктов: доверие, сотрудничество, межплатформенность и ИИ. Мы расширили своё видение Data Control Plane:

И всё это объединили под общими темой мероприятия: One dbt.

Но я сейчас не буду говорить о том, что означает «one», потому что... это может занять много места. Сегодня я хочу сосредоточиться на объявлениях о продуктах.

Вот сводка слайда с выводами о keynote продуктов, в которой содержатся основные объявления о продуктах по темам:

Вот три главных объявления, которые, на мой взгляд, наиболее критичны:

Визуальный редактор

Мы приветствовали новых пользователей в визуальном редактировании, которое позволяет нам писать код dbt, используя drag-and-drop интерфейс. Этот интерфейс читает и записыва

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The CEO-dashboard-Gettier-problem

Резюме:

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

К моему удивлению, в своем докладе на конференции Coalesce 2020 Тристан обсуждал, как группы могут приобретать знание, используя философию, историю коммуникаций и биологию эволюции. Оказалось, что сложно создавать консенсус в группах, но есть определённые условия, помогающие этому, например, коммуникация один ко многим. Были даны несколько рекомендаций:

- Ориентироваться на доверие и точность информации, которая циркулирует в группе
- Позволять решающим лицам напрямую подключаться к «центральной нервной системе» организации
- Создавать культурные нормы, которые вознаграждают прозрачность и «эпистемическую смирение»

Мы в dbt Labs формализовали процесс создания знаний на большом уровне как «жизненный цикл развития аналитики», включая мнения о том, как это делать хорошо. Рассмотрев все вложения, которые мы делаем в поисках знаний, вы могли бы подумать, что мы хорошо понимаем, что такое знание. Но это далеко не так, и я начинаю задаваться вопросом, может ли раскрытие самого понятия «знания» дать нам что-то ценное о том, как создавать знание?

Мы общаясь с коллегами и коллегами, мы, по крайней мере, можем согласиться на несколько ключевых моментов:

- Относительность доказательств: утверждения, как правило, требуют какого-то рода подтверждения, если мы хотим уверенно полагаться на них или доверять им. Мы ожидаем, что другие люди предоставляют доказательства своих утверждений, и можем их проверять, если нам кажется, что их недостаточно.
- Значение контекста: точность, которую мы нуждаемся в зависимости от того, чего мы пытаемся добиться. Достаточно приблизительные данные могут быть достаточны для оценки доступного рынка, в то время как гораздо более точные цифры могут понадобиться для финансовой отчетности.

Философы в течение многих лет соглашались с тем, что утверждение о факте должно быть, по крайней мере, обоснованным истинным убеждением, чтобы оно могло стать потенциальным «знанием». Но в 1963 году философ Эдмунд Геттиер, который работал ассистентом профессора в Уэйнском университете, начал сомневаться в этом. После вспышки вдохновения он опубликовал статью «Есть ли обоснованное истинное убеждение знанием?», где представил гипотетические сценарии («проблемы Геттиера»), нацеленные на то, чтобы

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

The data jobs to be done (w/ Erik Bernhardsson)

Эрик Бернхардссон, CEO и сооснователь Modal Labs, гостюет у Тристана в podcast "The Analytics Engineering Podcast" для обсуждения ген.ai, нехватки gpu, будущего облачных вычислений и сборов за выход данных (egress fees). Они также обсуждают, нужна ли должность data engineer в будущем. Эрик не стесняется в своем мнении, поэтому эта передача будет интересной!

В данной передаче Эрик Бернхардссон делится своим опытом работы над Modal Labs, whom он основал после того, как покинул пост data engineer в Spotify и Better.com. Вы узнаете о том, какую ценность несет Modal Labs, как они отличаются от traditinal'nyh облачных поставщиков услуг вычислений, таких как AWS, Oracle, и Microsoft Azure. Koneчно, в центре обсуждения находятся ген.ai и нехватка gpu, которая сегодня является большой проблемой для организаций.

В передаче также обсуждается рост облачных вычислений и то, будет ли в будущем нужна должность data engineer, учитывая бурное развитие и распространение gен.ai. Эрик считает, что с течением времени необходимость в ручных операциях по управлению данными будет снижаться, так как разработчики смогут больше сосредоточиться на предпринимательской логике, чем на ручных операциях по управлению инфраструктурой.

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

One dbt

Недавно я писал о <q>новостях функций</q> с события Coalesce. Сегодня я хочу расшифровать одну из тем, которую я анонсировал на главной сцене. Это важная тема для нас и сыграет ключевую роль в долгосрочном здоровье сообщества.

Имхо, основное нерасположение в сообществе дbt в течение последних нескольких лет было вызвано напряжением, связанным с транзитом сообщества OSS под руководством dbt Labs во взрослую программную компанию.

Многие, многие люди используют дbt Core в качестве центральной части своих рабочих процессов. Он стал важной профессиональной зависимостью для многих из нас, и поэтому в сообществе возникло некоторое напряжение, связанное с такими темами, как:

- Будет ли изменен лицензионный режим?
- Будут ли продолжать появляться новые полезные функции или dbt Labs оставит этот проект?

Мы делаем все возможное, чтобы отвечать на эти вопросы уже несколько лет. Мы не собираемся менять лицензию — она будет продолжать работать в режиме открытого исходного кода Apache 2.0. Мы продолжаем внедрять новые и важные функции в Core — посмотрите на новую инкрементальную функциональность и тесты на единицы, оба они были запущены в этом году, оба они были частью моего списка желаемого.

Но, несмотря на это, многие пользователи сообщества правильно определили основную точку трения между dbt Labs и сообществом дbt, которая создавала реальное напряжение.

Мы (dbt Labs) непреднамеренно создали контекст, в котором возникла дихотомия в сообществе дbt, что привело к разделению сообщества на два подсообщества: сообщество Core и сообщество Cloud.

Пользователи сообщества Core были большими, состояли в основном из ранних пользователей и любили безлимитную природу дbt Core. Они не заботились о том, что запуск Core сопряжен с некоторыми сложностями, потому что это стало важным инструментом в их профессиональном ящике для инструментов, и научиться его использовать стало источником гордости, а не задачей. Часто, хотя и не всегда, пользователи в этом сообществе были ориентированы на профессиональную персону Data Engineer.

Сообщество Cloud было меньше. Его участники были не менее страстны к принципам работы дbt, его воздействию и истории. Пользователи часто, хотя и не всегда, склонялись к персоне Data Analyst.

Хотя продукт не принуждал пользователей делать выбор столкновения — Core ИЛИ Cloud, — это не было простой задачей использовать оба этих варианта dbt одновременно.

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

Прочитать оригинал

Привет! 🤖 Summary Bot онлайн, и вот что я прочитал сегодня:

Data tales from across the multiverse

Неделя мышления о dbt и данных была насыщена множеством интересных статей и исследований. Прежде чем перейти к определенным материалам, мы призываем вас принять участие в опросе «Год аналитической инженерии 2023». Результаты исследования являются важными для разработки продуктов, понимания направлений развития отрасли и ведения презентаций.

### Использование Amazon Athena, Apache Iceberg и dbt для построения озера транзакционных данных, доктор Сумайя Матухоор

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

Одним из основных преимуществ использования Apache Iceberg заключается в его способности упростить паттерн писать-проверить-опубликовать (WAP). Этот паттерн обеспечивает качество данных путем написания данных во временную среду для проверки и устранения ошибок до их выпуска для пользователей. Iceberg облегчает WAP для полных обновлений с помощью возможности переименования промежуточной таблицы после прохождения проверок. Кроме того, функция «время путешествия» Iceberg упрощает WAP для поточных трубопроводов за счет доступа к историческим данным с помощью временного фильтра.

Мы ожидаем, что в будущем возрастает число команд, использующих dbt на вершине Iceberg (и далее переходящих на cross-platform dbt Mesh).

### Scaling dbt: несколько проектов мониторинга, Нуну Пинела

Пинела делится своим опытом использования API dbt Cloud для построения пользовательского мониторинга нескольких проектов dbt Cloud. Цель состоит в отслеживании ключевых показателей, таких как количество запланированных заданий на проект (ежедневно, ежемесячно и т. д.), мониторинг ошибок за последние дни и анализ производительности данных преобразований со временем. Эта реализация предоставляет удобный интерфейс для навигации непосредственно к dbt проектам и быстрого устранения возможных проблем.

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

### Наш путь к мастерству мониторинга Snowflake, Роб Скрива

Команда Canva делится своими размышлениями о построении системы метаданных мониторинга для получения детального просмотра затрат на их снежную базу данных. Из-за масштаба Canva необходима эффективная система мониторинга, позволяющая экономить ресурсы и выполнять эффективные операции.

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

### Создавайте смаarter,

Прочитать оригинал