Документ обсуждает использование Apache Cassandra и Apache Spark для быстрой аналитики данных в реальном времени, особенно в контексте проектов, таких как портирование мобильных номеров. Он описывает архитектуру систем, задачи и бизнес-процессы, а также технологии, позволяющие эффективно обрабатывать большие объемы данных. Основное внимание уделяется преимуществам решения Cassandra по сравнению с Hadoop, включая масштабируемость и производительность.

1. Fast In-memory Analytics Over
Cassandra Data
Shamim Ahmed
3rd Moscow Cassandra Meetup

2. 2
Agenda
Fast in memory analytics over Cassandra Data ЧАСТЬ 1
 Наша цель использования Cassandra.
 Какие проблемы мы решаем.
 Причина применения In Memory data processing
 Наша Cassandra/Spark архитектура.

3. 3
AT Consulting
О нас ЧАСТЬ 1
Предоставляем консалтинговые услуги, разработка ПО для
отраслей телекоммуникации, финансов, энергетики и
здравоохранения.
В данный момент более 11-и проектов используют NoSQL для
решения разных типов задач.

4. Краткий обзор проекта MNP (Mobile Number Portability)
4
ЧАСТЬ 1
ЦЕЛИ ПРОЕКТА
◼ Обеспечить исполнение законодательства по MNP к 01.12.2013
ЗАДАЧИ ПРОЕКТА
◼ Реализовать бизнес-процессы переноса (портации) номеров
ГЕОГРАФИЧЕСКИЕ РАМКИ ПРОЕКТА
◼ Сеть Оператора связи в РФ
◼ Офисы обслуживания абонентов в РФ

5. Бизнес-процессы переноса телефонного номера
5
ЧАСТЬ 1
Портация в сеть оператора связи (PortIn)
Клиент
приходит в
офис
обслуживания
Оператор
инициирует
процесс
переноса
Система через
ЦБДПН
запрашивает
систему-
донора
Система
вызывает
различные ИС
оператора для
активации
абонента
Портация из сети оператора связи (PortOut)
Клиент
приходит в
офис другого
оператора
связи
Их система
через ЦБДПН
запрашивает
возможность
переноса
Система
проверяет
баланс и
ARPU
абонента
Оператор
подтверждает
перенос
абонента

6. 6
Подсистема протоколирования ЧАСТЬ 1

7. 7
Контекст протоколирования ЧАСТЬ 1
Любые действия бизнес процесса
Отклоненные заявления от ЦБДПН
 Зависшие заявления
Прерывание работы систем ЦБДПН и других систем
Действия пользователя в портале

8. Причина использования Cassandra
8
Автоматическая репликация данных по дата центру.
Out of Box Sharding.
Линейное масштабирование кластера.
Отсутствие единой точки отказа кластера.
Big table дата модель.
Высоко производительная атомарная запись данных.
Open source.
Commodity hardware, достаточно private cloud инфраструктура.
ЧАСТЬ 2

9. 9
Объемы протоколирования ЧАСТЬ 1
Нагрузка
Протоколирование 70-100 записей для 1
заявления с 1 номером
Общий размер записей для 1 заявления  60 КБ
До 40000 заявлений в сутки
200ГБ
в сутки
Количество записей для обработки
Протоколирование 70-100 записей для 1
заявления с 1 номером
До 40000 заявлений в сутки
 ~3 номера в каждом заявлении
12000
000 в
сутки

10. Архитектура подсистемы протоколирования (2013)
10
ЧАСТЬ 2
OLAPOLTP
HIVE PIG
Движок БП
Асинхронный запись
REST
Load Balancer
Cassandra 1.2.*
Hadoop 1.2.*Сервис
протоколироания
Сервис
протоколироания
Поиск и Анализ
данных
(Ad Hoc query)
Экспорт данные в
JSON

11. 11
Производительность ЧАСТЬ 2

12. Почему новая модель программирования?
12
ЧАСТЬ 1
MapReduce значительно упростил обработки больших объемов данных, но как только
он стал популярным, пользователей хотели больше :
– Более сложные, multi-stage
приложения(например,
iterative graph algorithms and machine learning)
– Более интерактивный ad-hoc запросов
multi-stage и интерактивные приложения требуют быстрого обмена данных между
параллельными задачами.

13. Обмен данных в Hadoop Map Reduce
13
ЧАСТЬ 2
Итерация
1
Итерация
2 . . .
Input
HDFS/Cassandra
read
HDFS
write
HDFS
read
HDFS
write
Input
Запрос 1
Запрос 2
Запрос 3
result 1
result 2
result 3
. . .
HDFS/Cassandra
read
Медленно из-за репликации, сериализаций данных,
временных файлов и Disk IO

