Въпроси за интервю за инженер по данни с Python

Ходенето на интервюта може да е отнемащ време и изморителен процес, а техническите интервюта могат да бъдат още по-стресиращи! Този урок има за цел да ви подготви за някои често срещани въпроси, които ще срещнете по време на интервюто си с инженер по данни. Ще научите как да отговаряте на въпроси за бази данни, Python и SQL.

До края на този урок ще можете да:

Разберете често срещаните въпроси за интервю за инженери по данни
Разграничаване между релационни и нерелационни бази данни
Настройте бази данни с Python
Използвайте Python за запитване на данни

Безплатно изтегляне: Вземете примерна глава от Python Tricks:Книгата, която ви показва най-добрите практики на Python с прости примери, които можете да приложите незабавно, за да пишете по-красив + Pythonic код.

Да станеш инженер по данни

Ролята на инженеринга на данни може да бъде обширна и разнообразна. Ще трябва да имате работни познания за множество технологии и концепции. Инженерите на данни са гъвкави в мисленето си. В резултат на това те могат да владеят много теми, като бази данни, разработка на софтуер, DevOps и големи данни.

Какво прави инженерът по данни?

Като се има предвид разнообразния набор от умения, ролята на инженеринг на данни може да обхваща много различни длъжностни характеристики. Инженерът по данни може да отговаря за дизайна на база данни, дизайна на схеми и създаването на множество решения за бази данни. Тази работа може да включва и администратор на база данни.

Като инженер по данни , може да действате като мост между базата данни и екипите по наука за данни. В този случай вие ще носите отговорност и за почистването и подготовката на данните. Ако са включени големи данни, вашата работа е да излезете с ефективно решение за тези данни. Тази работа може да се припокрива с ролята на DevOps.

Ще трябва също да правите ефективни заявки за данни за отчитане и анализ. Може да се наложи да взаимодействате с множество бази данни или да пишете Съхранени процедури. За много решения като уебсайтове или услуги с висок трафик може да има повече от една база данни. В тези случаи инженерът по данни е отговорен за настройката на базите данни, поддържането им и прехвърлянето на данни между тях.

Как Python може да помогне на инженерите по данни?

Python е известен с това, че е швейцарският армейски нож на езиците за програмиране. Това е особено полезно в науката за данни, бекенд системите и скриптовете от страна на сървъра. Това е така, защото Python има силно въвеждане, прост синтаксис и изобилие от библиотеки на трети страни за използване. Pandas, SciPy, Tensorflow, SQLAlchemy и NumPy са едни от най-широко използваните библиотеки в производството в различни индустрии.

Най-важното е, че Python намалява времето за разработка, което означава по-малко разходи за компаниите. За инженер по данни повечето изпълнение на код е свързано с база данни, а не с процесора. Поради това има смисъл да се възползваме от простотата на Python, дори с цената на по-бавна производителност в сравнение с компилирани езици като C# и Java.

Отговаряне на въпроси за интервю за инженер по данни

Сега, когато знаете от какво може да се състои вашата роля, е време да научите как да отговаряте на някои въпроси за интервю за инженери по данни! Въпреки че има много място за покриване, ще видите практически примери за Python в целия урок, които да ви напътстват по пътя.

Въпроси относно релационни бази данни

Базите данни са един от най-важните компоненти в една система. Без тях не може да има държава и история. Въпреки че може да не сте считали дизайна на базата данни за приоритет, знайте, че той може да окаже значително влияние върху това колко бързо се зарежда страницата ви. През последните няколко години няколко големи корпорации въведоха няколко нови инструмента и техники:

NoSQL
Кеш бази данни
Графични бази данни
Поддръжка на NoSQL в SQL бази данни

Тези и други техники са измислени, за да се опитат да увеличат скоростта, с която базите данни обработват заявките. Вероятно ще трябва да говорите за тези концепции в интервюто си с инженер по данни, така че нека разгледаме някои въпроси!

В1:Релационни срещу нерелационни бази данни

релационна база данни е такъв, при който данните се съхраняват под формата на таблица. Всяка таблица имасхема , което е колоните и типовете, които записът трябва да има. Всяка схема трябва да има поне един първичен ключ, който уникално идентифицира този запис. С други думи, във вашата база данни няма дублиращи се редове. Освен това всяка таблица може да бъде свързана с други таблици с помощта на външни ключове.

