Основні тести перевірки даних

У своїй робочій ролі я часто працюю з наборами даних інших людей, неспеціалісти приносять мені клінічні дані, і я допомагаю їм узагальнити їх та провести статистичні тести.

Проблема, яку я маю, полягає в тому, що набори даних, які мені привозять, майже завжди пронизані друкарськими помилками, невідповідностями та всіма іншими проблемами. Мені цікаво знати, чи мають інші люди стандартні тести, які вони роблять, щоб спробувати перевірити будь-які набори даних, які входять.

Раніше я малював гістограми кожної змінної просто для того, щоб подивитися, але тепер я розумію, що існує багато жахливих помилок, які можуть пережити цей тест. Наприклад, у мене був день повторного набору даних про заходи, коли для деяких осіб повторний захід був ідентичним у Час 2, як і в Часі 1. Це згодом виявилося невірним, як можна було очікувати. Інший набір даних мав людину, яка перейшла від дуже сильно невпорядкованого (представленого високим балом) до безпроблемного, представленого 0 на всій площині. Це просто неможливо, хоча я не могла це довести остаточно.

То які основні тести я можу запустити на кожному наборі даних, щоб переконатися, що вони не мають помилок друку і не містять неможливих значень?

Спасибі заздалегідь!

Це допомагає зрозуміти, як були записані дані.

Дозвольте мені поділитися історією . Колись, давно, безліч наборів даних зберігалися лише у вицвілому твердому копії. У ті темні дні я уклав контракти з організацією (великої родоводу та розміру; багато хто з вас, мабуть, володіє її запасами), щоб комп'ютеризувати приблизно 10 ^ 5 записів даних моніторингу навколишнього середовища на одному з виробничих заводів. Для цього я особисто позначив полицю лабораторних звітів (щоб показати, де дані), створив бланки для введення даних та уклав контракт з тимчасовим агентством для грамотнихпрацівники вводять дані у бланки. (Так, вам довелося доплачувати людям, які могли читати.) Через цінність та чутливість даних я проводив цей процес паралельно з двома працівниками одночасно (які зазвичай змінювались з дня на день). Минуло пару тижнів. Я написав програмне забезпечення для порівняння двох наборів записів, систематично визначаючи та виправляючи всі виявлені помилки.

Хлопчик були помилки! Що може піти не так? Хороший спосіб описати та виміряти помилки - це рівень базового запису, який у цій ситуації був описом єдиного аналітичного результату (концентрація якоїсь хімічної речовини, часто) для певного зразка, отриманого в заданій точці моніторингу на задана дата. Порівнюючи два набори даних, я виявив:

• Помилки пропуску : один набір даних буде включати запис, інший - ні. Зазвичай це трапляється через те, що або (а) рядок або два будуть пропускатися внизу сторінки, або (b) вся сторінка буде пропущена.

• Явні помилки упущення, які були дійсно помилками введення даних. Запис ідентифікується за назвою точки моніторингу, датою та "аналітом" (зазвичай це хімічна назва). Якщо будь-яка з них має типографічну помилку, вона не буде відповідати іншим записам, з якими вона пов'язана. Насправді правильний запис зникає і з’являється неправильний запис.

• Підроблене дублювання . Одні і ті ж результати можуть з’являтися в декількох джерелах, переписуватися кілька разів і, здається, є справжніми повторними заходами, коли їх немає. Дублікати легко визначити, але рішення про те, чи є вони помилковими, залежить від того, чи слід дублікати відображатись у наборі даних. Іноді ти просто не можеш знати.

• Відверті помилки введення даних . "Хороших" легко впіймати, оскільки вони змінюють тип дати: використовуючи букву "O" для цифри "0", наприклад, перетворює число в не число. Інші добрі помилки змінюють значення настільки, що їх можна легко виявити за допомогою статистичних тестів. (В одному випадку провідну цифру в "1000,010 мг / кг" було відрізано, залишивши значення 10. Це величезна зміна, коли ви говорите про концентрацію пестицидів!) Погані помилки важко зрозуміти, оскільки вони змінюються значення в значення, яке відповідає (на зразок) решті даних, наприклад, набравши "80" для "50". (Ця помилка постійно відбувається з програмним забезпеченням OCR.)

• Транспозиції . Правильні значення можуть бути введені, але пов'язані з неправильними клавішами запису. Це підступно, оскільки глобальні статистичні характеристики набору даних можуть залишатися незмінними, але між групами можуть бути створені помилкові відмінності. Можливо, лише такий механізм, як подвійний запис, навіть здатний виявити ці помилки.

Після того, як ви знаєте про ці помилки і знаєте, або маєте теорію, як вони виникають, ви можете написати сценарії, щоб перенести ваші набори даних про можливу наявність таких помилок і позначити їх для подальшої уваги. Ви не завжди можете їх вирішити, але принаймні ви можете включити поле "коментар" або "прапор якості" для супроводу даних протягом їх подальшого аналізу.

З цього часу я приділяв увагу питанням якості даних і мав набагато більше можливостей зробити всебічну перевірку великих статистичних наборів даних. Жоден не ідеальний; всі вони виграють від перевірки якості. Деякі з принципів, які я розробляв протягом багатьох років для цього, включають

1. По можливості створюйте надмірність в процедурах введення даних та транскрипції даних: контрольні суми, підсумки, повторні записи: що-небудь для підтримки автоматичних внутрішніх перевірок узгодженості.

2. Якщо можливо, створіть та використовуйте іншу базу даних, яка описує, як повинні виглядати дані: тобто читаються на комп'ютері метадані. Наприклад, в експерименті з наркотиками ви можете заздалегідь знати, що кожного пацієнта побачать тричі. Це дає змогу створити базу даних з усіма правильними записами та їх ідентифікаторами зі значеннями, які просто очікують на заповнення. Заповніть їх даними, а потім перевірити наявність дублікатів, упущень та несподіваних даних.

