WEBVTT

00:00:08.802 --> 00:00:10.642
Здравствуйте, уважаемые студенты.

00:00:10.922 --> 00:00:14.762
Вашему вниманию предлагается лекция по
дисциплине «Использование больших данных в

00:00:14.842 --> 00:00:16.082
информационной системе».

00:00:16.602 --> 00:00:19.722
Тема лекции — технологии больших данных,
часть вторая.

00:00:20.762 --> 00:00:25.563
Лекция третья. Лекцию ведёт кандидат
технических наук, доцент Ченищук Виктор.

00:00:28.590 --> 00:00:31.826
План лекции: хранилище данных, эволюция и
общие основы.

00:00:31.986 --> 00:00:35.062
Большие данных, данные и хранилища данных.

00:00:35.222 --> 00:00:39.017
Переходы к архитектуре и принципам
проектирования хранилищ данных.

00:00:39.217 --> 00:00:40.775
Системы хранения данных.

00:00:40.895 --> 00:00:45.290
Современные технологии хранения, аналитика
больших данных, её инструментарий.

00:00:45.971 --> 00:00:48.573
От традиционного анализа к операционному.

00:00:48.613 --> 00:00:54.098
Инструментарий для анализа больших данных,
то есть реляционный и нереляционный.

00:00:54.218 --> 00:00:57.541
Технологии аналитики в памяти.

00:00:57.621 --> 00:01:01.144
Аналитика больших данных, техника
обработки и анализа.

00:01:01.545 --> 00:01:03.587
Методы анализа обработки больших данных.

00:01:04.179 --> 00:01:06.378
Анализ больших данных в облаках.

00:01:13.376 --> 00:01:15.056
Большие данные — хранилище данных.

00:01:15.136 --> 00:01:19.734
В начале восьмидесятых годов XX века, в
период бурного развития

00:01:20.854 --> 00:01:23.095
Регистрирующих информационных систем.

00:01:23.135 --> 00:01:27.459
Появилось осознание ограниченности их
применения для анализа данных и построения

00:01:27.619 --> 00:01:29.460
систем поддержки, принятия решений.

00:01:29.981 --> 00:01:33.503
Менеджерам и аналитикам требовались
системы, которые бы позволяли

00:01:33.824 --> 00:01:36.826
анализировать информацию во временном
аспекте.

00:01:37.305 --> 00:01:41.544
Формировать произвольные запросы к
системе, обрабатывать большие объёмы

00:01:41.624 --> 00:01:45.943
данных, интегрировать данные из различных
регистрирующих систем.

00:01:48.223 --> 00:01:52.822
Данные обычно хранились в многочисленных
разрозненных базах и в рамках одной

00:01:52.862 --> 00:01:55.541
организации. Используемые регистрирующие
системы

00:01:56.103 --> 00:01:58.704
...не удовлетворяли ни одному из этих
требований.

00:01:58.784 --> 00:02:02.505
Информация в такой системе актуальна
только на момент обращения к базе данных.

00:02:02.585 --> 00:02:06.507
В следующий момент времени по тому же
запросу можно получить совершенно другой

00:02:06.627 --> 00:02:12.388
результат. Интерфейс регистрирующих систем
рассчитан на проведение жёстко

00:02:12.508 --> 00:02:15.109
определённых операций и возможности
получения результатов.

00:02:16.056 --> 00:02:20.011
На нерегламентный, то есть этхок запрос
сильно ограничены.

00:02:20.331 --> 00:02:24.646
Возможности обработки больших массивов
данных также были невелики из-за настройки

00:02:24.686 --> 00:02:26.963
СУБД на выполнение коротких транзакций.

00:02:27.123 --> 00:02:30.839
Базы были оптимизированы для хранения и
извлечения информации путём простых

00:02:30.958 --> 00:02:31.478
операций.

00:02:32.003 --> 00:02:35.086
таких, как Select, Insert, atate и Delip.

00:02:35.647 --> 00:02:42.013
Для анализа данных компаниям требовалась
технология, которая могла бы объединять и

00:02:42.174 --> 00:02:46.818
согласовывать данные из разнородных баз и
облегчать проведение более сложных

00:02:46.979 --> 00:02:48.100
аналитических операций.

00:02:48.817 --> 00:02:52.096
Решение этой бизнес-задачи привело к
появлению хранилищ данных.

00:02:54.455 --> 00:02:56.254
Можно посмотреть Кехлера.

00:02:57.454 --> 00:03:02.053
Хранилище данных — это система, в которой
собраны данные из различных источников

00:03:02.173 --> 00:03:05.891
внутренних компании, внутри компании,
которые используются для поддержки и

00:03:05.931 --> 00:03:07.371
принятия управленческих решений.

00:03:09.577 --> 00:03:14.418
Один из создателей архитектуры хранилищ
данных OM, так определяют хранилища

00:03:14.578 --> 00:03:18.939
данных. Это предметно-ориентированное,
интегрированное, содержащее исторические

00:03:19.019 --> 00:03:23.459
данные, неразрушаемая совокупность данных,
предназначенная для поддержки принятия

00:03:23.540 --> 00:03:24.780
управленческих решений.

00:03:26.290 --> 00:03:30.533
Советую определение ещё раз прочитать и
осмыслить.

00:03:30.653 --> 00:03:34.775
Основная задача организации хранилищ
данных — создание хорошо спроектированного

00:03:34.895 --> 00:03:36.536
централизованного банка данных.

00:03:36.696 --> 00:03:40.739
Основное преимущество хранилища данных —
это сокращение времени выполнения проекта.

00:03:41.663 --> 00:03:45.745
Ключевой компонент любого процесса
обработки данных — это сами данные.

00:03:45.905 --> 00:03:49.707
Поэтому неудивительно, что во многих
проектах большая часть времени и усилий

00:03:49.827 --> 00:03:53.269
направляется на поиск, сбор и очистку
данных перед анализом.

00:03:53.750 --> 00:03:58.032
Если в компании есть хранилище данных, то
усилия и время, затраченное на подготовку

00:03:58.112 --> 00:03:59.633
данных, значительно сокращаются.

00:04:00.590 --> 00:04:02.628
Так, вот предлагается следующая таблица.

00:04:02.828 --> 00:04:06.663
Сравнительные характеристики хранилищ
данных и оперативных систем.

00:04:07.223 --> 00:04:10.099
Системы хранилищ данных — оперативные
системы.

00:04:10.339 --> 00:04:14.894
Системы хранилищ данных используется
руководством оперативные системы

00:04:15.054 --> 00:04:16.852
используется разработчиками, разработка.

00:04:17.444 --> 00:04:20.086
работниками переднего края.

00:04:20.646 --> 00:04:26.170
Стратегическое значение, тактическое
значение поддерживают стратегические

00:04:26.250 --> 00:04:29.292
направления развития бизнеса: оперативная
система.

00:04:29.372 --> 00:04:32.094
Поддерживают повседневную деятельность.

00:04:32.334 --> 00:04:36.657
Используется для интерактивного анализа,
используется для обработки транзакций.

00:04:37.452 --> 00:04:39.813
Система хранилищ данных. Предметно
ориентированные.

00:04:39.893 --> 00:04:44.096
Операционная система ориентированы на
приложения системы хранилищ данных.

00:04:44.496 --> 00:04:46.578
Хранят исторические данные.

00:04:47.138 --> 00:04:50.020
Оперативные системы хранят только текущие
данные.

00:04:51.141 --> 00:04:53.903
Система хранилищ данных, непредсказуемые
запросы.

00:04:55.755 --> 00:05:00.237
Оперативные системы выдают только
предсказуемые запросы.

00:05:00.997 --> 00:05:06.320
Для описания стандартных процессов и
инструментов для сопоставления объединения

00:05:06.640 --> 00:05:11.763
и перемещения данных между фазами
используется термин ETL.

00:05:15.454 --> 00:05:21.697
Экстракт трансформ Load the вернее
извлечение,

00:05:21.777 --> 00:05:23.218
преобразование, загрузка.

00:05:23.658 --> 00:05:27.220
Так, ссылочка, особенности построения
информационных.

00:05:31.074 --> 00:05:35.677
Типичные операции, выполняемые в хранилище
данных, отличаются от операций стандартной

00:05:35.757 --> 00:05:37.078
реакционной базы данных.

00:05:37.198 --> 00:05:40.640
Для их отношения используется, для их
описания используется термин

00:05:40.680 --> 00:05:43.682
«интерактивная аналитическая обработка» —
олап.

00:05:44.082 --> 00:05:48.525
Операции Олап, как правило, направлены на
создание сводных исторических данных,

00:05:48.605 --> 00:05:51.646
включают в себя сбор данных из нескольких
источников.

00:05:51.727 --> 00:05:52.887
Например, запрос Олап.

00:05:53.535 --> 00:05:57.015
Выраженный для удобства на естественном
языке может выглядеть так: отчёт о

00:05:57.055 --> 00:06:01.856
продажах всех магазинов по регионам и
кварталам и разница показателей по

00:06:01.976 --> 00:06:03.897
сравнению с отчётом за прошлый год.

00:06:04.017 --> 00:06:08.898
Этот пример показывает, что результат
запроса часто напоминает стандартный

00:06:08.978 --> 00:06:10.218
бизнес-бизнес-отчёт.

00:06:10.483 --> 00:06:13.764
По сути, операция Оллап позволяет
пользователям распределять,

00:06:13.924 --> 00:06:20.205
фрагментировать и переворачивать данные в
хранилища, а также получать их различные

00:06:20.285 --> 00:06:25.326
отображения. Операция Олap работает с
отображением данных, называемым кубом

00:06:25.406 --> 00:06:25.726
данных.

00:06:25.958 --> 00:06:28.557
...который построен поверх хранилища.

00:06:28.637 --> 00:06:33.757
Коб да, куб данных имеет фиксированный,
заранее определённый набор измерений, где

00:06:33.997 --> 00:06:37.116
каждое измерение отображает одну
характеристику данных.

00:06:37.516 --> 00:06:41.715
Для приведённых выше параметров запроса
необходимы следующие изменение куба

00:06:41.875 --> 00:06:45.875
данных: продажи по магазинам, продажи по
регионам, продажа по квартирам.

00:06:47.203 --> 00:06:51.041
Основные преимущество использования куба
данных с фиксированным набором измерений

00:06:51.201 --> 00:06:54.838
состоит в том, что он ускоряет время
отклика операции лап.

00:06:54.878 --> 00:07:01.754
Кроме того, поскольку набор измерений куба
данных предварительно запрограммирован

00:07:01.993 --> 00:07:04.592
в системе Лап, эти системы могут быть
отображены

00:07:05.350 --> 00:07:10.193
Дружественным пользовательским интерфейсом
интерфейс.

00:07:10.313 --> 00:07:14.514
Графический интерфейс пользователя для
формулирования запросов.

00:07:14.595 --> 00:07:19.397
Однако отображение купа данных
ограничивает анализ набором запросов,

00:07:19.477 --> 00:07:23.278
которые могут быть сгенерированы только с
использованием заранее определённых

00:07:24.318 --> 00:07:28.834
измерений. Интерфейс запросов SPL
сравнительно более гибок.

00:07:28.954 --> 00:07:34.629
Кроме того, хотя система была полезна для
исследования данных, составления отчётов,

00:07:34.988 --> 00:07:39.025
они не позволяют моделировать данные или
автоматически выявлять в них

00:07:39.065 --> 00:07:39.824
закономерности.

00:07:41.096 --> 00:07:45.100
Появление больших данных привело к
разработке новых технологий создания баз

00:07:45.221 --> 00:07:49.545
данных. Базы данных нового поколения часто
называют базами нового ск.

00:07:49.625 --> 00:07:53.470
Они имеют более простую модель, чем
первичные эляционные.

00:07:54.961 --> 00:07:57.320
...чем привычные реляционные базы данных.

00:07:57.320 --> 00:08:01.079
И хранят данные в виде объектов с
атрибутами, используя такой язык

00:08:01.159 --> 00:08:05.878
представления объекта, как, например,
JavaScript, Object otation сокращённо

00:08:05.957 --> 00:08:10.676
Джасон. Преимущества использования объекта
представления данных...

00:08:11.983 --> 00:08:16.222
По сравнению с моделью носной реляционной
таблицы состоит в том, что набор атрибутов

00:08:16.542 --> 00:08:19.221
для каждого объекта заключён в самом
объекте.

00:08:24.439 --> 00:08:26.641
Это даёт возможность гибко отображать
данные.

00:08:26.762 --> 00:08:31.366
Например, один из объектов базы данных
может иметь сокращённый набор атрибутов по

00:08:31.486 --> 00:08:32.848
сравнению с другими объектами.

00:08:32.888 --> 00:08:36.731
В структуре эволюционной базы данных
напротив, все значения в таблице должны

00:08:37.132 --> 00:08:39.014
иметь одинаковый набор атрибутов.

00:08:39.956 --> 00:08:44.079
И вот эта гибкость важна в тех случаях,
когда данные из-за их разнообразия или

00:08:44.199 --> 00:08:49.163
типа не раскладываются естественным
образом набор структурированных атрибутов.

00:08:49.243 --> 00:08:54.047
Однако, хотя эта гибкость представления
позволяет собирать и хранить данные в

00:08:54.127 --> 00:08:58.130
различных форматах для следующего
последующего анализа, их всё равно

00:08:58.210 --> 00:08:59.491
приходится структурировать.

00:09:00.341 --> 00:09:05.785
Итак, в конце восьмидесятых, начале
девяностых годов прошлого века, в связи с

00:09:05.866 --> 00:09:10.189
необходимостью анализа больших наборов
данных, началась разработка

00:09:10.269 --> 00:09:12.871
соответствующих хранилищ данных технологии
OLAP.

00:09:12.911 --> 00:09:15.433
Параллельно велось исследование и в других
областях.

00:09:15.794 --> 00:09:16.634
Так, значит, в 1

00:09:18.880 --> 00:09:25.553
В 989 году математик Григорий

00:09:25.673 --> 00:09:30.987
Петецкий, Шапира поднял вопрос об
обнаружении знаний базы данных КДД.

00:09:31.107 --> 00:09:33.664
По сути, это тот же глубинный анализ
данных.

00:09:33.824 --> 00:09:35.223
Таким базам данных обычно существ

00:09:36.500 --> 00:09:40.138
Сопутствуют существенные знания предметной
области, которые могут значительно

00:09:41.018 --> 00:09:42.777
облегчить обнаружение данных.