Един важен аспект на релационните бази данни е, че промяната в схемата трябва да се приложи към всички записи. Това понякога може да причини счупвания и големи главоболия по време на миграции. Нерелационни бази данни се справяте с нещата по различен начин. Те по своята същност са без схема, което означава, че записите могат да бъдат записани с различни схеми и с различна, вложена структура. Записите все още могат да имат първични ключове, но промяната в схемата се извършва на база запис по запис.

Ще трябва да извършите тест за сравнение на скоростта въз основа на типа на изпълняваната функция. Можете да изберете INSERT , UPDATE , DELETE , или друга функция. Дизайнът на схемата, индексите, броят на агрегирания и броят на записите също ще повлияят на този анализ, така че ще трябва да тествате задълбочено. Ще научите повече за това как да направите това по-късно.

Базите данни се различават и помащабируемост . Нерелационна база данни може да бъде по-малко главоболие за разпространение. Това е така, защото колекция от свързани записи може лесно да се съхранява на конкретен възел. От друга страна, релационните бази данни изискват повече мисъл и обикновено използват система главен-подчинен.

Пример за SQLite

Сега, след като сте отговорили какво представляват релационните бази данни, е време да се поразровим в някои Python! SQLite е удобна база данни, която можете да използвате на вашата локална машина. Базата данни е един файл, което я прави идеална за прототипни цели. Първо импортирайте необходимата библиотека на Python и създайте нова база данни:

import sqlite3

db = sqlite3.connect(':memory:')  # Using an in-memory database
cur = db.cursor()

Вече сте свързани с база данни в паметта и вашият курсор е готов за работа.

След това ще създадете следните три таблици:

Клиент: Тази таблица ще съдържа първичен ключ, както и името и фамилията на клиента.
Артикули: Тази таблица ще съдържа първичен ключ, името на артикула и цената на артикула.
Закупени артикули :Тази таблица ще съдържа номер на поръчка, дата и цена. Той също така ще се свърже с първичните ключове в таблиците с артикули и клиенти.

Сега, когато имате представа как ще изглеждат вашите таблици, можете да продължите и да ги създадете:

cur.execute('''CREATE TABLE IF NOT EXISTS Customer (
                id integer PRIMARY KEY,
                firstname varchar(255),
                lastname varchar(255) )''')
cur.execute('''CREATE TABLE IF NOT EXISTS Item (
                id integer PRIMARY KEY,
                title varchar(255),
                price decimal )''')
cur.execute('''CREATE TABLE IF NOT EXISTS BoughtItem (
                ordernumber integer PRIMARY KEY,
                customerid integer,
                itemid integer,
                price decimal,
                CONSTRAINT customerid
                    FOREIGN KEY (customerid) REFERENCES Customer(id),
                CONSTRAINT itemid
                    FOREIGN KEY (itemid) REFERENCES Item(id) )''')

Предадохте заявка към cur.execute() за да създадете трите си таблици.

Последната стъпка е да попълните таблиците си с данни:

cur.execute('''INSERT INTO Customer(firstname, lastname)
               VALUES ('Bob', 'Adams'),
                      ('Amy', 'Smith'),
                      ('Rob', 'Bennet');''')
cur.execute('''INSERT INTO Item(title, price)
               VALUES ('USB', 10.2),
                      ('Mouse', 12.23),
                      ('Monitor', 199.99);''')
cur.execute('''INSERT INTO BoughtItem(customerid, itemid, price)
               VALUES (1, 1, 10.2),
                      (1, 2, 12.23),
                      (1, 3, 199.99),
                      (2, 3, 180.00),
                      (3, 2, 11.23);''') # Discounted price

Сега, когато във всяка таблица има няколко записа, можете да използвате тези данни, за да отговорите на още няколко въпроса за интервю за инженер по данни.

В2:SQL функции за агрегиране

Агрегиращи функции са тези, които извършват математическа операция върху набор от резултати. Някои примери включват AVG , COUNT , MIN , MAX и SUM . Често ще ви трябва GROUP BY и HAVING клаузи за допълване на тези агрегирания. Една полезна функция за агрегиране е AVG , който можете да използвате, за да изчислите средната стойност на даден набор от резултати:

