什么是数据应用？
“数据应用程序”是一类使用数据提供洞察力或自动采取行动的交互式工具的总称。当我们谈论数据应用程序时，我们经常引用推荐引擎、内置于应用程序中的数据可视化以及为业务团队定制的内部报告工具的例子。
这不就是嵌入式分析吗？
嵌入式分析采用过去在仪表板和遗留 BI 工具中进行的探索，并将其直接注入内部团队和外部客户已经使用的应用程序中。Headless BI 有助于更快地构建嵌入式分析。但嵌入式分析仅仅是个开始。
尽管比传统仪表板更易于访问和定制，嵌入式分析仍然主要是一种数据探索工具。相比之下，数据应用程序能够解释数据：突出趋势、呈现见解和提出建议。这种类型的应用程序需要动态的、专门构建的用户体验，并且通常由软件和数据工程师而不是业务分析师开发。
数据应用程序有哪些用例？
第一类数据应用是嵌入式数据应用。将此视为嵌入式分析的演变，但与嵌入式分析的静态仪表板不同，嵌入式数据功能往往是高度定制的、动态的和专门构建的。这些应用程序在另一个应用程序的本机用户体验中展现洞察力。
企业内部的数据产品和入口是第二种数据应用。与传统或嵌入式探索仪表板不同，这种类型的数据应用程序是专门为特定业务部门构建的，并且是根据相关业务环境构建的。这些应用程序的自定义交互性允许业务用户在不掌握数据分析师的工作流程的情况下获得洞察力。
第三类数据应用是面向终端消费者的应用。这些可能是为客户、合作伙伴或股东构建的，它们与内部应用程序没有什么不同——但它们往往需要更精细的设计润色和定制。此外，此类应用程序必须针对更高性能而构建，以反映消费者对速度的期望。
应用接口
数据应用程序是如何构建的？
就其本质而言，数据应用程序需要求助于大量数据。云数据仓库的兴起以及不断增长的数据摄取、治理、转换和编排工具生态系统使这一切成为可能。
但考虑到它们的复杂性和功能，数据应用程序通常由工程团队构建，并且它们需要与现代工程工作流集成，包括版本控制、测试以及持续集成和部署实践。
从头开始构建
将数据应用程序功能嵌入到更大的应用程序中通常需要从头开始构建。这种解决方案的架构是什么？
数据存储
自然地，数据应用程序从数据开始——现代数据堆栈的基础是云数据仓库。这可以是像Snowflake这样的通用数据仓库，也可以是像Firebolt、ClickHouse或Materialize这样的实时工具。
无头双层
数据应用程序的一个重要组件是无头 BI 层。具体来说，其中一个主要部分是与仓库安全控制集成的访问控制，因为嵌入式分析总是需要多租户。第二部分是高级缓存。这是因为数据仓库是后端的理想选择，但它不支持现代数据消费者期望的具有亚秒级延迟的高并发查询。
BI 层也是处理数据建模的地方，以确保数据应用程序的用户使用与其他内部或外部应用程序的用户相同的数据定义。数据建模和指标定义应该处理一次，并且这必须从每个应用程序或仪表板向上堆栈。
然后通过各种 API（例如 SQL、GraphQL 和 REST）提供数据，供……使用。
混合表示层
对于嵌入式数据应用程序的高度定制化，以及当前端团队进入循环时，可以使用不同的图表库。这些范围从D3到Chart.js和Highcharts。这些很可能会与React或Angular等前端应用程序框架原生集成。
使用框架
对于第二类和第三类数据应用，数据堆栈的初始层是相同的——即基础层是数据仓库，然后是用于数据建模、访问控制、缓存和应用程序 API 的无头 BI 层。
然而，对于用户界面，通常需要较少的定制。这创造了利用新类别的无代码/低代码工具（如Appsmith和Retool ）的机会，这些工具可用于快速构建分析界面。
还有一些数据应用程序框架在这里很有用：像Plotly Dash和Streamlit这样的工具可以将数据脚本转换为可共享的 Web 应用程序，而无需进行前端开发。
下一步是什么？
随着构建定制化体验变得越来越容易，数据应用程序的数量和类型将会激增——但以仪表板为中心的基本体验用例不会消失。总会有这样的情况，传统图表最能满足需求，或者快速周转需要在不利用工程资源寻求帮助的情况下提供一些东西。对于这些，嵌入式分析现在是并将继续是最佳选择。