00:09:43.337 --> 00:09:47.815
Доступ к большим базам данных недешёвый,
поэтому необходимо использовать разные

00:09:47.935 --> 00:09:49.135
статистические методы.

00:09:49.295 --> 00:09:53.173
Для обнаружения знаний в базе данных могут
оказаться полезными существующие

00:09:53.253 --> 00:09:55.212
инструменты и методы из различных
областей.

00:09:56.406 --> 00:10:00.807
Таких, как экспертные системы, машинное
обучение, интеллектуальные базы данных,

00:10:00.927 --> 00:10:03.248
получение знаний и статистика.

00:10:04.768 --> 00:10:10.049
Следующий вопрос. Подходы к архитектуре и
принципам проектирования хранилищ данных.

00:10:10.490 --> 00:10:13.410
В основе концепции хранилища данных лежат
две основные

00:10:15.317 --> 00:10:21.873
Интеграция разъединённых детализированных
данных в едином хранилище и разделение

00:10:22.032 --> 00:10:26.750
наборов данных и приложений, используемых
для обработки и анализа.

00:10:31.827 --> 00:10:35.864
Существуют разные точки зрения на вопрос
об архитектуре хранилищ данных.

00:10:36.838 --> 00:10:40.913
Относительно подходов к проектированию,
количества уровней, направлений построения

00:10:41.073 --> 00:10:43.030
хранилищ, систем хранения данных.

00:10:43.190 --> 00:10:46.067
Выделяют следующие подходы к
проектированию хранилищ.

00:10:46.426 --> 00:10:49.302
Первый подход снизу-вверх — Imbla.

00:10:49.822 --> 00:10:52.418
Он основывается на важности витрин данных.

00:10:52.537 --> 00:10:57.258
...которые являются хранилищами данных,
принадлежащими конкретным направлениям

00:10:57.338 --> 00:11:01.178
бизнеса. По мнению автора подхода
хранилища данных — это просто сочетание

00:11:01.299 --> 00:11:05.900
различных витрин данных, которые облегчают
отчётность и анализ данных.

00:11:07.060 --> 00:11:09.540
Второе, нисходящий подход именно...

00:11:12.164 --> 00:11:16.600
Он основывается на том, что хранилище
данных является централизованным

00:11:16.720 --> 00:11:18.719
хранилищем всех корпоративных данных.

00:11:18.839 --> 00:11:23.275
При таком подходе организация сначала
создаёт нормализованную модель хранилища

00:11:23.395 --> 00:11:27.312
данных, а затем создаются витрины
размерных данных на основе модели

00:11:27.391 --> 00:11:27.951
хранилища.

00:11:29.111 --> 00:11:35.715
И при проектировании системы по
методологии Кимбала Front Mendom

00:11:35.915 --> 00:11:40.718
базы данных должна выступать витрина
данных, то есть Data Mart, который

00:11:40.958 --> 00:11:44.680
использует Analis и Service для куба в
качестве источника данных.

00:11:45.351 --> 00:11:48.268
Методология же BM сложнее.

00:11:49.267 --> 00:11:54.341
Data Mart включает в себя не только базы
данных, но и систему поддержки принятия

00:11:54.421 --> 00:11:56.339
решений клиент-серверную архитектуру.

00:11:56.419 --> 00:11:59.935
Тогда как Data Mart по сути является базой
данных, созданной с учётом требований

00:12:00.054 --> 00:12:00.294
будущего

00:12:01.680 --> 00:12:04.923
Соответственно, исходя из предложенных
подходов, можно выделить разную

00:12:05.003 --> 00:12:06.805
архитектуру хранилища данных.

00:12:07.486 --> 00:12:11.610
В первом случае используется двухуровневая
архитектура, она предполагает построение

00:12:11.770 --> 00:12:16.375
витрин данных — дата-март без создания
централизованного хранилища.

00:12:16.855 --> 00:12:19.538
Информация поступает из регистрирующих
систем.

00:12:20.249 --> 00:12:25.691
По ЛТП и ограничена конкретной предметной
областью.

00:12:26.011 --> 00:12:29.973
При построении витрин используются
основные принципы построения хранилищ

00:12:30.093 --> 00:12:33.894
данных, поэтому их можно считать хранилища
данных в миниатюре.

00:12:36.095 --> 00:12:36.615
Ссылки.

00:12:44.127 --> 00:12:48.443
Так, рисунок построения хранилищ данных по
кимболу.

00:12:49.483 --> 00:12:53.919
Такая архитектура имеет свои плюсы:
простота и малая стоимость реализации,

00:12:53.999 --> 00:12:57.557
высокая производительность за счёт
физического разделения регистрирующих

00:12:57.676 --> 00:13:03.033
аналитических систем, выделение загрузки,
трансформации данных, отдельный процесс,

00:13:03.072 --> 00:13:05.950
оптимизированный под анализ структуры
хранилищ данных.

00:13:07.819 --> 00:13:10.617
Поддержка истории, возможность добавления
метанных.

00:13:10.737 --> 00:13:14.494
Во втором случае построение полноценного
корпоративного хранилища данных, то есть

00:13:14.614 --> 00:13:18.211
Data-wordhouse, выполненная в
трёхуровневой архитектуре.

00:13:18.371 --> 00:13:20.050
Следующий рисунок — 10.

00:13:24.726 --> 00:13:25.885
Соответственно, построение

00:13:26.607 --> 00:13:33.177
Хранилище данных по итархаус, то есть

00:13:33.377 --> 00:13:34.819
хранилище данных.

00:13:35.460 --> 00:13:37.303
И вот, соответственно, витрины.

00:13:37.463 --> 00:13:39.025
Одна витрина, вторая.

00:13:41.120 --> 00:13:45.119
На первом нижнем уровне расположены
разнообразные источники данных:

00:13:45.359 --> 00:13:51.599
внутренние, регистрирующие системы,
справочные системы и,

00:13:51.759 --> 00:13:58.039
соответственно, внешние

00:13:58.199 --> 00:14:00.878
источники, то есть данные информационных
агентов.

00:14:02.152 --> 00:14:04.435
Макроэкономические показатели и другие.

00:14:04.595 --> 00:14:07.838
Здесь находится сервер баз данных,
используемый для извлечения данных из

00:14:07.918 --> 00:14:09.439
множества различных источников.

00:14:09.599 --> 00:14:12.722
Второй средний уровень содержит
центральное хранилище.

00:14:13.043 --> 00:14:17.247
Туда стекается информация от всех
источников первого уровня и возможный

00:14:17.367 --> 00:14:18.648
оперативный склад данных.

00:14:20.428 --> 00:14:23.951
которая не содержит исторических данных и
выполняет две основные функции.

00:14:24.031 --> 00:14:29.115
Во-первых, он является источником
аналитической информации для оперативного

00:14:29.275 --> 00:14:33.959
управления. И, во-вторых, здесь
подготавливаются данные, осуществляется их

00:14:34.080 --> 00:14:38.443
преобразование и проводятся определённые
проверки для последующей загрузки в

00:14:38.483 --> 00:14:39.404
центральное хранилища.

00:14:40.227 --> 00:14:45.069
Наличие оперативного склада данных просто
необходимо при различных регламентах

00:14:45.350 --> 00:14:47.671
поступления информации из источников.

00:14:47.791 --> 00:14:52.714
Второй уровень содержит сервер ОЛАП,
который преобразует данные в структуру,

00:14:52.794 --> 00:14:55.515
наиболее подходящую для анализа их сложных
запросов.

00:14:55.635 --> 00:14:59.197
Сервер Олап может работать двумя
способами: либо в качестве расширенной

00:14:59.277 --> 00:15:01.358
системы управления операционными базами
данных.

00:15:02.187 --> 00:15:07.145
которая отображает операции над
многомерными данными стандартные

00:15:07.225 --> 00:15:12.382
реляционные операции, такой называемый
relation Olap, либо с использованием

00:15:12.462 --> 00:15:15.981
многомерной модели Olap, которая
непосредственно реализует многомерные

00:15:16.140 --> 00:15:17.260
данные и операции

00:15:20.429 --> 00:15:25.827
Третий уровень представляет собой набор
предметно-ориентированных витрин данных.

00:15:32.105 --> 00:15:34.105
Значит, представляет собой набор

00:15:36.100 --> 00:15:39.742
Предметно ориентированных витрин данных,
источниками информации, для которых

00:15:39.902 --> 00:15:41.823
является центральное хранилище данных.

00:15:41.903 --> 00:15:45.224
Именно с витринами данных и работает
большинство конечных пользователей.

00:15:45.304 --> 00:15:49.947
Он содержит инструменты, используемые для
высокоуровнего анализа данных и создания

00:15:50.147 --> 00:15:53.428
клиентами. Соответственно, ссылка.

00:15:56.084 --> 00:16:00.087
В традиционной архитектуре хранилищ
выделяют несколько моделей: виртуальное

00:16:00.167 --> 00:16:03.810
хранилище, витрину данных и корпоративное
хранилище данных.

00:16:04.650 --> 00:16:08.653
Виртуальное хранилище данных — это набор
определённых баз данных, которые можно

00:16:08.854 --> 00:16:15.298
использовать совместно, чтобы можно было
эффективно получить доступ ко всем данным.

00:16:15.718 --> 00:16:18.200
Как если бы они хранились в одном
хранилище данных.

00:16:18.320 --> 00:16:22.203
Модель витрины данных используется для
отчётности и анализа конкретных

00:16:22.323 --> 00:16:27.207
бизнес-процессов. В этой модели хранилища
находятся агрегированные данные из ряда

00:16:27.327 --> 00:16:30.849
исходных систем, относящихся к конкретной
базе в бизнес-сфере.

00:16:30.929 --> 00:16:31.170
Например

00:16:32.226 --> 00:16:36.388
Продолжаем продажам клиентам или финансам.

00:16:36.868 --> 00:16:42.671
Идея создания витрин данных была
предложена в 1991 году Международным

00:16:42.831 --> 00:16:46.353
аналитическим агентством Форрестер Ресоч.

00:16:46.433 --> 00:16:51.035
Авторы идеи представляли данное хранилище
информации как определённое множество

00:16:51.155 --> 00:16:52.396
специфических баз данных.

00:16:53.037 --> 00:16:56.276
...который содержат в себе сведения,
относящиеся к конкретным векторам

00:16:56.556 --> 00:16:58.035
деятельности корпорации.

00:16:58.555 --> 00:17:02.553
Третье. Модель корпоративного хранилища
данных предполагает хранение

00:17:02.713 --> 00:17:05.751
агрегированных данных, охватывающих всю
организацию.

00:17:06.231 --> 00:17:09.789
Эта модель рассматривает хранилище данных
как сердце информационной системы

00:17:09.949 --> 00:17:13.068
предприятия с интегрированными данными
всех бизнес-единиц.

00:17:13.823 --> 00:17:17.904
Различают два архитектурных направления
построения хранилищ: нормализованные

00:17:18.024 --> 00:17:20.665
хранилища данных и хранилища с
измерениями.

00:17:21.186 --> 00:17:25.267
В нормализованных хранилищах данные
находятся предметно-ориентированных

00:17:25.387 --> 00:17:27.148
таблицах третьей нормальной формы.

00:17:27.188 --> 00:17:30.629
То есть это требования, предъявляемые к
структуре таблиц теории эволюционных баз

00:17:30.749 --> 00:17:32.270
данных для устранения из них

00:17:33.050 --> 00:17:37.053
Избыточных функциональных зависимостей
между атрибутами и полями таблиц.

00:17:37.494 --> 00:17:40.456
Они считаются простыми в создании
управления.

00:17:40.536 --> 00:17:44.620
К недостаткам нормализованных хранилищ
можно отнести большое количество таблиц

00:17:44.740 --> 00:17:49.905
вследствие нормализации из-за чего для
получения какой-либо информации нужно

00:17:50.305 --> 00:17:52.707
делать выборку из многих таблиц
одновременно.

00:17:53.479 --> 00:17:55.919
Что приводит к ухудшению
производительности системы.

00:17:56.520 --> 00:18:01.240
Следующее — хранилище с измерениями
использует разные типы схем хранения,

00:18:01.320 --> 00:18:03.561
такие как звезда и даже снежинка.

00:18:04.201 --> 00:18:10.962
Одно измерение куба может содержаться как
в одной таблице, в том числе при наличии

00:18:11.082 --> 00:18:14.442
нескольких уров иерархии, так и в
нескольких связанных таблицах.

00:18:15.725 --> 00:18:17.523
...соответствующих различным уровням.

00:18:17.843 --> 00:18:19.521
Так, опять же ссылки.

00:18:25.756 --> 00:18:28.553
Соответствующими различным уровням
иерархии измерений.

00:18:29.033 --> 00:18:34.188
Если каждое измерение содержится в одной
таблице, такая схема хранилищ данных носит

00:18:34.228 --> 00:18:36.306
название звезда — стар схема.

00:18:37.073 --> 00:18:41.875
Вот такой пример такой схемы приведён на
рисунке 11.

00:18:42.115 --> 00:18:46.276
Как видите, здесь у нас показана такая
структура.

00:18:46.596 --> 00:18:48.476
Пример схемы — звезда.

00:18:49.116 --> 00:18:53.917
Видите, один какой-то центральный модуль,
центральная таблица.

00:18:54.478 --> 00:18:57.520
Сайлес-факт.

00:18:58.161 --> 00:19:03.085
Соответственно, и вокруг связаны с ней
дополнительные таблицы.

00:19:05.967 --> 00:19:10.410
Значит, продукт, дим, тайм-дим и так
далее.

00:19:22.252 --> 00:19:25.932
В центре схемы «Звезда» находятся данные —
таблица фактов.

00:19:26.052 --> 00:19:28.172
А измерения образуют её лучи.

00:19:28.732 --> 00:19:33.412
Таблица фактов содержит агрегированные
данные, которые будут использоваться для

00:19:33.532 --> 00:19:37.292
составления отчётов, а таблица измерений
описывает хранимые данные.

00:19:38.070 --> 00:19:44.273
Достаточно простая конструкция
звёздообразной схемы значительно упрощает

00:19:44.834 --> 00:19:46.754
написание сложных запросов.

00:19:47.915 --> 00:19:53.518
Если же хотя бы одно измерение содержится
в нескольких связанных таблицах, каждая

00:19:53.638 --> 00:19:56.439
схема хранилища данных носит название
«Снежинка».

00:19:57.308 --> 00:19:59.266
Снова флайк схема.

00:19:59.746 --> 00:20:04.701
Дополнительная таблица измерений в такой
схеме обычно соответствует верхнему уровню

