sql >> Databáze >  >> RDS >> Database

Otázky k rozhovoru s datovým inženýrem s Pythonem

Chodit na pohovory může být časově náročný a únavný proces a technické pohovory mohou být ještě více stresující! Cílem tohoto kurzu je připravit vás na některé běžné otázky, se kterými se setkáte během pohovoru s datovým inženýrem. Dozvíte se, jak odpovídat na otázky o databázích, Pythonu a SQL.

Na konci tohoto výukového programu budete schopni:

  • Porozumět běžným otázkám při pohovorech s datovými inženýry
  • Rozlišujte mezi relačními a nerelačními databázemi
  • Nastavte databáze pomocí Pythonu
  • Pro dotazování na data použijte Python

Bezplatné stažení: Získejte ukázkovou kapitolu z Python Tricks:The Book, která vám ukáže osvědčené postupy Pythonu s jednoduchými příklady, které můžete okamžitě použít k psaní krásnějšího + Pythonic kódu.


Stát se datovým inženýrem

Role datového inženýrství může být rozsáhlá a různorodá. Budete potřebovat pracovní znalosti z mnoha technologií a konceptů. Datoví inženýři jsou flexibilní ve svém myšlení. Díky tomu mohou být zběhlí v mnoha tématech, jako jsou databáze, vývoj softwaru, DevOps a velká data.


Co dělá datový inženýr?

Vzhledem ke své rozmanité sadě dovedností může role datového inženýrství zahrnovat mnoho různých popisů práce. Datový inženýr může být zodpovědný za návrh databáze, návrh schématu a vytváření více databázových řešení. Tato práce může také zahrnovat správce databáze.

Jako datový inženýr můžete fungovat jako most mezi databází a týmy datové vědy. V takovém případě budete zodpovědní za čištění a přípravu dat. Pokud se jedná o velká data, pak je vaším úkolem přijít s efektivním řešením pro tato data. Tato práce se může překrývat s rolí DevOps.

Budete také muset provádět efektivní dotazy na data pro vytváření sestav a analýzy. Možná budete muset pracovat s více databázemi nebo psát uložené procedury. U mnoha řešení, jako jsou weby nebo služby s vysokou návštěvností, může existovat více než jedna databáze. V těchto případech je datový inženýr odpovědný za nastavení databází, jejich údržbu a přenos dat mezi nimi.



Jak může Python pomoci datovým inženýrům?

Python je známý jako švýcarský armádní nůž programovacích jazyků. Je to užitečné zejména ve vědě o datech, backendových systémech a skriptování na straně serveru. Je to proto, že Python má silné psaní, jednoduchou syntaxi a množství knihoven třetích stran, které lze použít. Pandas, SciPy, Tensorflow, SQLAlchemy a NumPy jsou některé z nejrozšířenějších knihoven ve výrobě v různých odvětvích.

A co je nejdůležitější, Python zkracuje dobu vývoje, což znamená méně nákladů pro společnosti. Pro datového inženýra je většina provádění kódu vázána na databázi, nikoli na CPU. Z tohoto důvodu má smysl využít jednoduchost Pythonu, a to i za cenu nižšího výkonu ve srovnání s kompilovanými jazyky, jako jsou C# a Java.




Odpovědi na otázky k rozhovoru s datovým inženýrem

Nyní, když víte, v čem by vaše role mohla spočívat, je čas naučit se odpovídat na některé otázky pohovoru s datovými inženýry! I když je toho hodně, co je potřeba probrat, v tomto tutoriálu uvidíte praktické příklady Pythonu, které vás povedou.



Otázky týkající se relačních databází

Databáze jsou jednou z nejdůležitějších součástí systému. Bez nich nemůže existovat stát ani historie. I když jste možná nepovažovali návrh databáze za prioritu, vězte, že může mít významný dopad na to, jak rychle se vaše stránka načítá. V posledních několika letech zavedlo několik velkých korporací několik nových nástrojů a technik:

  • NoSQL
  • Ukládání databází do mezipaměti
  • Databáze grafů
  • Podpora NoSQL v databázích SQL

Tyto a další techniky byly vynalezeny, aby se pokusily zvýšit rychlost, s jakou databáze zpracovávají požadavky. Pravděpodobně si o těchto konceptech budete muset promluvit při pohovoru s datovým inženýrem, takže si pojďme projít pár otázek!


