Бизнес требования к хранилищу

Построение хранилища данных (например на базе аналитических СУБД — Arenadata, PostgrePro) — проект, требующий серьезной проработки и усилий со стороны бизнеса и поставщика информационных технологий. Наиболее эффективным подходом здесь будет совместный проект предприятия и компании, специализирующейся в этой области. Общемировая практика показывает, что хранилища данных создаются под конкретного заказчика. Серьезным преимуществом является наличие квалифицированного персонала, типовых Витрин Данных, а также отраслевой модели данных.

Хранилище может содержать:

— Учетную информацию о клиентах (персональные данные, адреса, телефоны)
— Информацию о банковских продуктах и услугах (кредиты, депозиты, пластиковые карточки, мобильный банк и т.д. )
— Данные об операциях (включая карточные) в минимальной детализации за последние 3 года
— Сведения о счетах, остатках на них и т.д.

Чтобы спроектировать хранилище данных (DWH, DataWareHouse),

нужно ответить на вопросы о требованиях к хранилищу в целом:
Нужно определиться с назначением этого хранилища:

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

• оно строится для BI системы;
• для сотрудников для формирования своих отчетов;
• общее решение для двух вариантов.

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

Далее отталкиваться от этого и проектировать систему. Делать сразу для всех не получится: отчеты будут работать правильно и приемлемо (по времени), если хранилище заточено на работу с ними. В случае с BI, в некоторых системах мы можем переложить часть ETL (процесс Extract-Transform-Loading) на сторону BI, но это зависит от выбранной системы.

В случае, если это только для BI, то нужно учитывать выбранную систему. Как писали выше, некоторые BI системы имеют свой мощный ETL и при этом это технология in-memory, что в разы сокращает время преобразования данных (чеки, остатки – большой поток данных, даже с учетом инкрементальной загрузки). Речь не о полном переносе трансформации в BI, а о совмещении инструментов.

В случае, если это для отчетов пользователей – то нужно понимать, какие запросы будут чаще всего делаться к хранилищу и затачивать его на эти конкретные запросы (80% всех запросов должны отрабатываться оптимально, 20% — нет, но они должны быть редкими)

В случае, если для обоих вариантов – все рассчитывается на уровне хранилища. BI – это просто инструмент визуализации (но вопрос зачем двойная отчетность).

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

Например: количество чеков может быть аддитивным и неаддитивным; остатки – нужны движения или предрассчитанные остатки, какой период нужен, частота обновления и т.д.

После этого шага можно будет спроектировать модель, реализовать в рамках пилотного проекта один из его блоков. Реализация позволит правильно оценить размеры хранилища (на n-ый период времени с учетом прироста).

Зачем нужны бизнес требования?

Построение хранилища данных:

