Я долгое время был поклонником фермы на стол, прежде чем это даже стали называть так. Качество продукции, которая провела минимальное время в транспортировке. Участие в местной экономике. Есть что-то утешительное в мысли, что то, что вы сейчас едите, пришло оттуда.

Недавние проблемы с цепочками поставок и трудовыми ресурсами привлекли внимание к тому, как продукты питания попадают к нам. Я до сих пор смотрю на пустые полки в супермаркете, где когда-то стояли мои любимые банки с маринованными огурцами.

Мы получаем вещи каждый день. В процессе участвует много людей, и с материалом происходит много всего. Средний потребитель просто никогда не перестанет думать об этом, пока это не станет проблемой.

То же самое верно и для данных. Но пользователи данных редко задумываются об этом, даже когда проблем с данными полно. Это просто не приходит в голову большинству пользователей данных. На самом деле мы не задумываемся о том, как данные попадают к нам и что происходит по пути.

Цепочка поставок данных

Мы можем представить цепочку поставок, когда подумаем о том, как данные достигают конечного пользователя. Возьмем, к примеру, то, как практикующие аналитики получают данные, чтобы творить чудеса.

В простейшем случае данные собираются в поле. Аналитики-практики получают его, загружают в инструмент и выполняют некоторую обработку данных. Они идут с анализом. Это эквивалент данных для передачи данных с фермы на стол.

В большинстве современных сценариев данные собираются, преобразуются с помощью таких вещей, как бизнес-правила, и загружаются в хранилище данных. Затем кто-то извлекает подмножество данных из этого хранилища данных и выполняет дополнительное преобразование. Специалисты-аналитики получают его, обрабатывают, а затем наконец приступают к анализу. Аналитики-практики могут даже сами выполнять некоторые из более ранних задач.

В зависимости от ситуации, это может занять несколько путей. Но это всегда некоторая комбинация извлечения, преобразования и загрузки, и часто несколько раз с несколькими участниками.

Когда мы сталкиваемся с проблемами данных, мы склонны сбрасывать их все в одну большую корзину «проблемы качества данных». Но то, как возникают эти проблемы, имеет разные последствия. Каждый из этих шагов может привести к проблемам с данными, поэтому существует множество возможностей для того, чтобы что-то пойти не так.

И стоит отметить, что это сильно упрощено. Для каждого источника данных может быть несколько параллельных путей с несколькими участниками на каждом пути. Это быстро превращается в сложную сеть людей и процессов, которые выполняют всевозможные действия с данными.

Но ждать! Есть еще!

Я провел много времени в компаниях по обработке данных в дни моей работы, и у меня есть компании по обработке данных в качестве клиентов. Они часто получают данные из сотен, если не тысяч, разных мест. Все должно быть в одной структуре и иметь одни и те же определения. Создатели данных часто обещают соблюдать эти стандарты. Тем не менее, единообразие является огромным предположением и редко когда-либо верно на практике, даже когда эти обещания даются.

Рассмотрим агентства кредитной информации (CRA), которые, возможно, чаще называют кредитными бюро. CRA управляет гигантской базой данных всей истории платежей по потребительским кредитам. Когда вы подаете заявку на кредит, кредитор получает ваш кредитный отчет от CRA, чтобы увидеть, как вы оплачиваете свои другие обязательства.

Тысячи и тысячи кредиторов вносят данные в CRA. Все они делают это по одному и тому же стандарту, по крайней мере, теоретически. Тем не менее, это не вариант «поставил и забыл» при любом натяжении воображения, часто ни по чьей вине. У каждого кредитора своя политика и разные методы ведения бизнеса, не говоря уже об управлении данными и методах обеспечения качества.

Чтобы добавить к этому, у каждого кредитора есть свои собственные уровни нескольких ETL, прежде чем он отправит данные в CRA. Эти слои часто имеют несколько параллельных потоков. Таким образом, существует несколько уровней данных и потоков для каждого из тысяч участников. Затем CRA добавляет свои собственные наборы слоев и потоков только для их обработки.

Все это только для одного хранилища данных! Каждый из этих слоев и потоков имеет множество возможностей для дефектов, то есть проблем с данными. Конечно, даже самые лучшие усилия не гарантируют полного устранения ошибок. Но что еще более важно, постоянно появляются новые вещи, потому что изменения происходят независимо от того, хотите вы этого или нет. Политика меняется. Бизнес-стратегии и операции меняются. Правила меняются. Люди меняются. Мир собирается мириться и продолжает мириться.

Все тщательно обработано, чтобы создать гигантский беспорядок

Когда пользователи данных, в том числе аналитики-практики, делают с данными то, для чего их на самом деле наняли, они делают это со всем, что сейчас в них встроено. Имеющиеся данные прошли через бесконечные слои и потоки сбора, обработки, соединения, разборки и всего остального. Весь процесс крайне непрозрачен. В дата-кухне много поваров. И хотя в еде часто желательны замысловатые, сложные слои вкусов, они создают уродливый беспорядок в данных. Не исключено, что это создает больше проблем, чем решает в процессе.

Каждый раз, когда у меня появляется возможность, я настаиваю на том, чтобы у данных была своя специальная функция, как в этой статье здесь. Добавьте это к причинам, по которым использование функции, основной обязанностью которой является что-то еще, не решает проблему качества данных. Возможно, вы не занимаетесь агрегатором данных, но это все равно монументальное предприятие. Если функции технологии или аналитики берут на себя ответственность за данные, то вы по своей природе не преуспеете в данных. Существует гораздо больше, чем кажется на первый взгляд, если вам нужны эти данные — например, банки с маринованными огурцами — чтобы они были там, когда и как вам это нужно.

Подпишитесь на DDIntel Здесь.

Присоединяйтесь к нашей сети здесь: https://datadriveninvestor.com/collaborate