Аргументы в пользу стека технологий
В предыдущем посте мы рассмотрели стоящие перед нами задачи, наши общие цели и технологический стек, который мы выбрали. В этом посте анализируются причины, по которым мы выбрали.
Луиджи
Разработчик, плохо знакомый с созданием сложных конвейеров ETL, часто начинает с написания собственных версий конвейера данных. Похоже на простой скрипт на Python для начала:
- Получать данные из нескольких источников
- Хранить в памяти или во временных файлах
- Преобразовать данные
- Загрузить в хранилище данных
Со временем вам нужно будет добавить больше источников данных для ввода и вывода, добавить мониторинг, обработку исключений, логику повторных попыток, кэширование дорогостоящих вычислений, очистку устаревших данных и, если конвейер выйдет из строя в течение определенного периода времени, перезапустить для прошлых исторических данных, чтобы он начал стать примерно таким:
- Обработка аргументов для даты, источника ввода и источника вывода
- Проверка наличия временных файлов, чтобы избежать тяжелых вычислений
- Проверьте, на каком этапе обработки произошел сбой последнего запуска, чтобы повторно использовать все данные до этого этапа.
- Обработка параллелизма для выборки и загрузки данных
- Очистка файлов
- Множество служебных модулей для загрузки, взаимодействия с S3, Redshift, Postgres и логики обработки исключений / повтора для каждого из них.
- … и т.д.
И в конечном итоге у вас будет что-то, что работает… пока оно не перестанет работать. Или ваши данные могут быть повреждены / уничтожены, что означает, что теперь вам нужно написать собственную версию с измененным диапазоном дат, обработать всю очистку и зависимости.
Возьмите это у кого-то, кто пытался это сделать и в итоге потратил некоторое время на изобретение велосипеда: не пытайтесь сделать это самостоятельно. В долгосрочной перспективе гораздо важнее иметь стабильный конвейер, обрабатывающий частичные сбои, чем писать «простой» сценарий и поддерживать его годами!
Луиджи помогает вам несколькими способами:
- Он выполняет сантехнические работы, связанные со сложными конвейерами данных, включая повторный запуск, параллелизм, очистку файлов, проверку маркеров и т. Д.
- У него есть демон мониторинга, который можно использовать для проверки состояния, матрицы зависимостей и его исторических прогонов.
- Он имеет огромный набор инструментов, содержащий код для подключения и получения данных из множества источников данных, включая Redshift, S3, Postgres.
- Код, использующий Luigi, действительно чистый и состоит только из задач, содержащих вход, выход (который может быть передан на вход другой задачи) и логику выполнения.
Amazon Redshift
Большая часть нашей инфраструктуры работает на Amazon EC2, и мы уже используем S3 для хранения данных и Cloudfront для CDN. Redshift отлично сочетается с этими технологиями, и это означает, что для инфраструктуры достаточно одного биллинга, что удобно.
Другой фактор - это ценообразование. У него действительно простая предоплата, что довольно дешево, учитывая, насколько легко он упрощает анализ данных и объем хранимых данных. Мы начали с одного узла, учитывая, что наши данные составляют около 1 ТБ, а использование все еще довольно низкое, но это просто вопрос добавления узлов, когда они нам нужны.
Синтаксис запросов аналогичен PostgreSQL, но поскольку Redshift использует столбчатое хранилище для оптимизации хранилища и ввода-вывода, результаты сложных запросов агрегирования в несколько раз быстрее по сравнению с PostgreSQL.
Веб-аналитика и Cloudfront
Это был один из наиболее сложных элементов, так как при его полностью собственном масштабировании возникает масса проблем по следующим причинам:
- Обработка огромного количества запросов
- Имея достаточную скорость обработки и анализа, чтобы не было отставания
- Хранение журналов таким образом, чтобы мы могли запускать по ним быстрые специальные запросы
- Наличие надежного развертывания, поэтому нам не нужно время от времени увеличивать объем хранилища или устранять сбои.
Для решения этой проблемы мы решили использовать максимально простой подход.
Мы уже анализируем журналы nginx, чтобы получить некоторую полезную информацию, поэтому, используя тот же подход, мы решили поместить небольшой GIF на каждую страницу, чтобы у нас были журналы доступа, когда пиксель загружается через Cloudfront, который затем мы анализируем, чтобы получить полезную информацию об удобстве использования для наш сайт. Мы повторно использовали Luigi и Redshift для получения журналов из S3, их обработки и массового копирования обработанных строк в Redshift. Наш подход очень похож на один проект с открытым исходным кодом: https://github.com/snowplow/snowplow
Мы планируем открыть исходный код парсера и всего конвейера, чтобы любой мог создать дешевый масштабируемый парсер, не платя много за сторонние решения или не выполняя значительного обслуживания журналов.
Визуализация: метабаза
Мы изучили некоторые платные решения - Periscope, ChartIO и Looker - для нашей панели инструментов и визуализации. Все они примерно работают по тому же принципу, по которому вы напрямую подключаетесь к своему хранилищу данных и визуализируете результаты SQL-запроса. Интерфейсы, которые у них есть, действительно впечатляют, но они идут с ежемесячной оплатой или оплатой на человека, или с оплатой за количество строк, что кажется ограничивающим и что является действительно большим вложением, учитывая, что мы впервые использовали такие решения. Мы могли бы вернуться и исследовать их дальше, но не сейчас.
Итак, как и в случае с остальной частью нашего стека, мы хотели использовать решение с открытым исходным кодом и сохранить доступ к панели мониторинга в нашей сети. Мы исследовали решения Redash и Metabase, и в итоге мы выбрали последнее из-за простого пользовательского интерфейса и возможности извлекать данные даже без SQL-запросов в интуитивно понятной манере (полезно для людей, не являющихся экспертами. в SQL). Кроме того, было легко разместить на EC2, что позволяет нам хранить данные в нашей сети.
Мы также используем Metabase для визуализации статистики поддержки клиентов, маркетинговых данных, данных аналитики и некоторых бизнес-показателей.
Самая сложная часть работы с Metabase (или любым другим инструментом бизнес-аналитики) на самом деле заключается в начальной загрузке панелей мониторинга и ее упрощении, чтобы ее могли использовать коллеги, не являющиеся техническими специалистами. Как инженеру, это может быть трудно понять, поскольку мы иногда предполагаем, что конечный пользователь похож на нас, что часто не так. Мы постепенно перебираем информационные панели с разными командами, чтобы увидеть, можем ли мы по-разному моделировать некоторые данные, чтобы им стало проще запрашивать или понимать с первого взгляда. Поскольку мы знаем, что наши данные точны, имеет смысл смоделировать их по-другому сейчас или повторить визуализацию с течением времени.
Текущее состояние и размышления
Путешествие сюда не обошлось без нескольких лежачих полицейских и неприятных моментов. Мы должны были убедиться, что данные, полученные из разных источников, и то, как они обрабатываются, были точными. Ясно, что мы не хотели торопиться с точностью и в конечном итоге получить почти правильные данные.
Раньше конвейер данных выходил из строя по множеству причин (благодаря Луиджи его было легче отлаживать и запускать повторно), с которыми нам удалось лучше справиться с течением времени.
Дальнейшие действия
Мы только коснулись поверхности и учимся по ходу дела. Мы добавим некоторых специалистов по обработке данных с сильным математическим опытом, чтобы помочь нам улучшить аспекты моделирования и дедукции.
Некоторые вещи в нашем текущем списке дел:
- Прогностическое моделирование данных и обнаружение аберраций в ежедневных данных
- Придумайте план приема на работу для новых сотрудников, чтобы они могли использовать эту платформу для ускорения работы в компании.
- A / B-тестирование веб-аналитики, чтобы упростить использование нашего веб-сайта для клиентов.
- Упрощение визуализации данных для нетехнических сотрудников Smarkets
- Более тщательная проверка данных