1. Разработка Устава Проекта;
2. Создание на корпоративном web-портале (или иной web-системе) узла Проекта и формирование структуры web-узла:
3. библиотека бизнес-требований и методик;
4. раздел Протоколов рабочих совещаний, текущих задач;
5. подраздел обсуждений рабочих вопросов (возможно, в виде форума, трекинга);
6. разделы документации по хранилищу данных, витринам, OLAP-кубам;
7. система знаний (wiki);
8. библиотека регламентов;
9. раздел обучения, web-касты;
10. и другие разделы».
11. Сбор фрагментарных знаний о бизнес-процессах (БП) компании и метриках посредством проведения серий интервью с ключевыми бизнес-сотрудниками, экспертами. Формализация БП в виде укрупненных графических схем (например, BPMN-нотация);
12. Получение доступов к учетным системам (желательно к копиям; доступ как на чтение данных на уровне СУБД, так и просмотру данных через графический интерфейс пользователя);
13. Сбор и обсуждение методик, реализованных в существующих регламентных/управленческих отчетах;
14. Формулирование требований/ обсуждение методологий для новых/желаемых регламентных/управленческих отчетов;
15. Систематизация бизнес-требований (по результатам п.п 3, 5, 6) к составу атрибутов данных, которые должны быть отражены в хранилище данных;
16. Построение/актуализация и описание логических моделей учетных систем — источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
17. Описание/актуализация физических моделей (построение ER-диаграмм) учетных систем — источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
18. Анализ и формализация бизнес-требований к составу атрибутов данных (по п.п. 7, 8, 9), которые должны быть отражены в хранилище данных;
19. Подготовка технологической площадки для BI: сервер разработки, тестирования, производственного; установка серверного и прикладного программного обеспечения;
20. Разработка (возможно реинжиниринг существующих) процедур по извлечению необходимых данных (п. 10) из учетных систем в буферные таблицы (stage area); наполнение буферных таблиц;
21. Профилирование данных (по п.12), извлекаемых из учетных систем; систематизация статистики по метаданным и данным учетных систем;
22. Разработка логической модели хранилища данных;
23. Разработка структуры физической модели хранилища данных;
24. Разработка концептуальной схемы, подходов ETL-процессов по загрузке данных из учетных систем в хранилище данных;
25. Разработка карты мэппингов (поля source —> поля target);
26. Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных справочников из учетных систем в таблицы измерений (dimensions) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
27. Разработка процедур первичной/критической очистки/дедубликации данных справочников (совместно с п.18) [Проект НСИ (MDM) выполняется отдельным проектом/ подпроектом];
28. Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных из учетных систем в таблицы фактов (fact table, factless table) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
29. Тестирование:
30. контроль сходимости итогов по данным в учетной системе с итогами по данным таблиц хранилища;
31. скорости исполнения полного ETL-цикла»;
32. Доработка п.п. 18, 19, 20 по выявленным ошибкам, замечаниям по результатам работ п. 21;
33. Разработка структур витрин данных (агрегатных денормализованных таблиц/представлений). Выполняется поэтапно по предметным областям бизнеса;
34. Разработка ETL/ELT-процедур по обновлению витрин данных, расчету производных показателей (обогащение витрин данными);
35. Тестирование:
36. контроль сходимости итогов по данным витрин с итогами по данным учетных систем и итогами по данным таблиц хранилища;
37. скорости исполнения цикла обновления витрин данных»;
38. Разработка документации по хранилищу данных;
39. Разработка документации по витринам данных;
40. Выработка и согласование требований к аналитическим OLAP кубам (перечень измерений, метрик, доп. действий, разграничение прав доступа);
41. Разработка структур аналитических OLAP кубов, процедур обновления данных в кубах. Выполняется поэтапно по предметным областям бизнеса;
42. Тестирование аналитических кубов;
43. Подготовка, развёртывание инфраструктуры для публикации отчётов (репортинг, ad-hoc отчеты, OLAP) на web-портале (например, MS Sharepoint 2010 EE 64x + MS Reporting Services, возможно Gognos 10.х);
44. Разработка документации по аналитическим кубам, публикация документации на web-портале в системе знаний;
45. Разработка регламентных/управленческих отчётов (по п.п. 5, 6);
46. Публикация и систематизация регламентных/управленческих отчётов на корпоративном web-портале;
47. Обучение бизнес-пользователей интерактивному пользованию OLAP-кубами; выявление/формирование проактивных пользователей (power users);
48. Бизнес-пользователи (по возможности) самостоятельно формируют отчеты (по результатам п. 35); приемка и публикация отчетов осуществляется по согласованию с IT-аналитическим подразделением (возможно на первых порах).

Источник: datafinder.ru

Выбор оборудования для корпоративного облачного хранилища

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

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

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

Почему облако?

Облачная инфраструктура имеет ряд преимуществ:

Возможность быстрого масштабирования. Увеличение ёмкости и вычислительной мощности хранилища достигается с помощью быстрого подключения дополнительных серверов и СХД. Особенно это актуально для компаний, у которых нагрузка на облако предполагается нерегулярной.

Почему своё?

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

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

Выбор оборудования

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

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

Четко определить цель, для которой будет использоваться сервер. В нашем случае — это файловое хранилище. Соответственно, наибольший интерес представляют накопители. На что следует обратить внимание при их выборе:

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

