Hogyan demokratizálta a Google BigQuery-je az adatelemzést. 2. rész

Szia Habr! Az új kurzusfolyamra való jelentkezés jelenleg nyitva van az OTUS-nál Adatmérnök. A tanfolyam kezdetére számítva továbbra is hasznos anyagokat osztunk meg veletek.

Olvassa el az első részt

Hogyan demokratizálta a Google BigQuery-je az adatelemzést. 2. rész

Adatkezelés

Az erős adatkezelés a Twitter Engineering alapelve. A BigQuery platformunkba való bevezetése során az adatfeltárásra, a hozzáférés-szabályozásra, a biztonságra és az adatvédelemre összpontosítunk.

Az adatok felfedezéséhez és kezeléséhez az adatelérési rétegünket kiterjesztettük erre DAL), hogy eszközöket biztosítson mind a helyszíni, mind a Google Cloud-adatokhoz, egyetlen felületet és API-t biztosítva felhasználóinknak. Mint Google Adatkatalógus az általános elérhetőség felé halad, beépítjük projektjeinkbe, hogy olyan funkciókat biztosítsunk a felhasználóknak, mint például az oszlopkeresés.

A BigQuery megkönnyíti az adatok megosztását és elérését, de az adatok kiszűrésének megelőzése érdekében ezt némileg szabályoznunk kellett. Az egyéb eszközök mellett két funkciót választottunk ki:

  • Domain korlátozott megosztás: Béta funkció, amely megakadályozza, hogy a felhasználók megosszák a BigQuery-adatkészleteket a Twitteren kívüli felhasználókkal.
  • VPC szolgáltatásvezérlők: Olyan vezérlő, amely megakadályozza az adatok kiszűrését, és megköveteli a felhasználóktól, hogy ismert IP-címtartományokból hozzáférjenek a BigQuery szolgáltatáshoz.

A biztonság érdekében hitelesítési, engedélyezési és auditálási (AAA) követelményeket vezettünk be az alábbiak szerint:

  • Hitelesítés: GCP-felhasználói fiókokat használtunk az ad hoc kérésekhez és szolgáltatásfiókokat az éles kérésekhez.
  • Engedélyezés: Minden adatkészletnek rendelkeznie kell tulajdonosi szolgáltatási fiókkal és olvasócsoporttal.
  • Auditálás: Exportáltuk a részletes lekérdezés-végrehajtási információkat tartalmazó BigQuery veremvezérlő naplókat egy BigQuery-adatkészletbe az egyszerű elemzés érdekében.

A Twitter-felhasználók személyes adatainak megfelelő kezelése érdekében regisztrálnunk kell az összes BigQuery adatkészletet, megjegyzésekkel kell ellátnunk a személyes adatokat, gondoskodnunk kell a megfelelő tárolásról, és törölnünk kell (le kell törölnünk) a felhasználók által törölt adatokat.

Megnéztük a Google-t Cloud Data Loss Prevention API, amely gépi tanulást használ az érzékeny adatok osztályozására és szerkesztésére, de a pontosság miatt az adatkészlet manuális megjegyzése mellett döntött. Terveink szerint az adatvesztés-megelőzési API-t fogjuk használni az egyéni megjegyzések kiegészítésére.

A Twitternél négy adatvédelmi kategóriát hoztunk létre a BigQuery adatkészleteihez, amelyek érzékenység szerint csökkenő sorrendben vannak felsorolva:

  • A rendkívül érzékeny adatkészletek szükség szerint rendelkezésre állnak a legkisebb kiváltság elve alapján. Minden adatkészletnek külön olvasócsoportja van, és a felhasználást egyéni fiókok szerint követjük nyomon.
  • A közepes érzékenységű adatkészletek (egyirányú álnevek sózott hash-t használva) nem tartalmaznak személyazonosításra alkalmas információkat (PII), és az alkalmazottak nagyobb csoportja számára hozzáférhetők. Ez jó egyensúlyt teremt az adatvédelmi aggályok és az adatszolgáltatás között. Ez lehetővé teszi az alkalmazottak számára, hogy elemzési feladatokat hajtsanak végre, például kiszámítsák a szolgáltatást használó felhasználók számát anélkül, hogy tudnák, kik a valódi felhasználók.
  • Alacsony érzékenységű adatkészletek minden felhasználóazonosító információval. Ez egy jó megközelítés adatvédelmi szempontból, de nem használható felhasználói szintű elemzéshez.
  • A nyilvános adatkészletek (a Twitteren kívül) minden Twitter-alkalmazott számára elérhetők.

Ami a naplózást illeti, ütemezett feladatokat használtunk a BigQuery-adatkészletek számbavételére és az adatelérési rétegben való regisztrálására (DAL), Twitter metaadattár. A felhasználók az adatkészleteket adatvédelmi információkkal látják el, és megadják a megőrzési időszakot is. Ami a tisztítást illeti, két lehetőség teljesítményét és költségét értékeljük: 1. Adatkészletek tisztítása a GCS-ben olyan eszközökkel, mint a Scalding, és betöltése a BigQuery-be; 2. BigQuery DML-utasítások használata. Valószínűleg a két módszer kombinációját fogjuk használni, hogy megfeleljünk a különböző csoportok és adatok követelményeinek.

A rendszer funkcionalitása

Mivel a BigQuery felügyelt szolgáltatás, nem kellett a Twitter SRE csapatát bevonni a rendszerkezelésbe vagy az asztali feladatokba. Könnyű volt több kapacitást biztosítani mind a tárolás, mind a számítástechnika számára. Megváltoztathatjuk a helyfoglalást, ha jegyet hozunk létre a Google támogatásával. Meghatároztuk a javítható területeket, például az önkiszolgáló helyek kiosztását és az irányítópult-fejlesztéseket a figyeléshez, és benyújtottuk ezeket a kéréseket a Google-nak.