>>>

>>> cur.execute('''SELECT itemid, AVG(price) FROM BoughtItem GROUP BY itemid''')
>>> print(cur.fetchall())
[(1, 10.2), (2, 11.73), (3, 189.995)]

Тук извличате средната цена за всеки от закупените артикули във вашата база данни. Можете да видите, че елементът е с itemid от 1 има средна цена от $10,20.

За да направите горния изход по-лесен за разбиране, можете да покажете името на елемента вместо itemid :

>>>

>>> cur.execute('''SELECT item.title, AVG(boughtitem.price) FROM BoughtItem as boughtitem
...             INNER JOIN Item as item on (item.id = boughtitem.itemid)
...             GROUP BY boughtitem.itemid''')
...
>>> print(cur.fetchall())
[('USB', 10.2), ('Mouse', 11.73), ('Monitor', 189.995)]

Сега виждате по-лесно, че артикулът със средна цена от $10,20 е USB .

Друго полезно агрегиране е SUM . Можете да използвате тази функция, за да покажете общата сума пари, която всеки клиент е похарчил:

>>>

>>> cur.execute('''SELECT customer.firstname, SUM(boughtitem.price) FROM BoughtItem as boughtitem
...             INNER JOIN Customer as customer on (customer.id = boughtitem.customerid)
...             GROUP BY customer.firstname''')
...
>>> print(cur.fetchall())
[('Amy', 180), ('Bob', 222.42000000000002), ('Rob', 11.23)]

Средно клиентът на име Ейми похарчи около $180, докато Роб само $11,23!

Ако интервюиращият ви харесва бази данни, тогава може да искате да прегледате вложените заявки, типовете на присъединяване и стъпките, които релационната база данни предприема, за да изпълни вашата заявка.

В3:Ускоряване на SQL заявките

Скоростта зависи от различни фактори, но най-вече се влияе от това колко от всяко от следните са налице:

Присъединява се
Агрегации
Обиколки
Записи

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

Скоростта също се влияе от това дали има или неиндекси присъстват в базата данни. Индексите са изключително важни и ви позволяват бързо да търсите в таблица и да намерите съответствие за някаква колона, посочена в заявката.

Индексите сортират записите с цената на по-голямо време за вмъкване, както и малко място за съхранение. Множество колони могат да бъдат комбинирани, за да се създаде един индекс. Например колоните date и price може да се комбинира, защото вашата заявка зависи от двете условия.

В4:Отстраняване на грешки в SQL заявки

Повечето бази данни включват EXPLAIN QUERY PLAN който описва стъпките, които базата данни предприема, за да изпълни заявката. За SQLite можете да активирате тази функционалност, като добавите EXPLAIN QUERY PLAN пред SELECT изявление:

>>>

>>> cur.execute('''EXPLAIN QUERY PLAN SELECT customer.firstname, item.title, 
...                item.price, boughtitem.price FROM BoughtItem as boughtitem
...                INNER JOIN Customer as customer on (customer.id = boughtitem.customerid)
...                INNER JOIN Item as item on (item.id = boughtitem.itemid)''')
...
>>> print(cur.fetchall())
[(4, 0, 0, 'SCAN TABLE BoughtItem AS boughtitem'), 
(6, 0, 0, 'SEARCH TABLE Customer AS customer USING INTEGER PRIMARY KEY (rowid=?)'), 
(9, 0, 0, 'SEARCH TABLE Item AS item USING INTEGER PRIMARY KEY (rowid=?)')]

Тази заявка се опитва да изброи първото име, заглавието на артикула, оригиналната цена и купената цена за всички закупени артикули.

Ето как изглежда самият план на заявката:

SCAN TABLE BoughtItem AS boughtitem
SEARCH TABLE Customer AS customer USING INTEGER PRIMARY KEY (rowid=?)
SEARCH TABLE Item AS item USING INTEGER PRIMARY KEY (rowid=?)

Обърнете внимание, че операторът fetch във вашия Python код връща само обяснението, но не и резултатите. Това е така, защото EXPLAIN QUERY PLAN не е предназначен за използване в производството.

Въпроси относно нерелационни бази данни