В среднем для работы с текстовыми файлами, презентациями, PDF и небольшим количеством изображений нужно в среднем 10-15 Гб на сотрудника. Для работы с большими объемами высококачественных картинок и фотографий нужно увеличить минимум до 50-100 Гб, а то и больше. Потребности персонала, занимающегося обработкой видео и аудио, могут достигать нескольких терабайт на человека. В ряде случаев, например, при использовании крупных корпоративных программных пакетов с поддержкой версионности проектов, речь может идти и о 10 терабайтах на одного пользователя облака. Не забудьте учесть емкость под резервные копии файлов и непредвиденные нужды компании.

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

Также необходимо определиться с вычислительной мощностью. Если вы создаёте облачное хранилище на базе нескольких серверов, то рекомендуется подбирать идентичные или очень близкие конфигурации. Это несколько упростит управление распределением нагрузки. И вообще лучше не делать ставку на одну мощную машину, комплектуя её дорогим процессором и оперативной памятью, а купить подешевле 2-3 машины. Почему?

Если ваше хранилище будет только принимать и отдавать статичные файлы, без возможности их запуска, то мощность процессора не слишком важна. Поэтому лучше не гнаться за количеством ядер и выбрать модель с хорошим «тактом». Из недорогих вариантов неплохо подойдут процессоры Intel Xeon серии E56XX с 4 ядрами, из более дорогих моделей можно порекомендовать машины на Intel Core i5.

Примеры моделей серверов

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

Dell PowerEdge T110. Сервер оснащен процессором Intel Core i3 2120 с всего двумя ядрами, но зато каждое из них обладает неплохой тактовой частотой в 3,3 ГГц, что для нашего облака важнее. Начальная конфигурация оперативной памяти не очень велика — 4 Гб, однако может быть расширена до 32 Гб. Сервер поставляется в двух комплектациях — без предустановленного жесткого диска или с HDD-накопителем емкостью в 1 Тб и интерфейсом SATA.

Lenovo ThinkServer RS140. Имеет мощный процессор Intel Xeon E3 с четырьмя ядрами по 3,3 Ггц каждое. Оперативная память «из коробки» — 4 Гб, плюс еще четыре слота для ее расширения. Также в комплект входят два жестких диска по 1 Тб с SATA-интерфейсом.

HP ProLiant ML10 Gen9. Во многом схож с описанной выше моделью — всё тот же Intel Xeon E3 и два терабайтовых HDD. Основное отличие в оперативной памяти — сервер HP имеет две пластины по 4 Гб каждая.

Достаточно ли места для хранения файлов?

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

В случае виртуализации хранилища вы практически всегда (при разумном подходе к планированию СХД) сможете расширить дисковую подсистему виртуальной машины или увеличить LUN. В случае физического файлового сервера и локальных дисков, ваши возможности будут значительно скромнее. Даже не смотря на наличие свободных слотов в сервере для дополнительных дисков, можно столкнуться с проблемой подбора накопителей, подходящих для вашего RAID-массива.

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

Дисковые квоты NTFS

Один из самых старых и надежных механизмов ограничения пользователей — квоты файловой системы.

Включив квоты для тома, вы можете ограничивать объем файлов, сохраняемых каждым пользователем. В квоту пользователя попадают файлы, для которых на уровне NTFS он является владельцем. Главным недостатком механизма является то, что, во-первых, не так просто определить, какие файлы принадлежат конкретному пользователю, а во-вторых, файлы, созданные администраторами, не будут включены в квоту. Механизм квот редко используется на практике, его практически полностью заместил File Server Resource Manager, впервые появившийся в Windows Server 2003 R2.

File Server Resource Manager

Этот компонент Windows Server позволит квотировать дисковое пространство на уровне конкретной папки. Если вы выделяете для сотрудников персональные домашние каталоги на файловых серверах, а также выделенные папки для общих документов отделов, то FSRM — наилучший выбор.

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

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

Кроме того, FSRM включает в себя механизм «скрининга» (фильтрации) файлов, которые можно сохранять на сервере. Если вы уверены в том, что mp3- и avi- файлам не место на файловом сервере, то можно запретить их сохранения средствами FSRM.

