Сохранение данных в режиме реального времени через Cygnus в космос является медленным и ненадежным

Question

Версия Cygnus - 0.8.2, и я использую публичный экземпляр Cosmos из нашего экземпляра FI-Ware в FI-Ware Lab.

У меня есть 8 сенсорных устройств, которые загружают обновления для IDAS. Некоторые обновления происходят раз в секунду, некоторые раз в 5 секунд, в среднем около 8,35 обновлений в секунду. Я создал подписки на Orion (версия 0.22) для отправки уведомлений ONCHANGE на Cygnus.

Cygnus настроен на сохранение данных в Cosmos, Mongo и MySQL. Я использовал стандартную конфигурацию: 1 источник (http-источник), 3 канала (hdfs-канал, mysql-канал, монго-канал) и 3 приемника (hdfs-приемник, mysql-приемник, монго-приемник).

MySQL-приемник и приемник-монго сохраняют данные практически в реальном времени. Тем не менее, hdfs-приемник действительно медленный, всего около 1,65 событий в секунду. Поскольку http-источник получает около 8,35 событий в секунду, hdfs-канал скоро заполнится, и вы получите предупреждение в файл журнала.

time=2015-07-30T13:39:02.168CEST | lvl=WARN | trans=1438256043-345-0000002417 | function=doPost | comp=Cygnus | msg=org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet[203] : Error appending event to channel. Channel might be full. Consider increasing the channel capacity or make sure the sinks perform faster.
org.apache.flume.ChannelException: Unable to put batch on required channel: org.apache.flume.channel.MemoryChannel{name: hdfs-channel}
        at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:200)
        at org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet.doPost(HTTPSource.java:201)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.Server.handle(Server.java:326)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
        at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: org.apache.flume.ChannelException: Space for commit to queue couldn't be acquired Sinks are likely not keeping up with sources, or the buffer size is too tight
        at org.apache.flume.channel.MemoryChannel$MemoryTransaction.doCommit(MemoryChannel.java:128)
        at org.apache.flume.channel.BasicTransactionSemantics.commit(BasicTransactionSemantics.java:151)
        at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:192)
        ... 16 more

Побочным эффектом является то, что если http-источник не может внедрить уведомление в hdfs-канал, он также не вводит его в mysql-канал и mongo-канал, и это уведомление полностью теряется. Это не сохранилось нигде.

Вы можете частично обойти эту проблему, запустив 3 отдельных Cygnuses (один для Cosmos, один для MySQL и один для MongoDB) с другим портом http-source, другим портом интерфейса управления и добавлением подписок для каждого Cygnus. Сохранение MySQL и MongoDB не зависит от переполнения hdfs-канала, но сохранение Cosmos все еще имеет проблему. Добавление большего количества hdfs-приемников может сработать с нашими 8 сенсорными устройствами, но если вы добавите больше сенсорных устройств или они отправят больше обновлений, вы просто откладываете проблему.

Эти 2 вопроса немного не связаны, но я все равно спрашиваю...

Вопрос 1: Действительно ли дело в том, что сохранение в Космосе происходит так медленно?

Я знаю, что многое происходит за кулисами по сравнению с сохранением в локальных базах данных, и что мы используем публичный экземпляр Cosmos, который ограничен в ресурсах, но все же. Это даже предназначено для использования таким образом с данными в реальном времени (наш тест 8 сенсорных устройств даже довольно скромный)? Конечно, можно создать приемник, который помещает данные в файл, а затем выполняет простую загрузку файла в Космос, но это немного сложнее. Я думаю, что нет такой доступной файловой раковины?

Вопрос 2: Действительно ли это так, что если уведомление не может быть введено в hdfs-канал (я полагаю, какой-либо канал), оно также не добавляется в другие каналы и полностью удаляется?

Answer 1

Дизайн всех приемников очень похож, но между приемниками HDFS и приемниками MySQL/MongoDB есть некоторые различия:

• Конечная точка HDFS (сервер HttpFS, работающий на cosmos.lab.fiware.org:14000) является общей для многих пользователей FIWARE. Тем не менее, я предполагаю, что ваши MySQL и MongoDB развертывания были частными и поэтому использовались только вами.
• Приемник HDFS основан на WebHDFS, REST API, тогда как приемники MySQL и MongoDB основаны на "двоичных протоколах" (соответственно используются драйверы JDBC и Mongo). В Github существует старая проблема, связанная с переходом на "двоичную" реализацию приемника.

Сказав это, и пытаясь решить проблему с текущей реализацией, вот мои рекомендации:

• Попробуйте изменить уровень вложения в ERROR; регистрация трассировок потребляет много ресурсов.
• Попробуйте отправить "партии" уведомлений Cygnus (уведомление Orion может содержать несколько элементов контекста); каждая партия сохраняется как отдельное событие Flume в канале.
• Как вы уже поняли, попробуйте настроить более одного приемника HDFS, это объясняется здесь (чтение полной версии документа также является хорошей идеей).

Тем не менее, если узкое место на конечной точке HDFS, я считаю, что это ничего не исправит.

О Cygnus не помещает событие в другие каналы не HDFS, если оно не может быть сохранено в канале HDFS, я посмотрю на это. Cygnus полагается на Apache Flume, а функция доставки событий находится в ядре Flume, поэтому, похоже, это ошибка / проблема в Flume.