3. Завжди нормалізуйте свої дані (зокрема, переведіть їх у принаймні четверту нормальну форму ), незалежно від того, як ви плануєте відформатувати набір даних для аналізу. Це змушує вас створювати таблиці кожної концептуально окремої сутності, яку ви моделюєте. (У екологічному випадку це включатиме таблиці моніторингових місць, зразки, хімічні речовини (властивості, типові діапазони тощо), тести цих зразків (тест зазвичай охоплює набір хімікатів) та індивідуальні результати цих випробувань. Тим самим ви створюєте багато ефективних перевірок якості та послідовності даних та визначаєте багато потенційно відсутніх або повторюваних чи непослідовних значень.

   Це зусилля (яке вимагає хороших навичок обробки даних, але прямолінійне) є надзвичайно ефективним. Якщо ви прагнете проаналізувати великі або складні набори даних і не маєте належних робочих знань щодо реляційних баз даних та їх теорії, додайте це до свого списку речей, які слід дізнатися якнайшвидше. Це виплатить дивіденди протягом усієї вашої кар’єри.

4. Завжди виконуйте стільки "дурних" перевірок, скільки можливо . Це автоматизована перевірка очевидних речей, таких, що дати впадають у їх очікувані періоди, кількість пацієнтів (або хімікатів чи будь-чого іншого) завжди підсумовується правильно, що значення завжди розумні (наприклад, рН повинен бути від 0 до 14 і, можливо, в набагато більш вузький діапазон для, скажімо, показників рН крові) тощо. Тут саме допомога може бути найбільшою допомогою: статистик може безстрашно задавати дурні питання експертам і використовувати відповіді для перевірки даних.

Зрозуміло можна сказати набагато більше - тема варта книги - але цього має бути достатньо для стимулювання ідей.

@whuber робить чудові пропозиції; Я лише додав би це: Сюжети, сюжети, сюжети, сюжети. Розсіювачі, гістограми, вікна, лінійки, теплові карти та все, що ви можете придумати. Звичайно, як ви виявили, є помилки, які не будуть помітні на будь-яких сюжетах, але вони є гарним місцем для початку. Просто переконайтеся, що вам зрозуміло, як ваше програмне забезпечення обробляє відсутні дані тощо.

Залежно від контексту можна проявити творчість. Одне, що мені подобається робити З багатовимірними даними - це підходити до якоїсь факторної моделі / ймовірнісної PCA (те, що зробить багаторазову імпутацію за відсутніми даними) і подивитися на показники якомога більшої кількості компонентів. Точки даних, які набирають високий бал за менш важливих компонентів / факторів, часто є перешкодами, яких ви можете не бачити інакше.

Основні речі, які я схильний перевіряти:

1. Тип змінної - щоб побачити, що число числове, а не коефіцієнт / символ (може вказувати на певну проблему з введеними даними)
2. Послідовний рівень значень - щоб побачити, що змінна з іменем "t1" знову не знайшла себе з іменем "t1" або "t 1"
3. Аутлієри - бачите, що діапазон вартості має сенс. (ви отримали значення артеріального тиску 0? або мінус?). Тут ми іноді виявляємо, що хтось закодував -5 як відсутність значення чи щось подібне.
4. Лінійні обмеження. Я цього не використовую, але деякі вважають, що вони хочуть здійснити реструктуризацію залежностей деяких стовпців (стовпці A, B повинні додавати до C, або щось подібне). Для цього ви можете ознайомитись з пакетом дедукторекцій (я зустрічав спікера Марка ван дер Лоо на останній конференції useR - і був дуже вражений його пакетом)
5. занадто мало випадкових випадків Іноді значення повинні бути округлені до деяких значень або урізані в якийсь момент. Такі речі часто більш чіткі в сюжетних розкидах.
6. Пропущені значення - переконайтесь, що відсутня не пов’язана з якоюсь іншою змінною (відсутня навмання). Але я не маю права робити це.
7. Порожні рядки або рядки з переважно відсутніми значеннями. Вони повинні бути (як правило) знайдені та пропущені.

Чудове запитання BTW - сподіваюся прочитати досвід інших людей з цього питання.

Коли у вас є заходи протягом часу (" поздовжні дані "), часто корисно перевірити градієнти , а також граничні розподіли. Цей градієнт можна обчислити в різних масштабах. Більш загально, ви можете робити змістовні перетворення своїх даних (фур'є, вейвлет) і перевіряти розподіл маргіналів перетворених даних.

Кілька я завжди переживаю:

1. Чи має бути кількість записів там? Наприклад, якщо ви витягнули свої дані з іншого джерела або його підмножини, коли хтось видаляє дані, ваші номери виглядають розумними. Ви могли б подумати, що це буде прикрито, але ви ... здивуєтеся.
2. Чи є всі ваші змінні? Чи мають значення ці змінні значення? Наприклад, якщо змінна так / ні / відсутня кодована "1,2,3" - що це означає?
3. Де ваші відсутні значення? Чи є деякі змінні, які здаються перевантаженими відсутніми відомостями? Чи є певні предмети з масовою кількістю відсутніх значень.

Це перші кроки, які я проходжу, щоб переконатися, що набір даних навіть готовий до чогось подібного до дослідницького аналізу даних. Просто сідаючи, блукаючи над даними, які деякі збираються "Це здається ... правильно?"

Я б застосував метод вибіркової вибірки для кожного стовпця (він дає номер відсікання, де ви можете провести межу між високою та низькою якістю), для цього є онлайн-калькулятор.