00:20:04.861 --> 00:20:06.220
иерархии измерений.

00:20:06.620 --> 00:20:12.015
Так, ну вот здесь снизу ссылочка даётся,
хранилище данных, электронный ресурс.

00:20:13.174 --> 00:20:15.892
Так, и находящийся в отношении один ко
многим.

00:20:16.596 --> 00:20:20.035
План таблиц измерений, соответствующие
уровню иерархии.

00:20:20.115 --> 00:20:25.474
Иногда называют консольными таблицами, то
есть триггер тейбл.

00:20:25.594 --> 00:20:29.033
Пример схемы «Снежинка» приведён на
рисунке 12.

00:20:29.873 --> 00:20:32.153
Рисунок 12. Пример схемы «Снежинка».

00:20:33.893 --> 00:20:39.571
Соответственно, видите, вот как бы не
просто звезда, а там уже как бы такие ещё.

00:20:40.251 --> 00:20:47.089
Вот продукт 2, гим измерение какое-то по
продукту 2 делает какой-то свой

00:20:47.169 --> 00:20:50.688
отдельный луч. Схема разбивает таблицу
фактов.

00:20:51.696 --> 00:20:55.015
На ряд денормализованных таблиц измерений.

00:20:55.175 --> 00:21:00.894
Нормализованные проекты менее сложны,
потому что данные сгрупп сгруппированы.

00:21:01.054 --> 00:21:05.732
Таким таблицы фактов использует только
одну ссылку для присвоения каждой таблицы

00:21:05.852 --> 00:21:11.731
измерений. Пример схемы снежника.

00:21:12.986 --> 00:21:16.789
Схема типа «снижинка» отличается тем, что
использует нормализованные данные.

00:21:16.869 --> 00:21:20.872
Нормализация означает эффективную
организацию данных, чтобы в зависимости

00:21:21.072 --> 00:21:25.675
данных были определены и каждая таблица
держала минимум избыточности.

00:21:25.835 --> 00:21:29.558
Таким образом, таблицы измерений
разветвляются на отдельные таблицы

00:21:29.678 --> 00:21:30.158
измерений.

00:21:38.557 --> 00:21:43.081
Эта схема использует меньше дисковое
пространство и лучше сохраняет целостность

00:21:43.241 --> 00:21:47.045
данных. Основной её недостаток — сложность
запросов, необходимых для доступа к

00:21:47.125 --> 00:21:50.368
данным. Каждый запрос должен пройти
несколько соединений таблицы.

00:21:51.450 --> 00:21:53.288
Чтобы получить соответствующие данные.

00:21:53.448 --> 00:21:58.123
Даже при наличии иерархических измерений с
целью повышения скорости выполнения

00:21:58.203 --> 00:22:03.357
запросов в хранилище данных, нередко
предполагают предпочтение отдаётся схеме

00:22:03.397 --> 00:22:07.233
«звезда». Однако не все хранилища данных
проектируются.

00:22:07.768 --> 00:22:12.524
По этим двум схемам. Так довольно часто
вместо ключевого поля для измерения,

00:22:12.563 --> 00:22:16.999
содержащего данные типа data и
соответствующей таблицы измерений, схема

00:22:17.119 --> 00:22:21.155
таблицы фактов может содержать ключевые
слова поля типа data.

00:22:23.159 --> 00:22:26.281
В этом случае соответствующая таблица
измерений просто отсутствует.

00:22:26.361 --> 00:22:30.245
Основное достоинство хранилищ с
измерениями — их простота и понятность для

00:22:30.365 --> 00:22:31.927
разработчиков и пользователей.

00:22:32.287 --> 00:22:36.491
Кроме того, благодаря более эффективному
хранению данных и и формализованным

00:22:36.611 --> 00:22:41.455
измерениям облегчается и ускоряется доступ
к данным, особенно при сложных анализах.

00:22:42.193 --> 00:22:49.153
Основной недостаток — это более сложные
процедуры подготовки и загрузки данных,

00:22:49.193 --> 00:22:54.112
а также управления измерениями измерений
данных изменения измерений данных.

00:22:54.392 --> 00:22:57.832
Хранилище данных отличается разными
способами загрузки данных.

00:22:57.912 --> 00:22:58.272
Выделяем

00:23:00.165 --> 00:23:03.045
Соответственно, следующее ITL.

00:23:05.365 --> 00:23:09.085
Сначала извлекают данные из пяти
источников данных.

00:23:09.205 --> 00:23:12.845
Данные хранятся во временной промежуточной
базе данных.

00:23:13.725 --> 00:23:15.484
Временной промежуточной базе данных.

00:23:15.564 --> 00:23:19.644
Затем выполняются операции преобразования,
чтобы структурировать и преобразовывать

00:23:19.724 --> 00:23:21.044
данные в подходящую форму.

00:23:21.816 --> 00:23:23.814
Для целевой системы хранилища данных.

00:23:23.854 --> 00:23:27.490
Затем структурированные данные загружаются
в хранилище и после этого становятся

00:23:27.610 --> 00:23:28.849
готовы к анализу.

00:23:32.045 --> 00:23:36.601
ИЛТ — буквы те же, только в другом
порядке.

00:23:36.681 --> 00:23:39.438
ILT, экстракт Load Transformer.

00:23:40.448 --> 00:23:44.928
Данные сразу же загружаются после
извлечения из исходных пунктов данных.

00:23:45.008 --> 00:23:48.849
Промежуточная база данных отсутствует, что
означает, что данные немедленно

00:23:48.929 --> 00:23:51.649
загружаются в единый централизованный
репозиторий.

00:23:52.089 --> 00:23:56.529
Данные преобразуются в системе хранилища
данных для их использования с

00:23:56.649 --> 00:23:59.570
инструментальным бизнес-аналитике и
аналитике.

00:24:07.608 --> 00:24:10.727
Хранилище данных организации имеет
следующую структуру.

00:24:10.967 --> 00:24:14.606
Базовая структура позволяет, конечно,
пользователям хранилища напрямую

00:24:14.926 --> 00:24:21.044
приобретать доступ к сводным данным,
полученным из исходных схем систем,

00:24:21.124 --> 00:24:23.283
создавать отчёты, анализировать эти
данные.

00:24:23.865 --> 00:24:28.903
Эта структура используется в случаях,
когда источники данных происходят из одних

00:24:28.943 --> 00:24:30.782
и тех же типов систем баз данных.

00:24:30.862 --> 00:24:34.541
Хранилище с промежуточной областью
является следующим логическим шагом в

00:24:34.661 --> 00:24:39.338
организации и разнородным источниками
данных с множеством различных типов

00:24:39.538 --> 00:24:43.617
форматов данных. Промежуточная область
преобразует данные в обобщённый

00:24:43.736 --> 00:24:44.896
структурированный формат.

00:24:45.537 --> 00:24:49.539
...которые проще запрашивать с помощью
инструментов анализа и отчётности.

00:24:50.059 --> 00:24:54.140
Одной из разновидностей промежуточной
структуры является добавление витрин

00:24:54.260 --> 00:24:55.661
разных хранилищ данных.

00:24:55.821 --> 00:25:00.583
В витринах данных хранятся сводные данные
по конкретной сфере деятельности, что

00:25:00.743 --> 00:25:04.104
делает эти данные доступными для
конкретных форм анализа.

00:25:04.810 --> 00:25:11.614
Например, добавление витрин данных может
позволить финансовому аналитику легче

00:25:11.774 --> 00:25:17.298
выполнить подробные запросы данных,
прогнозировать поведение клиентов.

00:25:17.418 --> 00:25:22.220
Витрины данных облегчают анализ,
анализируя данные специально для

00:25:22.340 --> 00:25:24.502
удовлетворения потребностей конечного
пользователя.

00:25:24.980 --> 00:25:28.578
В последние годы хранилища данных
переходят в облако.

00:25:28.698 --> 00:25:33.696
Новые облачные хранилища данных не
придерживаются традиционной архитектурой,

00:25:33.736 --> 00:25:36.454
и каждая из них предлагает свою уникальную
архитектуру.

00:25:36.614 --> 00:25:37.493
Например, Amazon

00:25:43.267 --> 00:25:49.222
Google Biger и так далее имеются различия
в системах хранения данных.

00:25:51.460 --> 00:25:55.776
Системы хранения данных выделяют несколько
подходов к хранению данных.

00:25:55.856 --> 00:25:56.736
Первый — традиционный

00:25:57.195 --> 00:26:01.920
Основан на использование системы SAN, то
есть Torch Erio нет волк для

00:26:02.040 --> 00:26:03.442
структурированных данных.

00:26:03.842 --> 00:26:07.326
Первичные данные хранятся в виде блоков в
дата-центре.

00:26:08.368 --> 00:26:12.612
В функции блочного хранения используется

00:26:13.705 --> 00:26:16.944
На низких уровнях в виде блоков
фиксированного размера, которые легко

00:26:17.024 --> 00:26:19.383
индексируются и находятся в системе
хранения.

00:26:20.423 --> 00:26:25.142
Так, ссылочка Архитектура хранилищ данных
и

00:26:26.781 --> 00:26:30.780
традиционно их традиционные и облачные.

00:26:32.442 --> 00:26:36.558
Такой метод подходит при относительно
небольших объёмах хранения.

00:26:37.517 --> 00:26:39.754
При росте дискового хранилища

00:26:41.346 --> 00:26:45.908
Возникают проблемы с файловой системой
таблицы, становятся непомерно огромными.

00:26:46.028 --> 00:26:49.869
Это сильно замедляет поиск нужного блока и
увеличивает возможность ошибок.

00:26:50.069 --> 00:26:54.551
Поэтому пользователи вынуждены разбивать
свои наборы данных на многочисленные

00:26:54.671 --> 00:26:59.993
логические узлы. Logical Unice Nater,
чтобы как-то поддержать скорость

00:27:01.377 --> 00:27:05.340
На приемлемом уровне. При этом значительно
увеличивается сложность администрирования

00:27:05.460 --> 00:27:09.624
и поддержки IT-системы, соответственно,
растут затраты, а также возможны потери

00:27:09.784 --> 00:27:11.265
данных в простое системы.

00:27:11.425 --> 00:27:15.228
Для решения проблем, связанных с
увеличением объёмов данных, стали

00:27:15.308 --> 00:27:18.431
использоваться так называемые
горизонтально масштабируемые, то есть

00:27:18.551 --> 00:27:19.912
файловые системы, такие как

00:27:20.833 --> 00:27:26.188
HTFS, значит Hattup Distributor File
System.

00:27:26.708 --> 00:27:32.063
Файловая система хранения часто организуют
сиверхический файловый поток файлов и

00:27:32.143 --> 00:27:34.781
папок, которые существуют в системах
хранения нас.

00:27:35.020 --> 00:27:38.018
В устройствах САМ используются протоколы,
соответственно

00:27:41.923 --> 00:27:48.808
Fiber Channel и файловых системах у нас
протокола SMBS.

00:27:49.689 --> 00:27:52.131
Хранилище этих типов обычно

00:27:53.655 --> 00:27:56.651
располагаются поблизости от вычислительных
ресурсов.

00:27:56.731 --> 00:28:01.325
Однако по мере того, как объёмы данных
продолжают расти, их приходится всё более

00:28:01.525 --> 00:28:04.640
и более располагать в удалённых
дата-центрах.

00:28:04.680 --> 00:28:06.718
В большинстве случаев это так называемые

00:28:07.499 --> 00:28:11.461
Холодные данные, которые не часто
используются при вычислении, но их все всё

00:28:11.581 --> 00:28:15.782
равно нужно хранить. Поэтому должны быть
варианты для эффективного, надлежащего,

00:28:15.822 --> 00:28:19.904
экономного, экономичного хранения этих
данных.

00:28:20.144 --> 00:28:22.145
Соответственно, ссылка 87.

00:28:22.825 --> 00:28:25.986
Файловые системы решают проблему
масштабирования.

00:28:27.405 --> 00:28:30.045
Однако поддержка таких систем трудоёмкая.

00:28:30.565 --> 00:28:34.205
Одни конструктивно сложны и требуют
постоянного обслуживания.

00:28:34.245 --> 00:28:39.004
К тому же в них чаще всего используется
механизм репликации данных, то есть

00:28:39.124 --> 00:28:42.804
хранение копий одних и тех же данных в
разных местах системы.

00:28:42.924 --> 00:28:44.324
Стандартно сохраняются три

00:28:45.147 --> 00:28:50.507
Копии каждого файла. Это увеличили
дисковый объём на целых 200%.

00:28:54.067 --> 00:28:58.867
Для минимизации затрат многие компании
стали прибегать к использованию облачных

00:28:58.947 --> 00:29:01.747
хранилищ. Экономия на оплате

00:29:02.691 --> 00:29:09.532
По мере потребления Space SU Go возможно,
если речь идёт об относительно небольших

00:29:09.612 --> 00:29:13.212
объёмах данных и их нечастом
использовании.

00:29:13.292 --> 00:29:17.093
При постоянном масштабировании объёмов
данных, интенсивной работе с ними этот

00:29:17.253 --> 00:29:18.253
подход также становится

00:29:19.368 --> 00:29:22.884
...затратным и обойдётся не дешевле,
соответственно, HTFS.

00:29:22.964 --> 00:29:28.677
Дело в том, что многие облачные провайдеры
берут плату не только за объём хранения

00:29:28.957 --> 00:29:32.793
данных, но и за трафик, извлекаемый из
записанных данных, а также за число

00:29:32.913 --> 00:29:36.748
обращений к хранилищу. Поэтому, когда
приходится иметь дело с анализом больших

00:29:36.828 --> 00:29:37.028
данных

00:29:38.067 --> 00:29:41.866
Передача массивов объёмов данных по
хранилище в публичном облаке становится

00:29:41.986 --> 00:29:43.226
дорогостоящим вариантом.

00:29:43.346 --> 00:29:46.825
Кроме того, могут возникнуть проблемы
конфиденциальности данных и

00:29:46.945 --> 00:29:48.745
производительности системы.

00:29:49.305 --> 00:29:52.904
Если много других пользователей также
будут интенсивно использовать ресурсы

00:29:53.024 --> 00:29:53.544
данного облака

00:29:56.286 --> 00:30:01.007
По мнению специалистов, самым приемлемым
выходом может быть объектная система

00:30:01.127 --> 00:30:06.409
хранения, то есть Obgect Storge, в которой
используются примерно те же технологии,

00:30:06.449 --> 00:30:10.810
что и в публичном облаке, то есть
гипертекст, трансфер-протокол HTTP.