Q1:Relační vs nerelační databáze

Relační databáze je taková, kde jsou data uložena ve formě tabulky. Každá tabulka má schéma , což jsou sloupce a typy, které záznam musí mít. Každé schéma musí mít alespoň jeden primární klíč, který jedinečně identifikuje daný záznam. Jinými slovy, ve vaší databázi nejsou žádné duplicitní řádky. Navíc lze každou tabulku propojit s jinými tabulkami pomocí cizích klíčů.

Jedním z důležitých aspektů relačních databází je, že změna schématu musí být aplikována na všechny záznamy. To může někdy způsobit zlomení a velké bolesti hlavy během migrace. Nerelační databáze řešit věci jiným způsobem. Jsou ze své podstaty bez schémat, což znamená, že záznamy lze ukládat s různými schématy as odlišnou, vnořenou strukturou. Záznamy mohou mít stále primární klíče, ale změna schématu se provádí po jednotlivých položkách.

Budete muset provést test porovnání rychlosti na základě typu prováděné funkce. Můžete zvolit INSERT , UPDATE , DELETE , nebo jinou funkci. Návrh schématu, indexy, počet agregací a počet záznamů také ovlivní tuto analýzu, takže budete muset důkladně testovat. Více o tom, jak to udělat, se dozvíte později.

Databáze se také liší škálovatelností . Distribuce nerelační databáze může být méně bolestivá. Je to proto, že kolekci souvisejících záznamů lze snadno uložit na konkrétní uzel. Na druhou stranu relační databáze vyžadují více přemýšlení a obvykle využívají systém master-slave.



Příklad SQLite

Nyní, když jste si odpověděli, co jsou to relační databáze, je čas se ponořit do nějakého Pythonu! SQLite je pohodlná databáze, kterou můžete použít na svém místním počítači. Databáze je jeden soubor, díky čemuž je ideální pro účely prototypování. Nejprve importujte požadovanou knihovnu Pythonu a vytvořte novou databázi:

import sqlite3

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

Nyní jste připojeni k databázi v paměti a máte objekt kurzoru připravený k použití.

Dále vytvoříte následující tři tabulky:

  1. Zákazník: Tato tabulka bude obsahovat primární klíč a také jméno a příjmení zákazníka.
  2. Položky: Tato tabulka bude obsahovat primární klíč, název položky a cenu položky.
  3. Zakoupené položky :Tato tabulka bude obsahovat číslo objednávky, datum a cenu. Připojí se také k primárním klíčům v tabulkách Items a Customer.

