Python: взаимодействие со сложным хранилищем данных

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

Есть ли лучшая / стандартная практика взаимодействия между Python и сложной структурой базы данных?

Я вкратце оценил SQLAlchemy, SQLObject и Django-ORM, но (я легко могу что-то упустить), похоже, они настроены для крошечных транзакций веб-типа (OLTP), где я выполняю аналитические транзакции большого объема (OLAP).

Некоторые из моих требований, которые могут отличаться от обычных:

  1. относительно быстро загружать большие объемы данных
  2. быстро и легко обновлять / вставлять небольшие объемы данных
  3. легко обрабатывать большое количество строк (300 записей в минуту в течение 5 лет)
  4. позволяют вносить изменения в схему для будущих требований

Написать эти запросы легко, но написать код, чтобы выровнять все данные, утомительно, особенно по мере развития схемы. Это похоже на то, в чем компьютер может быть хорош?


python data-warehouse olap sqlalchemy django-models
person bukzor    schedule 23.09.2010    source источник
comment
Я добавлю это в качестве комментария, но обычно ORM используются для OLTP, и попытка втиснуть их в отображение хранилища данных обычно вызывает больше проблем, чем оно того стоит.   -  person nos    schedule 24.09.2010
comment
Хотя ORM можно использовать для OLTP, они также могут упростить определенные виды обработки хранилища данных. Большинство запросов DW должны быть простыми select sum/count and group-by операциями. Их создание с помощью инструмента ORM может значительно сэкономить время.   -  person S.Lott    schedule 24.09.2010
comment
Будут ли запросы создаваться конечными пользователями? Какой интерфейс вы предоставляете и какие уровни свободы?   -  person shmichael    schedule 24.09.2010
comment
@shmichael: насколько я могу, но мы начнем с раскрывающихся списков с несколькими значениями из трех или четырех измерений.   -  person bukzor    schedule 25.09.2010

Ответы (3)


arrow_upward
6
arrow_downward

Не запутайтесь в своих требованиях. Один размер не подходит для всех.

относительно быстро загружать большие объемы данных

Почему бы не использовать для этого собственные загрузчики баз данных? Используйте Python для подготовки файлов, но используйте инструменты базы данных для загрузки. Вы обнаружите, что это невероятно быстро.

быстро и легко обновлять / вставлять небольшие объемы данных

Это начинает нарушать правила хранилища данных. Если вы не говорите об управлении основными данными для обновления атрибутов отчетности измерения.

Вот для чего нужны ORM и веб-фреймворки.

легко обрабатывать большое количество строк (300 записей в минуту в течение 5 лет)

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

легко изменить схему (вместе с интерфейсом Python) для будущих требований

У вас почти нет смысла автоматизировать это. Это определенно ваша задача с самым низким приоритетом для "программирования". Вы часто будете делать это вручную, чтобы правильно сохранить данные.

Кстати, «вручную созданные запросы, построенные с помощью строковых манипуляций», вероятно, является самой большой ошибкой за всю историю. С ними сложно справиться парсеру СУБД - они медленнее, чем запросы, в которые вставлены переменные связывания.

person S.Lott    schedule 23.09.2010
comment
Спасибо. Под alter я имел в виду не блокировать схему. Много раз при взаимодействии с базой данных вы достигаете определенного порога изменяемых строк кода, когда больше не стоит редактировать схему. Я бы хотел полностью избежать этой ситуации, если это возможно. - person bukzor; 24.09.2010
comment
При загрузке в базу данных, как вы обрабатываете новые данные, которые перекрывают старые? Или вы просто каждый раз загружаете все данные? Это кажется чрезмерно неэффективным. - person bukzor; 24.09.2010
comment
@bukzor: Хранилище данных (почти всегда) означает только вставку. Новые данные - по определению - являются новыми и не перекрывают старые. У него могут быть общие ключи, но он новый. Пожалуйста, найдите копию набора инструментов Kimball's Data Warehouse Toolkit, прежде чем продолжить. - person S.Lott; 24.09.2010
comment
Я получил это на прошлой неделе, но я все еще на главе 2 ... Означает ли это, что вы всегда начинаете с пустой базы данных? Помимо этого, по крайней мере, некоторые из моих данных будут перекрываться: завершаются задания, обновляются машины и т. Д. Я отмечаю, что почти все медленно меняющиеся типы размерности требуют обновления старых данных, чтобы срок их действия истек. - person bukzor; 24.09.2010
comment
@bukzor: обновить отчетные атрибуты измерения. Я считаю, что это вариант использования правильного SQL. вы всегда начинаете с пустой базы данных? Вроде. Часто размеры заранее известны. Вы редко знаете факты заранее. рабочие места заканчиваются, машины обновляются, для меня это звучит как обновления измерений. Это маленькие, изолированные, специализированные, редкие вещи. Не нравится загрузка факта, которая составляет 80-90% изменения базы данных. - person S.Lott; 24.09.2010

arrow_upward
3
arrow_downward

Я использую SQLAlchemy с довольно большим хранилищем данных, и я успешно использую его для всего процесса ETL. Особенно в определенных источниках, где у меня есть несколько сложных правил преобразования или с некоторыми разнородными источниками (такими как веб-сервисы). Я не использую Sqlalchemy ORM, а использую его язык выражений SQL, потому что мне действительно не нужно ничего сопоставлять с объектами в процессе ETL. Стоит отметить, что когда я беру дословную копию некоторых источников, я предпочитаю использовать для этого инструменты db - например, утилиту дампа PostgreSQL-. Вы не можете победить это. Язык выражений SQL является наиболее близким к написанию SQL от руки SQLAlchemy (или любого другого ORM), но поскольку вы можете программно сгенерировать SQL из python, вы сэкономите время, особенно если у вас есть несколько действительно сложных правил преобразования, которым нужно следовать.

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

person Mariano    schedule 23.09.2010
comment
+1: изменить мою схему вручную. Для этого слишком сложно написать инструмент - слишком много частных случаев. - person S.Lott; 24.09.2010
comment
у вас есть источники и цели на одном сервере? - person hugo24; 17.11.2010
comment
Позвольте мне посмотреть ...: один источник находится на том же сервере, а три других источника находятся на трех разных серверах (два postgresql, 1 mysql и 1 oracle - мои источники). Кроме того, я собираю данные из SalesForce SOAP WS и данные из некоторых приложений Google (Analytics и Calendar). - person Mariano; 26.11.2010

arrow_upward
2
arrow_downward

SQLAlchemy определенно. По сравнению с SQLAlchemy все остальные ORM выглядят как детские игрушки. Особенно Django-ORM. Что Hibernate для Java, SQLAlchemy для Python.

person dekomote    schedule 23.09.2010
comment
Я трижды пытался изучить SA ORM, и каждый раз сталкиваюсь с совершенно причудливыми ошибками, из-за которых я больше не хочу к нему прикасаться. Как ты это узнал? - person bukzor; 24.09.2010
comment
совершенно причудливые ошибки или мои предположения, которые оказались неправдой SA? Часто мы делаем предположения, обнаруживаем, что программное обеспечение не соответствует нашим предположениям, и называем все это странным. Без подробностей оценить ваше утверждение невозможно. Если у вас возникнут проблемы, опубликуйте их как вопросы. - person S.Lott; 24.09.2010
comment
@ S.Lott: Вы, наверное, правы, но после неоднократных попыток у меня возникает соблазн подумать, что если мои предположения неоднократно ошибались, то, вероятно, это не инструмент для меня. Меня интересует подход @ user184757; основной язык выражения SA кажется более разумным. - person bukzor; 24.09.2010