00:30:11.050 --> 00:30:15.372
Протокол передачи данных предназначен для
передачи гипертекстовых документов,

00:30:15.452 --> 00:30:17.572
которые могут содержать ссылки,
позволяющие

00:30:18.331 --> 00:30:20.452
организовывать переход к другим
документом.

00:30:20.492 --> 00:30:26.133
То есть Application progaming интерфейс,
Интерфейс прикладного программирования.

00:30:26.533 --> 00:30:32.015
Объектные хранилища объектные хранилища
могут легко масштабировать до объёмов

00:30:32.335 --> 00:30:36.216
метабайтов в одном домене без каких-либо
снижений производительности.

00:30:36.296 --> 00:30:36.816
Кроме того,

00:30:37.697 --> 00:30:42.783
Объектные хранилища обладают функционалом
управления данными, чего нет в

00:30:42.823 --> 00:30:45.306
традиционных системах управления версиями.

00:30:46.707 --> 00:30:49.631
Кастомизация метаданных и встроенная
аналитика.

00:30:49.711 --> 00:30:54.996
Отличие традиционных хранилищ от объектных
наглядно представлено на рисунке No 13.

00:30:56.378 --> 00:31:00.859
Так, ну, во-первых, ссылка объектность
системы хранения.

00:31:01.979 --> 00:31:05.500
Так, рисунок — традиционное и объектное
хранилище.

00:31:05.821 --> 00:31:09.982
Соответственно, вот видите, с одной
стороны, так всё порядочно, таблично, а с

00:31:10.022 --> 00:31:11.342
другой стороны, оп.

00:31:12.262 --> 00:31:13.983
Объекты, объекты, объекты, объекты.

00:31:15.193 --> 00:31:18.951
Такие характеристики достигаются за счёт
абстрагирования уровня системы, то есть

00:31:19.191 --> 00:31:23.907
общего подхода, который сейчас
используется практически во всех

00:31:24.027 --> 00:31:26.585
EКT-системах, не только в системах
хранения.

00:31:26.665 --> 00:31:31.102
Каждый диск на надлежащем уровне
формируется простой локальной файловой

00:31:31.222 --> 00:31:31.662
системой.

00:31:34.080 --> 00:31:40.598
На верхнем уровне абстрагированном от
нижнего размещаются средства управления,

00:31:40.678 --> 00:31:44.677
что позволяет интегрировать все элементы в
единый унифицированный ток.

00:31:45.197 --> 00:31:46.877
Файлы различного вида.

00:31:47.800 --> 00:31:52.284
...хранятся как объекты, а не как файлы
файловой системы.

00:31:52.404 --> 00:31:56.688
Поскольку низкоуровневое управление
облаками передано локальной файловой

00:31:56.808 --> 00:32:02.573
системе, объектное хранилище ведёт только,
ведает только функциями управления

00:32:03.213 --> 00:32:06.897
высокого уровня, которые управляют
надлежащим уровнем через стандартное...

00:32:08.130 --> 00:32:11.766
Принцип объектного хранения можно
сравниться с услугой парковки, когда

00:32:11.966 --> 00:32:16.601
водитель просто оставляет машину, объект
для её размещения на парковочном

00:32:16.641 --> 00:32:20.917
пространстве и получает карточку, по
которой можно забрать машину.

00:32:20.997 --> 00:32:24.233
В карточку могут быть внесены метаданные:
имя водителя.

00:32:25.001 --> 00:32:27.079
Номер и марка машины.

00:32:28.798 --> 00:32:34.354
Где именно припаркуют машину водителю —
неважно, потому что ему не нужно кружить

00:32:34.554 --> 00:32:36.753
парковке в поиске свободного места.

00:32:38.032 --> 00:32:40.590
Такой подход позволяет сохранять таблицы.

00:32:40.912 --> 00:32:44.995
...просмотра файловой системы каждого узла
нижележащего уровня в пределах

00:32:45.516 --> 00:32:46.917
управляемого размера.

00:32:47.357 --> 00:32:52.080
Это позволяет масштабировать систему до
сотен Мбайт без заметного снижения

00:32:52.200 --> 00:32:56.884
производительности. Объектное хранилище
предназначено в основном для работы с

00:32:56.964 --> 00:32:58.085
неструктурированными данными...

00:32:59.515 --> 00:33:02.156
Понятие неструктурированных данных весьма
относительно.

00:33:02.316 --> 00:33:08.918
Все файлы с данными имеют ту или иную
структуру или тип.

00:33:09.598 --> 00:33:13.519
Неструктурированные данные просто не
хранятся вот в единой базе и содержат

00:33:13.919 --> 00:33:15.160
разные типы данных.

00:33:15.280 --> 00:33:18.801
Это набор разнородных файлов, созданных в
различных приложениях.

00:33:19.111 --> 00:33:20.990
...и полученных из разных источников.

00:33:21.110 --> 00:33:24.469
Это примерно то же самое, что папка «Мои
документы» на компьютере.

00:33:24.948 --> 00:33:30.146
Объекты неструктурированных данных можно
пометить метаданными, которые описывают их

00:33:30.146 --> 00:33:33.145
содержание и помогают быстро извлечь из
хранилища нужные объекты.

00:33:33.225 --> 00:33:35.783
В этом случае сами метаданные будут
структурированы.

00:33:36.549 --> 00:33:39.347
То есть будут иметь стандартную форму
определённой VIP.

00:33:39.467 --> 00:33:43.584
Это позволяет отслеживать,
идентифицировать объекты без необходимости

00:33:43.863 --> 00:33:46.501
применения внешних программ или баз
данных.

00:33:47.021 --> 00:33:50.538
Использование метаданных открывает новые
возможности для аналитики.

00:33:50.618 --> 00:33:51.618
Файлы объекты можно

00:33:52.553 --> 00:33:57.790
Индексировать и искать в объектном
хранилище, не зная структуру содержимого

00:33:58.389 --> 00:34:03.706
содержимого или того, в какой программе
они были созданы Репликация данных для

00:34:03.826 --> 00:34:08.023
надёжного хранения в объектной системе
нужна, как и для других подходов, но при

00:34:08.143 --> 00:34:09.502
этом не требуется устраивать

00:34:10.643 --> 00:34:12.883
утраивать объём дискового пространства.

00:34:13.043 --> 00:34:18.403
Для максимизации доступного дискового
пространства защиты данных используется

00:34:18.563 --> 00:34:23.242
технология эрашюры ES.

00:34:24.322 --> 00:34:26.202
Следующее поколение метода защиты

00:34:27.119 --> 00:34:32.518
данных рейд при котором необходимо двойное
или тройное резервирование.

00:34:32.598 --> 00:34:37.917
В методе ES, файлы объектов разделяются на
фрагменты шанс.

00:34:41.136 --> 00:34:45.619
Для некоторых из них создаются копии
избыточности в формате N +.

00:34:45.659 --> 00:34:49.821
Например, если для шести из десяти
фрагментов создаются копии, это будет

00:34:50.021 --> 00:34:51.782
формат 10 +6.

00:34:52.863 --> 00:34:59.266
Если для данных нужно, например, N-дисков,
копии избыточности разделяются по

00:34:59.426 --> 00:35:00.747
N+ дискам.

00:35:00.827 --> 00:35:02.228
В данном случае 16.

00:35:02.641 --> 00:35:07.002
При потере любых шести дисков оставшихся
десяти достаточно, чтобы восстановить

00:35:07.122 --> 00:35:11.803
исходные данные. Таким образом, объём
хранения получается на некоторых не такой

00:35:12.083 --> 00:35:13.524
большой, как в рай.

00:35:13.764 --> 00:35:17.124
И риск потери данных в случае отказа
дисков незначительный.

00:35:17.204 --> 00:35:17.965
Соответственно, тума

00:35:19.195 --> 00:35:25.360
могут выдерживать больше отказов дисков,
чем дисковые массивы rate.

00:35:25.440 --> 00:35:31.244
При этом пятабайтное масштабирование
системы не будет приводить к столь большим

00:35:31.324 --> 00:35:34.567
затратам на закупку дисков, как файловые
систем.

00:35:34.933 --> 00:35:36.971
Особенности объектных систем хранения.

00:35:37.371 --> 00:35:41.806
Данные хранятся как объекты, они в виде
традиционных блоков или файлов, состоящих

00:35:41.886 --> 00:35:46.202
из блоков. Объекты могут включать в себя
самые разные форматы: то есть резервные

00:35:46.322 --> 00:35:50.997
копии, архивы, видео, изображения,
лоб-журналы, файлы, и так далее.

00:35:51.798 --> 00:35:56.597
Объекты не структурированы по своей
природе, потому что нет единого формата

00:35:56.717 --> 00:35:58.437
для способа хранения таких данных.

00:35:58.517 --> 00:36:02.756
В отличие от структуры каталогов, который
имеется в традиционных файловых системах

00:36:02.836 --> 00:36:06.835
хранения, в объекте системы хранения,
используется простой список объектов,

00:36:07.155 --> 00:36:08.435
хранящихся в пакетах.

00:36:09.588 --> 00:36:14.589
Bookents. Объекты хранения с
использованием уникальных идентификаторов,

00:36:14.589 --> 00:36:18.629
а не имён файлов, что резко снижает
накладные расходы, необходимые для

00:36:18.749 --> 00:36:24.109
хранения данных. Объекты хранения вместе с
определёнными пользователями данными, что

00:36:24.189 --> 00:36:26.989
облегчает поиск объектов при
масштабировании данных.

00:36:27.109 --> 00:36:28.069
Объекты могут иметь

00:36:29.164 --> 00:36:32.807
...как тирабайтные объёмы, так и быть
размером с несколько кигабайт.

00:36:33.168 --> 00:36:35.610
Один пакет может содержать миллионы
объектов.

00:36:36.131 --> 00:36:40.215
Разработчики приложений могут легко
получить доступ к объектам, используя

00:36:40.335 --> 00:36:45.661
простые команды через интерфейс AP с
помощью запросов без сложных структур.

00:36:46.703 --> 00:36:53.227
Объектное хранилище часто выбирается для
данных Worm, которые пишутся один раз, но

00:36:53.347 --> 00:36:58.309
читаются много раз, right, once, reat
maning.

00:36:58.550 --> 00:37:03.673
Этот тип хранилища позволяет не для всех
объёмов данных, подходит не для всех

00:37:03.713 --> 00:37:06.434
объёмов данных из-под сценариев
использования.

00:37:09.535 --> 00:37:13.014
Объектная система хранения целесообразно
используется в следующих случаях.

00:37:13.174 --> 00:37:17.214
При долгосрочном хранении статичных
данных.

00:37:17.414 --> 00:37:19.774
Например, различной нормативной
документации.

00:37:24.253 --> 00:37:25.733
Резервное копирование.

00:37:26.443 --> 00:37:32.879
Дампы баз данных, файлы журналов,
ресервные кофии существующего программного

00:37:32.999 --> 00:37:39.634
обеспечения Разработки

00:37:39.794 --> 00:37:40.354
среды.

00:37:42.441 --> 00:37:46.885
Одно глобальное пространство имён, которое
легкодоступно с использованием простых

00:37:47.045 --> 00:37:51.930
запросов для управления различными
объектами большими данными: таблицами,

00:37:52.010 --> 00:37:54.532
изображениями, звука, видеофайлами и
прочим.

00:37:54.732 --> 00:37:58.616
Работа с неструктурированными данными:
мультимедийные факты, документы.

00:37:59.552 --> 00:38:05.070
Изображение звука и видеофайлы в отраслях
с большими объёмами хранения данных.

00:38:05.230 --> 00:38:10.908
Таких как здравоохранение, электронная
почта, мессенджеры, оцифрованные архивы

00:38:11.067 --> 00:38:14.466
музеев, конструкторских бюро и тому
подобное

00:38:14.949 --> 00:38:19.873
Итак, объектные системы хранения хорошо
подходят для хранения массивных,

00:38:19.953 --> 00:38:24.358
разнородных, то есть неструктурированных
данных, и отвечают запросам быстрого роста

00:38:24.518 --> 00:38:28.762
объёмов данных, которые нужно хранить,
обрабатывать и анализировать в различных

00:38:28.882 --> 00:38:33.006
отраслях. Именно поэтому объёмы объектных
систем хранения растут значительно

00:38:33.046 --> 00:38:34.167
быстрее, чем файловые.

00:38:35.466 --> 00:38:40.350
Какие бы системы хранения ни применялись,
цель у них одна — анализ имеющихся данных.

00:38:42.311 --> 00:38:43.592
Ссылочка.

00:38:46.955 --> 00:38:51.278
Так, следующий раздел современные
технологии хранения данных.

00:38:52.422 --> 00:38:55.505
Первое. Архитектура корпоративной системы
хранилища.

00:38:55.625 --> 00:39:01.070
То есть D.

00:39:01.991 --> 00:39:08.477
D. Система складирования данных
ориентируется на анализ

00:39:08.557 --> 00:39:09.598
накопленных данных.

00:39:10.809 --> 00:39:13.287
То есть на BI: Business interfейс.

00:39:13.327 --> 00:39:16.084
Intellegence, прошу прощения, Business
intillegens.

00:39:16.284 --> 00:39:20.481
Процесс анализа данных и получения
информации, помогающий компаниям принимать

00:39:20.641 --> 00:39:26.915
решения. Значит, структуризация данных и
хранилища данных должна быть

00:39:27.355 --> 00:39:31.151
выполнена таким образом, чтобы данные
эффективно использовались в аналитических

00:39:31.231 --> 00:39:31.711
приложениях.

00:39:33.247 --> 00:39:37.613
В корпоративных хранилищах, в удобном для
анализа виде хранятся данные из различных

00:39:37.734 --> 00:39:42.421
источников. Эти данные предварительно
обрабатываются и загружаются в хранилище с

00:39:42.461 --> 00:39:44.063
помощью технологии Indail.

00:39:44.848 --> 00:39:49.452
Поэтому главная особенность концепции
складирования данных — это структуризация,

00:39:49.532 --> 00:39:53.976
систематизация, классификация, фильтрация
и так далее, больших массивов информации в

00:39:54.016 --> 00:39:59.301
виде удобном для анализа, визуализации
результатов анализа и производства

00:39:59.501 --> 00:40:00.662
корпоративной отчётности.

00:40:01.643 --> 00:40:06.447
Системы, построенные на основе
информационных технологий складирования

00:40:06.567 --> 00:40:12.333
данных, обладают рядом особенностей,
которые выделяют их как новый класс

