Не секрет, что рынок полон разнообразных фитнес-трекеров в различных форм-факторах. Это и фитнес-браслеты, и умные часы, и нагрудные пульсометры с измерением ЭКГ. Их часто дарят в подарок и, поносив пару месяцев, убедившись, что пресловутые 10 тысяч шагов сидя в офисе не находишь, кладут в ящик письменного стола и забывают навсегда. Между тем эти устройства способны собирать очень значимую информацию о пользователе: большинство трекеров измеряет пульс либо методом плетизмографии, либо через электрическую активность сердца – ЭКГ. Часть устройств оценивает изменение кровяного давления, оксигенацию крови. Проблема в том, что обычный трекер не делает этого систематически, не анализирует данные.
Мы решили: почему бы не написать сервис, который бы помог людям следить за своим здоровьем с помощью носимых гаджетов: отслеживал 24х7 доступные физиологические параметры, строил индивидуальный профиль, следил за отклонением от этого профиля. Более того, нам хотелось, чтобы все это не ограничивалось сугубо нашим пользователем. Нам хотелось, чтобы наши пользователи имели возможность заботиться о своих близких, т.е. онлайн видеть все измерения, производимые гаджетом, который носит давно ушедшая на пенсию и живущая на другом конце страны мама. Мы хотим, чтобы телемедицинская консультация со специалистом проходила не на уровне: “доктор, болит вот тут”, а с объективным измерением.
Что следует из такой постановки задачи? Первое: мы на B2C рынке, т.е. мы не имеем ограничения по числу пользователей – чем больше, тем лучше. Второе: мы хотим стремиться к как можно более полной картине состояния организма, т.е. типов датчиков потенциально может быть много, и мы априори (a priori) не фиксируем их типы. Третье: мы не в состоянии регламентировать потоки данных. Поток данных живет своей жизнью; кто-то из пользователей измеряет только пульс, кто-то измеряет каждые полчаса давление, кого-то волнует его стресс, кто-то делает ЭКГ каждый час. Пользователи находятся в разных часовых поясах: для сервиса нет дня и ночи, нет “закрытия операционного дня”, любое время суток для кого-то – разгар дня, а для кого-то – время подвести итог того, как прошел день. Поскольку наша задача – анализ, мы не можем обрезать этот поток данных на уровне мобильного приложения, мы должны направить все данные на сервер, обеспечив их эффективный прием на сервере, хранение и последующую, а зачастую и параллельную с записью в базу, обработку.
Исходя из всего этого было принято решение использовать технологии Big Data. В качестве дистрибутива был выбран дистрибутив от Cloudera. Общая архитектура решения показана на рис. 1
Рисунок 1. Архитектура решения
Носимое устройство (гаджет) измеряет те или иные физиологические показатели пользователя и по Bluetooth протоколу передает их на смартфон. На смартфоне работает приложение (доступно как на Android, так и на iOS), функционально состоящее из двух частей:
Задача сервиса – поддержание взаимодействия с гаджетом: отслеживание наличия соединения и его восстановление в случае потери, конфигурация гаджета, синхронизация данных, запуск на гаджете команд пользователя, отправка данных на сервер. Сервис работает по расписанию, просыпаясь через заданный пользователем интервал времени – обычно раз в несколько минут – и выполняя запланированный объем задач. В большинстве случаев это запрос на регулярно собираемые данные от гаджета: пульс, сон, физическая активность. Получаемые данные отсылаются по REST протоколу на сервер. Если сеть недоступна или сервер ответил ошибкой, данные сохраняются на смартфоне до тех пор, пока связь не будет восстановлена. Таким образом обеспечивается надежная доставка данных через не слишком надежные и не всюду доступные мобильные сети. Кроме основного расписания пользователь может задать дополнительное расписание для исполнения определенных видов замеров, таких как давление, стресс, ЭКГ, которые не входят в основное расписание и выполняются несколько раз в день. По умолчанию эти замеры планируются на ночное время с тем, чтобы дневная активность пользователя заведомо не искажала замеры. Кроме этого, регулярное измерение показателей в фиксированных условиях – в данном случае во время сна – позволяет следить за динамикой показателей, оценивая их изменение относительно предварительно построенного профиля пользователя. Сам по себе пульс в 150 ударов в минуту не говорит ни о чем. Такой пульс может быть у совершенно здорового человека во время физической нагрузки или сразу после нее, но это же значение во время глубокого покоя, характерного для сна, свидетельствует о проблемах с сердечно-сосудистой системой человека.
Пользователь может установить расписание по своему желанию либо выполнить измерение в ручном режиме.
Основная задача интерфейса пользователя – предоставление пользователю доступа к данным: как собственно к сырым измерениям, так и к аналитике в виде построенных профилей и уведомлений, созданных по результатам анализа данных. На рисунке 2 показаны примеры таких предупреждений.
Рисунок 2. Уведомления
Рисунок 3
Профиль пульса во время сна и выход пульса во время начала сна за типовые значения, что может свидетельствовать о чрезмерной нагрузке в предшествующий день.
Сбор данных на сервере осуществляется через Flume, что позволяет гибко настроить потоки данных по различным каналам, маршрутизируя данные в различные таблицы для хранения либо на экспресс-обработку с помощью Spark Streams. Каналы также позволяют сгладить неравномерность поступающих объемов данных, буферизуя поступающие данные. Кроме того, при росте числа пользователей мы просто увеличиваем число агентов Flume, распределяя данные по агентам с помощью балансировщика – в нашем случае haproxy.
Для хранения данных нами используется HBase. Выбор в пользу HBase определяется не только фактом большого объема данных, но и шаблоном использования:
Собственно, мы имеем дело ровно с тем шаблоном работы с данными, под который проектировался HBase: максимально быстро записать данные и массово их обработать. На скорость записи положительно влияет и такая особенность HBase, что update записи реализован физически как создание новой версии записи, а не поиск и перезапись существующей, что облегчает нам работу с “дублями”. Для дополнительной гарантии от потерь данных мы отчасти дублируем обмен данными между гаджетом и сервером, а данная особенность HBase позволяет нам не терять производительности записи в случае дублей. Безусловно, часть хранимых данных может меняться, например, аналитические показатели – они регулярно пересчитываются на протяжении текущего дня, но их объем несоизмеримо мал по сравнению с сырыми данными, а требуемый отклик на доступ к ним определяется GUI и не является серьезным ограничением.
Часть данных, носящий характер метаданных, а также персональные данные пользователей хранятся в отдельной базе данных Postgres.
В системе реализовано три контура обработки данных в зависимости от срочности:
Во всех случаях расчеты выполняются в рамках Hadoop сервера, что позволяет эффективно использовать возможности распределенного хранения и обработки данных. В первых двух случаях в рамках одного задания обрабатываются данные многих пользователей, в третьем случае – конкретного пользователя, инициировавшего расчет. Использование Spark Stream позволяет не реагировать на каждое отдельное событие, а собрать в течение небольшого промежутка времени все требующие пересчета агрегатов события и обработать их в рамках одного задания, тем самым сохранив разумное время обновления агрегатов и снизив загрузку сервера.
Кроме мобильного приложения пользователям доступно web-приложение. Целью разработки web-версии приложения было дать пользователям доступ к большему объему данных, большему числу показателей, возможность более глубокого анализа, в том числе и медицинским специалистом. Мы также исходили из того, что в ряде случаев пользователям будет необходим доступ к своим данным без мобильного приложения. Например, при общении с врачом в рамках телемедицинской консультации трудно ожидать, что каждый врач имеет на своем смартфоне приложение Actenzo, но с большой вероятностью врач будет иметь возможность использовать WEB версию, не требующую установки.
С тем чтобы, с одной стороны, облегчить восприятие информации пользователям, не обладающим сколько-нибудь глубокими знаниями, а с другой – дать специалистам возможность как можно глубже проанализировать состояние, WEB приложение имеет два режима: пользовательский и профессиональный.
Пользовательский режим максимально близок по интерфейсу к мобильному приложению, однако пользователю доступна вся история наблюдений – в отличие от 7 последних дней в случае мобильного приложения.
В профессиональном режиме мы предоставляем доступ к более детальным показателям, смысл которых понятен медицинскому персоналу, но требует от среднего пользователя обращения к специальной литературе – не слишком глубокого, но необходимого для понимания терминов. В этом режиме доступны графики ЭКГ, пульсовой волны, детальный анализ вариабельности сердечного ритма как во временном, так и частотном доменах, анализ ЭКГ. Специалист имеет возможность дополнительно очистить записи кардио-интервалов, удалив пропущенные алгоритмом артефакты и экстрасистолы.
И мобильное, и web-приложение визуализирует данные, получаемые с Hadoop кластера через REST сервис с единым API для обоих приложений. Этот же API может быть использован для интеграции с внешними системами, поскольку спроектирован, отталкиваясь от данных, а не форматов их использования в приложениях.
Сервис реализован на фреймворке Play. Не последним аргументом при выборе фреймворка был язык программирования – Scala. Spark, используемый нами для обработки данных на Hadoop кластере, предоставляет возможность программирования на Python и Scala. Scala, будучи языком исходно спроектированным на парадигме функционального программирования, показался нам более удобным при работе со Spark, и было естественно использовать этот же язык для разработки сервиса.
Возвратимся, собственно, к фитнес-браслетам и возможности получить значимые для оценки состояния организма данные с подобных устройств. Мы уверены, что регулярный мониторинг – именно мониторинг, а не измерения от раза к разу, даже достаточно доступных физиологических параметров, таких как пульс, может помочь вовремя заметить негативные изменения и обратиться к специалистам за профессиональной помощью. Тем не менее, чтобы усилить возможности браслета, мы дополнительно поработали над его прошивкой. Любой фитнес-браслет с пульсометром так или иначе измеряет пульсовую волну с помощью плетизмографии, однако не каждое устройство делает эти данными доступными для анализа. То же самое и с ЭКГ. В браслете Actenzo мы открыли эти данные. Приложению доступны измерения пульсовой волны с частотой семплинга 84 Hz и ЭКГ с частотой 250 Hz, что позволило реализовать анализ вариабельности сердечного ритма в соответствии с рекомендациями рабочей группы Европейского Кардиологического Общества и Северо-Американского общества стимуляции и электрофизиологии. Мы также изменили общепринятый способ представления данных о физической активности. Традиционно браслеты сообщают только об общем объеме нагрузки за весь период активности: сожженные калории или количество шагов за весь период тренировки. Это не дает возможности оценить интенсивность нагрузки на различных временных участках и сопоставить это, например, с пульсом. Мы разбиваем период активности на пятиминутные интервалы, сообщая нагрузку в каждом из них, что дает возможность увидеть изменение интенсивности физической активности и, сопоставляя с пульсом и вариабельностью сердечного ритма, более точно понять допустимые для индивидуума уровни нагрузки.
В целом браслет Actenzo вместе с приложением позволяет мониторировать следующие параметры:
В настоящее время Actenzo работает с несколькими гаджетами: собственный браслет Actenzo, браслет iWown 6 pro, пульсометры Polar H10 и OH1, smart-часы Samsung Galaxy Watch и Galaxy Active, биоимпедансные весы MGB.
Интеграция устройств различных брендов не только дает возможность пользоваться сервисом с любимым гаджетом, но и позволяет преодолеть некоторые технологические ограничения. Так, пульсометры, использующие для измерения пульса плетизмографию, неизбежно наталкиваются на ограничения при активном движении: кровь, как любая жидкость, начинает колебаться не только в ответ на сокращение сердца, но и в такт с движением тела. Это ограничение отсутствует в случае пульсометров, измеряющих электрическую активность сердца. Именно этим продиктовано включение в линейку поддерживаемых устройств нагрудного пульсометра Polar H10, непрерывно снимающего ЭКГ пользователя, что позволяет использовать его во время интенсивных тренировок для точного измерения пульса и оценки адаптационного потенциала.
Для решения поставленной задачи мы продолжаем работать как над алгоритмами, так и линейкой доступных устройств, с тем чтобы расширить число измеряемых физиологических параметров и сделать картину состояния организма наших пользователей более полной.
Нам будет интересно, если расскажете в комментариях, для чего вы используете фитнес-браслет. Какие параметры мониторите регулярно, что это дает вам и чего не хватает в подобных сервисах?
Мы решили: почему бы не написать сервис, который бы помог людям следить за своим здоровьем с помощью носимых гаджетов: отслеживал 24х7 доступные физиологические параметры, строил индивидуальный профиль, следил за отклонением от этого профиля. Более того, нам хотелось, чтобы все это не ограничивалось сугубо нашим пользователем. Нам хотелось, чтобы наши пользователи имели возможность заботиться о своих близких, т.е. онлайн видеть все измерения, производимые гаджетом, который носит давно ушедшая на пенсию и живущая на другом конце страны мама. Мы хотим, чтобы телемедицинская консультация со специалистом проходила не на уровне: “доктор, болит вот тут”, а с объективным измерением.
Что следует из такой постановки задачи? Первое: мы на B2C рынке, т.е. мы не имеем ограничения по числу пользователей – чем больше, тем лучше. Второе: мы хотим стремиться к как можно более полной картине состояния организма, т.е. типов датчиков потенциально может быть много, и мы априори (a priori) не фиксируем их типы. Третье: мы не в состоянии регламентировать потоки данных. Поток данных живет своей жизнью; кто-то из пользователей измеряет только пульс, кто-то измеряет каждые полчаса давление, кого-то волнует его стресс, кто-то делает ЭКГ каждый час. Пользователи находятся в разных часовых поясах: для сервиса нет дня и ночи, нет “закрытия операционного дня”, любое время суток для кого-то – разгар дня, а для кого-то – время подвести итог того, как прошел день. Поскольку наша задача – анализ, мы не можем обрезать этот поток данных на уровне мобильного приложения, мы должны направить все данные на сервер, обеспечив их эффективный прием на сервере, хранение и последующую, а зачастую и параллельную с записью в базу, обработку.
Исходя из всего этого было принято решение использовать технологии Big Data. В качестве дистрибутива был выбран дистрибутив от Cloudera. Общая архитектура решения показана на рис. 1
Рисунок 1. Архитектура решения
Носимое устройство (гаджет) измеряет те или иные физиологические показатели пользователя и по Bluetooth протоколу передает их на смартфон. На смартфоне работает приложение (доступно как на Android, так и на iOS), функционально состоящее из двух частей:
- Сервис, управляющий гаджетом;
- Интерфейс пользователя.
Задача сервиса – поддержание взаимодействия с гаджетом: отслеживание наличия соединения и его восстановление в случае потери, конфигурация гаджета, синхронизация данных, запуск на гаджете команд пользователя, отправка данных на сервер. Сервис работает по расписанию, просыпаясь через заданный пользователем интервал времени – обычно раз в несколько минут – и выполняя запланированный объем задач. В большинстве случаев это запрос на регулярно собираемые данные от гаджета: пульс, сон, физическая активность. Получаемые данные отсылаются по REST протоколу на сервер. Если сеть недоступна или сервер ответил ошибкой, данные сохраняются на смартфоне до тех пор, пока связь не будет восстановлена. Таким образом обеспечивается надежная доставка данных через не слишком надежные и не всюду доступные мобильные сети. Кроме основного расписания пользователь может задать дополнительное расписание для исполнения определенных видов замеров, таких как давление, стресс, ЭКГ, которые не входят в основное расписание и выполняются несколько раз в день. По умолчанию эти замеры планируются на ночное время с тем, чтобы дневная активность пользователя заведомо не искажала замеры. Кроме этого, регулярное измерение показателей в фиксированных условиях – в данном случае во время сна – позволяет следить за динамикой показателей, оценивая их изменение относительно предварительно построенного профиля пользователя. Сам по себе пульс в 150 ударов в минуту не говорит ни о чем. Такой пульс может быть у совершенно здорового человека во время физической нагрузки или сразу после нее, но это же значение во время глубокого покоя, характерного для сна, свидетельствует о проблемах с сердечно-сосудистой системой человека.
Пользователь может установить расписание по своему желанию либо выполнить измерение в ручном режиме.
Основная задача интерфейса пользователя – предоставление пользователю доступа к данным: как собственно к сырым измерениям, так и к аналитике в виде построенных профилей и уведомлений, созданных по результатам анализа данных. На рисунке 2 показаны примеры таких предупреждений.
Рисунок 2. Уведомления
Рисунок 3
Профиль пульса во время сна и выход пульса во время начала сна за типовые значения, что может свидетельствовать о чрезмерной нагрузке в предшествующий день.
Сбор данных на сервере осуществляется через Flume, что позволяет гибко настроить потоки данных по различным каналам, маршрутизируя данные в различные таблицы для хранения либо на экспресс-обработку с помощью Spark Streams. Каналы также позволяют сгладить неравномерность поступающих объемов данных, буферизуя поступающие данные. Кроме того, при росте числа пользователей мы просто увеличиваем число агентов Flume, распределяя данные по агентам с помощью балансировщика – в нашем случае haproxy.
Для хранения данных нами используется HBase. Выбор в пользу HBase определяется не только фактом большого объема данных, но и шаблоном использования:
- Мы имеем дело с измерениями, т.е. с неизменяемыми по своей природе данными;
- Расчет аналитических показателей требует доступа не к отдельно взятой записи, а чтения массива последовательных во времени данных и параллельной обработки.
Собственно, мы имеем дело ровно с тем шаблоном работы с данными, под который проектировался HBase: максимально быстро записать данные и массово их обработать. На скорость записи положительно влияет и такая особенность HBase, что update записи реализован физически как создание новой версии записи, а не поиск и перезапись существующей, что облегчает нам работу с “дублями”. Для дополнительной гарантии от потерь данных мы отчасти дублируем обмен данными между гаджетом и сервером, а данная особенность HBase позволяет нам не терять производительности записи в случае дублей. Безусловно, часть хранимых данных может меняться, например, аналитические показатели – они регулярно пересчитываются на протяжении текущего дня, но их объем несоизмеримо мал по сравнению с сырыми данными, а требуемый отклик на доступ к ним определяется GUI и не является серьезным ограничением.
Часть данных, носящий характер метаданных, а также персональные данные пользователей хранятся в отдельной базе данных Postgres.
В системе реализовано три контура обработки данных в зависимости от срочности:
- Batch задания в виде очередей Oozie большей частью в виде заданий для Hive, исполняемых по расписанию, с относительно небольшим приоритетом.
- Spark Stream для обработки достаточно срочных событий, таких как пересчет агрегатов, например, статистики шагов, сна, не связанных с непосредственными действиями пользователя через GUI.
- Расчет аналитических показателей в ходе измерений, осуществляемых пользователем в ручном режиме через GUI. В этом случае запрос на обработку инициируется мобильным приложением, а сервер приложения – в нашем случае Play – запускает соответствующее задание на Hadoop сервере. Типичный пример – расчет показателей вариабельности по измерению ЭКГ или пульсовой волны, когда пользователь совершил это измерение самостоятельно через мобильное приложение, а не по заранее созданному расписанию. Естественно, что пользователь хочет в этом случае «моментального» результата, и прямой запуск расчета позволяет получить необходимую скорость отклика.
Во всех случаях расчеты выполняются в рамках Hadoop сервера, что позволяет эффективно использовать возможности распределенного хранения и обработки данных. В первых двух случаях в рамках одного задания обрабатываются данные многих пользователей, в третьем случае – конкретного пользователя, инициировавшего расчет. Использование Spark Stream позволяет не реагировать на каждое отдельное событие, а собрать в течение небольшого промежутка времени все требующие пересчета агрегатов события и обработать их в рамках одного задания, тем самым сохранив разумное время обновления агрегатов и снизив загрузку сервера.
Кроме мобильного приложения пользователям доступно web-приложение. Целью разработки web-версии приложения было дать пользователям доступ к большему объему данных, большему числу показателей, возможность более глубокого анализа, в том числе и медицинским специалистом. Мы также исходили из того, что в ряде случаев пользователям будет необходим доступ к своим данным без мобильного приложения. Например, при общении с врачом в рамках телемедицинской консультации трудно ожидать, что каждый врач имеет на своем смартфоне приложение Actenzo, но с большой вероятностью врач будет иметь возможность использовать WEB версию, не требующую установки.
С тем чтобы, с одной стороны, облегчить восприятие информации пользователям, не обладающим сколько-нибудь глубокими знаниями, а с другой – дать специалистам возможность как можно глубже проанализировать состояние, WEB приложение имеет два режима: пользовательский и профессиональный.
Пользовательский режим максимально близок по интерфейсу к мобильному приложению, однако пользователю доступна вся история наблюдений – в отличие от 7 последних дней в случае мобильного приложения.
В профессиональном режиме мы предоставляем доступ к более детальным показателям, смысл которых понятен медицинскому персоналу, но требует от среднего пользователя обращения к специальной литературе – не слишком глубокого, но необходимого для понимания терминов. В этом режиме доступны графики ЭКГ, пульсовой волны, детальный анализ вариабельности сердечного ритма как во временном, так и частотном доменах, анализ ЭКГ. Специалист имеет возможность дополнительно очистить записи кардио-интервалов, удалив пропущенные алгоритмом артефакты и экстрасистолы.
И мобильное, и web-приложение визуализирует данные, получаемые с Hadoop кластера через REST сервис с единым API для обоих приложений. Этот же API может быть использован для интеграции с внешними системами, поскольку спроектирован, отталкиваясь от данных, а не форматов их использования в приложениях.
Сервис реализован на фреймворке Play. Не последним аргументом при выборе фреймворка был язык программирования – Scala. Spark, используемый нами для обработки данных на Hadoop кластере, предоставляет возможность программирования на Python и Scala. Scala, будучи языком исходно спроектированным на парадигме функционального программирования, показался нам более удобным при работе со Spark, и было естественно использовать этот же язык для разработки сервиса.
Возвратимся, собственно, к фитнес-браслетам и возможности получить значимые для оценки состояния организма данные с подобных устройств. Мы уверены, что регулярный мониторинг – именно мониторинг, а не измерения от раза к разу, даже достаточно доступных физиологических параметров, таких как пульс, может помочь вовремя заметить негативные изменения и обратиться к специалистам за профессиональной помощью. Тем не менее, чтобы усилить возможности браслета, мы дополнительно поработали над его прошивкой. Любой фитнес-браслет с пульсометром так или иначе измеряет пульсовую волну с помощью плетизмографии, однако не каждое устройство делает эти данными доступными для анализа. То же самое и с ЭКГ. В браслете Actenzo мы открыли эти данные. Приложению доступны измерения пульсовой волны с частотой семплинга 84 Hz и ЭКГ с частотой 250 Hz, что позволило реализовать анализ вариабельности сердечного ритма в соответствии с рекомендациями рабочей группы Европейского Кардиологического Общества и Северо-Американского общества стимуляции и электрофизиологии. Мы также изменили общепринятый способ представления данных о физической активности. Традиционно браслеты сообщают только об общем объеме нагрузки за весь период активности: сожженные калории или количество шагов за весь период тренировки. Это не дает возможности оценить интенсивность нагрузки на различных временных участках и сопоставить это, например, с пульсом. Мы разбиваем период активности на пятиминутные интервалы, сообщая нагрузку в каждом из них, что дает возможность увидеть изменение интенсивности физической активности и, сопоставляя с пульсом и вариабельностью сердечного ритма, более точно понять допустимые для индивидуума уровни нагрузки.
В целом браслет Actenzo вместе с приложением позволяет мониторировать следующие параметры:
- Пульс
- Физическую активность в виде шагов и калорий
- Продолжительность и фазы сна
- ЭКГ
- Пульсовую волну
- Вариабельность сердечного ритма, стресс и адаптационные резервы организма
- Изменения артериального давления
В настоящее время Actenzo работает с несколькими гаджетами: собственный браслет Actenzo, браслет iWown 6 pro, пульсометры Polar H10 и OH1, smart-часы Samsung Galaxy Watch и Galaxy Active, биоимпедансные весы MGB.
Интеграция устройств различных брендов не только дает возможность пользоваться сервисом с любимым гаджетом, но и позволяет преодолеть некоторые технологические ограничения. Так, пульсометры, использующие для измерения пульса плетизмографию, неизбежно наталкиваются на ограничения при активном движении: кровь, как любая жидкость, начинает колебаться не только в ответ на сокращение сердца, но и в такт с движением тела. Это ограничение отсутствует в случае пульсометров, измеряющих электрическую активность сердца. Именно этим продиктовано включение в линейку поддерживаемых устройств нагрудного пульсометра Polar H10, непрерывно снимающего ЭКГ пользователя, что позволяет использовать его во время интенсивных тренировок для точного измерения пульса и оценки адаптационного потенциала.
Для решения поставленной задачи мы продолжаем работать как над алгоритмами, так и линейкой доступных устройств, с тем чтобы расширить число измеряемых физиологических параметров и сделать картину состояния организма наших пользователей более полной.
Нам будет интересно, если расскажете в комментариях, для чего вы используете фитнес-браслет. Какие параметры мониторите регулярно, что это дает вам и чего не хватает в подобных сервисах?