В предишния раздел изложихте разликите между релационни и нерелационни бази данни и използвахте SQLite с Python. Сега ще се съсредоточите върху NoSQL. Вашата цел е да подчертаете неговите силни страни, разлики и случаи на употреба.

Пример за MongoDB

Ще използвате същите данни, както преди, но този път вашата база данни ще бъде MongoDB. Тази база данни NoSQL е базирана на документи и се мащабира много добре. Първо, първо трябва да инсталирате необходимата библиотека на Python:

$ pip install pymongo

Може също да искате да инсталирате общността MongoDB Compass. Той включва локална IDE, която е идеална за визуализиране на базата данни. С него можете да виждате създадените записи, да създавате тригери и да действате като визуален администратор на базата данни.

Забележка: За да стартирате кода в този раздел, ще ви е необходим работещ сървър на база данни. За да научите повече за това как да го настроите, вижте Въведение в MongoDB и Python.

Ето как създавате базата данни и вмъквате някои данни:

import pymongo

client = pymongo.MongoClient("mongodb://localhost:27017/")

# Note: This database is not created until it is populated by some data
db = client["example_database"]

customers = db["customers"]
items = db["items"]

customers_data = [{ "firstname": "Bob", "lastname": "Adams" },
                  { "firstname": "Amy", "lastname": "Smith" },
                  { "firstname": "Rob", "lastname": "Bennet" },]
items_data = [{ "title": "USB", "price": 10.2 },
              { "title": "Mouse", "price": 12.23 },
              { "title": "Monitor", "price": 199.99 },]

customers.insert_many(customers_data)
items.insert_many(items_data)

Както може би сте забелязали, MongoDB съхранява записи от данни в колекции , които са еквивалентни на списък с речници в Python. На практика MongoDB съхранява BSON документи.

В5:Запитване на данни с MongoDB

Нека се опитаме да репликираме BoughtItem таблица първо, както направихте в SQL. За да направите това, трябва да добавите ново поле към клиент. Документацията на MongoDB посочва, че операторът за ключова дума set може да се използва за актуализиране на запис, без да се налага да се записват всички съществуващи полета:

# Just add "boughtitems" to the customer where the firstname is Bob
bob = customers.update_many(
        {"firstname": "Bob"},
        {
            "$set": {
                "boughtitems": [
                    {
                        "title": "USB",
                        "price": 10.2,
                        "currency": "EUR",
                        "notes": "Customer wants it delivered via FedEx",
                        "original_item_id": 1
                    }
                ]
            },
        }
    )

Забележете как сте добавили допълнителни полета към customer без изрично дефиниране на схемата предварително. Чудесно!

Всъщност можете да актуализирате друг клиент с леко променена схема:

amy = customers.update_many(
        {"firstname": "Amy"},
        {
            "$set": {
                "boughtitems":[
                    {
                        "title": "Monitor",
                        "price": 199.99,
                        "original_item_id": 3,
                        "discounted": False
                    }
                ]
            } ,
        }
    )
print(type(amy))  # pymongo.results.UpdateResult

Подобно на SQL, базираните на документи бази данни също позволяват да се изпълняват заявки и агрегирания. Въпреки това, функционалността може да се различава както синтактично, така и в основното изпълнение. Всъщност може би сте забелязали, че MongoDB запазва $ символ, за да посочите някаква команда или агрегиране на записите, като $group . Можете да научите повече за това поведение в официалните документи.

Можете да изпълнявате заявки точно както направихте в SQL. За да започнете, можете да създадете индекс:

>>>

>>> customers.create_index([("name", pymongo.DESCENDING)])

Това е по избор, но ускорява заявките, които изискват търсене на имена.

След това можете да извлечете имената на клиенти, сортирани във възходящ ред:

>>>

>>> items = customers.find().sort("name", pymongo.ASCENDING)

Можете също да преглеждате и отпечатвате закупените артикули:

>>>

>>> for item in items:
...     print(item.get('boughtitems'))    
...
None
[{'title': 'Monitor', 'price': 199.99, 'original_item_id': 3, 'discounted': False}]
[{'title': 'USB', 'price': 10.2, 'currency': 'EUR', 'notes': 'Customer wants it delivered via FedEx', 'original_item_id': 1}]

Можете дори да извлечете списък с уникални имена в базата данни:

>>>