00:40:12.453 --> 00:40:13.894
информационных систем.

00:40:14.295 --> 00:40:18.098
К таким особенностям относится
предметно-ориентированная ориентация

00:40:18.378 --> 00:40:21.781
системы, интегрированность хранимых в ней
данных, собираемых

00:40:22.355 --> 00:40:27.272
из различных источников инвариантность
этих данных по времени относительно

00:40:27.512 --> 00:40:28.951
высокая стабильность данных.

00:40:29.071 --> 00:40:32.550
Необходимость поиска компромисса при
избыточности данных

00:40:43.537 --> 00:40:48.658
Большое разнообразие видов данных
затрудняет получение консолидированной

00:40:48.738 --> 00:40:53.378
отчётности, когда нужна целостная картина
из всех прикладных систем.

00:40:53.418 --> 00:40:57.859
В результате в девяностых годах XX века в
компании ABM зародилась информационная

00:40:57.979 --> 00:40:59.579
технология складирования данных.

00:40:59.874 --> 00:41:02.711
Да, по-моемусен

00:41:02.871 --> 00:41:09.423
DV, которая была сформулирована Иманом

00:41:10.182 --> 00:41:11.741
и Кимбалом.

00:41:12.500 --> 00:41:14.817
Значит, DWH.

00:41:15.336 --> 00:41:20.660
Предметно-ориентированная базы данных для
конструированной подготовки отчётов,

00:41:20.740 --> 00:41:24.023
интегрированного бизнес-анализа и
оптимального принятия управленческих

00:41:24.183 --> 00:41:26.945
решений на основе полной информационной

00:41:30.388 --> 00:41:32.669
картины. Решение

00:41:34.550 --> 00:41:39.308
DWH по сути представляет собой ту же
систему для хранения и работы с

00:41:39.388 --> 00:41:41.427
корпоративной информацией, что и TL.

00:41:41.507 --> 00:41:48.383
Архитектура WH многоуровневая, слоёная,
называется

00:41:48.543 --> 00:41:50.542
LC, то есть Laer.

00:41:52.157 --> 00:41:53.997
Скайлебл архитектуре.

00:41:54.077 --> 00:41:58.316
Она реализует логическое деление структур
с данными на несколько функциональных

00:41:58.396 --> 00:42:03.714
уровней. Данные копируются с уровня на
уровень и трансформируются при этом, чтобы

00:42:03.954 --> 00:42:09.273
в итоге предстать в виде информации,
пригодной для анализа.

00:42:09.393 --> 00:42:11.112
Классически LC.

00:42:11.350 --> 00:42:13.871
Реализуется в виде следующих уровней.

00:42:17.992 --> 00:42:23.154
Операционный слой первичных данных, то
есть праймер Data laver, lave

00:42:24.234 --> 00:42:26.435
или.

00:42:27.567 --> 00:42:32.484
На котором выполняется загрузка информации
из систем источников в исходном качестве с

00:42:32.564 --> 00:42:34.683
сохранением полной истории измерений.

00:42:35.003 --> 00:42:38.920
Здесь происходит абстрагирование следующих
слоёв хранилища от физического устройства

00:42:39.080 --> 00:42:43.877
источника данных способа их сбора и
методов выделения изменений.

00:42:44.959 --> 00:42:50.955
Ядро хранилища Hore Dacola — центральный
компонент, который выполняет консолидацию

00:42:51.075 --> 00:42:55.632
данных из различных источников, приводя их
к единым структурам ключам.

00:42:56.032 --> 00:43:01.708
Именно здесь происходит основная работа с
качеством данных и общей трансформации.

00:43:02.404 --> 00:43:06.008
Чтобы абстрагировать потребителя от
особенностей логического устройства

00:43:06.208 --> 00:43:10.053
источником данных и необходимости их
взаимного сопоставления.

00:43:10.494 --> 00:43:14.058
Так решается задача обеспечения
центральности и качества данных.

00:43:14.619 --> 00:43:17.262
Аналитические витрины Data Martle.

00:43:17.950 --> 00:43:22.592
Для данных преобразуются, где данные
преобразуются в структуры, удобные для

00:43:22.712 --> 00:43:24.953
анализа и использования в системах
потребителя.

00:43:25.073 --> 00:43:30.835
Витрины могут быть брать данные из ядра,
то есть регулярные витрины операционного

00:43:30.955 --> 00:43:34.237
слоя, операционные витрины могут
использоваться для представления

00:43:34.317 --> 00:43:35.717
результатов сложных расчётов.

00:43:36.517 --> 00:43:39.479
...и нетипичных трансформаций, то есть
вторичные витрины.

00:43:39.559 --> 00:43:43.203
Таким образом, витрина обеспечивает разное
представление сетиных данных под

00:43:43.363 --> 00:43:45.325
конкретную бизнес-специфику.

00:43:46.686 --> 00:43:53.492
Серверный слой сервак снейлор обеспечивает
управление всеми

00:43:53.813 --> 00:43:55.214
вышеописанными уровнями.

00:43:56.245 --> 00:44:02.568
Он не содержит бизнес-данных, но оперирует
мета-данными и другими структурами для

00:44:02.768 --> 00:44:06.850
работы с качеством данных и позволяя
выполнять сквозной аудит данных.

00:44:06.930 --> 00:44:10.892
То есть Data Line.

00:44:11.132 --> 00:44:14.333
Также доступны средства мониторинга и
диагностики ошибок.

00:44:15.708 --> 00:44:18.343
Что ускоряет решение проблем.

00:44:27.002 --> 00:44:31.922
Все слои, кроме сервисного, состоят из
области постоянного хранения данных и

00:44:32.042 --> 00:44:33.722
модуля загрузки и трансформации.

00:44:33.842 --> 00:44:38.121
Области хранения содержат технические
буферные таблицы для трансформации данных,

00:44:38.241 --> 00:44:40.921
целевые таблицы, в которых обращается
потребитель.

00:44:41.281 --> 00:44:45.641
Для обеспечения процессов загрузки аудита,
процессов данные в целевых таблицах.

00:44:46.571 --> 00:44:51.245
Стенжинга ядра и витринок маркируется
техническими полями, то есть

00:44:51.524 --> 00:44:53.202
мета-атрибутами.

00:44:53.721 --> 00:44:59.114
Ещё выделяют свой виртуальный слой
виртуальных провайдеров, да, с

00:44:59.194 --> 00:45:00.393
использованием отчётов для

00:45:00.824 --> 00:45:04.742
...виртуального объединения, то есть без
хранения данных из различных объектов.

00:45:04.942 --> 00:45:09.099
Каждый уровень может быть реализован с
помощью связанной технологии хранения и

00:45:09.299 --> 00:45:12.577
преобразования данных или универсальных
продуктов.

00:45:12.697 --> 00:45:17.174
Например, SAP Netflaver Business of House.

00:45:18.815 --> 00:45:25.782
Соответственно, слойная архитектура DWH
представлена на рисунке 14.

00:45:26.503 --> 00:45:28.625
Соответственно, как видите, хаус

00:45:33.190 --> 00:45:34.591
первичный слой данных.

00:45:36.375 --> 00:45:42.296
Ядроплеер с витрины служебные слои

00:45:42.616 --> 00:45:44.216
серва.

00:45:44.456 --> 00:45:51.376
С одной стороны, соус-систем, источники, и
с другой стороны,

00:45:51.576 --> 00:45:52.816
соответственно, бизнес.

00:45:56.357 --> 00:46:02.834
Системс, то есть системы анализа
бизнес-анализа.

00:46:03.274 --> 00:46:09.112
Значимость концепции DWH может может
проиллюстрироваться на примере.

00:46:09.232 --> 00:46:12.070
Допустим, в онлайн-магазине компании упал.

00:46:12.950 --> 00:46:18.794
Менеджеры просят бизнес-аналитика
разобраться в этом.

00:46:18.874 --> 00:46:24.798
Тот обращается, соответственно к D
извлекает данные по продажам, выручке,

00:46:24.838 --> 00:46:28.841
количеству пользователей, расходам и
собирает отчёт, который точно и подробно

00:46:28.921 --> 00:46:29.842
сообщает причины

00:46:30.871 --> 00:46:32.469
Падение финансовых пользователей.

00:46:32.629 --> 00:46:35.706
Менеджеры на основе этой информации
принимают решение.

00:46:41.740 --> 00:46:45.497
По изменению ассортимента товаров и
маркетинговой политики.

00:46:45.617 --> 00:46:50.093
Если бы такого аналитического отчёта не
было, управленцам пришлось бы искать

00:46:50.172 --> 00:46:51.052
проблему но.

00:46:51.800 --> 00:46:55.561
Ну, аналитики ведь не могут обращаться к
базам данных разных систем, просто

00:46:55.801 --> 00:47:01.361
извлекать оттуда то, что им надо, не
прибегая, соответственно, к WH.

00:47:01.641 --> 00:47:04.682
Это возможно, но нецелесообразно по
следующим причинам.

00:47:04.922 --> 00:47:11.362
Если компания большая то получение данных
из разных источников можно

00:47:11.602 --> 00:47:11.962
собирать

00:47:14.155 --> 00:47:17.114
Нужно собирать разрешения доступ и
доступы.

00:47:17.154 --> 00:47:21.112
У каждого подразделения, и, как правило,
свои базы данных со своими паролями,

00:47:21.192 --> 00:47:23.471
которые надо будет запрашивать отдельно.

00:47:23.631 --> 00:47:28.629
Соответственно, всё нужное уже хранится
под рукой в готовом виде.

00:47:28.828 --> 00:47:31.427
Там можно просто взять необходимую
статистику.

00:47:33.218 --> 00:47:39.891
Данные в DWH не теряются в хранилище
удобном для принятия

00:47:39.971 --> 00:47:45.845
решения. Есть исторические записи, есть
сагрегированные значения в определённых

00:47:45.925 --> 00:47:48.762
базе данных. Такой информации может и не
быть, вряд ли.

00:47:49.249 --> 00:47:54.131
На складском сервере будет храниться архив
запасов 10 лет.

00:47:54.451 --> 00:47:57.572
Базы данных склада в таком случае будут
слишком тяжёлые.

00:47:57.973 --> 00:48:03.055
А вот хранить агрегированные запасы на
складе, соответственно, iD H, вполне

00:48:03.135 --> 00:48:08.457
реально. Duble H оптимизируется для работы
аналитиков для запросов очень больших

00:48:08.497 --> 00:48:09.497
объёмов информации.

00:48:10.360 --> 00:48:12.520
Что невозможно сделать с базами данных
сервера.

00:48:12.600 --> 00:48:16.081
Он не справляется с этой задачей и создаст
проблемы другим системам.

00:48:16.201 --> 00:48:21.081
Итак, чтобы воспользоваться преимуществами
больших данных, важно учитывать их

00:48:21.161 --> 00:48:23.562
инфраструктуру для хранения и обработки.

00:48:24.002 --> 00:48:28.242
Современная инфраструктура системы
хранения больших данных должна, во-первых,

00:48:28.322 --> 00:48:31.283
обеспечивать длительное хранение больших
массивов данных.

00:48:32.279 --> 00:48:34.558
С возможностью оперативного доступа к ним.

00:48:34.638 --> 00:48:38.515
И, во-вторых, поддерживать функции их
консолидации, обработки и

00:48:38.595 --> 00:48:42.672
структурирования. Кроме того, современная
архитектура хранения должна эффективно

00:48:42.752 --> 00:48:47.229
справляться с данными, которые поступают в
реальном времени и на которые нужно

00:48:47.868 --> 00:48:49.147
реагировать мгновенно.

00:48:49.672 --> 00:48:54.025
А с данными, которые накапливаются годами,
имеют богатую историю.

00:48:55.582 --> 00:48:56.460
Так, ссылки.

00:49:01.434 --> 00:49:05.236
Архитектура для обработки и хранения
больших данных постоянно усложняется и

00:49:05.356 --> 00:49:07.757
может насчитывать десятки, сотни
компонентов.

00:49:08.037 --> 00:49:12.639
Сейчас получил признание тип хранилищ,
который специалисты называют озеро данных,

00:49:12.679 --> 00:49:17.401
куда можно записывать данные из множества
источников в исходном виде и эффективно их

00:49:17.441 --> 00:49:17.881
обрабатывать.

00:49:18.923 --> 00:49:22.807
Наличие у него такого уровня обработки,
как уровень памяти, то есть Speed Laer

00:49:24.168 --> 00:49:28.253
позволяет, то есть добавляет новые
возможности обработки данных в потоке

00:49:28.373 --> 00:49:35.340
реального времени. Так, хранилище данных в
озёрах Данных.

00:49:35.996 --> 00:49:42.720
В 2010 году с наступлением эпохи Big Data
фокус внимания традиционных DWH

00:49:43.000 --> 00:49:47.682
сместился к озёрам данных, то есть
Datalain, так называемый 99.

00:49:50.445 --> 00:49:54.607
Озеро данных — это не синоним хранилищ
данных или витрин данных.

00:49:54.687 --> 00:49:58.449
Конечно, это хранилище данных, но оно
принципиально отличается от остальных.

00:49:59.129 --> 00:50:05.891
По мнению программиста Лошина,
соответственно Лошина, идея озера данных

00:50:06.091 --> 00:50:07.612
заключается в том, что хранить

00:50:08.468 --> 00:50:13.273
Необработанные данные в их оригинальной
форме до тех пор, пока они не понадобятся.

00:50:13.674 --> 00:50:19.440
Данные DetaLake как рыба в озере, которая
попала туда из реки.

00:50:19.520 --> 00:50:22.523
Но точно неизвестно, какая именно это рыба
и где она находится.

00:50:22.603 --> 00:50:25.006
А чтобы приготовить в кавычках рыбу

00:50:25.647 --> 00:50:27.925
То есть обработать данные, её нужно ещё
поймать.

00:50:28.165 --> 00:50:31.162
Озера данных принимают любые файлы всех
форматов.

00:50:31.282 --> 00:50:34.720
Источник данных тоже не имеет никакого
значения.

00:50:34.799 --> 00:50:40.635
Это могут быть данные из CRM, данные
ЕРП-систем, продуктовых каталогов,

00:50:40.755 --> 00:50:41.754
банковских программ.

00:50:42.680 --> 00:50:46.640
Датчиков или умных устройств, любых
систем, которые используют бизнес.

00:50:46.800 --> 00:50:50.800
Потом, когда данные будут сохранены, с
ними можно будет работать