14. Вычислительная модель Spark
14
ЧАСТЬ 2
Ключевые идеи: RDDS (resilient distributed datasets)
– Распределенные коллекции объектов, которые могут
кэшироваться в памяти между узлами кластера.
– Автоматическое восстановление DataSets при сбоях.
– Написано на языке программирования Scala с
поддержкой JAVA и Python API

15. Обмен данных в SPARK
15
ЧАСТЬ 2
В 10-100 раз быстрее
Итерация
1
Итерация
2 . . .
Распределенная
память
Input
Запрос 1
Запрос 2
Запрос 3
. . .
Input

16. Вычислительный кластер Spark
16
ЧАСТЬ 2
Spark кластер можно запустить:
– Standalone (параллельно с Hadoop)
– Yarn (Hadoop 2)
– Mesos (Cluster Management)
– Amazon EC2

17. Программный интерфейс
17
ЧАСТЬ 2
– JAVA, Python, Scala
– Shark (Hive on Spark)
– Calliope

18. Spark Stack
18
ЧАСТЬ 2
Apache Spark
Spark
Straming
Shark
(SQL)
Mlib
(Machine
learning)
GraphX
Amazon
EC2
Standalone
Yarn
(Hadoop 2)
Mesos

19. 19
MNP архитектура ЧАСТЬ 2
OLAPOLTP
Shark
Движок БП
Асинхронный запись
REST
Load Balancer
Cassandra 2.0.4
Hadoop 1.2.*Сервис
протоколироания
Сервис
протоколироания
Поиск и Анализ
данных
(Ad Hoc query)
Экспорт данные в
JSON

20. 20
NoSQL стек ЧАСТЬ 2
Apache Cassandra 2.0.4
Spark 0.9.0-incubating-bin-hadoop1
Hive-0.11.0-bin-shark
ApacheHadoopHDFS
1.2.7
Shark 0.9.0
Cash (Hive Cassandra handler)

21. 21
Установка Spark кластера ЧАСТЬ 2
 Build Spark и Shark из исходного кода (необходимо Scala)
 Установка и запуск Spark cluster
 Установка Hive
 Копировать библиотеки Cash в $HIVE/lib
 Установка и запуска Shark

22. 23
Пример ЧАСТЬ 2
shark> CREATE EXTERNAL TABLE mnp.audit(processId int, pname string, pcategory string, penddate date, pinstance
string, pevent string)
STORED BY 'org.apache.hadoop.hive.cassandra.cql.CqlStorageHandler'
WITH SERDEPROPERTIES ("cql.primarykey" = “processid", "comment"="check", "read_repair_chance" = "0.2",
"dclocal_read_repair_chance" = "0.14", "gc_grace_seconds" = "989898", "bloom_filter_fp_chance" = "0.2",
"compaction" = "{'class' : 'LeveledCompactionStrategy'}", "replicate_on_write" = "false", "caching" = "all");
shark> select count(*) from audit;
185.022: [Full GC 106345K->24340K(1013632K), 0.2817830 secs]
189.722: [Full GC 228461K->30033K(1013632K), 0.3228080 secs]
OK
4870000
Time taken: 37.106 seconds
shark> select pcategory, count(*) from audit group by pcategory;
185.022: [Full GC 106345K->24340K(2013632K), 0.3017930 secs]
189.722: [Full GC 228461K->30033K(1993632K), 0.4558780 secs]
OK
portin 1000300
Portout 2001000
Pgov 1710003
Time taken: 136.199 seconds

23. 24
Пример (Таблица cache) ЧАСТЬ 2
shark> CREATE TABLE mnp.audit_cache TBLPROPERTIES ("shark.cache" = "true") AS SELECT * FROM mnp.audit;
shark> select pcategory, count(*) from audit-cache group by pcategory_cache;
135.022: [Full GC 106345K->24340K(2013632K), 0.2118930 secs]
129.722: [Full GC 228461K->30033K(1993632K), 0.3368880 secs]
OK
portin 1000300
Portout 2001000
Pgov 1710003
Time taken: 46.019 seconds

24. 25
Производительность ЧАСТЬ 2
0
100
200
300
400
500
600
1 2 3 4
Performance Benchmark (11000000
records)
Hadoop Spark Spark cache

25. 26
Reference
Hadoop Spark Summit presentation
http://tuplejump.github.io/calliope/
http://brianoneill.blogspot.ru/2014/03/shark-on-cassandra-w-cash-
interrogating.html
Amplab (spak & shark)
http://frommyworkshop.blogspot.ru

26. 27
Обратная связь
bsha@at-consulting.ru
Blog: http://frommyworkshop.blogspot.ru
WE ARE HIRING

27. 28
Вопросы