Költség

Előzetes elemzésünk azt mutatta, hogy a BigQuery és a Presto lekérdezési költségei azonos szinten voltak. számára vettünk slotokat rögzített ár, hogy fizetés helyett stabil havi költség legyen igény szerint TB feldolgozott adatonként. Ez a döntés a felhasználók visszajelzésein is alapult, akik nem akartak minden kérés előtt a költségekre gondolni.

Az adatok BigQuery-ben való tárolása a GCS-költségek mellett költségekkel is járt. Az olyan eszközökhöz, mint a Scalding, adatkészletekre van szükség a GCS-ben, és a BigQuery eléréséhez ugyanazokat az adatkészleteket kellett betöltenünk BigQuery formátumba. Kondenzátor. Dolgozunk a BigQuery-adatkészletekhez való Scalding kapcsolat kialakításán, amely megszünteti az adatkészletek tárolásának szükségességét mind a GCS-ben, mind a BigQuery-ben.

Ritka, több tíz petabájtos lekérdezést igénylő esetek esetén úgy döntöttünk, hogy az adatkészletek tárolása a BigQuery szolgáltatásban nem volt költséghatékony, és a Presto segítségével közvetlenül hozzáfértünk az adatkészletekhez a GCS-ben. Ehhez a BigQuery külső adatforrásait vizsgáljuk.

Következő lépések

Az alfa-kiadás óta nagy érdeklődést tapasztaltunk a BigQuery iránt. További adatkészleteket és parancsokat adunk a BigQuery szolgáltatáshoz. Csatlakozókat fejlesztünk olyan adatelemző eszközökhöz, mint a Scalding a BigQuery tárhely olvasásához és írásához. Olyan eszközöket vizsgálunk, mint a Looker és az Apache Zeppelin, amellyel vállalati minőségi jelentéseket és feljegyzéseket hozhat létre BigQuery-adatkészletek használatával.

Együttműködésünk a Google-lal nagyon eredményes volt, és örömmel folytatjuk és fejlesztjük ezt a partnerséget. A Google-lal együttműködve megvalósítottuk a sajátunkat Partneri probléma nyomkövetőközvetlenül a Google-nak küldeni a lekérdezéseket. Ezek egy részét, például a BigQuery Parquet rakodót már implementálta a Google.

Íme néhány kiemelt fontosságú szolgáltatási kérésünk a Google számára:

  • Eszközök a kényelmes adatfogadáshoz és az LZO-Thrift formátum támogatásához.
  • Óránkénti tagolás
  • Hozzáférés-vezérlési fejlesztések, például táblázat-, sor- és oszlopszintű engedélyek.
  • BigQuery Külső adatforrások Hive Metastore integrációval és az LZO-Thrift formátum támogatásával.
  • Továbbfejlesztett adatkatalógus-integráció a BigQuery felhasználói felületén
  • Önkiszolgáló résidőkiosztáshoz és -felügyelethez.

Következtetés

Az adatelemzés, a vizualizáció és a gépi tanulás biztonságos módon történő demokratizálása kiemelt prioritás a Data Platform csapata számára. A Google BigQuery-t és a Data Studiot olyan eszközökként azonosítottuk, amelyek segíthetnek elérni ezt a célt, és tavaly a vállalat egészére kiadtuk a BigQuery Alpha-t.

A BigQuery lekérdezéseit egyszerűnek és hatékonynak találtuk. A Google eszközeit használtuk az egyszerű csővezetékek adatainak feldolgozására és átalakítására, de az összetett csővezetékekhez saját Airflow keretrendszert kellett felépíteni. Az adatkezelési területen a BigQuery hitelesítési, engedélyezési és auditálási szolgáltatásai megfelelnek az igényeinknek. A metaadatok kezeléséhez és az adatvédelem fenntartásához nagyobb rugalmasságra volt szükségünk, és saját rendszereinket kellett felépíteni. A BigQuery felügyelt szolgáltatásként könnyen használható volt. A lekérdezési költségek hasonlóak voltak a meglévő eszközökhöz. Az adatok BigQuery-ben való tárolása a GCS-költségek mellett költségekkel is jár.

Összességében a BigQuery jól működik az általános SQL elemzéshez. Nagy érdeklődést tapasztalunk a BigQuery iránt, és azon dolgozunk, hogy több adatkészletet migráljunk, több csapatot hozzunk létre, és több folyamatot építsünk ki a BigQuery segítségével. A Twitter számos olyan adatot használ, amelyekhez olyan eszközök kombinációjára lesz szükség, mint a Scalding, a Spark, a Presto és a Druid. Továbbra is tovább kívánjuk erősíteni adatelemző eszközeinket, és egyértelmű útmutatást kívánunk nyújtani felhasználóinknak kínálatunk legjobb felhasználásához.

Hála szavai

Szeretnék köszönetet mondani szerzőtársaimnak és csapattársaimnak, Anju Jha-nak és Will Pascuccinak nagyszerű együttműködésükért és kemény munkájukért a projekten. Szeretnék köszönetet mondani a Twitter és a Google több csapatának mérnökeinek és menedzsereinek is, akik segítettek nekünk, valamint a BigQuery-felhasználóknak a Twitteren, akik értékes visszajelzést adtak.

Ha érdekli ezekkel a problémákkal foglalkozni, tekintse meg oldalunkat megüresedett állások a Data Platform csapatában.

Adatminőség a DWH-ban – Adattárház-konzisztencia

Forrás: will.com

Hozzászólás