00:50:54.881 --> 00:50:59.001
То есть извлекать по определённому шаблону
из классических баз данных или

00:50:59.161 --> 00:51:01.561
анализировать и обрабатывать прямо внутри
хозда.

00:51:02.198 --> 00:51:08.355
Озеро данных имеет свои особенности,
поэтому у нас не совсем корректно относить

00:51:08.474 --> 00:51:12.752
его к новому поколению корпоративных
хранилищ данных по следующим причинам.

00:51:12.832 --> 00:51:17.390
То есть в традиционных хранилищах люди и
машины сначала собирали данные, очищали.

00:51:18.094 --> 00:51:20.214
Структурировали их, а затем использовали.

00:51:20.535 --> 00:51:25.415
Озеро данных состоит из разных типов
данных, которые стекаются из

00:51:25.535 --> 00:51:26.936
многочисленных источников.

00:51:27.016 --> 00:51:32.057
Заполнение озера только структурированными
данными означало бы, что оно теряет хотя

00:51:32.137 --> 00:51:33.857
бы часть своей структуры и значений.

00:51:33.977 --> 00:51:37.297
Если компании необходимо только
структурированные данные, корпоративное

00:51:37.337 --> 00:51:39.378
хранилище подходит ей лучше, чем озеро
данных.

00:51:41.399 --> 00:51:46.844
DWH и озеро данных имеют разные целевые
назначения.

00:51:47.004 --> 00:51:52.450
DW используется менеджерами, аналитиками и
другими конечными бизнес-пользователями.

00:51:52.530 --> 00:51:55.653
Так как озеро данных в основном эксперты
по аналитиче

00:51:57.567 --> 00:52:02.010
аналитическим данным, которые обладают
техническими навыками для решения сложных

00:52:02.131 --> 00:52:05.734
задач, также любопытством, которое
помогают задачи ставить.

00:52:05.934 --> 00:52:10.978
Так называемые даты-стематикс схематиксами

00:52:11.979 --> 00:52:16.102
неструктурированная сырая информация,
которая хранится в озере данных

00:52:16.426 --> 00:52:21.343
видеозаписи с беспилотников, камер
наружного наблюдения, транспортная

00:52:21.503 --> 00:52:26.260
телеметрия, графические изображения, логи
пользовательского поведения, метрики

00:52:26.380 --> 00:52:30.738
сайтов, информационные системы, а также
прочие данные с разными форматами

00:52:30.818 --> 00:52:35.455
хранения, схемами представления пока
непригодны для ежедневной аналитики в

00:52:35.575 --> 00:52:37.613
би-системах, то есть бизнеса.

00:52:39.611 --> 00:52:46.215
Но может использоваться, соответственно,
дальсентист быстрые для быстрой отработки

00:52:46.295 --> 00:52:49.617
бизнес-гипотез с помощью алгоритмов
машинного обучения.

00:52:50.258 --> 00:52:54.741
Чтобы работать с осёрами данных в
компании, должны быть технические

00:52:54.821 --> 00:52:55.461
специалисты.

00:52:55.807 --> 00:53:01.088
Data Centist, Data-инeр, проектировщик,
надёжная инфраструктура для данных,

00:53:01.128 --> 00:53:05.209
бизнес-аналитик. Такие специалисты имеют
доступ к данным в озере и могут их

00:53:05.249 --> 00:53:11.530
обрабатывать с помощью

00:53:11.810 --> 00:53:14.091
различных аналитических систем и подходов.

00:53:14.131 --> 00:53:16.011
В озере данных можно обработать

00:53:16.978 --> 00:53:21.897
Без извлечения достаточно оборудовать
системы для анализа прямо внутри него.

00:53:22.377 --> 00:53:27.655
В DWH и озере данных отличаются разными
подходами к проектированию.

00:53:27.975 --> 00:53:32.694
Дизайн DWH основан на реляционной логике
работы с данными.

00:53:32.734 --> 00:53:35.573
То есть третья нормальная форма для
нормализованных хранилищ.

00:53:36.142 --> 00:53:41.502
Схема-звезда или снежинка для хранилищ с
измерениями, смотрите предыдущие разделы.

00:53:41.942 --> 00:53:46.221
При проектировании озера данной
архитектуры Big Dita и Dita Inginein

00:53:46.781 --> 00:53:52.420
больше внимания уделяют процессам с учётом
многообразия источников приёмников.

00:53:53.519 --> 00:53:55.438
Разноформной информации.

00:53:56.077 --> 00:53:59.155
Вопрос непосредственно хранения данных
решается достаточно просто.

00:53:59.275 --> 00:54:05.191
Требуется лишь масштабируемая,
отказоустойчивая и относительно дешёвая

00:54:05.351 --> 00:54:09.987
файловая система. Например HD или,
соответственно, Amazon Streep.

00:54:10.523 --> 00:54:15.370
Озеро данных отличается гибкостью и
доступностью данных может

00:54:16.972 --> 00:54:21.939
представлять пользователями последующим
приложениям базы данных.

00:54:24.124 --> 00:54:27.883
Две схемы, то есть данные в естественном
формате независимо от их происхождения.

00:54:27.963 --> 00:54:31.121
Здесь ничего не нужно определять заранее,
так как в случае использования

00:54:31.521 --> 00:54:35.720
корпоративных хранилищ, когда ещё на
старте нужно выявить актуальные для неё

00:54:35.800 --> 00:54:40.078
типы данных структуру, а в случае
появления данных новых форматов базу

00:54:40.797 --> 00:54:47.469
Придётся перестраивать. В базе данных все
данные полезные и актуальны для компании

00:54:48.029 --> 00:54:52.464
прямо сейчас. Данные, которые пока кажутся
бесполезными, отсеиваются и теряются

00:54:52.624 --> 00:54:56.660
навсегда. База данных идеальна для
хранения важной информации, которая всегда

00:54:56.899 --> 00:54:58.697
должна быть под рукой, либо для основного

00:54:59.359 --> 00:55:04.359
Основной аналитики. В озёрах данных
хранят, в том числе и бесполезные данные,

00:55:04.479 --> 00:55:07.599
которые могут пригодиться в будущем или не
понадобятся вовсе.

00:55:07.919 --> 00:55:12.759
В них удобно хранить архивы неочищенной
информации, создавать большую базу для

00:55:12.839 --> 00:55:14.319
масштабированной аналитики.

00:55:15.114 --> 00:55:19.230
Масштабная аналитика. Большинство
приложений озера данных не поддерживают

00:55:19.350 --> 00:55:22.028
частичную или инкрементную загрузку.

00:55:22.107 --> 00:55:25.904
Организация не может загружать или
перезагружать части своих данных в озеро

00:55:26.024 --> 00:55:30.380
данных. То есть все или ничего.

00:55:35.668 --> 00:55:40.585
Озеро данных обычно строится на базе
бюджетных серверов, собачик и дуб, без

00:55:40.865 --> 00:55:44.424
дорогостоящих лицензии и мощного
оборудования, в отличие от больших затрат

00:55:44.943 --> 00:55:48.742
на проектирование и покупку
специализированных платформ класса Dita

00:55:48.782 --> 00:55:51.220
Workhouse, таких как SAP, orrucle.

00:55:52.087 --> 00:55:53.486
Теродаты и прочее.

00:55:53.846 --> 00:55:58.922
При доступе к озерам данных пользователи
должны знать конкретные типы данных и

00:55:59.002 --> 00:56:01.081
источники, в которых они нуждаются.

00:56:01.600 --> 00:56:05.957
Сколько данных им нужно, когда это нужно,
методы аналитики, которые будут

00:56:06.037 --> 00:56:09.235
применяться к этим данным. Такое
невозможно в хранилище данных.

00:56:09.315 --> 00:56:10.754
Поэтому схема озера данных

00:56:11.540 --> 00:56:14.656
Определяется не по записи, а по чтению.

00:56:15.096 --> 00:56:20.570
Для озера данных всё ещё требуется схема,
но она не предопределена.

00:56:20.730 --> 00:56:24.086
Это как отход — отход.

00:56:24.246 --> 00:56:28.002
То есть данные используются по плану или
схеме.

00:56:28.229 --> 00:56:34.275
Когда пользователи извлекают их, а не
когда загружают озёра данных сохраняют

00:56:34.355 --> 00:56:37.798
данные в неизменном, то есть естественном
состоянии.

00:56:37.958 --> 00:56:41.721
Требования не определяются до тех пор,
пока пользователи не запросят данные.

00:56:41.801 --> 00:56:45.765
Таким образом, в случае озера данных
информацию структурируют на выходе.

00:56:46.273 --> 00:56:48.995
...когда нужно извлечь данные или
проанализировать их.

00:56:49.075 --> 00:56:52.358
При этом процесс анализа не влияет на сами
данные в озере.

00:56:52.598 --> 00:56:57.842
Они так и остаются неструктурированными,
чтобы их было так же удобно хранить и

00:56:57.922 --> 00:56:59.404
использовать для других целей.

00:56:59.884 --> 00:57:02.967
При правильном использовании,
соответственно, озера данных...

00:57:03.947 --> 00:57:07.306
Предоставляет бизнес-пользователям,
техническим пользователям возможность

00:57:08.306 --> 00:57:13.264
затрачивать меньше более актуальные и
более гибкие наборы данных.

00:57:13.784 --> 00:57:18.262
В результате время запросов может
сократиться до работы как витрины данных

00:57:18.382 --> 00:57:20.382
хранилища данных или реакционной базы
данных

00:57:21.109 --> 00:57:25.266
Указанные выше особенности отличает озёра
данных от соответственно корпоративных

00:57:25.346 --> 00:57:30.423
хранилищ. Вместе с тем архитектурный
подход SA может использоваться и при

00:57:30.543 --> 00:57:32.581
построении озёр данных.

00:57:43.458 --> 00:57:47.815
Например, на уровне RA хранятся сырые
данные различных форматов.

00:57:48.175 --> 00:57:55.091
Допустим, TSV, XML, CSLOC, Jesson

00:57:55.451 --> 00:57:58.889
и так далее. На операционном уровне, то
есть OD

00:57:59.803 --> 00:58:02.082
Операция Data Definition.

00:58:02.202 --> 00:58:06.198
Сырые данные преобразуются в приближённый
к велиционному формату на уровне

00:58:06.318 --> 00:58:12.993
детализации DDStorge собирается,
консолидируется

00:58:13.193 --> 00:58:14.592
модель детальных данных.

00:58:14.792 --> 00:58:18.869
Уровень март — витрина данных через Deta
wouphouse выполняет

00:58:19.868 --> 00:58:24.151
Роль прикладных витрин данных для
бизнес-пользователей и моделей машинного

00:58:24.271 --> 00:58:30.035
обучения. Озёра данных можно использовать
в любом бизнесе, который собирает данные,

00:58:30.235 --> 00:58:36.640
соответственно, маркетинг, ритейл,
IT-производство, логистика и прочее.

00:58:37.779 --> 00:58:42.461
Возврат данных позволяет накапливать
данные про запас, а не под конкретный

00:58:42.581 --> 00:58:43.942
запрос бизнеса.

00:58:48.784 --> 00:58:53.067
За счёт того, что данные всегда под рукой,
компания может быстро проверить любую

00:58:53.187 --> 00:58:55.628
гипотезу или использовать данные для своих
целей.

00:58:55.748 --> 00:58:58.390
Например, на производстве использующем
интернет-вещей

00:59:00.307 --> 00:59:05.705
IOT на сложном оборудовании, которое часто
ломается, устанавливаются датчики

00:59:05.825 --> 00:59:09.465
контроля, данные из которых можно собирать
в озеро данных без фильтрации.

00:59:09.625 --> 00:59:13.424
Когда данные накопятся достаточно, можно
их проанализировать и понять, из-за чего

00:59:13.664 --> 00:59:15.743
случаются поломки и как их

00:59:16.517 --> 00:59:23.037
Предотвратить. В Ритейле ИКомс можно
хранить в озере разрозненную

00:59:23.117 --> 00:59:28.638
информацию о клиентах: время, проведённое
на сайте, активность в группе, в соцсетях,

00:59:29.078 --> 00:59:34.038
тон голоса при звуках, звонках менеджеру и
регулярность покупок.

00:59:34.726 --> 00:59:38.694
Потом эту информацию можно использовать
для глобальной масштабной аналитики,

00:59:38.775 --> 00:59:40.659
прогнозирования поведения клиентов.

00:59:40.739 --> 00:59:41.421
Таким образом,

00:59:42.207 --> 00:59:46.728
Озёра данных нужны для гибкого анализа
данных и построения гипотез.

00:59:47.288 --> 00:59:51.969
Они позволяют собирать так, как можно
больше данных, чтобы потом с помощью

00:59:52.049 --> 00:59:57.169
инструментов машинного обучения, аналитики
сопоставлять разные факты, делать

00:59:57.249 --> 01:00:01.450
невероятные прогнозы, анализировать
информацию с разных сторон, извлекать из

01:00:01.610 --> 01:00:03.130
данных всё больше пользы.

01:00:05.404 --> 01:00:11.054
Исследования показали, что компании,
внедрившие в озер данных на 9% опережают

01:00:11.214 --> 01:00:13.458
своих конкурентов по выручке.

01:00:14.314 --> 01:00:18.673
Так что можно сказать, что озера данных
нужны компаниям, в которых озёра данных,

01:00:18.713 --> 01:00:22.472
которые нужны компаниям, которые хотят
зарабатывать больше, используя для этого

01:00:22.672 --> 01:00:27.590
анализ собственных данных. Компании-лидеры
используют передовые подходы к аналитике

01:00:27.710 --> 01:00:29.710
данных, хранящихся в озере.

01:00:29.790 --> 01:00:31.150
Например, машинное обучение.

01:00:31.270 --> 01:00:35.108
С помощью такого подхода компания может
получить полезные инсайты.

01:00:35.618 --> 01:00:40.053
Различные природы выявить закономерности,
прогнозировать сценарий будущего.

01:00:40.133 --> 01:00:46.326
Вместе с преимуществами у озер озёрданных
есть одна серьёзная проблема: любые данные

01:00:46.446 --> 01:00:48.604
попадают туда практически без контроля.

01:00:48.724 --> 01:00:51.241
Это значит, что определять их качество
невозможно.

01:00:52.047 --> 01:00:57.532
Если у компании нет чёткой модели данных,
то есть понимания типов структур данных и

01:00:57.652 --> 01:01:02.577
методов методов обработки, то управление
озером плохо организовано, в нём быстро

