Einige Überlegungen basieren auf Doris Echtzeitdatenentwicklung

3 Millionen Wörter! Die umfassendste Community für Big-Data-Learning-Interviews im gesamten Netzwerk wartet auf Sie!

Die jüngste Entwicklung von Doris ist für alle offensichtlich. Es kommen weiterhin neue Funktionen wie die Heiß- und Kalttrennung hinzu. Dadurch ist Doris hinsichtlich Benutzerfreundlichkeit und Kosten erheblich verbessert.

Einige auf Doris basierende Speicher-Echtzeit-Data-Warehouses haben begonnen, sich in immer mehr Szenarien zu etablieren. Sie haben auch gesehen, dass diese Art von Schema beim Community-Sharing häufig vorkommt. Wir müssen diese Lösung jedoch objektiv betrachten. Das speicherbasierte Echtzeit-Data Warehouse hat seine Vor- und Nachteile. In der Produktionsumgebung müssen wir unsere persönlichen Geschäftsszenarien sorgfältig bewerten. In diesem Artikel werde ich basierend auf meiner persönlichen Praxis und meinem Denken kurz auf dieses Thema eingehen. .

Warum gibt es ein solches Schema?

In vielen Fällen basiert das auf OLAP basierende Echtzeit-Computing-Geschäft wie Doris auf den folgenden Überlegungen.

In mehr Fällen ist die Schwierigkeit der Echtzeit-Datenentwicklung auf Basis von Flink deutlich höher als die von Offline-Aufgaben (die beiden liegen überhaupt nicht in der gleichen Größenordnung). Die Entwicklung der Echtzeit-Datenspeicherung auf Basis von Doris kann reduzieren die Entwicklungsschwelle erheblich, es besteht jedoch die Möglichkeit eines Missbrauchs.

Zweitens ist Flink nicht gut in Szenarien mit großen Fenstern, großen Zuständen und flexiblem Computing (beachten Sie, dass es darin nicht gut, aber nicht unmöglich ist). Hoch, aber Doris kann dies erheblich reduzieren.

Schließlich ist die Beobachtbarkeit von Flink-basierten Computerdaten schlecht. Beispielsweise sind Statusdaten unsichtbar. Es gibt erhebliche Schwellenwerte für die Fehlerbehebung und das Debuggen und es ist sehr schwierig, historische Daten zu reparieren.

Man sieht also, dass es für die oben erwähnte Echtzeitdatenentwicklung auf Basis von Flink keine kleinen Schwellenwerte gibt. Wir haben also eine qualitative Schlussfolgerung: Unterhalb der Skala von 100 Millionen (oder mehreren zehn Millionen) Daten können wir eine Analyse-Engine wie Doris verwenden, um Schichtung und Zeitplanung wie Offline-Daten durchzuführen und große Fensterdaten (allgemeine Zeitspanne) zu verarbeiten Unter der Prämisse, die Leistung sicherzustellen, werden die Entwicklungskosten von Echtzeitdaten gesenkt, die Beobachtbarkeit der Daten erheblich verbessert und die Effizienz der Entwicklung sowie des Betriebs und der Wartung bis zu einem gewissen Grad verbessert.

Im Vergleich zu einigen Flink-basierten Lösungen

Niedrige Schwelle, einfache Entwicklung

Jeder kann solche Aufgaben entwickeln;

Einfache Bedienung und Wartung

Da es im Gegensatz zu Flink keine staatliche Kompatibilität berücksichtigt, ist es nicht erforderlich, über einen längeren Zeitraum eine große Menge an Ressourcen zu belegen. Es ist nur erforderlich, Ressourcen einzuplanen, wenn SQL ausgeführt wird.

Verbessern Sie die Entwicklungseffizienz

Es ist kein tiefes Verständnis von Flink erforderlich (das ist natürlich keine gute Sache), es gibt fast keine Parameterleisten, der Test ist einfach und es ist nicht erforderlich, den Planungscontainer zu starten (z. B. die Planung von TaskManager usw.). Aufgabe);

Das Debuggen von Daten ist bequem und die Zwischenergebnisse können vor Ort eingesehen werden

Es gibt keine Statusdaten von Flink, alle Daten sind in der Tabelle verfügbar.

Die oben genannten Punkte sind einige Vorteile, aber diese auf Doris basierende Lösung weist auch offensichtliche Mängel auf, die besondere Aufmerksamkeit erfordern!

Offensichtliche Verzögerung

Wenn Sie Doris verwenden, arbeiten wir höchstwahrscheinlich mit der geplanten Planung zusammen. Im Allgemeinen beträgt der Planungszyklus mehr als 30 Sekunden, was bedeutet, dass die Echtzeitleistung von Daten stark eingeschränkt ist und einige Echtzeit-Beobachtungsindikatoren wie Echtzeit GMV, Online-Nummer und andere Szenarien sind nicht anwendbar;

Datengrößenbeschränkung

Wenn Sie Doris adoptieren, bedeutet das, dass Ihr TPS nicht zu hoch sein darf. Dies ist nicht das Gebiet, in dem Doris gut ist, und jeder muss besonders darauf achten. Darüber hinaus dürfen die Daten eines einzelnen Scans nicht zu groß sein. Wie bereits erwähnt, ist die Leistungsgarantie nur dann besser, wenn die Datengröße unter 100 Millionen (oder mehreren zehn Millionen) liegt.

Wenn Sie sich schließlich wirklich für die Doris-basierte Echtzeit-Datenentwicklung entscheiden, bedeutet dies, dass Doris zu Ihrem Kosten-, Betriebs- und Wartungszentrum wird. Es müssen sehr strenge unterstützende Tools vorhanden sein, wie z. B. Alarm, Überwachung des Aufgabenbetriebs, Aufgabenstandardisierung, Terminplanung und Blutsverwandtschaftsfunktionen. Achten Sie besonders auf Ressourcen- und SQL-Leistungsprobleme. Sobald sie zu Engpässen werden, wirken sie sich auf alle Doris-basierten Aufgaben aus.

Wenn dieser Artikel für Sie hilfreich ist, vergessen Sie nicht, dreimal „Gefällt mir“, „Gefällt mir“ und „Favorit“ zu markieren!