This commit is contained in:
@@ -60,7 +60,7 @@ The backend services already exist, and looks like this:
|
||||
|
||||
### Backend
|
||||
|
||||

|
||||

|
||||
|
||||
What happens here is that we have variety of business services, which are used
|
||||
and serviced by either a User, or an engineer specifically. All the models are
|
||||
@@ -73,7 +73,7 @@ These domain events are what ends up in the data platform.
|
||||
|
||||
### Internet of Things
|
||||
|
||||

|
||||

|
||||
|
||||
Like the backend services, we have IoT services for various things, such as
|
||||
storing measured data, or controllers for doing various things. Most of these
|
||||
@@ -148,7 +148,7 @@ An event will flow through a NATS global event consumer, which will then get a
|
||||
schema applied while being transported to a data fusion pipeline (Apache spark
|
||||
alternative)
|
||||
|
||||

|
||||

|
||||
|
||||
This is not very different than normal data ingestion pipelines, though without
|
||||
Kafka and Spark. If a schema application fails, or cannot be found, it will be
|
||||
@@ -169,7 +169,7 @@ date base models, and integrated transformations by the users. It includes
|
||||
support for compaction, versioning, scale out queries, transformations and much
|
||||
more.
|
||||
|
||||

|
||||

|
||||
|
||||
In here we see the data entering the system from the NATS listener, it will pull
|
||||
out data from the nats stream and ingest them into the datafusion pipeline
|
||||
@@ -190,7 +190,7 @@ Trino (distributed sql).
|
||||
I will have a need for realtime aggregations, as such a bunch of allowed
|
||||
transformations should end up in clickhouse for rapid querying.
|
||||
|
||||

|
||||

|
||||
|
||||
Much of the same architecture from before is used (See datalake section),
|
||||
however, we also put data in `clickhouse`, this is to enable rapid querying on a
|
||||
|
Reference in New Issue
Block a user