01:01:02.737 --> 01:01:07.742
накапливаются огромные объёмы
неконтролируемых данных, чаще всего

01:01:07.862 --> 01:01:11.426
бесполезных. В итоге озеро превращается в
болото данных

01:01:12.408 --> 01:01:16.363
То есть бесполезное, поглощающее ресурсы
компании и не приносящее пользы.

01:01:16.483 --> 01:01:20.357
В таком случае его нужно полностью стереть
и начать собирать данные заново.

01:01:21.556 --> 01:01:24.991
Проблема использования озера данных
представлена на следующем рисунке.

01:01:26.522 --> 01:01:33.238
В общем, в 2018 году 90% внедрения озёр
данных будут бесполезны, потому что они

01:01:33.358 --> 01:01:36.716
будут переполнены информацией, собранной
неизвестно с какой целью.

01:01:37.356 --> 01:01:42.832
Соответственно, вот это вот в 2015 году
был такой прогноз.

01:01:43.296 --> 01:01:47.854
Прогноз гейграфик планет Суши.

01:01:48.294 --> 01:01:50.772
Интересно, насколько он сбылся.

01:01:51.892 --> 01:01:58.209
Данные в озере могут быть неконцистентны и
иметь не иметь

01:01:58.289 --> 01:02:00.248
метаданных, поэтому реально только

01:02:01.331 --> 01:02:07.535
Очень опытные аналитики, хорошо знающие
контекст, могут, соответственно, сливать и

01:02:07.695 --> 01:02:10.097
согласовывать данные из разных источников.

01:02:10.737 --> 01:02:17.302
Чтобы озеро не стало болотом, нужно
наладить в компании процесс управления

01:02:17.382 --> 01:02:17.742
данными.

01:02:21.814 --> 01:02:25.491
Главная составляющая этого процесса —
определение достоверности и качества

01:02:25.650 --> 01:02:28.088
данных ещё до загрузки.

01:02:30.127 --> 01:02:35.242
Для этого необходимо отсекать источники
заведомо

01:02:35.885 --> 01:02:37.243
недостоверных данных.

01:02:37.323 --> 01:02:42.278
Ограничивать доступ на загрузку для
сотрудников, у которых нет на это прав.

01:02:42.438 --> 01:02:48.233
Проверять некоторые параметры файлов,
например, не пропускать в озеро картинки,

01:02:48.312 --> 01:02:50.630
которые весят десятки Гбайт.

01:02:50.830 --> 01:02:52.828
Настроить такую фильтрацию проще, чем

01:02:53.935 --> 01:02:56.698
Каждый раз структурировать данные для
загрузки базы данных.

01:02:56.859 --> 01:03:01.024
Если процесс налажен, в озеро попадают
только актуальные данные, значит, и сама

01:03:01.104 --> 01:03:06.150
база будет достоверной при проектировании
любого озера данных.

01:03:06.918 --> 01:03:10.595
Надо заранее определиться, для какой, для
какой цели его строить.

01:03:10.755 --> 01:03:14.633
Есть мнение, что озеро данных — это не
только важное, но и обязательное условие

01:03:14.752 --> 01:03:18.870
для компаний, которая управляет данными,
поскольку хранилища данных не создавались

01:03:18.950 --> 01:03:22.307
для обработки огромных потоков
неструктурированных данных.

01:03:22.347 --> 01:03:25.225
Следовательно, организация эффективного
управления озером данных.

01:03:25.936 --> 01:03:28.133
Важная задача для компании.

01:03:29.692 --> 01:03:32.489
Так, ну и в конце раздел ссылки.

01:03:37.803 --> 01:03:41.479
Так, ну и следующий раздел, сколько
успеем: аналитика больших данных, её

01:03:41.639 --> 01:03:42.438
инструментарий.

01:03:43.457 --> 01:03:45.296
От традиционного анализа к операционному.

01:03:45.376 --> 01:03:49.816
Данные, собранные в хранилище, нужны не
сами по себе, а для их анализа и принятия

01:03:49.856 --> 01:03:53.735
управленческих решений. Традиционный
пакетный анализ или аналитик 1-ноль

01:03:53.895 --> 01:03:57.095
сформировался ещё в
восьмидесятые-двадцатые, получается

01:03:58.250 --> 01:04:02.457
Вплоть до XX века. Изначально аналитика
1.0 задумывалась как средство хранения и

01:04:02.537 --> 01:04:05.983
загрузки информации для составления
отчётов и предназначалось для

01:04:06.103 --> 01:04:07.586
руководителей высшего звена.

01:04:08.100 --> 01:04:12.344
Аналитика 1.0 в большей степени опиралась
на описательную статистику отчётности с

01:04:12.384 --> 01:04:15.026
редкими вкраплениями прогностической
аналитики.

01:04:15.467 --> 01:04:20.110
Данные поставлялись почти исключительно из
внутренних источников, хорошо были хорошо

01:04:20.311 --> 01:04:24.994
структурированы, они собирались, хранились
IT-отделом, предоставлялись по запросу.

01:04:25.115 --> 01:04:26.476
Чтобы сделать данные

01:04:27.209 --> 01:04:31.012
Доступными для анализа IT-систем
требовалось довольно много времени.

01:04:31.173 --> 01:04:36.617
После получения данных аналитики выполняли
массу дополнительных последовательных

01:04:36.737 --> 01:04:40.580
работ разного рода преобразования,
агрегирования, комбинирования данных из

01:04:40.741 --> 01:04:44.183
различных источников. Всё это затягивало
процесс получения результатов.

01:04:45.101 --> 01:04:48.781
Получилось, что время в основном тратилось
на сбор и обработку данных, а не на

01:04:48.861 --> 01:04:55.142
собственный анализ. В начале двухтысячных
годов началось становление эры больших

01:04:55.222 --> 01:04:58.862
данных. То есть произошла замена
технологий на базе на более дешёвые и

01:04:58.982 --> 01:05:02.942
быстрые версии прежних аналогов, которые
отвечали требованиям времени.

01:05:03.581 --> 01:05:10.501
Этот этап становления так называемой
аналитики 2.0 прогностической аналитики.

01:05:11.901 --> 01:05:15.381
Так, ну вот если аналитика 1.0 в большей
степени опиралась на описательную

01:05:15.501 --> 01:05:19.581
статистику и отчётность с редким
вкраплением прогностической аналитики,

01:05:19.621 --> 01:05:22.982
данные поставлялись почти исключительно из
внутренних источников, собирались,

01:05:23.022 --> 01:05:24.262
хранились IT-отделом.

01:05:24.852 --> 01:05:26.651
...и предоставлялись по запросу.

01:05:27.371 --> 01:05:30.970
Значит, чтобы данные сделать доступными
для IT-анализа, IT-специалистам

01:05:31.050 --> 01:05:32.449
требовалось довольно много времени.

01:05:32.569 --> 01:05:36.687
После получения данных аналитики выполняли
массу дополнительных подготовительных

01:05:36.767 --> 01:05:39.046
работ, разного рода преобразования.

01:05:39.446 --> 01:05:41.845
Всё это затягивало процесс получения...

01:05:42.813 --> 01:05:47.089
Так, новый этап развития технологий Биг
Дата в условиях современного цифрового

01:05:47.209 --> 01:05:51.685
бизнеса называют аналитикой 3.0 или
операционная аналитика.

01:05:52.045 --> 01:05:59.039
Так, ссылки, значит, Фрэнкс революция
аналитики, как в эпоху Бигдата

01:05:59.398 --> 01:06:00.917
улучшить ваш бизнес с помощью

01:06:01.433 --> 01:06:02.793
Операционной аналитики.

01:06:07.914 --> 01:06:11.995
Речь идёт о переходе к совершенно новой
для бизнес-ситуации, когда аналитические

01:06:12.115 --> 01:06:16.076
решения внутри компании не просто помогают
видеть результаты прошлого, тестировать

01:06:16.236 --> 01:06:19.717
сценарии будущего, правильно построенная
аналитическая машина.

01:06:20.384 --> 01:06:25.186
способна на основании доступных ей данных
самостоятельно принимать решения

01:06:25.346 --> 01:06:30.349
операционного уровня, делая это тысячи и
миллионы раз в день.

01:06:30.429 --> 01:06:35.512
Очень многие управленческие решения могут
приниматься разработанными алгоритмами без

01:06:35.672 --> 01:06:38.514
вмешательства человека. Таким образом,
операционная аналитика

01:06:39.283 --> 01:06:43.164
Интегрирует аналитику в бизнес-процессы и
автоматизирует принятие решений без

01:06:43.284 --> 01:06:48.804
участия человека. Такая аналитика
традиционного уровня — это новый шаг по

01:06:48.844 --> 01:06:52.404
сравнению с традиционным пониманием
бизнес-анализа как базы для принятия

01:06:52.444 --> 01:06:54.124
решений на стратегическом уровне.

01:06:54.244 --> 01:06:55.484
Например, правильно настроенный

01:06:56.334 --> 01:07:00.177
Рекомендательный алгоритм на сайте
интернет-магазина гораздо лучше любого

01:07:00.297 --> 01:07:05.222
человека и продавца имеет предлагать
покупателю дополнительные сервисы и

01:07:05.342 --> 01:07:11.828
покупки. В отличие от неторопливой
пакетной аналитики, операционная аналитика

01:07:11.948 --> 01:07:14.270
выполняется много быстрее и непрерывно.

01:07:15.312 --> 01:07:19.149
При этом она интегрируется с существующими
бизнес-процессами и системами.

01:07:19.588 --> 01:07:24.425
Становление аналитики 3.0 можно сравнить с
историей разворачивания промышленной

01:07:24.545 --> 01:07:28.142
революции, которая трансформировала
ремесленничество в современные технологии

01:07:28.222 --> 01:07:31.820
производства, позволяющие производить
качественные продукты в массовом масштабе.

01:07:32.575 --> 01:07:35.332
Что-то похожее происходит сейчас и в
области аналитики.

01:07:35.692 --> 01:07:39.609
Переход к операционной аналитике не
устраняет ни одного из шагов, которые

01:07:39.889 --> 01:07:43.206
традиционно требуют создание
аналитического процесса, и при этом

01:07:43.326 --> 01:07:44.885
процесс развивается дальше.

01:07:45.284 --> 01:07:48.442
Операционная аналитика придаёт аналитике
промышленный масштаб.

01:07:49.371 --> 01:07:54.246
У современного бизнеса есть возможности
для применения операционной аналитики.

01:07:54.366 --> 01:07:58.642
Она уже работает и оказывает влияние на
многие стороны жизни человека.

01:07:59.361 --> 01:08:03.237
Например, в случае задержки рейса
авиакомпании автоматически перенаправляют

01:08:03.317 --> 01:08:04.675
пассажиров на другой маршрут.

01:08:04.981 --> 01:08:08.902
При этом автоматически программы применяют
во внимание множество факторов, в том

01:08:08.942 --> 01:08:12.784
числе касающихся конкретного клиента,
других пассажиров, статуса альтернативных

01:08:12.944 --> 01:08:18.866
рейсов. Например, приходя в магазин, люди
могут на месте получить кредит на основе

01:08:19.186 --> 01:08:22.827
оценки их текущей кредитоспособности,
которая определяется с помощью анализа

01:08:22.947 --> 01:08:25.668
широкого диапазона данных кредитной
истории клиента.

01:08:26.524 --> 01:08:31.238
Ещё пример. Операционная аналитика,
основан на показателе датчиков двигателя

01:08:31.358 --> 01:08:33.995
автомобиля выдаётся почти сразу.

01:08:34.155 --> 01:08:38.390
Она выполняется параллельно с работой
двигателя, а поступающая с датчиков

01:08:38.590 --> 01:08:41.067
информация анализируется в режиме
реального времени.

01:08:41.226 --> 01:08:42.944
Если выявляется некая проблема

01:08:43.979 --> 01:08:47.377
То принимаются меры по её предотвращению.

01:08:47.537 --> 01:08:53.654
Например, водитель за рулём автомобиля
получает ущеждающую уведомление о том, что

01:08:53.734 --> 01:08:55.853
в двигателе начинает твориться что-то
неладное.

01:08:55.973 --> 01:08:58.972
По мере развития аналитики будет
происходить и смена существующих

01:08:59.468 --> 01:09:02.467
...моделей и конкурентной среды.

01:09:03.226 --> 01:09:07.783
Если раньше можно было действительно
довольствоваться данными недельной

01:09:07.863 --> 01:09:11.101
давности аналитическими процессами,
построенными на пакетной обработке, то

01:09:11.221 --> 01:09:13.220
сейчас это уже, как правило, недостаточно.

01:09:13.620 --> 01:09:17.937
Ещё через 5—10 лет не останется
практически ни одной бизнес-модели,

01:09:18.057 --> 01:09:19.936
которая затронет данные тенденции.

01:09:20.368 --> 01:09:24.048
Переход к операционной аналитике может
сводиться к модернизации существующего

01:09:24.128 --> 01:09:25.448
аналитического процесса.

01:09:25.568 --> 01:09:29.248
Но чаще операционные аналитики включают в
себя разные типы аналитики.

01:09:29.648 --> 01:09:34.649
Операционная аналитика используется для
поддержки стратегических и повседневных

01:09:34.809 --> 01:09:39.009
технических решений. Но не только
рекомендует те или иные действия, а

01:09:39.049 --> 01:09:40.289
непосредственно их реализует.

01:09:41.061 --> 01:09:44.542
Причём эти действия осуществляются
незамедлительно.

01:09:44.663 --> 01:09:49.384
Человек не участвует ни в принятии
решений, ни в осуществлении действий.

01:09:49.945 --> 01:09:54.186
Получается, что операционная аналитика
выходит за пределы описаний или прогнозов.

01:09:54.267 --> 01:09:57.268
Она предписывает. Это означает, что
операционная аналитика

01:09:58.835 --> 01:10:02.275
...встраивается в бизнес-процесс, чтобы
самостоятельно принимать решение и

01:10:02.355 --> 01:10:05.914
выполнять действия на основе заложенных в
неё алгоритмов.

01:10:06.714 --> 01:10:09.834
Ссылка эволюция аналитики.

01:10:11.114 --> 01:10:15.754
Так, иллюстрация. Виды аналитики
подписывающая, описательная...

01:10:17.315 --> 01:10:19.196
Предиктивная диагностическая.

01:10:19.356 --> 01:10:23.837
Итак, на протяжении последнего десятилетия
много внимания уделялось переходу

01:10:23.997 --> 01:10:26.398
аналитики от описательной к азностической.

