Добро пожаловать в четвертый пост из серии, в которой документируется эволюция моего побочного проекта по обучению: анализировать изменение цены криптовалюты в зависимости от связанных с ней событий, таких как выпуск вехи.
- Пост 1 представил конечную цель и ее мотивацию.
- В посте 2 были рассмотрены атрибуты качества, на которых следует сосредоточиться, учитывая характер данных этого проекта.
- В посте 3 описан процесс штурма событий, через который я прошел.
Этот пост приближает нас к металлу и описывает мой выбор, чтобы воплотить этот проект в жизнь.
После нескольких итераций сеансы бурения событий остановились на четырех разных агрегатах, которые я сопоставил с двумя независимыми сервисами. Один будет собирать и очищать данные, а другой обучать и применять модели прогнозирования.
В более ранних итерациях модели я планировал иметь 4 разных сервиса: наблюдение за монетами было отделено от сервиса криптографических событий, а обучение ML было отделено от предсказания. В конечном счете, это было слишком сложно, и сейчас доступны только две службы. Это упрощение является результатом итерации модели и ее штурма событий. Давайте рассмотрим некоторые из сделанных мной выборов.
Источники криптовалют. Цель состоит в том, чтобы связать криптографические события с изменением относительных криптовалют. К счастью, вся необходимая информация доступна бесплатно (по крайней мере, на момент написания). CoinMarketCap является ведущим веб-сайтом по таким параметрам, как объем и цена, и предлагает бесплатный API. CoinMarketCal собирает серию криптовалютных событий, классифицированных по таким категориям, как Событие сообщества, Форк / своп, Выпуск и так далее. Это отлично подходит для моих целей - по общему признанию, это тот веб-сайт, который меня впервые вдохновил, - но в то же время он сильно зависит от этого конкретного веб-сайта. Если он перестанет работать, мне нужно будет найти другой источник данных.
Язык программирования. Мой любимый язык - Scala, и это тот язык, которым я владею быстрее всех. Более того, он дает вам сверхспособности в сочетании с Akka, который предоставляет все абстракции, необходимые для реализации реактивных систем: продуктов, которые остаются отзывчивыми при любых условиях нагрузки или сбоя, сохраняя при этом сложность под контролем. Один из самых мощных модулей Akka, Akka Streams, который предлагает высокоуровневые абстракции для работы с потоком элементов. Посмотрим на это поближе.
Облачное хранилище. У каждой кодовой базы должно быть свое гнездо. Если вы хотите разместить его в облаке, а не на собственном сервере, в настоящее время можно выбрать три основных варианта: GitHub, BitBucket или GitLab.
GitHub - самый популярный, особенно в мире с открытым исходным кодом. В отличие от многих других разработчиков, меня не беспокоило приобретение Microsoft (на самом деле, Microsoft молодец!), Но в конце концов я решил разместить этот проект на BitBucket, так как мне особенно любопытно опробовать их конвейерную функцию. . Я никогда не чувствовал себя слишком комфортно со всем миром CD / CI, и обещание более простого способа очень привлекательно.
Конвейер CI / CD. Как уже упоминалось, я собираюсь изучить BitBucket и его конвейерные функции. Раньше я использовал Jenkins, но никогда не любил его. Плагин Чак Норрис сделал работу с ним немного интереснее.
Мониторинг. Если вы не хотите использовать коммерческий пакет Lightbend, фактическим стандартом для мониторинга реактивных систем является Kamon. Хотя он нацелен на любое стандартное программное обеспечение JVM, пара дополнительных модулей информирует его обо всех асинхронных контекстах, которые можно найти в Akka. Он прекрасно сочетается с другими открытыми решениями, такими как Prometheus и Graphana, которые я и собираюсь использовать.
Развертывание. Выбор здесь не вызывает удивления. Докер и Кубернетес - команда победителей. Мне не нужны никакие основные функции, прославившие их обе - развертывание в любом месте, автоматическое масштабирование и т. Д. Классическая установка виртуальной машины может быть дешевле, но мне удобна установка контейнеров и оркестровки, и я даже говорю об этом на конференциях.
Облачный сервис. У меня есть опыт работы с AWS, но мне почему-то удобнее работать с Google. Документация AWS кажется многословной, и мне всегда кажется, что я ищу иголку в стоге сена. Инфраструктура, которую я использую для демонстраций своих выступлений, находится в Google, поэтому чем больше я практикуюсь, тем лучше.
Межсервисное общение. В более ранних версиях я выбрал Kafka в качестве моста между разделенными службами. На самом деле я не собираюсь придерживаться строго событийной устойчивой модели. Kafka был бы отличным вариантом, если бы мне потребовались повторы журналов, но в этом случае достаточно простой очереди и добавляет меньше сложности. Управляемые экземпляры Kafka стоят дорого, даже из-за ожидаемой низкой скорости отправки сообщений, что является еще одним фактором при выборе другого решения. Учитывая, что мои сервисы будут работать в Google, Pub / Sub - наиболее естественный выбор.
Постоянный слой. Для того, что я могу видеть на данный момент, мне нужно сохранить криптографические события, измерения монет и обученные модели. В качестве облачного хранилища я выбрал Google Cloud Datastore, дешевый и надежный. Что касается размеров монет, я изучил различия между всеми вариантами хранения Google, и BigQuery, кажется, лучше всего подходит для моего случая. Есть Java SDK, который, будем надеяться, отлично подойдет. Я пока не уверен, как лучше всего хранить обученные модели, поэтому на архитектурной диаграмме есть вопросительный знак.
Машинное обучение. Вот где я начинаю чувствовать себя в зоне исследования. У меня был опыт работы со Spark, к тому же я недавно сидел рядом с Холденом Карау на ужине докладчика, поэтому, естественно, я пошел и проверил Spark ML. Аааа, я не знаю. Я наткнулся на другую библиотеку Smile, и я думаю, что сначала поэкспериментирую с ней - по крайней мере, она не доставит мне головной боли с Scala 2.12, которая все еще остается актуальной темой в мире Spark.
Сумма этих вариантов очень сильно пахнет привязкой к поставщику, но, честно говоря, я чувствую, что это неизбежно. Я уже знаю, что после начала разработки потребуются изменения. Так что следите за первыми шагами по внедрению!