>>> customers.distinct("firstname")
['Bob', 'Amy', 'Rob']

Сега, когато знаете имената на клиентите във вашата база данни, можете да създадете заявка за извличане на информация за тях:

>>>

>>> for i in customers.find({"$or": [{'firstname':'Bob'}, {'firstname':'Amy'}]}, 
...                                  {'firstname':1, 'boughtitems':1, '_id':0}):
...     print(i)
...
{'firstname': 'Bob', 'boughtitems': [{'title': 'USB', 'price': 10.2, 'currency': 'EUR', 'notes': 'Customer wants it delivered via FedEx', 'original_item_id': 1}]}
{'firstname': 'Amy', 'boughtitems': [{'title': 'Monitor', 'price': 199.99, 'original_item_id': 3, 'discounted': False}]}

Ето еквивалентната SQL заявка:

SELECT firstname, boughtitems FROM customers WHERE firstname LIKE ('Bob', 'Amy')

Имайте предвид, че въпреки че синтаксисът може да се различава само леко, има драстична разлика в начина, по който заявките се изпълняват под капака. Това може да се очаква поради различните структури на заявки и случаи на използване между SQL и NoSQL бази данни.

В6:NoSQL срещу SQL

Ако имате постоянно променяща се схема, като например финансова регулаторна информация, тогава NoSQL може да промени записите и информацията, свързана с гнездото. Представете си броя на присъединяванията, които трябва да направите в SQL, ако имате осем реда на влагане! Тази ситуация обаче е по-честа, отколкото си мислите.

Ами сега, ако искате да изготвите отчети, да извлечете информация за тези финансови данни и да направите заключения? В този случай трябва да изпълнявате сложни заявки и SQL обикновено е по-бърз в това отношение.

Забележка: SQL бази данни, особено PostgreSQL, също пуснаха функция, която позволява да се вмъкват JSON данни за заявка като част от запис. Въпреки че това може да съчетае най-доброто от двата свята, скоростта може да бъде проблем.

По-бързо е да се заявят неструктурирани данни от NoSQL база данни, отколкото да се заявят JSON полета от колона от тип JSON в PostgreSQL. Винаги можете да направите тест за сравнение на скоростта за окончателен отговор.

Независимо от това, тази функция може да намали необходимостта от допълнителна база данни. Понякога маринованите или сериализирани обекти се съхраняват в записи под формата на двоични типове и след това се десериализират при четене.

Скоростта обаче не е единственият показател. Също така ще искате да вземете предвид неща като транзакции, атомарност, издръжливост и мащабируемост. Транзакции са важни във финансовите приложения и такива функции имат предимство.

Тъй като има широк спектър от бази данни, всяка със свои собствени характеристики, работата на инженера по данни е да вземе информирано решение коя база данни да използва във всяко приложение. За повече информация можете да прочетете за свойствата на ACID, свързани с транзакциите на база данни.

Може също да бъдете попитани за какви други бази данни знаете в интервюто си с инженер по данни. Има няколко други подходящи бази данни, които се използват от много компании:

Еластично търсене е много ефективен при текстово търсене. Той използва своята базирана на документи база данни, за да създаде мощен инструмент за търсене.
Newt DB комбинира ZODB и PostgreSQL JSONB функцията, за да създаде удобна за Python NoSQL база данни.
InfluxDB се използва в приложения за времеви серии за съхраняване на събития.

Списъкът продължава, но това илюстрира как голямото разнообразие от налични бази данни се грижат за своята нишова индустрия.

Въпроси относно кеш бази данни

Кеш бази данни съхраняват често достъпни данни. Те живеят заедно с основните SQL и NoSQL бази данни. Целта им е да облекчат натоварването и да обслужват заявките по-бързо.

Пример за Redis

Обхванахте SQL и NoSQL бази данни за решения за дългосрочно съхранение, но какво да кажем за по-бързото, по-незабавно съхранение? Как може един инженер по данни да промени колко бързо се извличат данните от база данни?

Типичните уеб приложения извличат често използвани данни, като потребителски профил или име, много често. Ако всички данни се съдържат в една база данни, тогава броят напосещения сървърът на базата данни, който получава, ще бъде прекомерен и ненужен. Като такова е необходимо по-бързо и по-незабавно решение за съхранение.

