LinkedIn open sources, un plan de contrôle pour les maisons au bord du lac / Blogs / Perficient

LinkedIn sources ouvertes beaucoup de code. Kafkabien sûr, mais aussi Samza et Voldemoor et un tas d’outils Hadoop comme DonnéesFu et Gobelin. Les projets open source ont tendance à être créés par des développeurs pour résoudre des problèmes d’ingénierie alors que les produits commerciaux… Quoi qu’il en soit, LinkedIn propose une nouvelle offre de données open source appelée Journée portes ouvertesqui est présenté comme un plan de contrôle pour les tables dans les Lakehouses de données ouvertes. Beaucoup de entreprises offre lacs de données. Il semblait que LinkedIn utilisait Cloudera‘ avec Lakehouse de données « ouvertes ». Cela est logique car Linked in utilise beaucoup de Hadoop en interne et Hadoop demande beaucoup de travail. Les avions de contrôle demandent beaucoup de travail et je voulais approfondir un peu pour voir où je pourrais vouloir utiliser cela.

Plan de données

LinkedIn utilise stockage d’objets blob et HDFS pour leur stockage de données. HDFS est spécifique à Hadoop mais la plupart ont interagi avec Stockage Blob Azure plus récemment et peut même penser qu’il s’agit d’une technologie spécifique à Microsoft. Les Binary Large Objects (BLOBS) sont un mécanisme typique de stockage de données non structurées. Le système de fichiers distribués Hadoop (HDFS) divise les fichiers en morceaux et distribue le stockage sur plusieurs (généralement trois) nœuds.

Ils utilisent plusieurs formats de table open source différents pour accéder aux données. Mauvais a été open source par Uber en 2017 et est désormais considéré comme le premier data lakehouse. J’ai ajouté cette mise en garde car lorsque Hudi est sorti pour la première fois, il s’appelait un « lac de données incrémentiel ». Le terme « data lakehouse » n’est pas apparu avant trois ans jusqu’à ce que Databricks invente le terme. L’offre Databricks dans l’espace est Lac Delta. Apache Iceberg est un format de table qui permet des analyses très performantes sur des tables volumineuses à l’aide de SQL. OpenHouse propose un comparaison des fonctionnalités des trois formats, c’est assez complet. J’ai l’impression qu’ils aiment Hudi là-bas même s’il s’agit d’un magasin Iceberg bien connu.

Pour le calcul, ils utilisent Étincelle, Trino et Considérable. En règle générale, Trino sera aussi performant que possible lors de l’exécution de SQL sur des ensembles de données volumineux. Spark est un framework d’exécution distribué plus général qui lui permet de faire plus que simplement SQL, comme l’apprentissage automatique, le streaming et le traitement des données. J’ai vu des opinions différentes, mais elles utilisent généralement des ensembles de données plus petits. Le microbenchmarking est vraiment très difficile et vous devez prendre les résultats avec des pincettes. Flink est idéal pour les applications basées sur les événements, les analyses de flux et de lots et les pipelines de données. La plupart des comparaisons entre Flink et Spark se concentrent sur leur prise en charge respective du streaming natif par rapport au micro-batching.

Avion de contrôle

L’avenir du Big Data

Avec quelques conseils, vous pouvez créer une plateforme de données adaptée aux besoins de votre organisation et tirer le meilleur parti de votre capital de données.

Obtenez le guide

Les plans de contrôle offrent une sécurité, une gouvernance, une découverte et une observabilité unifiées. Les options courantes pour un plan de contrôle capable de gérer les différentes couches et formats de stockage et les options de calcul répertoriées ci-dessus sont…

Rien.

Si vous êtes une boutique Databricks ou une boutique Snowflake, vous n’avez pas ce problème. Tu as Catalogue Unity ou vous exploitez le fournisseur de cloud. Il s’agit d’un excellent exemple de projets open source représentant les problèmes des développeurs. Je suis anxieux rien qu’en écrivant ceci. Les résultats étaient exactement ceux que l’on pourrait imaginer. Chacun fait de son mieux pour faire le travail dont il a besoin avec les compétences et les outils dont il dispose. L’équipe LinkedIn a commencé avec une abstraction de base, à savoir les tableaux. Ils ont essentiellement extrait la couche la plus basse, les blobs et les fichiers, et les ont appelés tables. C’est juste car c’est ainsi que presque tous les utilisateurs les appelleraient.

Le tableau est la seule abstraction d’API disponible pour les utilisateurs finaux. Ces tables sont stockées dans un espace de noms de stockage protégé accessible uniquement par le plan de contrôle. Cela donne au plan de contrôle un contrôle total sur la mise en œuvre, y compris la sécurité, la haute disponibilité, la reprise après incident, les quotas, l’organisation, etc. Cela permet également de faire respecter les normes de l’entreprise. Un grand pouvoir implique de grandes responsabilités, c’est pourquoi il existe désormais une seule équipe responsable de l’optimisation, du regroupement, du partitionnement, de l’aspiration, de la collecte des déchets, etc. Votre maison ; vos règles. Cela ouvre la possibilité d’interfaces opiniâtres.

API RESTful

OpenHouse fournit un service de table RESTful avec lequel les utilisateurs peuvent interagir en utilisant la sémantique déclarative. Les utilisateurs définissent les schémas, les tables et les métadonnées associées de manière déclarative à l’aide de ce service de table RESTful. C’est le travail d’OpenHouse de concilier l’état observé des Tables avec l’état souhaité exprimé par l’utilisateur. Je vais extraire un exemple de code de leur Blog d’ingénierie LinkedIn sur OpenHouse en raison de la solidité, je pense, de la mise en œuvre de l’UX.

-- create table in openhouse
CREATE TABLE openhouse.db.table (id bigint COMMENT 'unique id', data string);


-- manipulate table metadata
ALTER TABLE openhouse.db.table_partitioned SET POLICY ( RETENTION=30d );
ALTER TABLE openhouse.db.table ALTER COLUMN measurement TYPE double;
ALTER TABLE openhouse.db.table SET TBLPROPERTIES ('key1' = 'value1');


-- manipulate table data
INSERT INTO openhouse.db.table VALUES ('1', 'a');


-- share table
ALTER TABLE openhouse.db.table_partitioned SET POLICY ( SHARING=true );
GRANT SELECT ON TABLE openhouse.db.table TO user;

Encore une fois, si vous utilisez une seule application commerciale avec un plan de données et de contrôle intégré, cela semble parfaitement normal. Et c’est tout l’intérêt. Revenez en arrière et examinez toutes les différentes technologies qu’ils prennent en charge. Selon ce même article, il faut deux à trois semaines pour intégrer une nouvelle table sans OpenHouse. OpenHouse est en libre-service.

Conclusion

Nous adoptons généralement deux approches pour les systèmes de données afin de maintenir la fiabilité, la stabilité et la bonne gouvernance. Une approche est la normalisation. Si vous utilisez un seul outil qui résout tous ces problèmes de manière native, vous aurez la gorge serrée. Il s’agit d’une approche centrée sur la gestion. Cela fonctionne bien dans le sens où tous les développeurs sont également mécontents. L’autre approche consiste à utiliser le meilleur outil pour le travail, mais à être prêt à payer le prix élevé de la possession. Il s’agit d’une solution très élégante qui place la barre très haute pour ceux qui pensent que la deuxième option offre en fin de compte la meilleure valeur commerciale. Il s’agissait d’une initiative pluriannuelle fondée sur des étapes progressives et un soutien de la direction et c’est ce qu’il faut, de manière réaliste, pour obtenir ce niveau d’impact technique.