From 99dfdfffd14d20a1688ee8d5492d18fb24dd67af Mon Sep 17 00:00:00 2001 From: Mike Driscoll Date: Sat, 30 Mar 2024 13:03:26 -0700 Subject: [PATCH] Some minor clean-up to documentation --- docs/docs/build/dashboards/customize.md | 4 ++-- docs/docs/concepts/architecture.md | 8 ++++---- docs/docs/concepts/operational.md | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/docs/build/dashboards/customize.md b/docs/docs/build/dashboards/customize.md index 830145bc4c0..e699d3ff71e 100644 --- a/docs/docs/build/dashboards/customize.md +++ b/docs/docs/build/dashboards/customize.md @@ -37,8 +37,8 @@ One of the more important configurations, available time ranges allow you to cha - PT1H - P7D - P4W - - rill-TD // Today - - rill-WTD // Week-To-date + - rill-TD ## Today + - rill-WTD ## Week-To-date ``` **`available_time_zones`** diff --git a/docs/docs/concepts/architecture.md b/docs/docs/concepts/architecture.md index c542c620474..a5e7e09696f 100644 --- a/docs/docs/concepts/architecture.md +++ b/docs/docs/concepts/architecture.md @@ -10,13 +10,13 @@ import TabItem from '@theme/TabItem'; ## Overview -Rill's strategy for fast dashboards is twofold: +Rill's strategy for fast dashboards is two-fold: -1) Define metrics & dimensions up front use these definitions to automatically aggregate and prune the raw tables. This modest modeling pain yields a massive gain: the data footprint is typically 10-100X smaller than the underlying raw sources. +1) *Define metrics & dimensions up front*, and use these definitions to automatically aggregate and prune the raw tables. This modest modeling pain yields a massive gain: the data footprint of aggregated metrics is typically 10-100X smaller than the underlying raw events in data lakes or warehouses. -2) Avoid lowest common denominator of database performance. Instead, orchestrate data out of warehouses and lakehouses into OLAP databases +2) *Use an integrated OLAP database* to drive dashboards, by orchestrating (and aggregating, per above) data out of a cloud data warehouses, lakehouse, or object store. -The decoupling of databases and BI tools served a purpose at one phase in the evolution of data stacks, but the cost and performance trade-offs have begun to shift in favor of consolidated analytics offerings. +The decoupling of BI applications and database servers served a purpose at one phase in the evolution of data stacks, but the cost and performance trade-offs have begun to shift in favor of consolidated analytics offerings. ## Architecture diff --git a/docs/docs/concepts/operational.md b/docs/docs/concepts/operational.md index c259afb04f5..f0fc24eb39d 100644 --- a/docs/docs/concepts/operational.md +++ b/docs/docs/concepts/operational.md @@ -10,7 +10,7 @@ import TabItem from '@theme/TabItem'; ## Operational vs. Traditional BI -The distinction between operational and business intelligence is analogous to the distinction between fast and slow thinking, as characterized by psychologist Daniel Kahneman in his paper Thinking, Fast and Slow. One system operates quickly and automatically for simple decisions and the other leverages slow and effortful deliberation for complex decisions. +The distinction between operational and business intelligence is analogous to the distinction between fast and slow thinking, as characterized by the late psychologist Daniel Kahneman in his book __Thinking, Fast and Slow__. One system operates quickly and automatically for simple decisions and the other leverages slow and effortful deliberation for complex decisions. Ultimately, the output of operational and business intelligence are decisions. Operational intelligence fuels fast, frequent decisions on real-time and near-time data by hands-on operators. Business intelligence drives complex decisions that occur daily or weekly, on fairly complete data sets.