Въпреки че това намалява натоварването на сървъра, това също създава две главоболия за инженера по данни, бекенд екипа и DevOps екипа. Първо, сега ще ви трябва някаква база данни, която има по-бързо време за четене от основната ви SQL или NoSQL база данни. Съдържанието на двете бази данни обаче в крайна сметка трябва да съвпада. (Добре дошли в проблема споследователността на състоянието между базите данни! Насладете се.)

Второто главоболие е, че DevOps вече трябва да се тревожи за мащабируемостта, излишъка и т.н. за новата база данни за кеш. В следващия раздел ще се потопите в проблеми като тези с помощта на Redis.

В7:Как да използвате кеш бази данни

Може да сте получили достатъчно информация от въведението, за да отговорите на този въпрос! Кеш база данни е бързо решение за съхранение, използвано за съхранение на краткотрайни, структурирани или неструктурирани данни. Тя може да бъде разделена и мащабирана според вашите нужди, но обикновено е много по-малка по размер от основната ви база данни. Поради това вашата кеш база данни може да се намира в паметта, което ви позволява да заобиколите необходимостта от четене от диск.

Забележка: Ако някога сте използвали речници в Python, Redis следва същата структура. Това е магазин ключ-стойност, където можете да SET и GET данни точно като dict на Python .

Когато постъпи заявка, първо проверявате кеш базата данни, след това основната база данни. По този начин можете да предотвратите достигането на ненужни и повтарящи се заявки до сървъра на основната база данни. Тъй като кеш базата данни има по-малко време за четене, вие също се възползвате от увеличение на производителността!

Можете да използвате pip, за да инсталирате необходимата библиотека:

$ pip install redis

Сега помислете за заявка за получаване на името на потребителя от неговия идентификационен номер:

import redis
from datetime import timedelta

# In a real web application, configuration is obtained from settings or utils
r = redis.Redis()

# Assume this is a getter handling a request
def get_name(request, *args, **kwargs):
    id = request.get('id')
    if id in r:
        return r.get(id)  # Assume that we have an {id: name} store
    else:
        # Get data from the main DB here, assume we already did it
        name = 'Bob'
        # Set the value in the cache database, with an expiration time
        r.setex(id, timedelta(minutes=60), value=name)
        return name

Този код проверява дали името е в Redis с помощта на id ключ. Ако не, тогава името се задава с време на изтичане, което използвате, тъй като кешът е краткотраен.

Сега, какво ще стане, ако интервюиращият ви попита какво не е наред с този код? Вашият отговор трябва да бъде, че няма обработка на изключения! Базите данни могат да имат много проблеми, като прекъснати връзки, така че винаги е добра идея да опитате да хванете тези изключения.

Въпроси относно моделите на проектиране и ETL концепциите

В големите приложения често ще използвате повече от един тип база данни. Всъщност е възможно да използвате PostgreSQL, MongoDB и Redis само в едно приложение! Един предизвикателен проблем е справянето с промените в състоянието между базите данни, което излага разработчика на проблеми с последователността. Помислете за следния сценарий:

Стойност в база данни №1 се актуализира.
Същата стойност в база данни №2 се запазва същото (не се актуализира).
Запитване се изпълнява в база данни №2.

Сега имате непоследователен и остарял резултат! Резултатите, върнати от втората база данни, няма да отразяват актуализираната стойност в първата. Това може да се случи с всякакви две бази данни, но е особено често срещано, когато основната база данни е NoSQL база данни и информацията се трансформира в SQL за целите на заявката.

Базите данни може да имат фонови работници за справяне с подобни проблеми. Тези работнициизвличати данни от една база данни,трансформиране го по някакъв начин изареди го в целевата база данни. Когато конвертирате от NoSQL база данни в SQL, процесът на извличане, трансформиране, зареждане (ETL) извършва следните стъпки:

Извлечение: Има тригер MongoDB всеки път, когато се създава, актуализира и т.н. Функцията за обратно извикване се извиква асинхронно в отделна нишка.
Трансформиране: Части от записа се извличат, нормализират и поставят в правилната структура от данни (или ред), за да бъдат вмъкнати в SQL.
Зареждане: SQL базата данни се актуализира на пакети или като един запис за запис с голям обем.

