Forwarded from Инжиниринг Данных (Dmitry)
Практически каждый проект в инжиниринге данных начинается с package manager (пакетный менеджер), как правило для Python.
С одной стороны у всех цель одна, а с другой стороны “кто в лес, кто по дрова”.
Мне попались 3 хорошие статьи от Dagster на эту тему (про сам Dagster там нет), в которых хорошо рассказывают как это работает и как сделать удобно и красиво.
Python Packages: a Primer for Data People (part 1 of 2)
Python Packages: a Primer for Data People (part 2 of 2)
Best Practices in Structuring Python Projects
Вообще там 11 частей, в каждом посте будут ссылки на все части, например есть и другие полезные:
High-performance Python for Data Engineering
Write-Audit-Publish in data pipelines
Breaking Packages in Python
CI/CD and Data Pipeline Automation (with Git)
Factory Patterns in Python
Type Hinting in Python
Environment Variables in Python
Если вы еще на “вы” со всеми этими менеджерами, зависимостями или не очень понимаете, что творится у вас на работе в репозитории, то будет полезно ознакомиться.
С одной стороны у всех цель одна, а с другой стороны “кто в лес, кто по дрова”.
Мне попались 3 хорошие статьи от Dagster на эту тему (про сам Dagster там нет), в которых хорошо рассказывают как это работает и как сделать удобно и красиво.
Python Packages: a Primer for Data People (part 1 of 2)
Python Packages: a Primer for Data People (part 2 of 2)
Best Practices in Structuring Python Projects
Вообще там 11 частей, в каждом посте будут ссылки на все части, например есть и другие полезные:
High-performance Python for Data Engineering
Write-Audit-Publish in data pipelines
Breaking Packages in Python
CI/CD and Data Pipeline Automation (with Git)
Factory Patterns in Python
Type Hinting in Python
Environment Variables in Python
Если вы еще на “вы” со всеми этими менеджерами, зависимостями или не очень понимаете, что творится у вас на работе в репозитории, то будет полезно ознакомиться.
dagster.io
Python Packages Primer for Data People 1/2
Start mastering Python project structure with this guide to modules, imports, and package organization for data practitioners.
Forwarded from 5 minutes of data
Modern Data Stack: Где баланс между мощью и простотой?
Автор статьи на moderndata101 поднимает важный вопрос:
современные инструменты для работы с данными превратились в сложный «пазл»,
который мешает компаниям сосредоточиться на главном - извлечении ценности из данных.
Более 70% респондентов вынуждены использовать более 5-7 различных инструментов или работать с 3-5 поставщиками для различных задач. Около 10% используют более 10 инструментов, что показывает растущую сложность ландшафта данных.
Проблемы текущих data-стеков:
1. Фрагментация инфраструктуры
Раньше хватало SQL-базы и BI-инструмента. Сейчас компании используют десятки узкоспециализированных решений, которые слабо интегрируются друг с другом. Результат — «лоскутное» решение, где данные теряются на стыке систем.
2. Экономические и временные затраты:
Каждый новый инструмент - это:
• Лицензии,
• Обучение сотрудников,
• Настройка интеграций,
• Постоянные доработки под меняющиеся требования.
Команды тратят 60% времени на поддержку инфраструктуры вместо анализа.
3. Зависимость от экспертов:
Сложные стеки требуют узких специалистов, которых не хватает на рынке. Уход такого сотрудника может парализовать процессы.
4. Снижение гибкости:
Добавление новых источников данных или изменение ETL-процессов превращается в многонедельный проект из-за нагромождения технологий.
Что предлагает автор?
• Консолидация вместо фрагментации
Платформы, которые объединяют сбор, трансформацию, хранение и визуализацию данных (например, Databricks или Google BigQuery). Чем меньше «точек соприкосновения» между инструментами, тем ниже риски ошибок.
• Стандартизация процессов
Унификация форматов данных, API и протоколов (как в случае с Apache Arrow или Parquet). Это снижает порог входа для новых сотрудников и упрощает масштабирование.
• End-to-end решения
«Бесшовные» платформы, где данные перемещаются между этапами без ручных преобразований. Например, Snowflake с поддержку ML-моделей или Looker.
Сложность - не всегда признак продвинутости.
@data_whisperer
Автор статьи на moderndata101 поднимает важный вопрос:
современные инструменты для работы с данными превратились в сложный «пазл»,
который мешает компаниям сосредоточиться на главном - извлечении ценности из данных.
Более 70% респондентов вынуждены использовать более 5-7 различных инструментов или работать с 3-5 поставщиками для различных задач. Около 10% используют более 10 инструментов, что показывает растущую сложность ландшафта данных.
Проблемы текущих data-стеков:
1. Фрагментация инфраструктуры
Раньше хватало SQL-базы и BI-инструмента. Сейчас компании используют десятки узкоспециализированных решений, которые слабо интегрируются друг с другом. Результат — «лоскутное» решение, где данные теряются на стыке систем.
2. Экономические и временные затраты:
Каждый новый инструмент - это:
• Лицензии,
• Обучение сотрудников,
• Настройка интеграций,
• Постоянные доработки под меняющиеся требования.
Команды тратят 60% времени на поддержку инфраструктуры вместо анализа.
3. Зависимость от экспертов:
Сложные стеки требуют узких специалистов, которых не хватает на рынке. Уход такого сотрудника может парализовать процессы.
4. Снижение гибкости:
Добавление новых источников данных или изменение ETL-процессов превращается в многонедельный проект из-за нагромождения технологий.
Что предлагает автор?
• Консолидация вместо фрагментации
Платформы, которые объединяют сбор, трансформацию, хранение и визуализацию данных (например, Databricks или Google BigQuery). Чем меньше «точек соприкосновения» между инструментами, тем ниже риски ошибок.
• Стандартизация процессов
Унификация форматов данных, API и протоколов (как в случае с Apache Arrow или Parquet). Это снижает порог входа для новых сотрудников и упрощает масштабирование.
• End-to-end решения
«Бесшовные» платформы, где данные перемещаются между этапами без ручных преобразований. Например, Snowflake с поддержку ML-моделей или Looker.
Сложность - не всегда признак продвинутости.
@data_whisperer
Forwarded from Data Engineering Zoomcamp
Hi everyone!
The content and the homework for module 6 are ready
You can start working on the module
Module: https://github.com/DataTalksClub/data-engineering-zoomcamp/tree/main/06-streaming
Homework: https://github.com/DataTalksClub/data-engineering-zoomcamp/blob/main/cohorts/2025/06-streaming/homework.md
The homework is based on the PyFlink stream that Zach did, so you can treat the rest of the videos in module 6 as optional
Have fun and let us know in Slack if you have any problems
The content and the homework for module 6 are ready
You can start working on the module
Module: https://github.com/DataTalksClub/data-engineering-zoomcamp/tree/main/06-streaming
Homework: https://github.com/DataTalksClub/data-engineering-zoomcamp/blob/main/cohorts/2025/06-streaming/homework.md
The homework is based on the PyFlink stream that Zach did, so you can treat the rest of the videos in module 6 as optional
Have fun and let us know in Slack if you have any problems
GitHub
data-engineering-zoomcamp/06-streaming at main · DataTalksClub/data-engineering-zoomcamp
Data Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. The next cohort starts in January 2026. Join the course here 👇🏼 - DataTalksClub/data-engineering-zoomcamp
Forwarded from DataJourney
Немного истории Greenplum
В продолжение новости про документацию GP. Порой, в поисках доки или каких-то решений в поисковике можно попадать на разные сайты или на мертвые ссылки, которые вроде бы должны описывать то или иное поведение. А все по той причине, что история владения Greenplum сложна:
2005 год, компания Greenplum Software выпускает продукт Bizgres – СУБД, основанную на коде PostgreSQL, которая умеет в колоночное хранение и горизонтальное масштабирование;
2010 год, компанию поглощает компания EMC (ныне Dell EMC), продукт сохраняет название компании и теперь называется Greenplum Database;
2012 год, из EMC выходит компания Pivotal, которая продолжает разработку, а продукт теперь называться Pivotal Greenplum Database;
2013 год, Pivotal презентует вариант Greenplum с хранением данных файловой системе Hadoop, который называет Hawq;
2015 год, Pivotal выкладывает код Greenplum DB и Hawq в OpenSource;
2019 год, компанию Pivotal поглощает компания VMware, продукт теперь называется VMware Greenplum;
2020 год, VMware презентует VMware Tanzu Greenplum – вариант Greenplum для разворачивания в облаке;
2022 год, Broadcom анонсирует крупную сделку и покупает VMware целиком по рыночной стоимости;
2024 год, Broadcom закрывает код Greenplum (github)
Что будет дальше? А дальше все в тумане. Ближе всего к нам есть Greenplum от Аренадаты, но это уже не OpenSource.
В продолжение новости про документацию GP. Порой, в поисках доки или каких-то решений в поисковике можно попадать на разные сайты или на мертвые ссылки, которые вроде бы должны описывать то или иное поведение. А все по той причине, что история владения Greenplum сложна:
2005 год, компания Greenplum Software выпускает продукт Bizgres – СУБД, основанную на коде PostgreSQL, которая умеет в колоночное хранение и горизонтальное масштабирование;
2010 год, компанию поглощает компания EMC (ныне Dell EMC), продукт сохраняет название компании и теперь называется Greenplum Database;
2012 год, из EMC выходит компания Pivotal, которая продолжает разработку, а продукт теперь называться Pivotal Greenplum Database;
2013 год, Pivotal презентует вариант Greenplum с хранением данных файловой системе Hadoop, который называет Hawq;
2015 год, Pivotal выкладывает код Greenplum DB и Hawq в OpenSource;
2019 год, компанию Pivotal поглощает компания VMware, продукт теперь называется VMware Greenplum;
2020 год, VMware презентует VMware Tanzu Greenplum – вариант Greenplum для разворачивания в облаке;
2022 год, Broadcom анонсирует крупную сделку и покупает VMware целиком по рыночной стоимости;
2024 год, Broadcom закрывает код Greenplum (github)
Что будет дальше? А дальше все в тумане. Ближе всего к нам есть Greenplum от Аренадаты, но это уже не OpenSource.
Forwarded from DataJourney
Кто такой Apache Iceberg
В последнее время вокруг всё больше и больше информации про озера данных и какое-то слово «Iceberg», которое позволяет строить такие хранилища. До ознакомления с вопросом, я ошибочно полагал, что Iceberg - это просто новый формат файла по аналогии с Parquet или Avro, которй предлагает какие-то новые фичи, которых не было до него.
На самом же деле, Iceberg - это некий протокол, который описывает договоренность по укладке файлов в хранилище, чтобы потом эти файлы можно было удобно с хранилища поднимать и выполнять к ним запросы. При этом сами файлы, которые физичеки находятся на диске, имеют уже знакомые форматы: Parquet, Avro или ORC. Рядом с файлами данных лежат статистики - отдельные файлы, в которых описано их содержимое: максимумы, распределения, количество и т.п.
Команда Iceberg написала реализацию протокола для некоторых движков (вот, например, jar для Apache Spark 3), что позволило достаточно комформтно начать работать работать с новым форматом на имеющихся инсталяциях этих самых движков. По сути, администратору нужно добавить пару библиотек и дать доступ к бакету S3, чтоб начать использование.
Пощупать Iceberg локально в связке со с Spark можно с помощью Docker и нехитрой инструкции из официальной документации: https://iceberg.apache.org/spark-quickstart/
В последнее время вокруг всё больше и больше информации про озера данных и какое-то слово «Iceberg», которое позволяет строить такие хранилища. До ознакомления с вопросом, я ошибочно полагал, что Iceberg - это просто новый формат файла по аналогии с Parquet или Avro, которй предлагает какие-то новые фичи, которых не было до него.
На самом же деле, Iceberg - это некий протокол, который описывает договоренность по укладке файлов в хранилище, чтобы потом эти файлы можно было удобно с хранилища поднимать и выполнять к ним запросы. При этом сами файлы, которые физичеки находятся на диске, имеют уже знакомые форматы: Parquet, Avro или ORC. Рядом с файлами данных лежат статистики - отдельные файлы, в которых описано их содержимое: максимумы, распределения, количество и т.п.
Команда Iceberg написала реализацию протокола для некоторых движков (вот, например, jar для Apache Spark 3), что позволило достаточно комформтно начать работать работать с новым форматом на имеющихся инсталяциях этих самых движков. По сути, администратору нужно добавить пару библиотек и дать доступ к бакету S3, чтоб начать использование.
Пощупать Iceberg локально в связке со с Spark можно с помощью Docker и нехитрой инструкции из официальной документации: https://iceberg.apache.org/spark-quickstart/
Forwarded from DataJourney
…продолжаю про Iceberg
Попробую вкратце описать фичи протокола, который делает его таким популярным. Первое, о чем хочется поговорить и самое главное, на мой взгляд, - это пачка статистики и описаний, которая лежит рядом с дата файлами и содержит информацию, которую используют движки расчета для того, чтоб поднимать данные из S3. Несмотря на все свершения человечества, одной из самых медленных операций по прежнему остаётся подъем данных с диска и все системы, которые оперируют с данными, стараются уменьшать количество байт, которые читаются в память. У Iceberg эти принципы вшиты прямо в протокол.
На картинке к посту изображена схема хранения из документации Iceberg (github link). Условно, протокол делит все данные на три большие части (снизу-вверх):
1️⃣ Собственно сами данные. Это файлы в форматах Parquet, Avro или ORC. Тут никакой магии. Просто данные, просто на хранилище.
2️⃣ Слой метаданных. Тут уже начинается магия связи верхнеуровнего объекта «таблица» с множеством файлов из первого пункта. Имеем три группы файлов:
файлы манифеста, который описывает файлы с данными: их расположение, статистики столбцов и партиции;
файлы со списком файлов манифеста, который описывает обобщенные статисткии уже файлов манифестов и их перечень;
файлы метаданных, который описывает «таблицу» в целом, списки манифестов для каждого конкретного снэпшота. Эти же файлы обеспечивают изоляции по принципам MVCC. Если два процесса одновременно собираются читать и писать данные, то создается копия файлов, достаточная для того, чтобы каждый процесс получил доступ к данным изолированно. Каждая такая копия - это снапшот. О них детальнее поговорим позже, но даже на этой схеме уже видны две версии таблицы db1.table1: S0 и S1, для которых хранятся отдельные наборы файлы манифестов, метаданных и данных. При этом, для обеспечения изоляции, в моменте файлы с данными будут дублироваться, что приведет к повышенному потребелению ресурсов дискового пространства.
3️⃣ Каталог. Некая сущность, которая умеет хранить информацию о связи «объект таблица» - «набор метаданных». Единственное требование к каталогу - уметь инфомрацию перезаписывать атомарно. Так, чтобы два процесса одновременно не смогли создать конкурирующие наборы файлов. Поговорим о каталогах чуть поздней.
Таким образом, получается, что для записи информации в формате Iceberg движок должен последоватльно создать записи в трёх местах:
1. Записать данные на хранилище.
2. Посчитать агрегаты и записать их в слой метаданных.
3. Записать информацию о привязке новых метаданных в каталог.
При этом есть одна вещь, про которую следует помнить. Информация, которая указана в манифесте - даётся под «честное слово». Так как Iceberg это не управляющая программа, то никто не проверяет действительно ли есть файл данных, если он указан в манифесте. Действительно ли существуют ограничения (uniq, not null, order) если они указаны в манифесте.
Попробую вкратце описать фичи протокола, который делает его таким популярным. Первое, о чем хочется поговорить и самое главное, на мой взгляд, - это пачка статистики и описаний, которая лежит рядом с дата файлами и содержит информацию, которую используют движки расчета для того, чтоб поднимать данные из S3. Несмотря на все свершения человечества, одной из самых медленных операций по прежнему остаётся подъем данных с диска и все системы, которые оперируют с данными, стараются уменьшать количество байт, которые читаются в память. У Iceberg эти принципы вшиты прямо в протокол.
На картинке к посту изображена схема хранения из документации Iceberg (github link). Условно, протокол делит все данные на три большие части (снизу-вверх):
файлы манифеста, который описывает файлы с данными: их расположение, статистики столбцов и партиции;
файлы со списком файлов манифеста, который описывает обобщенные статисткии уже файлов манифестов и их перечень;
файлы метаданных, который описывает «таблицу» в целом, списки манифестов для каждого конкретного снэпшота. Эти же файлы обеспечивают изоляции по принципам MVCC. Если два процесса одновременно собираются читать и писать данные, то создается копия файлов, достаточная для того, чтобы каждый процесс получил доступ к данным изолированно. Каждая такая копия - это снапшот. О них детальнее поговорим позже, но даже на этой схеме уже видны две версии таблицы db1.table1: S0 и S1, для которых хранятся отдельные наборы файлы манифестов, метаданных и данных. При этом, для обеспечения изоляции, в моменте файлы с данными будут дублироваться, что приведет к повышенному потребелению ресурсов дискового пространства.
Таким образом, получается, что для записи информации в формате Iceberg движок должен последоватльно создать записи в трёх местах:
1. Записать данные на хранилище.
2. Посчитать агрегаты и записать их в слой метаданных.
3. Записать информацию о привязке новых метаданных в каталог.
При этом есть одна вещь, про которую следует помнить. Информация, которая указана в манифесте - даётся под «честное слово». Так как Iceberg это не управляющая программа, то никто не проверяет действительно ли есть файл данных, если он указан в манифесте. Действительно ли существуют ограничения (uniq, not null, order) если они указаны в манифесте.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Грефневая Кафка (pro.kafka)
🔴 Чат, вы не просили, но я сделяль ™
Я возобновляю стримы на канале Confluent Developer (отличный от корпоративного канала, где я раньше стримил, back in a day).
Please, welcome - Streaming Frontiers - Where No Data Streaming Engineers Has Gone Before.
Планирую выходить лайв хотя бы раз в месяц, если понравится аудитории, то чаще.
Формат будет - «Витя делает вид что понимает что-то в программировании и в Кафке».
Заходите на огонек завтра, где мы поковыряем Confluent Extension для VS Code и попробуем сделать что-то интересное с ним.
Слылка https://www.youtube.com/watch?v=qzTzo7VLx9c
Я возобновляю стримы на канале Confluent Developer (отличный от корпоративного канала, где я раньше стримил, back in a day).
Please, welcome - Streaming Frontiers - Where No Data Streaming Engineers Has Gone Before.
Планирую выходить лайв хотя бы раз в месяц, если понравится аудитории, то чаще.
Формат будет - «Витя делает вид что понимает что-то в программировании и в Кафке».
Заходите на огонек завтра, где мы поковыряем Confluent Extension для VS Code и попробуем сделать что-то интересное с ним.
Слылка https://www.youtube.com/watch?v=qzTzo7VLx9c
Forwarded from Николай Крупий
GitHub
GitHub - Datavault-UK/automate-dv: A free to use dbt package for creating and loading Data Vault 2.0 compliant Data Warehouses…
A free to use dbt package for creating and loading Data Vault 2.0 compliant Data Warehouses (powered by dbt, an open source data engineering tool, registered trademark of dbt Labs) - Datavault-UK/...
Forwarded from Data Engineering Digest
Самые интересные слайды из доклада про каталог данных)
Forwarded from Ivan Begtin (Ivan Begtin)
Что я понял про дата инженерию за N лет работы с данными:
1. Из всех ресурсов всегда более всего, почти всегда, нехватает места для хранения и каналов для передачи данных. А когда начинает хватать, то потребности вырастают
2 Держи данные сжатыми, желательно всегда, но выбирая между способами сжатия выбирай те что позволяют использовать данные при потоковом разжимании данных.
3. Всегда имей архивную копию данных которые когда либо использовались. Если только нет юридических ограничений и ограничения в хранилищах не припёрли жёстко к стенке.
4. Не документировать данные тяжкий грех. Большинство патологические тяжкие грешники.
5. Если ты не платишь за данные поставщику они могут исчезнуть из доступа в любой момент. Если платишь то тоже, но реже и можно быстрее отреагировать.
6. Инструментарий очень быстро меняется, зацикливаться на инструментах 10-15 летней давности опасно для потери квалификации.
7. Все ненавидят облака, но жрут этот кактус. Иногда надо заставлять других этот кактус есть . Пользователей жалко, но всё идет туда.
8. Владей хотя бы одним ETL/ELT инструментом хорошо и ещё 2-3 хотя бы базово.
9. Данные всегда грязные. С небольшими табличками аналитики могут справиться сами, а большие требуют навыков дата инженеров.
10. Командная строка имеет значение (с). Многое работает значительно быстрее и эффективнее с командной строки.
Добавляйте ваши пункты😜
#dataengineering #thoughts
1. Из всех ресурсов всегда более всего, почти всегда, нехватает места для хранения и каналов для передачи данных. А когда начинает хватать, то потребности вырастают
2 Держи данные сжатыми, желательно всегда, но выбирая между способами сжатия выбирай те что позволяют использовать данные при потоковом разжимании данных.
3. Всегда имей архивную копию данных которые когда либо использовались. Если только нет юридических ограничений и ограничения в хранилищах не припёрли жёстко к стенке.
4. Не документировать данные тяжкий грех. Большинство патологические тяжкие грешники.
5. Если ты не платишь за данные поставщику они могут исчезнуть из доступа в любой момент. Если платишь то тоже, но реже и можно быстрее отреагировать.
6. Инструментарий очень быстро меняется, зацикливаться на инструментах 10-15 летней давности опасно для потери квалификации.
7. Все ненавидят облака, но жрут этот кактус. Иногда надо заставлять других этот кактус есть . Пользователей жалко, но всё идет туда.
8. Владей хотя бы одним ETL/ELT инструментом хорошо и ещё 2-3 хотя бы базово.
9. Данные всегда грязные. С небольшими табличками аналитики могут справиться сами, а большие требуют навыков дата инженеров.
10. Командная строка имеет значение (с). Многое работает значительно быстрее и эффективнее с командной строки.
Добавляйте ваши пункты😜
#dataengineering #thoughts
Forwarded from Big Data Science
🛠 Another Roundup of Tools for Data Management, Storage, and Analysis
🔹 DrawDB – A visual database management system that simplifies database design and interaction. Its graphical interface allows developers to create and visualize database structures without writing complex SQL queries.
🔹 Hector RAG – A Retrieval-Augmented Generation (RAG) framework built on PostgreSQL. It enhances AI applications by combining retrieval and text generation, improving response accuracy and efficiency in search-enhanced LLMs.
🔹 ERD Lab – A free online tool for designing and visualizing Entity-Relationship Diagrams (ERD). Users can import SQL scripts or create new databases without writing code, making it an ideal solution for database design and documentation.
🔹 SuperMassive – A distributed, fault-tolerant in-memory key-value database designed for high-performance applications. It provides low-latency access and self-recovery, making it perfect for mission-critical workloads.
🔹 Smallpond – A lightweight data processing framework built on DuckDB and 3FS. It enables high-performance analytics on petabyte-scale datasets without requiring long-running services or complex infrastructure.
🔹 ingestr – A CLI tool for seamless data migration between databases like Postgres, BigQuery, Snowflake, Redshift, Databricks, DuckDB, and more. Supports full refresh & incremental updates with append, merge, or delete+insert strategies.
🚀 Whether you’re designing databases, optimizing AI pipelines, or managing large-scale data workflows, these tools will streamline your work and boost productivity!
🔹 DrawDB – A visual database management system that simplifies database design and interaction. Its graphical interface allows developers to create and visualize database structures without writing complex SQL queries.
🔹 Hector RAG – A Retrieval-Augmented Generation (RAG) framework built on PostgreSQL. It enhances AI applications by combining retrieval and text generation, improving response accuracy and efficiency in search-enhanced LLMs.
🔹 ERD Lab – A free online tool for designing and visualizing Entity-Relationship Diagrams (ERD). Users can import SQL scripts or create new databases without writing code, making it an ideal solution for database design and documentation.
🔹 SuperMassive – A distributed, fault-tolerant in-memory key-value database designed for high-performance applications. It provides low-latency access and self-recovery, making it perfect for mission-critical workloads.
🔹 Smallpond – A lightweight data processing framework built on DuckDB and 3FS. It enables high-performance analytics on petabyte-scale datasets without requiring long-running services or complex infrastructure.
🔹 ingestr – A CLI tool for seamless data migration between databases like Postgres, BigQuery, Snowflake, Redshift, Databricks, DuckDB, and more. Supports full refresh & incremental updates with append, merge, or delete+insert strategies.
🚀 Whether you’re designing databases, optimizing AI pipelines, or managing large-scale data workflows, these tools will streamline your work and boost productivity!
GitHub
GitHub - drawdb-io/drawdb: Free, simple, and intuitive online database diagram editor and SQL generator.
Free, simple, and intuitive online database diagram editor and SQL generator. - drawdb-io/drawdb