Современные подходы к управлению данными

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Rocket clouds
Современные подходы к управлению данными создатель Mind Map: Современные подходы к управлению данными

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 операция над всеми элементами списка одновременно