сначала в плане было заложен интерфейс, только компания datastax когда решил выпустить IDE под названием Datastax DevCenter, было принято решения ждать и применять его.
Если сейчас поставили задачи для решения таких проблем, я бы проектировал его по другому.
>>> По производительности — на скромном кластере в 20 нод агрегация не 300 миллионов, а 300 миллиардов записей лога делается за <30 минут
проблема было еще с Cassandra и Pig (data flow). У cassandra еще не было готово выборки данных через where clause. Pig в любой обработки подтянул все данные (хоть это млрд)и после этого pig начал фильтрации обработки.
если это начале 2011 года, да было организационная проблема.
>>> Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним.
по моему эту жалобу относится к CryptoPro а не к СМЭВ
Служба эксплуатации тогда еще не было готов пользоваться CQL запросами чтобы вытащить данные из Cassandra таблицы, поэтому часто для оперативной работы спрашивали «пришлите трейс запроса/ответа»
>>> Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных
Речь идет о Cassandra Replication
вот вам 2 пример
create keyspace p00skimKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 0 and strategy_options:p00skimDC = 1;
— create keyspace p00smev_archKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 1 and strategy_options:p00skimDC = 0;
на первом примере данные не когда не будет реплицироваться в дата центре p00smevDC, а на втором примере нет. Есть хорошая документация в cassandra planet www.datastax.com/dev/blog/multi-datacenter-replication (раздел Geographical Location Scenario)
>>> Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
причем тут это не очень понял ))
Да рост был линейный, за 3 млрд строк надо было бы еще hadoop data node добавлять. Да мы провели агрегацию в одном месте (федеральном цоде). Данные были не транзакционные и агрегировал суточные данные
Договор NDA с заказчикам не позволяет все детализировать, я все таки попробую отвечать на ваше все вопросы:
>>> Во-первых, зачем для сервиса накопления и анализа логов Cassandra? Почему нельзя было взять тот же Flume и спокойно грузить данные в HDFS, а там их с тем же успехом обрабатывать в MR?
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). Если через flume тогда необходимо было хранить все эти данные в Oracle ExaData, серверные диски было довольно дорогие, нам еще бы нужно было вычислить промижуточные данные во время свой канал связи между ЦОД.
>>> Картинки исходной и целевой архитектуры не имеют общих компонент, сложно понять куда именно (и как) вы подключили Cassandra
Cassandra установлись в каждом регионе, стратегия NetworkTopologyStrategy, репликация между дата центрами.
>>> 300млн записей за 100 минут — какого рода обработка проводится? Мой ноутбук может спокойно распарсить 300млн строк лога за 7-8 минут на одном ядре. Обработка очень сложная с подтягиванием данных из внешних систем?
в основном группировка данных, большее 9 groupBy а также во время reduce в обновили данных в Cassandra таблицу
>>> Показатели производительности без указания характеристик кластера смотрятся немного странно
Cassandra сервер: 4 CPU, 8 Gb Ram, virtual machine
Hadoop data node: 6 cpu, 16 Gb RAM, virtual machine
>>> На графиках не подписаны оси и что где меряется непонятно
оси X — время в минутах
оси Y — количества строк в таблице
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). А также масштабируемость системы было критично.
>>> По производительности — на скромном кластере в 20 нод агрегация не 300 миллионов, а 300 миллиардов записей лога делается за <30 минут
проблема было еще с Cassandra и Pig (data flow). У cassandra еще не было готово выборки данных через where clause. Pig в любой обработки подтянул все данные (хоть это млрд)и после этого pig начал фильтрации обработки.
>>> Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним.
по моему эту жалобу относится к CryptoPro а не к СМЭВ
Речь идет о Cassandra Replication
вот вам 2 пример
create keyspace p00skimKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 0 and strategy_options:p00skimDC = 1;
— create keyspace p00smev_archKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 1 and strategy_options:p00skimDC = 0;
на первом примере данные не когда не будет реплицироваться в дата центре p00smevDC, а на втором примере нет. Есть хорошая документация в cassandra planet www.datastax.com/dev/blog/multi-datacenter-replication (раздел Geographical Location Scenario)
>>> Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
причем тут это не очень понял ))
>>> Во-первых, зачем для сервиса накопления и анализа логов Cassandra? Почему нельзя было взять тот же Flume и спокойно грузить данные в HDFS, а там их с тем же успехом обрабатывать в MR?
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). Если через flume тогда необходимо было хранить все эти данные в Oracle ExaData, серверные диски было довольно дорогие, нам еще бы нужно было вычислить промижуточные данные во время свой канал связи между ЦОД.
>>> Картинки исходной и целевой архитектуры не имеют общих компонент, сложно понять куда именно (и как) вы подключили Cassandra
Cassandra установлись в каждом регионе, стратегия NetworkTopologyStrategy, репликация между дата центрами.
>>> 300млн записей за 100 минут — какого рода обработка проводится? Мой ноутбук может спокойно распарсить 300млн строк лога за 7-8 минут на одном ядре. Обработка очень сложная с подтягиванием данных из внешних систем?
в основном группировка данных, большее 9 groupBy а также во время reduce в обновили данных в Cassandra таблицу
>>> Показатели производительности без указания характеристик кластера смотрятся немного странно
Cassandra сервер: 4 CPU, 8 Gb Ram, virtual machine
Hadoop data node: 6 cpu, 16 Gb RAM, virtual machine
>>> На графиках не подписаны оси и что где меряется непонятно
оси X — время в минутах
оси Y — количества строк в таблице