01:10:26.879 --> 01:10:31.000
Если в традиционной бизнес-аналитике
внимание сосредоточивалось на анализе

01:10:31.800 --> 01:10:34.602
произошедшего с описательной точки зрения,
то есть, например

01:10:35.432 --> 01:10:42.160
Определение объёма товара продаж товара по
каждому региону доли поставок или

01:10:42.360 --> 01:10:43.641
других важных показателей.

01:10:43.842 --> 01:10:49.007
Целью прогностической аналитики наоборот
является предсказание того, что произойдёт

01:10:49.087 --> 01:10:52.812
в будущем. Например, как увеличить долю
современных поставок товара.

01:10:53.944 --> 01:10:58.782
Какие клиенты с наибольшей вероятностью
откликаются на новые маркетинговые

01:10:58.822 --> 01:11:03.819
предложения. Операционная аналитика идёт
ещё дальше и делает аналитику

01:11:03.939 --> 01:11:07.657
предписывающую. Операционно-аналитический
процесс начинается с определения того,

01:11:07.777 --> 01:11:10.216
какие действия повлияют на время поставки.

01:11:10.773 --> 01:11:14.809
...или повысит уровень откликов, а затем
автоматически побуждает эти действия

01:11:14.969 --> 01:11:20.003
произойти. Сущность разных видов аналитики
представлена вот в таблице три.

01:11:21.921 --> 01:11:25.678
Значит, вид аналитики, особенность: вид
аналитики, описательная аналитика,

01:11:25.718 --> 01:11:28.435
анализирует и описывает события,
произошедшие в прошлом...

01:11:30.242 --> 01:11:35.279
Вид аналитики: прогностическая аналитика,
особенность прогнозирует будущие события.

01:11:35.439 --> 01:11:39.916
Наконец, вид аналитики, предписывающий
аналитика, особенности, определяет

01:11:40.036 --> 01:11:42.435
действия, необходимые для достижения цели.

01:11:43.154 --> 01:11:47.192
Одно из важных отличий операционной
аналитики состоит в том, что анализ

01:11:48.187 --> 01:11:52.305
Выполняется в автоматическом
интегрированном режиме в пределах так

01:11:52.385 --> 01:11:54.185
называемого времени принятия решения.

01:11:54.264 --> 01:11:58.423
То есть анализ выполняется со скоростью,
позволяющей быстро принять решение.

01:11:58.543 --> 01:12:02.062
В некоторых случаях принятие решения
происходит в режиме реального времени.

01:12:03.141 --> 01:12:04.381
Или очень быстро к тому

01:12:05.724 --> 01:12:10.720
В других случаях период ожидания может
составлять несколько минут, часов или даже

01:12:10.960 --> 01:12:15.517
дней. Знать время принятия решения крайне
важно для достижения успеха, поскольку

01:12:15.597 --> 01:12:19.594
аналитический процесс должен быть доступен
и выполняться в пределах этого интервала.

01:12:19.914 --> 01:12:23.591
Итак, к основным отличием операционной
аналитики от

01:12:24.276 --> 01:12:26.555
Традиционный можно отнести следующее.

01:12:26.715 --> 01:12:30.593
Первое. Операционная аналитика
автоматизирована.

01:12:33.151 --> 01:12:37.989
То есть операционно-аналитический процесс
выполняется внутри определённых систем в

01:12:38.029 --> 01:12:39.428
автоматическом режиме.

01:12:40.148 --> 01:12:41.827
Операционная аналитика предписывает

01:12:42.581 --> 01:12:43.819
Действия.

01:12:44.059 --> 01:12:50.052
Она не просто рекомендует, какое наилучшее
предложение следует сделать клиенту, когда

01:12:50.372 --> 01:12:56.166
оно вернётся, а действительно предписывает
это сделать, отдав распоряжение

01:12:56.445 --> 01:12:57.524
соответствующим системе.

01:12:57.918 --> 01:13:02.194
Операционная аналитика принимает решения,
затем выполняет действия, которые из них

01:13:02.274 --> 01:13:06.910
вытекают. В то время как традиционной
аналитика анализ производит рекомендации,

01:13:06.910 --> 01:13:09.228
а человек решает: принять их или
отклонить.

01:13:09.547 --> 01:13:12.944
Операционная аналитика осуществляется в
пределах времени принятия решения.

01:13:12.984 --> 01:13:15.981
То есть во многих случаях оно
соответствует реальному времени, в

01:13:16.021 --> 01:13:18.938
некоторых случаях аналитика применяется к
входящему потоку.

01:13:19.586 --> 01:13:21.426
А не к хранилищу данных.

01:13:24.025 --> 01:13:28.384
Операционная аналитика не может позволить
себе ждать до следующего сеанса пакетной

01:13:28.464 --> 01:13:32.823
обработки. Она должна осуществляться
немедленно, чтобы принять решение

01:13:33.023 --> 01:13:35.183
использовать его, исполнить его.

01:13:35.765 --> 01:13:39.691
Чтобы организация смогла применять
операционную аналитику, нужно иметь

01:13:39.771 --> 01:13:43.937
прочные аналитические основы, научиться
успешно применять традиционную аналитику

01:13:44.017 --> 01:13:45.299
на основе пакетной обработки.

01:13:45.339 --> 01:13:47.862
Без этого операционная аналитика останется

01:13:48.915 --> 01:13:53.436
недостижимой мечтой. Итак, операционная
аналитика — это интегрированные в

01:13:53.436 --> 01:13:58.197
автоматические процессы принятия решений,
описывающие и реализующие действия в

01:13:58.237 --> 01:14:00.158
пределах времени принятия решения.

01:14:00.638 --> 01:14:04.479
Как только операционно-аналитический
процесс получает одобрение и запускается,

01:14:04.559 --> 01:14:04.999
он начинает

01:14:05.887 --> 01:14:08.325
Автоматически принимать многочисленные
решения.

01:14:08.405 --> 01:14:11.722
Но в любом случае центральная роль
остаётся за человеком.

01:14:13.441 --> 01:14:17.518
Кто-то должен разрабатывать, выстраивать,
конфигурировать и контролировать

01:14:17.718 --> 01:14:19.277
операционно-аналитические процессы.

01:14:20.916 --> 01:14:23.718
Компьютеры сами по себе не могут принимать
решения.

01:14:23.798 --> 01:14:27.840
Операционная аналитика представляет собой
новую степень эволюции аналитических

01:14:27.960 --> 01:14:34.283
технологий. Аналитика 3.0 способна
считывать информацию, соответственно, и

01:14:34.404 --> 01:14:38.686
реагировать на события, которые влияют на
пользователя: машины и девайсы в режиме

01:14:38.806 --> 01:14:41.848
реального времени. Преимущество аналитики
3.0 заключается в том, что

01:14:42.921 --> 01:14:47.279
Есть возможность синтезировать и
соотносить друг с другом разрозненные

01:14:47.359 --> 01:14:51.558
источники информации, чтобы принимать
автоматические решения на основе

01:14:51.638 --> 01:14:54.597
полученных данных. Сочетание
искусственного интеллекта с аналитикой

01:14:55.157 --> 01:14:57.236
открывает вообще безграничные возможности.

01:14:57.596 --> 01:15:01.834
Из всего вышесказанного следует, что
анализ данных проводится в компаниях

01:15:02.585 --> 01:15:04.144
...и до появления больших данных.

01:15:04.224 --> 01:15:10.262
Однако именно он, то есть именно они,
подтолкнули дальнейшее развитие

01:15:10.662 --> 01:15:12.221
инструментария-аналитики.

01:15:12.541 --> 01:15:15.700
Так, ну а несколько слов, собственно,
инструментарий для аналитики больших

01:15:15.780 --> 01:15:18.019
данных. Прежде всего, эволюционный сОД.

01:15:18.831 --> 01:15:22.389
Хотя бизнес-аналитика и большие данные
имеют одинаковую цель, то есть поиск

01:15:22.628 --> 01:15:24.667
ответов на вопросы, они отличаются друг от
друга.

01:15:24.707 --> 01:15:28.345
А именно: технология Big Danth
предназначена для обработки сразу всего

01:15:28.424 --> 01:15:33.181
массива разных типов данных по сравнению с
инструментальными бизнес-аналитикой, что

01:15:33.381 --> 01:15:36.419
даёт возможность фокусироваться не только
на структурированных данных.

01:15:37.737 --> 01:15:40.295
Получаемых в реальном времени и меняющихся
сведений.

01:15:40.415 --> 01:15:44.133
Что означает глубокое исследование и
интерактивность.

01:15:44.253 --> 01:15:48.570
В некоторых случаях результаты формируются
быстрее, чем загружаются веб-страница.

01:15:48.850 --> 01:15:53.567
Тем самым скорость обработки больших
данных позволяет сделать анализ

01:15:53.687 --> 01:15:54.486
предсказуемым.

01:15:56.456 --> 01:15:59.177
...способом давать бизнесу рекомендации на
будущее.

01:15:59.257 --> 01:16:04.540
Неструктурированные данных в их исходном
виде, то есть алгоритмы и способы

01:16:04.980 --> 01:16:07.862
использования которых находится в процессе
становления.

01:16:08.782 --> 01:16:12.944
Второй момент: подход к работе с большими
данными отличается от подхода к проведению

01:16:13.064 --> 01:16:13.865
бизнес-анализа...

01:16:14.805 --> 01:16:19.450
В отличие от простого сложивания известных
нам значений в традиционной аналитике при

01:16:19.570 --> 01:16:23.333
работе с большими данными, результат
получается в процессе их очистки путём

01:16:23.454 --> 01:16:25.055
последовательного моделирования.

01:16:25.455 --> 01:16:30.900
Сначала выдвигается гипотеза, строится
статистическая или визуальная, или

01:16:31.101 --> 01:16:33.303
семантическая модель, на её основе поверх

01:16:34.498 --> 01:16:39.460
Проверяется вероятность выдвинутой
гипотезы, затем выдвигаются следующие.

01:16:39.781 --> 01:16:44.142
Этот процесс требует от исследователя либо
интерпретации визуальных значений, или

01:16:44.422 --> 01:16:48.744
составления интерактивных запросов на
основе заданий либо разработки адаптивных

01:16:48.784 --> 01:16:50.505
алгоритмов машинного обучения.

01:16:54.535 --> 01:16:58.974
Всё это соответствует большим перспективам
технологии свидетельствует о больших

01:16:59.054 --> 01:17:02.573
перспективах технологии Big данных, в
отличие от дационного анализа.

01:17:03.013 --> 01:17:05.612
Для анализа данных используются разные
инструменты.

01:17:05.692 --> 01:17:09.851
То есть одним из самых известных
инструментов является ХИДУП, то есть

01:17:09.931 --> 01:17:13.250
программное обеспечение, позволяющее
обрабатывать большие объёмы данных

01:17:13.490 --> 01:17:14.929
различных типов и структур.

01:17:15.572 --> 01:17:18.969
С его помощью собираемые данные можно
распределить и структурировать,

01:17:19.049 --> 01:17:23.085
настраивать аналитику для построения
моделей и проверки предположения

01:17:23.245 --> 01:17:25.243
использовать машинное обучение.

01:17:26.362 --> 01:17:31.277
Практически все современные средства
HedUP, то есть анализ больших данных

01:17:31.437 --> 01:17:33.515
вообще представляют средства интеграции с
HedUP.

01:17:34.248 --> 01:17:39.249
Их разработчиками выступают как страны,
так и общеизвестные мировые компании.

01:17:39.690 --> 01:17:45.891
К аналитическим движкам для работы с
большими данными можно отнести ApathUpa,

01:18:07.424 --> 01:18:10.701
на базе языка R для метастатистики.

01:18:12.036 --> 01:18:17.714
Аналитика больших данных развивалась
постепенно по мере развития двух уровней

01:18:17.794 --> 01:18:21.234
модели обработки. Первый уровень
представляет собой традиционную аналитику

01:18:21.314 --> 01:18:25.712
Big Data, когда большие массивы данных
подвергаются анализу не в режиме реального

01:18:25.792 --> 01:18:29.231
времени. Второй уровень обеспечивает
возможность анализа относительно больших

01:18:29.271 --> 01:18:30.911
объёмов данных в реальном времени.

01:18:31.544 --> 01:18:35.107
В основном за счёт технологии аналитики и
памяти, то есть инмемери.

01:18:35.307 --> 01:18:38.911
Аналитика памяти предполагает наличие
поддерживающих технологий, чтобы

01:18:39.071 --> 01:18:44.837
обеспечить достаточный объём памяти для
размещения деятельно-масштабных наборов

01:18:44.957 --> 01:18:47.360
данных, действительно масштабных наборов
данных.

01:18:47.693 --> 01:18:54.257
Для эффективного перемещения данных между
большими объектами, хранилищами и

01:18:54.297 --> 01:19:00.421
системами, ведущими анализ памяти, важную
роль в этом играют решения с открытым.

01:19:00.982 --> 01:19:03.623
В наиболее популярном в мировом
IT-сегменте

01:19:04.872 --> 01:19:09.592
Продуктами для решения проблем BIDA
считаются аналитические платформы SQL и

01:19:09.712 --> 01:19:14.552
NMAMR. Изначально основным способом работы
с базами данных, соответственно,

01:19:14.632 --> 01:19:20.192
SQLBA, язык структурированных запросов,
появившихся в 1974 году.

01:19:21.016 --> 01:19:27.051
Авторынных, применяемые для создания
модификации и управления данными базы

01:19:27.211 --> 01:19:32.167
данных. Он позволил выполнить следующие
операции: создание в базы данных новой

01:19:32.287 --> 01:19:35.884
таблицы, добавление в таблицу новых
записей, изменение записи, удаление

01:19:36.123 --> 01:19:39.840
записей, выборку записи из одной или
нескольких таблиц в соответствии с данным

01:19:39.920 --> 01:19:40.280
условием.

01:19:40.984 --> 01:19:47.346
Измерение, изменение структур таблиц Так,
ну подробно об

01:19:48.946 --> 01:19:50.346
нас говорить не будем.

01:19:51.267 --> 01:19:55.027
Значит, ссылки спринтер, что такое?

01:19:55.067 --> 01:19:56.828
Почему у них дешевле хранить дата?

01:19:58.321 --> 01:19:59.601
Революция Vegat.

01:19:59.681 --> 01:20:02.200
Как извлечь необходимую информацию из
больших данных

01:20:06.839 --> 01:20:08.199
на этом лекцию заканчиваю.

01:20:08.279 --> 01:20:09.119
Спасибо за внимание.