Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

Здравствуйте, дорогие друзья.

Сегодня хочу поделиться историей из жизни, как было устроено хранилище DWH в Tele2 до внедрения КХД (EDW).

Поступил я в ИТ подразделение Tele2 в 2012 в отдел по системам отчетности. На тот момент в компании уже было создано хранилище DWH, на котором уже крутилось много процессов по предоставлению отчетности и не только.

Немного по поводу технического стека, который там использовался на тот момент. Для хранилища использовалась Оракловая база объемом 60-100 Тб сервер T4-4 c оперативой под 1 Тб. Туда загружались данные из различных источников. Но основными из них были 4 оракловые биллинговые базы, которые были по сути платформой тарификации. И был отдел, который занимался поддержкой этих баз и предоставлением сервисов. Разделение этих баз было по макрорегионам. Причина: слишком большие объемы. Т.е если абонент звонит, скажем, из Московской сим-карты то и расчет стоимости звонка производится в соответствующем биллинге.

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

Привет, Хабр!

Мы с моим приятелем fedoref занимаемся разработкой и поддержкой решений на MS SQL.

Одной из наших проблем при работе с MS SQL было то, что без MS SQL Management Studio невозможно что-то сделать или проверить. А значит — всегда нужен под рукой компьютер и VPN в сеть клиента (или что посложнее). Нас это не устраивало — мы не всегда сидим перед монитором, а ситуации ингода требуют оперативности, особенно когда дело касается высоких нагрузок в real-time системах. Поэтому мы решили сделать телеграм-бота SQL. (Поискали готовые варианты на Github, но, увы, не нашли того, что нам подошло бы).

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

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

Ответственность за качество данных

"Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.

Типичный цикл работы по аналитической задаче выглядит так:

1. Бизнес приходит с проблемой и просит получить ответ.
2. Аналитики обсуждают с бизнесом, что надо сделать.
3. Аналитики поняли, что от них хочет бизнес и понимают, что им примерно нужно в данных.
4. Аналитики пишут запрос в DWH, чтобы получить данные.
5. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
6. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
7. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.

Любая операция с большими данными требует больших вычислительных мощностей. Обычное перемещение данных из базы на Hadoop может длиться неделями или стоить, как крыло самолёта. Не хотите ждать и тратиться? Сбалансируйте нагрузку на разные платформы. Один из способов – pushdown-оптимизация.

Я попросил ведущего в России тренера по разработке и администрированию продуктов Informatica Алексея Ананьева рассказать о функции pushdown-оптимизации в Informatica Big Data Management (BDM). Когда-то учились работать с продуктами Informatica? Скорее всего именно Алексей рассказывал вам азы PowerCenter и объяснял, как строить маппинги.

Алексей Ананьев, руководитель направления по обучению DIS Group

Что такое pushdown?

Многие из вас уже знакомы с Informatica Big Data Management (BDM). Продукт умеет интегрировать большие данные из разных источников, перемещать их между разными системами, обеспечивает к ним лёгкий доступ, позволяет профилировать их и многое другое.
В умелых руках BDM способен творить чудеса: задачи будут выполняться быстро и с минимальными вычислительными ресурсами.

Тоже так хотите? Научитесь использовать функцию pushdown в BDM для распределения вычислительной нагрузки между разными платформами. Технология pushdown позволяет превратить маппинг в скрипт и выбрать среду, в которой этот скрипт запустится. Возможность такого выбора позволяет комбинировать сильные стороны разных платформ и достигать их максимальной производительности.

Для настройки среды исполнения скрипта нужно выбрать тип pushdown. Скрипт может быть полностью запущен на Hadoop или частично распределен между источником и приемником. Есть 4 возможных типа pushdown. Маппинг можно не превращать в скрипт (native). Маппинг можно исполнить максимально на источнике (source) или полностью на источнике (full). Также маппинг можно превратить в скрипт Hadoop (none).

Практически каждый человек сталкивается с ведением какого-либо учета, сбором и анализом данных: от использования таблиц в экселе до работы с данными в клиент-банковском приложении. Повсеместно для такого учета используются различные системы управления базами данных (СУБД).

В статье я хотел бы рассказать о своем пути поиска такой системы.

Всем привет Хабровчане!!

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

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