12 вещей, которые следует учитывать при развертывании собственных конвейеров данных
Хотя существуют сервисы (Openbridge!), которые могут помочь вам в интеграции данных, иногда отдельные лица и организации решают создавать, а не покупать. Если вы решили отказаться от пути «купить» с коммерческим готовым или коммерчески доступным готовым (COTS) программным обеспечением, то вы принадлежите к тем уникальным душам, которые получают огромное удовольствие, преследуя индивидуальные или индивидуальные решения. Ты не одинок!
Вот 12 моментов, которые следует учитывать при планировании работы с конвейером данных:
1. Аутентификация
Интеграция с различными механизмами OAuth исходной системы, ключами и именами пользователей и паролями. Это включает в себя обработку истечения срока действия, деавторизацию и иерархические схемы разрешений. Например, пользователь разрешает вам собирать данные из Google Analytics в декабре. Однако через три месяца пользователь прерывает эту авторизацию в своей учетной записи Google. Что должно произойти в вашей системе (см. 2)?
2. Управление пользователями
Управление привязкой авторизации пользователя к конкретному ресурсу. Например, пользователь A предоставляет авторизацию для системы X. Что касается (1), вам необходимо позаботиться об уведомлениях о доставке для ошибочных учетных данных, обновлении учетной записи и аудите статуса предоставленных пользователем авторизаций. Например, у вас может быть пользователь А, который предоставляет или может предоставить авторизацию для 50 страниц Facebook. Что произойдет, если что-то изменится, связанное с авторизацией пользователей на 1 или на всех 50 из этих 50 страниц?
3. Управление версиями
Быть в курсе версий API для исходных систем может быть проблемой. Это может включать разветвление SDK поставщиков для устранения ошибок/багов. Это также включает разрешение недокументированных функций, функций или обходных путей, необходимых для получения желаемых результатов. Не все SDK поддерживаются в актуальном состоянии или работают должным образом. Особенно забавны орфографические ошибки в API. Глядя на ваш Сизмек! Отслеживаете ли вы исходный код и оперативно управляете изменениями?
4. Запросы
Что может дать вам этот API? Как вы можете подчинить его своей воле, чтобы получить желаемый результат? Как кто-то вызывает этот API, чтобы получить желаемый результат? Как вообще узнать, какой выход доступен? Не стоит недооценивать время, затрачиваемое на исследование, планирование и разработку интеграции. Убедитесь, что вы понимаете все запросы к API, включая любые правила инклюзивности/эксклюзивности, состояние запроса, методы выполнения вызовов API и любые необходимые определения схемы/запроса.
5. Дросселирование/лимиты
Каждый источник данных будет иметь условия обслуживания (ToS), которые обеспечивают ограничения или регулирование их API. Кроме того, многие API имеют значительные ограничения на объем данных, которые могут быть запрошены в любое время. Эти ограничения также могут меняться чаще, чем вам бы хотелось. Что произойдет, если вы достигнете пределов? Все терпит неудачу?
6. Ошибки
Неудача — это не крайний случай. Вы должны предполагать неудачу для всех ваших вызовов API. Ваши системы должны будут заботиться о недоступности API, плохих ответах, недокументированных изменениях, проблемах с производительностью, искаженных выходных данных и неполных ответах. Наконец, исходные SDK могут содержать и содержат ошибки, которые могут усложнить работу, особенно в зависимости от их реакции на запросы об изменениях/ошибках. Как вы тестируете, особенно в процессе производства?
7. Доступность
Вы должны понимать, когда данные становятся доступными в исходной системе. Во многих системах данные не поступают «в режиме реального времени», поэтому вам нужно знать, когда «истина» устанавливается в исходной системе. Почему это важно? Если вы слишком часто запрашиваете данные, которые недоступны или неполны, вы можете напрасно тратить драгоценные вызовы API, увеличивая количество ошибок и снижая качество данных в вашей системе. Например, вы звоните в систему X каждые 6 часов, и она отвечает принятым запросом и правильным ответом. Однако эти выходные данные содержат противоречивые результаты. Есть несколько записей с 0 или NULL. Эти значения сохраняются на вашем складе. Причина таких значений в том, что истина не установилась в исходной системе. Они учитывают ваш вызов API, но не возвращают ожидаемых значений. Если вы доносите эти ценности до пользователей и руководителей, это может привести к путанице и создать проблемы с доверием.
8. Планирование
Когда что-то должно запускаться? Должен ли запрос быть сдвинут во времени? Например, сделать запрос 16 марта для данных от 14 марта? Это связано с (7), когда некоторые системы требуют от вас сдвига во времени периода данных, которые вы запрашиваете. Facebook Graph API лучше всего работает с запросами со сдвигом во времени, чтобы обеспечить согласованный вывод. Это означает понимание того, как задания настроены и будут инициировать вызовы API через определенные промежутки времени. Не забывайте отслеживать задачи, запросы и результаты, чтобы вы могли исправить любые проблемы или сбои.
9. Схемы
Если вы вызываете (или получаете) данные, они будут иметь некоторую структуру. Большинство API захотят, чтобы вы определили свой запрос, и эти запросы имеют структуру. Ответы могут быть менее структурированными, но в целом есть нечто, с чем соглашаются те, кто вызывает API, и те, кто отвечает на запрос. Запросы будут определять схемы «полезной нагрузки». Эти запросы обычно также тесно связаны с определениями вывода ответов API. Например, этот запрос к Google Analytics определяет не только то, что вы запрашиваете, но и результат:
ids=profile_id, start_date=start_date, end_date=end_date, metrics=’ga:pageviews’, dimensions=’ga:visitorType,ga:sourceMedium,ga:networkLocation,ga:country,ga:region,ga:city’
Если вы используете СУБД, важны схемы. Планируйте соответственно.
10. Кодирование
В зависимости от вашей исходной системы, кодирование может быть диким западом. Даже системы, которые обязуются предоставлять стандартную кодировку, иногда делают это не во всех случаях. Вероятно, вам потребуется обрабатывать данные из исходных систем, чтобы правильно кодировать данные в соответствии со спецификациями UTF-8 для обеспечения согласованности. Плохие вещи случаются, если ваша кодировка испорчена.
11. Обработка
Данные, доставленные исходной системой, могут нуждаться в дальнейшей обработке (т. е. см. Кодирование). В некоторых случаях это может быть незначительным, а в других случаях, более обширным. Вам нужно будет запланировать такие действия, как добавление метаданных, согласование выходных форматов, дедупликация, проверка выходных данных на соответствие спецификациям/схемам API и так далее. Например, ваши системы немного сбиваются, а запросы к Google Analytics выполняются 100 раз. Вы можете загрузить эти данные 100 раз или убедиться, что до/во время загрузки вы не «загрязняете» таблицу, на которую полагаются ваши аналитики. Например, многие источники данных не предоставляют уникальные идентификаторы для каждой записи. Это было бы то, что вы хотели бы добавить к своим данным.
12. Асинхронные/синхронные операции
Достижение желаемого результата не означает, что для достижения этой цели существует единый исходный API. В некоторых случаях может потребоваться связать несколько исходных API, которые необходимо вызывать последовательно или параллельно для получения желаемого результата. Например, один вызов API может генерировать необработанные транзакционные данные. Однако эти данные не имеют меток для определенных ключей. Вам нужно вызвать второй API для поиска каждого идентификатора, чтобы определить эту понятную человеку метку. Youtube делает это для своих каналов. Вы можете получить идентификаторы видео или списка воспроизведения из одного API, но вам нужно вызвать второй API, чтобы определить метки/имена для этих идентификаторов. Кроме того, все эти вызовы API учитываются в ваших квотах!
Резюме
Забота об этих областях поможет гарантировать, что вам не будут звонить разгневанные специалисты по данным, кричащие на вас, что данные отсутствуют, неверны, неполны, непоследовательны…! Они будут полагаться на вашу работу, как электричество и водоснабжение. Просто нужно работать.
Удачи в разработке индивидуального решения! Это может быть очень весело (пока не 😳). Если вы предпочитаете пропустить веселье и сразу перейти к извлечению пользы из ваших данных, позвоните нам!
Нужна платформа и команда экспертов, чтобы начать работу с данными и аналитикой? Мы можем помочь! Если вы пытаетесь научиться реализовывать конвейеры данных, обратитесь к нашей команде экспертов по данным, чтобы обсудить ваши потребности.
Использование новых технологий, особенно если это означает, что ваша команда работает по-новому и незнакомо, может стать препятствием на пути к успеху. Это особенно верно в мире самообслуживания. Если вы хотите обсудить проверку концепции, пилотный проект, проект или любую другую работу, платформа Openbridge и команда экспертов по данным готовы помочь.
Посетите нас на www.openbridge.com, чтобы узнать, как мы помогаем другим компаниям с полностью автоматизированной пакетной обработкой без кода.
