Seit letztem Jahr organisiert unser Unternehmen Hackathons. Der erste derartige Wettbewerb war sehr erfolgreich, wir haben darüber geschrieben . Der zweite Hackathon fand im Februar 2019 statt und verlief nicht weniger erfolgreich. Über die Ziele, letzteres vor nicht allzu langer Zeit zu halten Veranstalter.
Den Teilnehmern wurde eine recht interessante Aufgabe gestellt, bei der sie völlige Freiheit bei der Auswahl eines Technologie-Stacks für die Implementierung hatten. Es war notwendig, eine Entscheidungsplattform für den bequemen Einsatz von Kundenbewertungsfunktionen zu implementieren, die mit einem schnellen Antragsfluss funktioniert, hohen Belastungen standhält und das System selbst leicht skalierbar ist.
Die Aufgabe ist nicht trivial und auf viele Arten lösbar, wovon wir uns bei der Demonstration der Abschlusspräsentationen der Projekte der Teilnehmer überzeugt haben. Beim Hackathon waren 6 Teams zu je 5 Personen anwesend, alle Teilnehmer hatten gute Projekte, aber unsere Plattform erwies sich als die wettbewerbsfähigste. Wir haben ein sehr interessantes Projekt, über das ich in diesem Artikel sprechen möchte.
Unsere Lösung ist eine Plattform, die auf einer serverlosen Architektur innerhalb von Kubernetes basiert und die Zeit verkürzt, die erforderlich ist, um neue Funktionen in die Produktion zu bringen. Es ermöglicht Analysten, Code in einer für sie geeigneten Umgebung zu schreiben und ihn ohne Beteiligung von Ingenieuren und Entwicklern in der Produktion bereitzustellen.
Was zählt
Tinkoff.ru verfügt, wie viele moderne Unternehmen, über eine Kundenbewertung. Beim Scoring handelt es sich um ein Kundenbewertungssystem, das auf statistischen Methoden der Datenanalyse basiert.
Beispielsweise wendet sich ein Kunde mit der Bitte an uns, ihm einen Kredit zu gewähren oder bei uns ein Einzelunternehmerkonto zu eröffnen. Wenn wir planen, ihm einen Kredit zu gewähren, müssen wir seine Zahlungsfähigkeit beurteilen, und wenn es sich bei dem Konto um ein Einzelunternehmerkonto handelt, müssen wir sicherstellen, dass der Kunde keine betrügerischen Transaktionen durchführt.
Grundlage für solche Entscheidungen sind mathematische Modelle, die sowohl die Daten aus der Anwendung selbst als auch die Daten aus unserem Speicher analysieren. Neben dem Scoring können ähnliche statistische Verfahren auch im Dienste der Generierung individueller Empfehlungen für neue Produkte für unsere Kunden eingesetzt werden.
Die Methode einer solchen Bewertung kann eine Vielzahl von Eingabedaten akzeptieren. Und irgendwann können wir der Eingabe einen neuen Parameter hinzufügen, der basierend auf den Ergebnissen der Analyse historischer Daten die Konversionsrate der Nutzung des Dienstes erhöht.
Wir verfügen über eine Fülle von Daten über Kundenbeziehungen und die Menge dieser Informationen wächst ständig. Damit das Scoring funktioniert, sind für die Datenverarbeitung auch Regeln (oder mathematische Modelle) erforderlich, die es Ihnen ermöglichen, schnell zu entscheiden, wem Sie einen Antrag genehmigen, wen Sie ablehnen und wem Sie noch ein paar weitere Produkte anbieten und deren potenzielles Interesse beurteilen können.
Für die jeweilige Aufgabenstellung nutzen wir bereits ein spezialisiertes Entscheidungssystem , das auf der Grundlage der von Analysten, Technologen und Entwicklern festgelegten Regeln entscheidet, ob ein bestimmtes Bankprodukt dem Kunden genehmigt oder abgelehnt wird.
Es gibt viele vorgefertigte Lösungen auf dem Markt, sowohl Scoring-Modelle als auch Entscheidungssysteme selbst. Wir nutzen eines dieser Systeme in unserem Unternehmen. Aber das Geschäft wächst, diversifiziert sich, sowohl die Anzahl der Kunden als auch die Anzahl der angebotenen Produkte nehmen zu und gleichzeitig entstehen Ideen, wie der bestehende Entscheidungsprozess verbessert werden kann. Sicherlich haben Leute, die mit dem bestehenden System arbeiten, viele Ideen, wie man es einfacher, besser und bequemer machen kann, aber manchmal sind Ideen von außen nützlich. Der New Hackathon wurde mit dem Ziel organisiert, fundierte Ideen zu sammeln.
Aufgabe
Der Hackathon fand am 23. Februar statt. Den Teilnehmern wurde eine Kampfaufgabe gestellt: ein Entscheidungssystem zu entwickeln, das eine Reihe von Bedingungen erfüllen musste.
Uns wurde erklärt, wie das bestehende System funktioniert und welche Schwierigkeiten bei seinem Betrieb auftreten, sowie welche Geschäftsziele die entwickelte Plattform verfolgen soll. Das System muss eine schnelle Markteinführungszeit für die Entwicklung von Regeln haben, damit der Arbeitscode der Analysten so schnell wie möglich in die Produktion gelangt. Und für den eingehenden Bewerbungsstrom sollte die Entscheidungszeit auf ein Minimum beschränkt werden. Darüber hinaus muss das zu entwickelnde System über Cross-Selling-Funktionen verfügen, um dem Kunden die Möglichkeit zu geben, andere Produkte des Unternehmens zu erwerben, wenn diese von uns genehmigt wurden und potenzielles Interesse des Kunden besteht.
Es ist klar, dass es unmöglich ist, über Nacht ein veröffentlichungsreifes Projekt zu schreiben, das mit Sicherheit in die Produktion geht, und es ist ziemlich schwierig, das gesamte System abzudecken, daher wurden wir gebeten, zumindest einen Teil davon zu implementieren. Es wurden eine Reihe von Anforderungen festgelegt, die der Prototyp erfüllen muss. Es konnte versucht werden, sowohl alle Anforderungen in ihrer Gesamtheit abzudecken als auch detailliert an einzelnen Abschnitten der zu entwickelnden Plattform zu arbeiten.
Was die Technik angeht, wurde allen Teilnehmern völlige Entscheidungsfreiheit gelassen. Es konnten beliebige Konzepte und Technologien eingesetzt werden: Datenstreaming, maschinelles Lernen, Event Sourcing, Big Data und andere.
Unsere Lösung
Nach einem kleinen Brainstorming kamen wir zu dem Schluss, dass eine FaaS-Lösung ideal für die Bewältigung der Aufgabe wäre.
Für diese Lösung war es notwendig, ein geeignetes Serverless-Framework zu finden, um die Regeln des zu entwickelnden Entscheidungssystems umzusetzen. Da Tinkoff Kubernetes aktiv für das Infrastrukturmanagement nutzt, haben wir uns mehrere darauf basierende fertige Lösungen angesehen; darüber werde ich Ihnen später mehr erzählen.
Um die effektivste Lösung zu finden, haben wir das zu entwickelnde Produkt aus der Sicht seiner Benutzer betrachtet. Die Hauptnutzer unseres Systems sind Analysten, die an der Regelentwicklung beteiligt sind. Für die spätere Entscheidungsfindung müssen die Regeln auf dem Server oder, wie in unserem Fall, in der Cloud bereitgestellt werden. Aus Sicht eines Analysten sieht der Workflow folgendermaßen aus:
- Der Analyst schreibt ein Skript, eine Regel oder ein ML-Modell basierend auf Daten aus dem Warehouse. Im Rahmen des Hackathons haben wir uns für den Einsatz von Mongodb entschieden, die Wahl des Datenspeichersystems spielt hier jedoch keine Rolle.
- Nachdem er die entwickelten Regeln anhand historischer Daten getestet hat, lädt der Analyst seinen Code in das Admin-Panel hoch.
- Um die Versionierung sicherzustellen, wird der gesamte Code in Git-Repositorys gespeichert.
- Über das Admin-Panel ist es möglich, den Code als separates funktionales Serverless-Modul in der Cloud bereitzustellen.
Ursprüngliche Daten von Kunden müssen einen speziellen Anreicherungsdienst durchlaufen, der darauf ausgelegt ist, die ursprüngliche Anfrage mit Daten aus dem Lager anzureichern. Es war wichtig, diesen Dienst so zu implementieren, dass er mit einem einzigen Repository (aus dem der Analyst bei der Regelentwicklung Daten entnimmt) funktioniert, um eine einheitliche Datenstruktur aufrechtzuerhalten.
Bereits vor dem Hackathon haben wir uns für das Serverless-Framework entschieden, das wir verwenden würden. Heutzutage gibt es eine ganze Reihe von Technologien auf dem Markt, die diesen Ansatz umsetzen. Die beliebtesten Lösungen innerhalb der Kubernetes-Architektur sind Fission, Open FaaS und Kubeless. Es gibt sogar .
Nachdem wir alle Vor- und Nachteile abgewogen hatten, entschieden wir uns . Dieses serverlose Framework ist recht einfach zu verwalten und erfüllt die Anforderungen der Aufgabe.
Um mit Fission arbeiten zu können, müssen Sie zwei grundlegende Konzepte verstehen: Funktion und Umgebung. Eine Funktion ist ein Codestück, das in einer der Sprachen geschrieben ist, für die es eine Fission-Umgebung gibt. umfasst Python, JS, Go, JVM und viele andere beliebte Sprachen und Technologien.
Fission ist auch in der Lage, Funktionen auszuführen, die in mehrere Dateien aufgeteilt und in einem Archiv vorverpackt sind. Der Betrieb von Fission in einem Kubernetes-Cluster wird durch spezialisierte Pods sichergestellt, die vom Framework selbst verwaltet werden. Um mit Cluster-Pods interagieren zu können, muss jeder Funktion eine eigene Route zugewiesen werden, an die Sie im Falle einer POST-Anfrage GET-Parameter oder den Anforderungstext übergeben können.
Aus diesem Grund planten wir, eine Lösung zu erhalten, die es Analysten ermöglichen würde, entwickelte Regelskripte ohne die Beteiligung von Ingenieuren und Entwicklern bereitzustellen. Der beschriebene Ansatz macht es für Entwickler außerdem überflüssig, Analystencode in eine andere Sprache umzuschreiben. Für das aktuelle Entscheidungssystem, das wir verwenden, müssen wir beispielsweise Regeln in hochspezialisierten Technologien und Sprachen schreiben, deren Umfang äußerst begrenzt ist, und es besteht auch eine starke Abhängigkeit vom Anwendungsserver, da alle Entwürfe Bankregeln sind werden in einer einzigen Umgebung bereitgestellt. Um neue Regeln bereitzustellen, ist es daher erforderlich, das gesamte System freizugeben.
Bei unserer vorgeschlagenen Lösung besteht keine Notwendigkeit, Regeln freizugeben; der Code kann einfach per Knopfdruck bereitgestellt werden. Darüber hinaus ermöglicht Ihnen die Infrastrukturverwaltung in Kubernetes, sich keine Gedanken über Auslastung und Skalierung zu machen; solche Probleme werden sofort gelöst. Und durch die Verwendung eines einzigen Data Warehouse entfällt die Notwendigkeit, Echtzeitdaten mit historischen Daten zu vergleichen, was die Arbeit des Analysten vereinfacht.
Was wir bekommen haben
Da wir (in unseren Fantasien) mit einer fertigen Lösung zum Hackathon kamen, mussten wir nur noch alle unsere Gedanken in Codezeilen umwandeln.
Der Schlüssel zum Erfolg bei jedem Hackathon ist die Vorbereitung und ein gut geschriebener Plan. Daher haben wir zunächst entschieden, aus welchen Modulen unsere Systemarchitektur bestehen und welche Technologien wir verwenden würden.
Die Architektur unseres Projekts war wie folgt:
Dieses Diagramm zeigt zwei Einstiegspunkte: den Analysten (den Hauptbenutzer unseres Systems) und den Kunden.
Der Arbeitsprozess ist wie folgt aufgebaut. Der Analyst entwickelt eine Regelfunktion und eine Datenanreicherungsfunktion für sein Modell, speichert seinen Code in einem Git-Repository und stellt sein Modell über die Administratoranwendung in der Cloud bereit. Betrachten wir, wie die bereitgestellte Funktion aufgerufen wird, und treffen wir Entscheidungen über eingehende Anfragen von Clients:
- Der Kunde füllt auf der Website ein Formular aus und sendet seine Anfrage an den Verantwortlichen. Ein Antrag, über den eine Entscheidung zu treffen ist, gelangt in den Systemeingang und wird in seiner ursprünglichen Form in der Datenbank erfasst.
- Als nächstes wird die Rohanforderung bei Bedarf zur Anreicherung gesendet. Sie können die Erstanfrage mit Daten sowohl von externen Diensten als auch aus dem Speicher ergänzen. Die resultierende angereicherte Abfrage wird ebenfalls in der Datenbank gespeichert.
- Die Analystenfunktion wird gestartet, die eine erweiterte Abfrage als Eingabe verwendet und eine Lösung erstellt, die ebenfalls in den Speicher geschrieben wird.
Aufgrund der dokumentenorientierten Speicherung von Daten in Form von JSON-Dokumenten haben wir uns für MongoDB als Speicher in unserem System entschieden, da die Anreicherungsdienste, einschließlich der ursprünglichen Anfrage, alle Daten über REST-Controller aggregiert haben.
Wir hatten also XNUMX Stunden Zeit, die Plattform zu implementieren. Die Rollenverteilung ist uns recht gelungen, jedes Teammitglied hatte in unserem Projekt seinen eigenen Aufgabenbereich:
- Front-End-Admin-Panels für die Arbeit des Analysten, über die er Regeln aus dem Versionskontrollsystem geschriebener Skripte herunterladen, Optionen zur Anreicherung von Eingabedaten auswählen und Regelskripte online bearbeiten konnte.
- Backend-Administrator, einschließlich REST-API für die Front und Integration mit VCS.
- Aufbau einer Infrastruktur in Google Cloud und Entwicklung eines Dienstes zur Anreicherung von Quelldaten.
- Ein Modul zur Integration der Admin-Anwendung in das Serverless-Framework für die anschließende Bereitstellung von Regeln.
- Regelskripte zum Testen der Leistung des gesamten Systems und zur Aggregation von Analysen eingehender Anwendungen (getroffene Entscheidungen) für die abschließende Demonstration.
Lassen Sie uns von Anfang an beginnen.
Unser Frontend wurde in Angular 7 mit dem Banking UI Kit geschrieben. Die endgültige Version des Admin-Panels sah so aus:
Da die Zeit knapp war, haben wir versucht, nur die Kernfunktionen zu implementieren. Um eine Funktion im Kubernetes-Cluster bereitzustellen, war es notwendig, ein Ereignis (einen Dienst, für den eine Regel in der Cloud bereitgestellt werden muss) und den Code der Funktion auszuwählen, der die Entscheidungslogik implementiert. Für jede Bereitstellung einer Regel für den ausgewählten Dienst haben wir ein Protokoll dieses Ereignisses geschrieben. Im Admin-Bereich konnten Sie Protokolle aller Ereignisse sehen.
Der gesamte Funktionscode wurde in einem Remote-Git-Repository gespeichert, das ebenfalls im Admin-Panel festgelegt werden musste. Um den Code zu versionieren, wurden alle Funktionen in verschiedenen Zweigen des Repositorys gespeichert. Das Admin-Panel bietet außerdem die Möglichkeit, Anpassungen an geschriebenen Skripten vorzunehmen, sodass Sie vor der Bereitstellung einer Funktion in der Produktion nicht nur den geschriebenen Code überprüfen, sondern auch die erforderlichen Änderungen vornehmen können.
Zusätzlich zu den Regelfunktionen haben wir auch die Möglichkeit implementiert, die Quelldaten mithilfe von Enrichment-Funktionen schrittweise anzureichern. Deren Code bestand ebenfalls aus Skripten, mit denen es möglich war, in das Data Warehouse zu gelangen, Dienste von Drittanbietern aufzurufen und vorläufige Berechnungen durchzuführen . Um unsere Lösung zu demonstrieren, haben wir mithilfe eines REST-Dienstes eines Drittanbieters das Sternzeichen des Kunden berechnet, der die Anfrage hinterlassen hat, und seinen Mobilfunkanbieter ermittelt.
Das Backend der Plattform wurde in Java geschrieben und als Spring Boot-Anwendung implementiert. Ursprünglich hatten wir geplant, Postgres zum Speichern von Verwaltungsdaten zu verwenden, aber im Rahmen des Hackathons haben wir uns entschieden, uns auf ein einfaches H2 zu beschränken, um Zeit zu sparen. Im Backend wurde die Integration mit Bitbucket implementiert, um die Abfrageanreicherungsfunktionen und Regelskripte zu versionieren. Für die Integration mit Remote-Git-Repositorys haben wir verwendet , eine Art Wrapper für CLI-Befehle, der es Ihnen ermöglicht, beliebige Git-Anweisungen über eine praktische Softwareschnittstelle auszuführen. Wir hatten also zwei separate Repositorys für Anreicherungsfunktionen und -regeln und alle Skripte waren in Verzeichnisse unterteilt. Über die Benutzeroberfläche war es möglich, den neuesten Commit eines Skripts eines beliebigen Zweigs des Repositorys auszuwählen. Bei Änderungen am Code über das Admin-Panel wurden Commits des geänderten Codes in Remote-Repositorys erstellt.
Um unsere Idee umzusetzen, brauchten wir eine geeignete Infrastruktur. Wir haben uns entschieden, unseren Kubernetes-Cluster in der Cloud bereitzustellen. Unsere Wahl fiel auf die Google Cloud Platform. Das serverlose Fission-Framework wurde auf einem Kubernetes-Cluster installiert, den wir in Gcloud bereitgestellt haben. Ursprünglich wurde der Quelldatenanreicherungsdienst als separate Java-Anwendung implementiert, die in einen Pod innerhalb des k8s-Clusters eingebettet war. Aber nach einer vorläufigen Demonstration unseres Projekts mitten im Hackathon wurde uns empfohlen, den Enrichment-Dienst flexibler zu gestalten, um die Möglichkeit zu geben, zu wählen, wie die Rohdaten eingehender Anwendungen angereichert werden sollen. Und wir hatten keine andere Wahl, als den Anreicherungsdienst auch serverlos zu machen.
Um mit Fission zu arbeiten, haben wir die Fission-CLI verwendet, die zusätzlich zur Kubernetes-CLI installiert werden muss. Die Bereitstellung von Funktionen in einem k8s-Cluster ist recht einfach; Sie müssen der Funktion lediglich eine interne Route und einen Eingang zuweisen, um eingehenden Datenverkehr zuzulassen, wenn Zugriff außerhalb des Clusters erforderlich ist. Die Bereitstellung einer Funktion dauert normalerweise nicht länger als 10 Sekunden.
Abschlusspräsentation des Projekts und Zusammenfassung
Um die Funktionsweise unseres Systems zu demonstrieren, haben wir ein einfaches Formular auf einem Remote-Server platziert, über das Sie einen Antrag für eines der Produkte der Bank einreichen können. Zur Beantragung mussten Sie Ihre Initialen, Ihr Geburtsdatum und Ihre Telefonnummer eingeben.
Die Daten aus dem Client-Formular gingen an den Controller, der gleichzeitig Anfragen für alle verfügbaren Regeln sendete, nachdem er die Daten zuvor gemäß den angegebenen Bedingungen angereichert und in einem gemeinsamen Speicher gespeichert hatte. Insgesamt haben wir drei Funktionen bereitgestellt, die Entscheidungen über eingehende Bewerbungen treffen, sowie vier Datenanreicherungsdienste. Nach Einreichung des Antrags erhielt der Kunde unsere Entscheidung:
Neben der Ablehnung oder Genehmigung erhielt der Kunde auch eine Liste weiterer Produkte, für die wir parallel Anfragen verschickten. So haben wir die Möglichkeit des Cross-Sales auf unserer Plattform aufgezeigt.
Insgesamt standen 3 fiktive Bankprodukte zur Verfügung:
- Anerkennung.
- Spielzeug
- Hypothek.
Während der Demonstration stellten wir für jeden Dienst vorbereitete Funktionen und Anreicherungsskripte bereit.
Jede Regel erforderte einen eigenen Satz an Eingabedaten. Um eine Hypothek zu genehmigen, haben wir also das Sternzeichen des Kunden berechnet und dieses mit der Logik des Mondkalenders verknüpft. Um ein Spielzeug zu genehmigen, überprüften wir, ob der Kunde volljährig war, und um einen Kredit zu vergeben, schickten wir eine Anfrage an einen externen offenen Dienst zur Ermittlung des Mobilfunkanbieters und es wurde eine Entscheidung darüber getroffen.
Wir haben versucht, unsere Demonstration interessant und interaktiv zu gestalten, jeder Anwesende konnte zu unserem Formular gehen und prüfen, ob unsere fiktiven Dienste für ihn verfügbar sind. Und ganz am Ende der Präsentation zeigten wir eine Analyse der eingegangenen Bewerbungen, aus der hervorgeht, wie viele Personen unseren Service in Anspruch genommen haben, wie viele Genehmigungen und Ablehnungen es gab.
Um Analysen online zu sammeln, haben wir zusätzlich ein Open-Source-BI-Tool eingesetzt und schraubte es an unsere Lagereinheit. Mit Metabase können Sie Bildschirme mit Analysen zu den Daten erstellen, die uns interessieren; Sie müssen lediglich eine Verbindung zur Datenbank registrieren, Tabellen auswählen (in unserem Fall Datensammlungen, da wir MongoDB verwendet haben) und die für uns interessanten Bereiche angeben .
Als Ergebnis erhielten wir einen guten Prototyp einer Entscheidungsplattform, und während der Demonstration konnte jeder Zuhörer deren Leistung persönlich überprüfen. Eine interessante Lösung, ein fertiger Prototyp und eine erfolgreiche Demonstration ermöglichten es uns, trotz der starken Konkurrenz anderer Teams zu gewinnen. Ich bin sicher, dass auch zu jedem Projekt eines Teams ein interessanter Artikel geschrieben werden kann.
Source: habr.com