Helló, Habr! Jelenleg az OTUS új kurzusára jelentkezést hirdetünk. . A kurzus kezdetére készülve folytatjuk hasznos anyagok megosztását veletek.
Adatkezelés
Az erős adatkezelés (Strong Data Governance) a Twitter Engineering alapelve. Mivel a BigQuery-t integráljuk platformunkba, az adatok felfedezésére, a hozzáférés ellenőrzésére, a biztonságra és a magánélet védelmére összpontosítunk.
Az adatok felfedezésére és kezelésére kiterjesztettük az adat-hozzáférési szintünket (Data Access Layer — ), hogy eszközöket biztosítsunk mind a helyi adatok, mind a Google Cloud adatok kezelésére, egyetlen interfészt és API-t biztosítva felhasználóink számára. Ahogy a Google a nyilvánosság felé halad, integrálni fogjuk a projektjeinkbe, hogy olyan funkciókat nyújtsunk a felhasználóknak, mint a mezők keresése.
A BigQuery lehetővé teszi az adatok egyszerű megosztását és hozzáférését, de bizonyos mértékig kontrollálnunk kellett ezt, hogy megakadályozzuk az adatok kiszivárgását. Más eszközök mellett két funkciót választottunk:
- : béta funkció, amely megakadályozza, hogy a felhasználók BigQuery adatállományokat osszanak meg a Twitteren kívüli felhasználókkal.
- : egy vezérlőelem, amely megakadályozza az adatok kiszivárgását, és megköveteli a felhasználóktól, hogy ismert IP-címtartományokból férjenek hozzá a BigQuery-hez.
Az alábbiak szerint valósítottuk meg az autentikációs, engedélyezési és auditálási (AAA) követelményeket a biztonság érdekében:
- Autentikáció: GCP felhasználói fiókokat használtunk ad hoc lekérdezésekhez és szolgáltatói fiókokat munkahelyi lekérdezésekhez.
- Engedélyezés: megköveteltük, hogy minden adatállománynak legyen egy szolgáltatói fiók tulajdonosa és egy olvasói csoportja.
- Auditálás: a BigQuery stackdriver naplóit, amelyek részletes információkat tartalmaztak a lekérdezések végrehajtásáról, exportáltuk BigQuery adatállományba az egyszerűbb elemzés érdekében.
A Twitter felhasználók személyes adatainak megfelelő kezelése érdekében minden BigQuery adatállományt regisztrálnunk kell, annotálnunk kell a személyes adatokat, biztosítanunk kell a megfelelő tárolást, és törölnünk (ki kell takarítani) azokat az adatokat, amelyeket a felhasználók töröltek.
Megvizsgáltuk a Google , amely gépi tanulást alkalmaz az érzékeny adatok osztályozására és szerkesztésére, de a pontosság miatt a kézi adatok annotálása mellett döntöttünk. Tervezünk Data Loss Prevention API-t használni a felhasználói annotációk kiegészítésére.
A Twitteren négy adatvédelmi kategóriát hoztunk létre a BigQuery adatbázisok számára, amelyek érzékenység szerint csökkenő sorrendben itt vannak felsorolva:
- A Magas érzékenységű adatok csak szükség szerint érhetők el a legkisebb privilégium elve alapján. Minden adatbázis külön olvasói csoporttal rendelkezik, és nyomon követjük az egyes fiókok használatát.
- A Közepes érzékenységű adatok (egyetlen irányú álnév sózott hash-eléssel) nem tartalmaznak személyes azonosításra alkalmas információt (Personally Identifiable Information - PII), és egy nagyobb alkalmazotti csoport számára elérhetők. Ez jó egyensúlyt teremt az adatvédelmi és az adatok hasznossági megfontolások között. Ez lehetővé teszi, hogy az alkalmazottak olyan elemzési feladatokat végezzenek, mint például megtudni, hogy hány felhasználó használta a funkciót anélkül, hogy tudnák, kik a valós felhasználók.
- Az Alacsony érzékenységű adatok mindazon információt tartalmazzák, amely azonosítani képes a felhasználót. Ez jó megközelítés az adatvédelem szempontjából, de nem használható felhasználói szintű analízisekhez.
- A Nyilvános adatok (a Twitteren kívül kiadottak) minden Twitter alkalmazott számára elérhetők.
A nyilvántartás vonatkozásában ütemezett feladatokat használtunk a BigQuery adatbázisok felsorolására és azok nyilvántartásba vételére a Data Access Layerben (), a Twitter metaadatainak tárolója. A felhasználók annotálni fogják az adatbázisokat az adatvédelmi információkkal, és megjelölik a tárolási időtartamot. A tisztítással kapcsolatban a teljesítményt és a költséget két lehetőség értékelése érdekében nézzük: 1. Adatbázisok tisztítása GCS-ben olyan eszközökkel, mint a Scalding, és ezek BigQuery-be való betöltése; 2. BigQuery DML parancsok használata. Valószínűleg mindkét módszer kombinációját fogjuk használni a különböző csoportok és adatok igényeinek kielégítése érdekében.
A rendszer funkcionalitása
Mivel a BigQuery egy kezelés alatti szolgáltatás, nem volt szükség a Twitter SRE csapatának bevonására a rendszerek kezelésébe vagy a ügyeleti feladatok ellátásába. Könnyen biztosítható volt a nagy tárolási és számítási kapacitás. A slotok fenntartását Google támogatási jegyek létrehozásával módosíthattuk. Megállapítottuk, hogy lehetne javítani, például az önkiszolgálás a slotok elosztásában és a felügyeleti panel fejlesztése terén, és ezeket a kéréseket átadtuk a Google-nak.
Ár
Előzetes elemzésünk azt mutatta, hogy a BigQuery és a Presto kérésének költsége azonos szinten volt. Slotokat vásároltunk igény szerint A BigQuery-ban tárolt adatok költségei adódnak a GCS költségeihez. Az olyan eszközök, mint a Scalding, megkövetelik a készletek meglétét GCS-ben, miközben a BigQuery-hoz való hozzáféréshez ugyanazokat a készleteket BigQuery formátumban kellett feltöltenünk.
Capacitor. A ritka esetek, amelyek nem gyakori tízpetabájtos lekérdezéseket igényeltek, alapján úgy döntöttünk, hogy az adatállományok BigQuery-ban való tárolása nem gazdaságos, és a Presto-t használtuk közvetlen hozzáféréshez a GCS készletekhez. Ennek érdekében a BigQuery Külső Adatforrásokra figyelünk.
A BigQuery iránti nagy érdeklődés tapasztalható az alfa verzió kiadása óta. Továbbá több adatállományt és csapatot adunk hozzá a BigQuery-hoz. Konektorokat fejlesztünk adat-elemző eszközök, például a Scalding számára, hogy olvashassanak és írjanak a BigQuery tárolójába. Olyan eszközöket fontolgatunk, mint a Looker és az Apache Zeppelin, az üzleti jelentések készítésére a BigQuery adatállományok felhasználásával.
Következő lépések
A Google-lal való együttműködés nagyon eredményes volt, és örömmel folytatjuk és fejlesztjük ezt a partnerséget. Dolgoztunk a Google-lal, hogy bevezethessük saját
Partner Issue Trackerünket, , hogy közvetlenül küldje el a lekérdezéseket a Google-nak. Néhány közülük, mint például a BigQuery Parquet betöltő, már megvalósult a Google által.
Íme néhány kiemelt funkciókérelmünk a Google számára:
- Eszközök az adatok könnyű fogadásához és LZO-Thrift formátum támogatása.
- Óránkénti szegmentáció
- Hozzáférés-ellenőrzési fejlesztések, például táblaszintű, sor- és oszlopszintű engedélyek.
- : Tábla particionálás és csoportosítás, Összefésülési viselkedés, KMS titkosítás, Címkék és Tagok valamint integrálva és támogatva van a Hive Metastore az LZO-Thrift formátumhoz.
- Javított adat katalógus integráció a BigQuery felhasználói felületén
- Önki szolgáltatások a slotok elosztására és figyelésére.
Zárás
Az adatelemzés, vizualizáció és gépi tanulás demokratizálása biztonságos módon kiemelt prioritást élvez a Data Platform csapata számára. Azonosítottuk a Google BigQuery-t és a Data Studio-t, mint olyan eszközöket, amelyek segíthetnek céljaink elérésében, és tavaly kiadottuk a BigQuery Alpha-t a teljes vállalat számára.
Feltűnt, hogy a BigQuery-ben végzett lekérdezések egyszerűek és hatékonyak voltak. Az adatok fogadásához és átalakításához a Google eszközeit használtuk egyszerű munkafolyamatokhoz, de bonyolult munkafolyamatokhoz saját Airflow infrastruktúrát kellett létrehoznunk. Az adatkezelési szolgáltatások a BigQuery-ben az autentikáció, engedélyezés és auditálás terén kielégítik igényeinket. A metadatok kezelése és a magánélet védelme érdekében nagyobb rugalmasságra volt szükségünk, így saját rendszereket kellett létrehoznunk. A BigQuery, mint felügyelt szolgáltatás, könnyen használható volt. A lekérdezések költségei a meglévő eszközökhöz hasonlóak voltak. A BigQuery adatainak tárolása a GCS költségein kívül további kiadásokat jelentett.
Összességében a BigQuery jól működik a általános SQL elemzéshez. Nagy érdeklődést tapasztalunk a BigQuery iránt, és azon dolgozunk, hogy több adatállományt áthelyezzünk, több csapatot vonjunk be, és több munkafolyamatot készítsünk a BigQuery-vel. A Twitter különböző adatokat használ, amelyekhez eszközök kombinációja, például Scalding, Spark, Presto és Druid szükséges. Folytatni kívánjuk az adat elemző eszközeink fejlesztését, és világos útmutatásokat nyújtunk felhasználóinknak arról, hogyan használják a legjobban ajánlatainkat.
Hála szavai
Szeretnék köszönetet mondani a társaimnak és a csapatomnak, Anju Djanak és Will Pascuccinak, a kiváló együttműködésükért és kemény munkájukért ebben a projektben. Szeretném megköszönni a Twitter és a Google több csapatának mérnökeit és menedzsereit is, akik segítettek nekünk és a Twitter BigQuery felhasználóinak, értékes visszajelzésükkel.
Ha érdeklik ezek a feladatok, nézze meg a Data Platform csapatban.
Forrás: habr.com