Този работен процес е доста често срещан във финансови, игрови и отчетни приложения. В тези случаи постоянно променящата се схема изисква NoSQL база данни, но отчитането, анализът и агрегирането изискват SQL база данни.

В8:ETL предизвикателства

В ETL има няколко предизвикателни концепции, включително следните:

Големи данни
Проблеми със състоянието
Асинхронни работници
Съвпадение на типа

Списъкът продължава! Въпреки това, тъй като стъпките в ETL процеса са добре дефинирани и логични, инженерите по данни и бекенд обикновено ще се тревожат повече за производителността и наличността, отколкото за внедряването.

Ако вашето приложение записва хиляди записи в секунда в MongoDB, тогава вашият ETL работник трябва да бъде в крак с трансформирането, зареждането и доставянето на данните на потребителя в исканата форма. Скоростта и латентността могат да се превърнат в проблем, така че тези работници обикновено са написани на бързи езици. Можете да използвате компилиран код за стъпката на трансформиране, за да ускорите нещата, тъй като тази част обикновено е свързана с процесора.

Забележка: Многократната обработка и разделянето на работниците са други решения, които може да искате да обмислите.

Ако имате работа с много функции, интензивни на процесора, тогава може да искате да проверите Numba. Тази библиотека компилира функции, за да ги направи по-бързи при изпълнение. Най-доброто от всичко е, че това се прилага лесно в Python, въпреки че има някои ограничения за това какви функции могат да се използват в тези компилирани функции.

В9:Модели на проектиране в големи данни

Представете си, че Amazon трябва да създаде система за препоръки да предложи подходящи продукти на потребителите. Екипът по наука за данни се нуждае от данни и много от тях! Те отиват при вас, инженерът по данни, и ви молят да създадете отделно хранилище за етапна база данни. Това е мястото, където те ще изчистят и трансформират данните.

Може да се шокирате, когато получите такова искане. Когато имате терабайти данни, ще ви трябват няколко машини, за да обработвате цялата тази информация. Функцията за агрегиране на база данни може да бъде много сложна операция. Как можете да правите заявки, да обобщавате и да използвате относително големи данни по ефективен начин?

Първоначално Apache въведе MapReduce, който следва карта, разбъркване, намаляване работния процес. Идеята е да се картографират различни данни на отделни машини, наричани още клъстери. След това можете да извършите работа върху данните, групирани по ключ, и накрая да обобщите данните в последния етап.

Този работен процес все още се използва днес, но напоследък избледнява в полза на Spark. Моделът на проектиране обаче формира основата на повечето работни потоци за големи данни и е изключително интригуваща концепция. Можете да прочетете повече за MapReduce в IBM Analytics.

В10:Общи аспекти на ETL процеса и работните потоци за големи данни

Може да си помислите, че това е доста странен въпрос, но това е просто проверка на вашите познания по компютърни науки, както и на цялостните ви познания и опит в дизайна.

И двата работни процеса следват Продуцент-Потребител модел. Работник (Продуцентът) произвежда данни от някакъв вид и ги извежда в конвейер. Този тръбопровод може да приеме много форми, включително мрежови съобщения и задействания. След като Производителят изведе данните, Потребителят ги консумира и използва. Тези работници обикновено работят по асинхронен начин и се изпълняват в отделни процеси.

Можете да оприличите производителя на стъпките за извличане и трансформиране на ETL процеса. По същия начин в големите данни, mapperът може да се разглежда като Производител, докато редукторът всъщност е Потребителят. Това разделяне на проблемите е изключително важно и ефективно при разработването и архитектурния дизайн на приложенията.

Заключение

Честито! Покрихте много теми и отговорихте на няколко въпроса за интервю за инженери по данни. Сега разбирате малко повече за многото различни шапки, които може да носи инженерът по данни, както и какви са вашите отговорности по отношение на базите данни, дизайна и работния процес.

Въоръжени с това знание, сега можете:

Използвайте Python със SQL, NoSQL и кеш бази данни
Използвайте Python в ETL и приложения за заявки
Plan projects ahead of time, keeping design and workflow in mind

While interview questions can be varied, you’ve been exposed to multiple topics and learned to think outside the box in many different areas of computer science. Now you’re ready to have an awesome interview!