Nyní, když máte představu, jak budou vaše tabulky vypadat, můžete pokračovat a vytvořit je:

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) )''')

Předali jste dotaz do cur.execute() vytvořit své tři tabulky.

Posledním krokem je naplnění tabulek daty:

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 

Nyní, když je v každé tabulce několik záznamů, můžete tato data použít k zodpovězení několika dalších otázek z rozhovoru s datovým inženýrem.



Q2:SQL agregační funkce

Funkce agregace jsou ty, které provádějí matematickou operaci se sadou výsledků. Některé příklady zahrnují AVG , COUNT , MIN , MAX a SUM . Často budete potřebovat GROUP BY a HAVING doložky k doplnění těchto agregací. Jednou z užitečných agregačních funkcí je AVG , který můžete použít k výpočtu střední hodnoty dané sady výsledků:

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

Zde jste získali průměrnou cenu pro každou z položek zakoupených ve vaší databázi. Můžete vidět, že položka má itemid z 1 má průměrnou cenu 10,20 $.

Aby byl výše uvedený výstup srozumitelnější, můžete místo itemid zobrazit název položky :

>>>
>>> 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)]

Nyní snadněji uvidíte, že položka s průměrnou cenou 10,20 $ je USB .

Další užitečnou agregací je SUM . Tuto funkci můžete použít k zobrazení celkové částky peněz, kterou každý zákazník utratil:

>>>
>>> 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)]

V průměru zákazník jménem Amy utratil asi 180 USD, zatímco Rob pouze 11,23 USD!

Pokud má váš tazatel rád databáze, možná budete chtít oprášit vnořené dotazy, typy spojení a kroky, které relační databáze provádí při provádění vašeho dotazu.



Q3:Zrychlení SQL dotazů

Rychlost závisí na různých faktorech, ale většinou je ovlivněna tím, kolik z následujících je přítomno:

  • Připojí se
  • Agregace
  • Procházení
  • Záznamy

Čím větší počet spojení, tím vyšší složitost a větší počet průchodů v tabulkách. Vícenásobné spojení je poměrně drahé na několik tisíc záznamů zahrnujících několik tabulek, protože databáze také potřebuje ukládat mezivýsledky do mezipaměti! V tomto okamžiku můžete začít přemýšlet o tom, jak zvětšit velikost paměti.

Rychlost je také ovlivněna tím, zda existují či neexistují indexy přítomný v databázi. Indexy jsou extrémně důležité a umožňují vám rychle prohledávat tabulku a najít shodu pro některý sloupec zadaný v dotazu.

Indexy třídí záznamy za cenu delší doby vkládání a také určitého úložiště. Více sloupců lze kombinovat a vytvořit jeden index. Například sloupce date a price může být kombinováno, protože váš dotaz závisí na obou podmínkách.



Q4:Ladění SQL dotazů

Většina databází obsahuje EXPLAIN QUERY PLAN , která popisuje kroky, které databáze provádí při provádění dotazu. Pro SQLite můžete tuto funkci povolit přidáním EXPLAIN QUERY PLAN před SELECT prohlášení:

>>>
>>> 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=?)')]

Tento dotaz se pokusí vypsat křestní jméno, název položky, původní cenu a kupní cenu pro všechny zakoupené položky.

Takto vypadá samotný plán dotazů:

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=?)

Všimněte si, že příkaz fetch ve vašem kódu Pythonu vrací pouze vysvětlení, ale ne výsledky. Je to proto, že EXPLAIN QUERY PLAN není určeno k použití ve výrobě.




Otázky týkající se nerelačních databází

V předchozí části jste nastínili rozdíly mezi relačními a nerelačními databázemi a použili SQLite s Pythonem. Nyní se zaměříte na NoSQL. Vaším cílem je zdůraznit jeho silné stránky, rozdíly a případy použití.


Příklad MongoDB

Budete používat stejná data jako dříve, ale tentokrát bude vaší databází MongoDB. Tato databáze NoSQL je založena na dokumentech a velmi dobře se škáluje. Nejprve musíte nainstalovat požadovanou knihovnu Pythonu:

$ pip install pymongo

Možná budete chtít nainstalovat komunitu MongoDB Compass. Zahrnuje lokální IDE, které je ideální pro vizualizaci databáze. S ním můžete vidět vytvořené záznamy, vytvářet spouštěče a působit jako vizuální správce databáze.

Poznámka: Ke spuštění kódu v této části budete potřebovat spuštěný databázový server. Chcete-li se dozvědět více o tom, jak jej nastavit, podívejte se na Úvod do MongoDB a Pythonu.

Zde je návod, jak vytvořit databázi a vložit některá data:

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)

Jak jste si mohli všimnout, MongoDB ukládá datové záznamy do kolekcí , které jsou ekvivalentem seznamu slovníků v Pythonu. V praxi MongoDB ukládá dokumenty BSON.



O5:Dotazování na data pomocí MongoDB

Zkusme replikovat BoughtItem nejprve tabulku, jako jste to udělali v SQL. Chcete-li to provést, musíte k zákazníkovi připojit nové pole. Dokumentace MongoDB uvádí, že operátor klíčových slov set lze použít k aktualizaci záznamu bez nutnosti vypisovat všechna existující pole:

# 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
                    }
                ]
            },
        }
    )

Všimněte si, jak jste přidali další pole do customer aniž byste předem explicitně definovali schéma. Šikovné!

Ve skutečnosti můžete aktualizovat jiného zákazníka s mírně pozměněným schématem:

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

Podobně jako SQL umožňují databáze založené na dokumentech také provádění dotazů a agregací. Funkčnost se však může lišit jak syntakticky, tak v základním provedení. Ve skutečnosti jste si možná všimli, že MongoDB si vyhrazuje $ znak k určení nějakého příkazu nebo agregace na záznamech, jako je $group . Více o tomto chování se můžete dozvědět v oficiálních dokumentech.

Dotazy můžete provádět stejně jako v SQL. Chcete-li začít, můžete vytvořit index:

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

Toto je volitelné, ale urychluje to dotazy, které vyžadují vyhledávání jmen.

Poté můžete načíst jména zákazníků seřazená ve vzestupném pořadí:

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

Zakoupené položky můžete také iterovat a vytisknout:

>>>
>>> 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}]

Můžete dokonce získat seznam jedinečných jmen v databázi:

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

Nyní, když znáte jména zákazníků ve své databázi, můžete vytvořit dotaz a získat o nich informace:

>>>
>>> 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}]}

Zde je ekvivalentní SQL dotaz:

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

Všimněte si, že i když se syntaxe může lišit jen nepatrně, existuje drastický rozdíl ve způsobu provádění dotazů pod kapotou. To se dá očekávat kvůli různým strukturám dotazů a případům použití mezi databázemi SQL a NoSQL.



Otázka 6:NoSQL vs SQL

Pokud máte neustále se měnící schéma, jako jsou finanční regulační informace, pak NoSQL může upravit záznamy a vnořit související informace. Představte si, kolik spojení byste museli provést v SQL, kdybyste měli osm objednávek vnoření! Tato situace je však častější, než byste si mysleli.

Co když teď chcete spouštět zprávy, extrahovat informace o těchto finančních datech a vyvozovat závěry? V tomto případě musíte spouštět složité dotazy a SQL bývá v tomto ohledu rychlejší.

Poznámka: SQL databáze, zejména PostgreSQL, také uvolnily funkci, která umožňuje vkládat dotazovatelná data JSON jako součást záznamu. I když to může kombinovat to nejlepší z obou světů, rychlost může být znepokojivá.

Je rychlejší dotazovat se na nestrukturovaná data z databáze NoSQL než dotazovat pole JSON ze sloupce typu JSON v PostgreSQL. Pro definitivní odpověď můžete vždy provést test porovnání rychlosti.

Tato funkce však může snížit potřebu další databáze. Někdy jsou nakládané nebo serializované objekty uloženy v záznamech ve formě binárních typů a poté jsou při čtení de-serializovány.

Rychlost však není jediným měřítkem. Budete také chtít vzít v úvahu věci, jako jsou transakce, atomičnost, trvanlivost a škálovatelnost. Transakce jsou důležité ve finančních aplikacích a takové funkce mají přednost.

Vzhledem k tomu, že existuje široká škála databází, z nichž každá má své vlastní funkce, je úkolem datového inženýra učinit informované rozhodnutí o tom, kterou databázi v každé aplikaci použít. Pro více informací si můžete přečíst o vlastnostech ACID souvisejících s databázovými transakcemi.

Při pohovoru s datovým inženýrem můžete být také dotázáni, jaké další databáze znáte. Existuje několik dalších relevantních databází, které používá mnoho společností:

  • Elastické vyhledávání je vysoce efektivní v textovém vyhledávání. Využívá svou databázi založenou na dokumentech k vytvoření výkonného vyhledávacího nástroje.
  • Newt DB kombinuje funkci ZODB a PostgreSQL JSONB k vytvoření databáze NoSQL přátelské k Pythonu.
  • InfluxDB se používá v aplikacích časových řad k ukládání událostí.

Seznam pokračuje, ale to ilustruje, jak široká škála dostupných databází uspokojuje jejich specializované odvětví.




Otázky k databázím mezipaměti

Ukládat do mezipaměti databáze uchovávat často používaná data. Žijí vedle hlavních SQL a NoSQL databází. Jejich cílem je snížit zatížení a rychleji obsluhovat požadavky.


Příklad Redis

Pokryli jste databáze SQL a NoSQL pro řešení dlouhodobého úložiště, ale co rychlejší a bezprostřednější úložiště? Jak může datový inženýr změnit rychlost načítání dat z databáze?

Typické webové aplikace získávají běžně používaná data, jako je profil nebo jméno uživatele, velmi často. Pokud jsou všechna data obsažena v jedné databázi, pak jde o počet hledání databázový server dostane bude přehnané a zbytečné. Proto je potřeba rychlejší a bezprostřednější řešení úložiště.

I když to snižuje zatížení serveru, přináší to také dvě bolesti hlavy pro datového inženýra, backendový tým a tým DevOps. Nejprve budete potřebovat nějakou databázi, která má rychlejší čtení než vaše hlavní databáze SQL nebo NoSQL. Obsah obou databází se však nakonec musí shodovat. (Vítejte v problému konzistence stavu mezi databázemi! Užijte si to.)

Druhým problémem je, že DevOps se nyní musí starat o škálovatelnost, redundanci a tak dále pro novou databázi mezipaměti. V další části se s pomocí Redis ponoříte do podobných problémů.



Otázka 7:Jak používat databáze mezipaměti

Možná jste z úvodu získali dostatek informací, abyste na tuto otázku odpověděli! databáze mezipaměti je řešení rychlého úložiště používané k ukládání krátkodobých, strukturovaných nebo nestrukturovaných dat. Může být rozdělena a škálována podle vašich potřeb, ale obvykle je mnohem menší než vaše hlavní databáze. Z tohoto důvodu může být vaše databáze mezipaměti umístěna v paměti, což vám umožní obejít nutnost čtení z disku.

Poznámka: Pokud jste někdy používali slovníky v Pythonu, Redis má stejnou strukturu. Je to úložiště párů klíč–hodnota, kde můžete SET a GET data stejně jako dict Pythonu .

Když přijde požadavek, nejprve zkontrolujete databázi mezipaměti a poté hlavní databázi. Tímto způsobem můžete zabránit tomu, aby se na server hlavní databáze nedostaly žádné zbytečné a opakující se požadavky. Protože databáze mezipaměti má kratší dobu čtení, můžete také těžit ze zvýšení výkonu!

K instalaci požadované knihovny můžete použít pip:

$ pip install redis

Nyní zvažte žádost o získání jména uživatele z jeho ID:

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

Tento kód zkontroluje, zda je jméno v Redis pomocí id klíč. Pokud ne, pak je název nastaven s dobou vypršení platnosti, kterou používáte, protože mezipaměť je krátkodobá.

Co když se vás tazatel zeptá, co je na tomto kódu špatného? Vaše odpověď by měla být, že neexistuje žádná výjimka! Databáze mohou mít mnoho problémů, například přerušená připojení, takže je vždy dobré pokusit se tyto výjimky zachytit.




Otázky týkající se návrhových vzorů a konceptů ETL

Ve velkých aplikacích budete často používat více než jeden typ databáze. Ve skutečnosti je možné používat PostgreSQL, MongoDB a Redis v jediné aplikaci! Jedním z náročných problémů je řešení změn stavu mezi databázemi, což vystavuje vývojáře problémům konzistence. Zvažte následující scénář:

  1. Hodnota v databázi #1 je aktualizován.
  2. Stejná hodnota v databázi č. 2 je zachována stejná (neaktualizovaná).
  3. Dotaz běží na databázi #2.

Nyní máte nekonzistentní a zastaralý výsledek! Výsledky vrácené z druhé databáze nebudou odrážet aktualizovanou hodnotu v první. To se může stát u libovolných dvou databází, ale je to zvláště běžné, když je hlavní databází NoSQL databáze a informace jsou transformovány do SQL pro účely dotazů.

Databáze mohou mít pracovníky na pozadí, aby se s takovými problémy vypořádali. Tito pracovníci extrahují data z jedné databáze, transformovat jej nějakým způsobem a načíst do cílové databáze. Když převádíte z databáze NoSQL na databázi SQL, proces Extrahování, transformace, načtení (ETL) zahrnuje následující kroky:

  1. Výpis: Při každém vytvoření, aktualizaci a tak dále existuje spouštěč MongoDB. Funkce zpětného volání se volá asynchronně v samostatném vláknu.
  2. Transformace: Části záznamu jsou extrahovány, normalizovány a vloženy do správné datové struktury (nebo řádku), aby mohly být vloženy do SQL.
  3. Načíst: Databáze SQL se aktualizuje v dávkách nebo jako jeden záznam pro velké objemy zápisů.

Tento pracovní postup je zcela běžný ve finančních, herních a reportovacích aplikacích. V těchto případech neustále se měnící schéma vyžaduje databázi NoSQL, ale vytváření sestav, analýzy a agregace vyžadují databázi SQL.


O8:Výzvy ETL

V ETL existuje několik náročných konceptů, včetně následujících:

  • Velká data
  • Problémy se stavem
  • Asynchronní pracovníci
  • Shoda typu

Seznam pokračuje! Protože jsou však kroky v procesu ETL dobře definované a logické, datoví a backendoví inženýři se budou obvykle starat spíše o výkon a dostupnost než o implementaci.

Pokud vaše aplikace zapisuje do MongoDB tisíce záznamů za sekundu, pak váš ETL pracovník musí držet krok s transformací, načítáním a doručováním dat uživateli v požadované podobě. Rychlost a latence se mohou stát problémem, takže tito pracovníci jsou obvykle psáni v rychlých jazycích. Pro urychlení můžete použít kompilovaný kód pro krok transformace, protože tato část je obvykle vázána na CPU.

Poznámka: Vícenásobné zpracování a oddělení pracovníků jsou další řešení, která byste mohli chtít zvážit.

Pokud máte co do činění s mnoha funkcemi náročnými na CPU, možná budete chtít vyzkoušet Numba. Tato knihovna kompiluje funkce, aby byly rychlejší při provádění. Nejlepší ze všeho je, že to lze snadno implementovat v Pythonu, i když existují určitá omezení ohledně toho, jaké funkce lze v těchto kompilovaných funkcích použít.



Otázka 9:Návrhové vzory ve velkých datech

Představte si, že Amazon potřebuje vytvořit systém doporučení navrhnout uživatelům vhodné produkty. Tým datové vědy potřebuje data a hodně jich! Jdou k vám, datovému inženýrovi, a požádají vás o vytvoření samostatného skladu přípravné databáze. Tam vyčistí a transformují data.

Obdržení takové žádosti vás možná šokuje. Když máte terabajty dat, budete potřebovat více počítačů, které budou všechny tyto informace zpracovávat. Funkce agregace databáze může být velmi složitá operace. Jak můžete dotazovat, agregovat a využívat relativně velká data efektivním způsobem?

Apache původně představil MapReduce, který následuje po mapování, zamíchání, zmenšení Pracovní postup. Cílem je mapovat různá data na samostatných strojích, nazývaných také clustery. Poté můžete pracovat na datech seskupených podle klíče a nakonec je v konečné fázi agregovat.

Tento pracovní postup se dodnes používá, ale v poslední době se vytrácí ve prospěch Sparku. Návrhový vzor však tvoří základ většiny pracovních toků velkých dat a je velmi zajímavým konceptem. Více o MapReduce si můžete přečíst na IBM Analytics.



O10:Společné aspekty procesu ETL a pracovních toků velkých dat

Můžete si myslet, že je to poněkud zvláštní otázka, ale je to pouze kontrola vašich znalostí informatiky a také vašich celkových znalostí a zkušeností v oblasti designu.

Oba pracovní postupy se řídí Producentem-spotřebitelem vzor. Pracovník (výrobce) vytváří data určitého druhu a odesílá je do potrubí. Tento kanál může mít mnoho podob, včetně síťových zpráv a spouštěčů. Poté, co výrobce odešle data, spotřebitel je spotřebovává a využívá. Tito pracovníci obvykle pracují asynchronním způsobem a jsou prováděni v samostatných procesech.

Producenta můžete přirovnat k krokům extraktu a transformace procesu ETL. Podobně ve velkých datech mapovač lze považovat za výrobce, zatímco reduktor je fakticky Spotřebitel. Toto oddělení zájmů je extrémně důležité a efektivní při vývoji a návrhu architektury aplikací.




Závěr

Gratulujeme! Pokryli jste spoustu věcí a odpověděli jste na několik otázek týkajících se rozhovoru s datovým inženýrem. Nyní chápete trochu více o mnoha různých kloboucích, které může datový inženýr nosit, a také o tom, jaké jsou vaše povinnosti s ohledem na databáze, návrh a pracovní postup.

Vyzbrojeni těmito znalostmi nyní můžete:

  • Používejte Python s databázemi SQL, NoSQL a mezipamětí
  • Používejte Python v ETL a dotazovacích aplikacích
  • Plánujte projekty s předstihem, mějte na paměti design a pracovní postup

I když otázky na pohovoru mohou být různé, byli jste vystaveni mnoha tématům a naučili jste se přemýšlet mimo rámec v mnoha různých oblastech informatiky. Nyní jste připraveni na úžasný rozhovor!



  1. Mohu požádat Postgresql, aby ignoroval chyby v transakci

  2. mySQL převést varchar na datum

  3. Jak přidám vlastní omezení CHECK do tabulky MySQL?

  4. Vytvořte databázový diagram v MySQL Workbench