Компрессия NTFS

Обычные файлы хорошо поддаются сжатию средствами NTFS, а с учетом производительности современных процессоров, у сервера достаточно ресурсов на эту операцию. Если места не хватает — можно смело включать её для тома или отдельных папок. К примеру, в Windows Server 2012 появился более совершенный механизм, при использовании которого NTFS-сжатие на файловых серверах для большинства сценариев остается в прошлом.

Дедупликация

Windows Server 2012 включает в себя возможность дедупликации данных, расположенных в томе NTFS. Это достаточно продвинутый и гибкий механизм, сочетающий в себе как дедупликацию с переменной длинной блока, так и эффективную компрессию сохраняемых блоков. При этом для разных типов данных механизм может использовать разные алгоритмы сжатия, а если сжатие не эффективно — не использовать её. Такие тонкости недоступны традиционному сжатию средствами NTFS.

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

Оценить потенциальную прибавку свободного места можно утилитой ddpeval. На типичном файловом сервере экономия составляет 30-50%.

Производительность файлового сервера

Как мы отмечали ранее — файловый сервер не самый требовательный к ресурсам сервис, но всё же следует разумно подойти к конфигурации дисковой и сетевой подсистем.

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

Если посмотреть на статистику Perfmon, средняя скорость чтения/записи для 150-200 пользователей достаточно низка и составляет всего лишь несколько мегабайт в секунду. Более интересны пиковые значения. Но следует иметь в виду, что и эти пики ограничены скоростью сетевого интерфейса, а для обычного сервера это 1 Гбит/с (т.е. 100 Мб обмена с дисковой подсистемой).

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

Для 150-200 сотрудников показатели достаточно скромны — 10-20 операций ввода вывода в секунду с дисковой очередью в пределах 1-2.

Этим требованиям удовлетворит любой массив из стандартных SATA дисков.

Для 500-1000 активных пользователей количетсво операции подскакивает до 250-300, а дисковая очередь достигает 5-10. Когда очередь достигает этой величины, пользователи могу заметить, что файловый сервер «подтормаживает».

На практике для достижения производительности в 300 IOPS вам уже потребуется массив как минимум из 3-4 дисков типичных SATA-дисков.

При этом следует учесть не только «сырую производительность», но и задержку, вносимую работой RAID-контроллера — так называемую RAID penalty. Эта тема доступно разъяснена в статье https://habrahabr.ru/post/164325/.

Для определения необходимого количества дисков используем формулу:

Total number of Disks required = ((Total Read IOPS + (Total Write IOPS*RAID Penalty))/Disk Speed IOPS)

RAID-5 с penalty на запись в 4 операции, профилем чтение 50%, запись 50%, скоростью диска в 75 IOPS, целевая производительность в 300 IOPS:

(300*0,5 + (300*0,5*4))/75 = 10 дисков.

Если у вас много активных пользователей, то вам потребуется ёмкий сервер или более производительные диски, такие как SAS со скоростью вращения 10 000 RPM.

Скорость сетевого интерфейса
Низкая скорость сетевого интерфейса — одна из причин задержек при работе с файловым сервером. В 2016 году сервер с 100 Мбит/с сетевой картой — нонсенс.

Типичный сервер оборудован сетевой картой со скоростью 1 Гбит/с, но и это ограничивает дисковый обмен скоростью около 100 Мб/с. Если в сервере несколько сетевых карт, то вы можете объединить их (агрегировать) в один логический интерфейс для увеличения как производительности, так и доступности облака. Хорошая новость в том, что для файлового сервера («много клиентов обращаются к одному серверу») агрегация работает хорошо.

Владельцы серверов HP могут использовать фирменную утилиту HP Network Configuration Utility

Если вы используете Windows Server 2012, то более простым и надежным способом будет использование штатного средства NIC Teaming.

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

• облачное хранилище
• файловый сервер

• Блог компании Сервер Молл
• Облачные вычисления
• Серверное администрирование

Источник: habr.com