1. Ограничения реляционных БД
1.1. нет гибкости
1.2. запросы
1.3. масштабирование
2. Проблема совместной обработки данных
2.1. Shahred - everithing
2.1.1. DSM
2.1.2. SMP
2.2. Shared - nothing
2.2.1. map reduce
2.2.2. mpp
3. Big Data
3.1. 7V
3.1.1. Технические аспекты
3.1.1.1. Volume
3.1.1.1.1. Объем данных невозможно обработать средствами реляционных моделей
3.1.1.2. Variety
3.1.1.2.1. Разнообразие данных не позволяет создать нормальную структуру данных
3.1.1.3. Velocity
3.1.1.3.1. Скорость обработки данных не достаточна для классических средств
3.1.1.4. Veracity
3.1.1.4.1. Чистота данных не позволяет воспользоваться нормальными средствами
3.1.2. Бизнес аспекты
3.1.2.1. Vision
3.1.2.1.1. Необходимо рассматривать различные аспекты одной сущности
3.1.2.2. Value
3.1.2.2.1. Польза использования именно подобного подхода
3.1.2.3. Visualization
3.1.2.3.1. Визуализация данных с помощью дополнительных средств
3.1.3. Причины использования непосредственно Big Data решений
4. Интеграция данных
4.1. Способы интеграции данных
4.1.1. Общая база данных
4.1.1.1. Набор приложений обращаются к одной и той же базе данных
4.1.1.2. Недостатки
4.1.1.2.1. Происходят конфликты
4.1.1.2.2. Невозможно расширять
4.1.1.3. Достоинства
4.1.1.3.1. Дешево
4.1.1.3.2. Легко добавить новое приложение
4.1.2. File transfer
4.1.2.1. Система, при которой приложения работают в различных базах, но синхронизируются отдельным модулем
4.1.2.2. Полуручной способ обработки с использованием тригеров
4.1.3. RPC
4.1.3.1. Асинхронный варианты реализации
4.1.3.1.1. Pull
4.1.3.1.2. Push
4.1.4. Messaging
4.1.4.1. Topic
4.1.4.2. Queue
4.1.4.3. Иерархия вариантов
4.1.4.3.1. MQ
4.1.4.3.2. Message branch
4.1.4.3.3. Message bus
4.1.4.4. Способ обмена данных между системами через шину данных с помощью сообщений
4.1.4.4.1. Сообщение может содержать весь набор данных
4.1.4.4.2. Сообщение может содержать минимум информации, по которой обработчик позволит найти данные для скачивания
5. Продукты
5.1. Kafka
5.1.1. Способы настройки достоверности информации на распределенном источнике
5.1.1.1. Exactly once
5.1.1.2. At least once
5.1.1.3. At most once
5.2. Nginx
5.3. F5
5.4. Denodo
5.4.1. Визуализатор данных
5.5. Spanner
5.5.1. New SQL база данных от Google
6. Классификация данных
6.1. типы обработки
6.2. хранения
6.2.1. формат данных
6.2.1.1. структурированные
6.2.1.2. неструктурированные
6.2.1.3. полуструктурированные
6.2.1.4. методанные
6.2.1.4.1. данные о данных
6.2.2. частота поступления
6.2.2.1. по запросу
6.2.2.2. поток
6.2.2.3. real timr
6.2.2.4. time series
6.2.2.4.1. tsdb
6.2.3. категория
6.2.3.1. транзакционные
6.2.3.2. историчные
6.2.3.3. мастер
6.2.3.3.1. MDM
6.2.3.4. reference
6.2.3.4.1. справочники
6.2.4. источники данных
6.2.4.1. machine generated
6.2.4.2. human generated
7. Event analytics (stream processing)
7.1. Непрерывный поток событий (кортежей данных)
7.2. Подходы построения
7.2.1. Micro batch
7.2.1.1. Накапливается некий объем очереди, который обрабатывается разово
7.2.2. True steaming
7.2.2.1. Вся поступающая информация обрабатываются сразу
7.3. Типы систем
7.3.1. Event source processing
7.3.1.1. Основное применение в мониторинге систем
7.3.2. Complex event processing
7.3.2.1. Основное применение в составлении аналитики
8. use cases
8.1. financial
8.1.1. conplince
8.1.2. risk
8.1.3. fraud
8.1.4. loyalty
8.1.5. credit risk
8.1.6. high speed trading
8.1.7. abnormal trading pattern
8.2. fraud detection
8.3. web
8.3.1. click stream
8.3.2. social graph
8.3.3. profile segmentation
8.3.4. campaign management
8.4. telecomunication
8.5. health ....
9. На изучение
9.1. Теорема SCV
9.2. CLOB
10. масштабирование
10.1. rack
10.1.1. сеть нод подключенных к одному switch
10.1.2. соедениняются магистральными switch
10.1.2.1. firewall
10.1.2.2. router
10.2. построение нод
10.2.1. могут быть древовидны
10.2.2. spine fabric
10.2.2.1. ноды подсключаются к нескольким разным свичам
10.3. фактор репликации
10.3.1. обычно нечетное число
10.3.2. файл дублируется и хранится на разных нодах
10.3.2.1. обновление файла
11. Теорема CAP
11.1. Расшифровка
11.1.1. С - консистентность
11.1.1.1. Один и тот же запрос к разным нодам в одно и тоже время возращает одно и то же значение
11.1.2. A - доступность
11.1.2.1. Когда бы к системе не обратились она вернет результат
11.1.2.2. Типы
11.1.2.2.1. Строгая
11.1.2.2.2. Слабая
11.1.3. P - partition tolerance
11.1.3.1. Устойчивость к возникновению партиций (возникли сетевые разрывы)
11.2. В любой системе можно реализовать только 2 из 3 факторов
11.2.1. В современном мире обработка партиций требуется всегда
11.2.1.1. CP
11.2.1.1.1. Примеры
11.2.1.2. AP
11.2.1.2.1. Примеры
11.2.2. CA
11.2.2.1. H-Base
11.3. Консистентная модель Base
11.3.1. Всегда доступна
11.3.2. Может возращать разные результаты без проведения новых транзакций
11.3.3. Eventual consistent
11.3.4. Примеры
11.3.4.1. H-Base
11.3.4.2. Apache Cassandra
11.3.4.3. Mongo DB
12. модель ACID
12.1. атомарность
12.2. консистентность
12.3. изолированость
12.4. постоянность транзакции
13. consistency/performance tradeoff tuning
13.1. N - фактор репликации
13.2. W - кворум на запись
13.2.1. количество нод подтверждающих запись
13.2.1.1. блокирующая операция
13.2.1.2. ем больше тем дольше происходит запись
13.3. К - кворум на чтение
13.3.1. количество нод которые должны отдавать одно значени
13.4. W<N
13.4.1. high write availability
13.5. R<N
13.5.1. high read availability
13.6. W+R>N
13.6.1. strong consistency
13.7. W+R<=N
13.7.1. eventual consistency
14. Highload architecture patterns
14.1. Возможные варианты реализации
14.1.1. Master-Slave database replication model
14.1.1.1. Master служит для записи. Мастер конфигураций обычно 1 для учеличения скорости
14.1.1.2. Slave служит для чтения информации
14.1.1.2.1. Slave конфигураций может быть несколько
14.1.1.2.2. Чем больше таких конфигураций, тем медленее будет происходить чтение
14.1.1.3. + -
14.1.1.3.1. Подходит больше для read-heavy систем
14.1.1.3.2. Чем больше конфигураций slave, тем дольше репликация
14.1.1.3.3. Способна обрабатывать не особо много данных
14.1.1.3.4. Не очень консистентные данные
14.1.2. Сashe
14.1.2.1. Read-through
14.1.2.1.1. Режим на чтение
14.1.2.2. Write-trough
14.1.2.2.1. Синхронизирует запись
14.1.2.3. Write-ahead
14.1.3. Index
14.1.4. Масштабирование
14.1.5. Lazy processing
14.1.6. Sharding
15. модели данных
15.1. части
15.1.1. integrity part
15.1.2. структурная часть
15.1.3. manipulation part
15.2. типы
15.2.1. relation
15.2.2. key-value
15.2.2.1. поддерживает операторы
15.2.2.1.1. put
15.2.2.1.2. get
15.2.2.1.3. delete
15.2.2.2. необходимость
15.2.2.2.1. cashe
15.2.2.2.2. хранение бинарных объектов структуру которых не читаю\т
15.2.3. document-oriented
15.2.3.1. mongo
15.2.3.2. postgress после 10 версии
15.2.4. graph
15.2.5. wide column
16. современная архитектура данных
16.1. вернеуровневая архитектура
16.1.1. логический уровень
16.1.1.1. источники
16.1.1.1.1. откуда бизнес берет всю информацию
16.1.1.2. data system
16.1.1.2.1. enterpris OLAp
16.1.1.2.2. big data anysis
16.1.1.2.3. способы связать
16.1.1.3. apps
16.1.1.3.1. enterprise apps
16.1.1.3.2. BI
16.1.1.3.3. Statistical analysis
16.1.1.3.4. Mobile web
16.2. лямбда архитектура
16.2.1. batch слой
16.2.1.1. обработка за большой промежуток времени
16.2.1.2. ограничен объемом оперативной памяти и частотой speed layer
16.2.1.3. может заниматься улучшением качество данных
16.2.2. speed слой
16.2.2.1. обработка за необходимый короткий промежуток времени
16.2.3. srrving layer
16.2.3.1. доставка данных потребителям данных
16.2.3.2. реализация контракта данных
16.2.4. data storege layer
16.2.4.1. максимально масштабируемым
16.2.5. слои суммируется результаты двух слоев
16.2.5.1. после перехода на новый отрезок batch все в speed очищается
16.2.5.2. слои не обязательно занимаются обработкой одинаковой работой
16.2.6. data acquisition layer
16.2.6.1. конвертирует часть данных в сообщения
16.2.6.2. компоненты
16.2.6.2.1. коннекторы
16.2.6.2.2. преобразование данных
16.2.6.2.3. тасформация даных
16.2.6.3. apache sqoop
16.2.6.4. apache flume
16.2.7. messaging layer
16.2.7.1. разделение слоев
16.2.7.2. apache kafka
16.2.7.3. rabbit mq
16.2.8. data ingestion layer
16.2.8.1. разделяет данные на обработку
16.2.8.2. apache flink
16.2.9. ограничения
16.2.9.1. сложная и многослойная
16.2.9.2. трудно поддерживать и мониторить
16.2.9.3. богатая экспертиза
16.2.9.4. большой объем железа и его настройки
16.2.10. драйверы
16.2.10.1. мягкое обновлени
16.2.10.2. что делать если реал тайв выпало
16.2.10.3. как сократить пересчет
16.2.11. больные точки
16.2.11.1. exactly once
16.2.11.2. динамическое масштабирование
16.2.11.3. изменение схемы
17. безоппасность
17.1. perimeter security
17.1.1. apache knox
17.2. authentication
17.2.1. kerberos
17.3. authorisation
17.3.1. apache ranger
17.4. hdfs encryption
17.5. os security
18. cloud computing
18.1. причины принятия решения в стороны cloud
18.1.1. нет четкого понимания стоимости
18.1.2. недостаточно внутренних ресурсов
18.1.3. proof of concept
18.1.4. есть компетентая команда по данным технологиям
18.2. выбирается delivery model
18.2.1. iaas
18.2.1.1. почучаем непосредственноресурсы
18.2.2. Paas
18.2.3. saas
18.3. deployment model
18.3.1. public
18.3.1.1. дешево войти
18.3.1.2. эластичность
18.3.1.3. гибкость
18.3.2. private
18.3.2.1. полезен когда все датасеты внутри компании
18.3.2.2. real-time
18.3.3. hybrid
19. hadoop
19.1. части
19.1.1. core
19.1.2. hdfs
19.1.2.1. файловое хранилище
19.1.2.2. google file system
19.1.3. yarn
19.1.3.1. resource manager
19.1.4. map reduce
19.1.4.1. обработчик данных
19.1.4.2. map - применение операции над каждым элеменом списка
19.1.4.3. reduce операция над всеми элементами списка одновременно