现代数据栈中的消费层

1 什么是 Modern Data Stack

1.1 背景

近两年来，Modern Data Stack 越来越成为了一个热门的技术话题。越来越多的企业组织在完成了信息化，在线化转型后，都把数据智能化作为下一个战略目标，出现了“数据是新的石油”的说法。

于是一方面，大数据的浪潮席卷而来，每家公司都在致力于收集更多的数据，推动了 Hadoop，数据湖等技术的兴起。另一方面，AI 成了从海量数据中获取业务价值的“炼金术”，几乎每家公司都在不遗余力的投入各种 AI 项目的尝试与探索。

但经过几年的实践，现实给我们上了很好的一课，大家越来越发现 光有更多的数据并不一定代表更好的业务产出，现有的算法也很难在混乱的数据中挖到业务洞见 。于是 Modern Data Stack 应运而生，其主要目的就是围绕数据与业务决策打造一个更好的基础设施，来提升数据的产出价值。这背后的驱动因素主要来自两方面：

• 商业方面：从软件吞噬世界，到数据作为差异化竞争力的核心，赋能组织做更好的决策。
• 技术方面：大数据，云原生，AI 浪潮的兴起，对技术栈的形态和组成部分造成了巨大的影响。

这两个因素推动了我们的 Data Stack 从早年的传统数仓，再到 2010 年前后开始出现的数据湖，再到现在的云原生数据平台的演化过程。

1.2 演化逻辑

传统数据栈的典型架构就是“数据源 -> ETL 工具 -> 数据仓库 -> BI 软件”这几个步骤。这里面最大的瓶颈来自于数据仓库，从一开始并没有区分 OLTP 和 OLAP，到后来逐渐有了 MPP 架构，都是为了去提升数据分析消费场景下的数仓服务性能与可扩展性。总体来说当时数仓都是价格昂贵的商业系统，使用门槛较高。为了更好地实现数据分析消费，我们不得不在数仓的输入和输出两端做各种优化，例如通过复杂的 ETL，将数据预先做筛选清洗，并聚合到较高的维度，避免出现超大的数据量。在 BI 软件层面，也做了很多查询优化，缓存，二次计算，Cube 等方面的技术创新，使得系统整体能服务更多的用户的复杂查询和并发操作。

在 2010 年左右大数据技术开始兴起，但当时的 SQL-on-Hadoop 技术主要还是应用在 ETL 这种批处理操作中，并没有对实时交互分析产生多大的影响。当时还出现了知名的 Lambda 架构等，其中也仍然需要数据仓库层对外提供分析服务。

2016 年开始逐渐火热的云原生浪潮带来了不少新的思路，其中一个很重要的想法就是做“ 拆分 ”，出现了存储和计算两个模块分离的云数仓，使得其扩展能力得到了极大的提升，并且成本方面也能控制的比较好。传统 ETL 对于数据应用造成的一个最大困难就在于我需要提前设计好分析消费时需要的表结构，一旦后续出现变更，需要消耗巨大的时间和成本来重新执行 ETL，甚至可能原先的数据都不存在了。有了几乎可以“无限扩展”的云数仓，我们可以把 ETL 也拆分了，其中 EL 两步主要做数据的“复制”，把所有可用信息都导入到云数仓中，后续再根据需求灵活的执行 T 就可以。

ETL 到 ELT

这个“拆分”还在不断自我增强，计算和存储拆开了，EL 和 T 拆开了，那么调度自然也需要单独一个模块来跨组件统筹，元数据分散在各个系统也不行，于是数据管控，可观测性也都拆了出来。这跟微服务兴起后，服务发现，消息系统，可观测性等都有了自然的需求是类似的，我们也可以把 DevOps 中的很多概念对应到 DataOps 上。于是现在，现代数据栈的全景图就变成了下面这个模样：

面向现代数据应用的各类公司

也难怪要叫现代数据“栈”了。

1.3 特性

相比于数仓和数据湖平台，Modern Data Stack 以云数据库为中心 ，引发了一系列的产品技术的变化，进而影响到了企业组织，业务流程的改进优化，形成了新一代平台的特点与优势，包括：

• 充分拥抱云原生 ，极大地降低运维方面开销，更低的启动成本，且可以弹性扩展，按量付费。当然这一点也会带来新的挑战，例如如何管理和优化云服务的开销。
• 从 IT 为中心转向以业务为中心 ，更加强调基础设施要为快速的业务变化提供敏捷，灵活，自助化的解决方案。这也是传统平台的一大痛点，典型的例子如前所述的 ETL 到 ELT 的转变，analytics engineer 的出现等。
• 随着数据量，用户数的增长，应用场景的数量也会迎来爆发。因此 数据管控会成为重要的“一等公民” 。如果只是一味追求自助化，那么更多的数据意味着更多的混乱，更少的信任。
• 传统数仓的应用以数据分析为主，相对单一。 为了实现数据价值，必须要赋能决策，深入到各个业务流程中去 ，支持分析与决策的完整工作流。这方面也出现了反向 ETL 等技术产品。
• 模块化，易于集成的产品组合 ，而不再是之前的 all-in-one 解决方案。例如存算分离的趋势，各种接口的标准化，避免 vendor lock-in。

后面我们会针对这些特性做进一步的展开分析。

1.4 典型架构

在之前的聊聊云原生数据平台 一文中，我们已经详细介绍过 Modern Data Stack 的典型架构，其中主要包括以下几个部分：

• 数据获取
• 数据存储
• 数据处理
• 数据分析消费
• 数据管控
• 流程编排

典型的 Modern Data Stack 架构

今天我们的主题会围绕着数据分析与消费这个方向来展开。

2 Modern Data Stack 中的数据分析

数据分析与消费是整个 Data Stack 中面向用户量最广的一个环节，也是让数据最终产生业务价值的“门户”，影响了整体技术栈的演进。延续前面提到的 Modern Data Stack 特性，我们来看下针对分析领域出现的趋势。

2.1 流程对比

对于用户来说，最显著的变化来自于数据分析的流程从 IT 为中心转向了以业务为中心。例如传统数据分析产品的典型流程如下：

1. 决策人员提出了一个业务问题。
2. 分析师需要提 request 给数据/IT 部门，获取相关数据。
3. 经过几周漫长的等待，数据终于准备好了，可能以 Excel 或数据库表或 cube 的形式提供给分析师。
4. 分析师使用 BI 工具进行数据准备，建模等工作，涉及大数据量时可能会碰到工具的性能问题。而且如果发现数据有问题，还需要反复与 IT 部门进行沟通，重新获取。
5. 完成处理后，制作报表，看板进行业务问题的分析。
6. 得出结论后，导出数据和可视化内容，放到报告文档（word，ppt）里，构建相关的叙述内容。
7. 展示给决策者，过程中决策者提了几个新问题，但现有的数据没法进行回答。
8. 回到第一步，再针对新的问题走一遍流程。

从这个过程中，可以看出很多问题：

• 由于技术的局限，数据架构的性能和易用性无法达到要求，各类数据操作中涉及到复杂的定制化代码撰写，MapReduce 任务开发，复杂度高且运行效率较低。这一点引发了后续问题。
• 在组织与流程上，传统的数据栈更多是以 IT 为中心，面向技术人员为主。对于业务最了解的需求提出方，无法深度参与数据的获取，处理流程，会导致很多来回沟通与返工的额外开销。
• 从分析产品角度来说，因为底层技术的不成熟，需要做很多额外的工作，例如查询优化，二次计算，本地缓存，OLAP cube 建模等等，反而忽视了产品核心的分析能力和用户体验。
• 在应用落地方面，分析与决策相对割裂，一般都是导出分析结果后再通过其它方式进行呈现，讨论，最终进行决策，这个流程中又引入了决策人员与分析师的认知 gap，也会有很多额外开销与返工。

这几个因素叠加，让传统的数据消费变得非常低效，容易出错，相关项目的 ROI 较低甚至很容易回退到抛开数据凭经验决策的旧方法上去。

理想中的现代数据分析流程如下：

1. 决策人员有了一个业务问题，首先在数据分析工具中搜索相应的关键词。
2. 选择与之相关的，经过数据 owner 认证的数据集。
3. 对数据进行自助式的交互分析。也可以通过一些增强分析能力，由系统自动诊断生成数据中的洞察。
4. 创建可视化仪表板，形成图文并茂的数据故事。还可以选择将分析结果一键推送到移动端，或其它业务系统中。
5. 与决策者会面讨论，过程中有新的问题也可以快速通过分析工具进行回答。
6. 迅速形成决策，在业务系统中生成相关动作，也可以为特定场景配置特定的监控和自动化决策流程，减少后续的人工介入。
7. 所有流程都可以在一个整体的产品中完成，减少任务切换。业务人员解决完一个问题后，可以立刻开始探索下一个问题。

怎么样，是不是感觉好了很多！

2.2 挑战和趋势

为了实现这个理想的分析流程，也就给 Modern Data Stack 中的数据分析部分提出了很多挑战。很多现代 BI 软件的发展趋势都顺应了这些挑战：

• 为了与整个 Modern Data Stack 协同，实现较低的运维成本和强大的弹性扩展能力， 现代 BI 产品也必须适配云原生的基础架构要求 。而传统的私有化部署将很难融入 cloud infra 中，遇到存储，计算方面的需求时必须单独进行规划和维护，效率，性能和稳定性都存疑。
• 以业务为中心，对于产品力也提出了更高的要求。 现代 BI 产品需要满足多种数据消费者角色的需求，包括业务人员，数据分析师，数据工程师，数据科学家等 。不同角色对于产品能力上会有不同的要求，且整个流程的串联与协作也需要非常细致深入的考量，并以先进的架构设计进行配套服务。
• 业务的自助分析获得初步成功后，很快随之而来的就是 面对大量的分析场景和业务应用，我们如何进行有效的管理，编排，监控，运维和持续优化 。这对于传统的高门槛的分析软件来说是全新的挑战。很多一开始推崇完全自助分析的产品也都在大规模应用后，遇到了这方面的问题。
• 随着数据分析成熟度的提升，数据消费的覆盖范围也会开始拓展， 从单一的分析，到之后的决策，业务流程打通，形成决策闭环 。这对于分析软件来说一方面提升了对决策相关能力的需求，如预测，仿真，优化等；另一方面也对于其 composable 能力有了更多的要求，能够与各类业务系统融合打通。

接下来我们会主要从这四个方面来详细阐述现代 BI 产品的演进趋势。

3 云原生架构

传统的企业级软件栈都是以硬件采购，私有化部署模式为主的。这种方式在启动成本，产品项目的快速交付与迭代，持续的运维开销，可扩展性等方面都具有比较大的问题。

以数据分析中的 ETL 数据准备为例，一般在业务系统更新数据后，每天会在固定的时间段触发大量的 ETL 计算操作，将业务数据载入到分析系统中。这个时候就对计算资源提出了非常高的要求，需要采购大量的服务器资源才能够满足。一旦完成了 ETL 操作，整个系统的负荷又会很快下降到一个较低的水平，大量的服务器资源又处于一个闲置的状态，造成浪费。而现代云服务就能比较好的解决这类弹性计算资源的需求问题，降低成本。

随着云原生技术的兴起和成熟，越来越多的企业都开始拥抱“上云”，带来了诸多好处：

• 各种存储，计算资源都可以做到按量付费，灵活扩缩容。
• 各种专业技术能力如身份认证，数据安全，负载均衡，动态扩展，计算优化等都可以通过调用成熟的云服务来实现普惠。
• 在服务接口标准化的情况下，灵活的替换云服务产品，获得极致的用户体验也会变得越来越便捷可行。

云服务让用户可以专注于核心业务

随着这个大的发展趋势，数据分析软件也必须符合云原生的架构标准，才能充分享受到这些“技术红利”。具体如：

• 数据分析软件本身应该按照云原生的标准来进行设计，研发与部署运行。如微服务，容器化，DevOps 和持续交付等。
• 组件化架构，除了核心模块外，各种扩展功能支持“即插即用”，通过 serverless 的方式按需启动。后续也能在此基础上形成丰富的数据应用市场。
• 支持对接各类主流的云服务，从底层的公有云基础设施，到核心的云数仓，再到各类 SaaS 云服务，而不是各种功能都只能使用自身实现。
• “云无关”特性，不与某个具体的云服务深度绑定，适应各类企业的不同需求，同时也能利用不同云中最适应业务需求的服务。例如使用 Azure 来做企业级身份管理，而利用谷歌云做机器学习相关能力的拓展。

当然云服务时代也给企业带来了新的挑战，尤其是在新应用的部署越来越方便的今天， 如何更好的去管理和优化云计算的费用开销，成了一个新的课题 。以往碰到一些效率低下的 SQL 查询，或者没有被用户使用的 workflow，顶多占用一些已有的硬件资源而已。但在云服务时代，一条有问题的 Snowflake 查询，就可能要花掉公司几百块钱。如果这个查询被反复执行，而其产出结果却没人来消费，那就真的是“烧钱”了。而且云服务本身的可选项也越来越丰富，同一件事情可能有好几种不同的云服务和计费方式可以选择，进一步提升了问题难度。

另一方面，如何满足企业级应用中多租户，资源隔离以及计算优先级等问题，即使在云计算时代也仍然是一个需要面对的重要课题。

我们观远数据在这块处在国内比较领先的状态， 从 16 年第一行代码开始就跑在了 K8s 环境上，很多基础能力都同时考虑了私有化部署和公有云服务对接的兼容性 。这几年更是与很多超头部企业一起共建，积累了很多大型公有云，私有云基础设施深度集成协作的经验，能够在上万 CPU 的集群上执行复杂的计算调度，服务整个企业多个事业部 3 万名以上的活跃数据分析师、决策者用户。

在管理云计算开销方面，我们也做了不少创新的实践， 推出了“云巡检”功能，与后面提到的数据管控与观测能力一起，在保证高质量的数据分析应用交付的同时，还能不断控制降低不必要的计算开销 ，可谓是云时代的必备核心功能了。

4 自助分析：从服务到产品

前面有提到，以往的分析软件以服务 IT 部门为主，业务方发起需求，由 IT 部门来进行满足。所以分析系统以一种被动提供服务，响应需求的形式存在，周期长，效率低。现代分析软件的一个重要趋势就是 将被动服务转变为主动打造“数据产品” ，做更系统和长远的规划，协同业务部门一起来推动数据赋能决策。

4.1 数据产品

实现自助分析的一个核心观念转变是打造数据产品，而非被动响应服务。那么什么是数据产品呢？

简单来说，就是通过提供数据，来满足各类企业决策和流程应用的产品。我们在日常生活中其实也在很多情况下不经意间在使用数据产品，例如出门逛街时找吃饭的地方，我们就会打开大众点评应用，上面列出了各种饭店的类型，多个维度的评分，评价人数，具体的评论信息等数据，我们通过分析这一系列的数据，最终做出选择（想象一下如果这个过程需要通过 dashboard 来完成）。这个过程与企业内部的业务决策者流程很相似，所以说 数据产品并不只是复杂的 dashboard 的形态，而需要根据不同的用户角色来进行特定的交互设计 。例如对于很多业务人员来说，移动端的数据智能应用就更加方便易用，而不是碰到任何的业务问题都需要打开电脑来做复杂的看板分析。

日常生活中的数据产品

数据产品的构建需要引入产品设计思维：

• 我们需要去深入了解用户需求，设计 user story，撰写设计文档等。
• 系统性规划产品的长期 roadmap，关注产品的功能，性能，可扩展性，ROI 等属性，并持续与用户同步。
• 需要了解各类领域知识，例如前面提到的不同垂直领域的决策者，可能对产品形态的要求就会很不一样。
• 需要有相应的 SLA（如典型的数据质量指标），提供帮助文档，各类技术支持等配套。
• 需要做持续的用户推广，并设定相应的客户成功指标，例如通过数据产品来提升决策速度和质量。
• 可以借鉴产品迭代开发的模式，这一点后面我们会再展开。

需要注意的是数据产品的核心还是在分析型应用，辅助决策和业务流程，而不是自研各种 data infra。相反，为了实现数据产品化，投资于自助式的数据类软件会是非常有帮助的。他们相当于 提供了一个底层的“数据操作系统”，提供标准的数据收集，存储，消费能力 ，帮助企业的数据团队能更好的在这之上去构建数据应用产品。

4.2 数据消费者倒三角

产品思维中很重要的一点是明确目标客户，我们来看下数据产品需要服务的目标用户有哪些。一般来说，企业的数据分析决策相关人员会分成下图中的几类角色：

数据产品用户组成

1. 业务决策者 ：通过数据来做业务情况监控与决策的用户，一般会专注于某个垂直场景，如供应链，市场，销售，财务，人力资源等。他们一般会使用的数据产品的功能包括指标查看，监控与告警推送，移动端或业务软件中的嵌入式分析等。这类用户也会非常受益于新一代的增强分析能力，例如自然语言的数据问答，数据洞察的自动推荐等。
2. 业务分析师 ：在业务问题驱动之下进行深入分析的用户，尤其在一些复杂场景，跨部门的交叉分析领域，为决策者提供数据洞见。他们一般会进行高级交互式分析，what-if 场景分析，协助进行业务数据准备，构建数据故事等。
3. 分析工程师 ：从这一层开始往下，主要就是数据产品的开发者群体了。分析工程师是结合业务理解与 IT 能力的开发者，为分析师和决策者构建相应的数据，可视化，分析应用基础。他们主要负责数据建模，ELT 开发，分析应用设计开发，数据质量，数据管控，以及相关的流程编排等方面工作，也可以利用一些 autoML 的能力进行一些算法建模开发。
4. 数据科学家 ：深入业务流程的特定 AI 解决方案开发者，将企业整体的分析成熟度进一步提升，实现决策建议甚至自动化决策流程。他们主要进行各类探索性数据科学实验，AI 解决方案设计和流程开发，主要依靠 notebook，IDE 等代码开发环境的支持。

当然这几个典型分类在不同规模的公司也会有不同的体现，相对小型的公司可能会主要分为数据开发者和消费者两类，而大型公司可能在这个基础上进一步细分出数据工程师，BI 工程师，数据运维，数据产品经理，数据大使等角色来。

另外这里只考虑了数据方面的相关角色，没有把软件开发，基础架构，云服务运维等方面的角色放进来。如果考虑商业化问题，那么我们还需要关注企业管理者角色的思考与决策方式，可能会对具体的采购行为有较大的影响力。

这几类角色的用户数量会呈现一个倒三角的分布，例如典型的例子可能是决策者 10000 人，分析师 1000 人，看板开发 300 人，AI 建模 30 人这样的比例。

为了服务多种多样的用户群体，就对现代数据分析软件提出了更高的要求。传统的 BI 软件基本上都只能提供可视化，看板的组合，但我们知道对于市场部门来说，体验最好的肯定是 Google Analytics 这类的分析形式；对于门店店长来说，通过移动端数据应用来获取信息与实时分析或许效率更高；而对于数据科学家，则必须提供灵活的 notebook 支持。因此 现代的自助分析软件就需要提升在数据消费方面的能力 ，例如支持定制化的可视化，低代码的数据应用开发，各种连接器来实现“反向 ETL”，或提供高级探索实验所需要的 notebook，SQL IDE 支持等。

除了业务用户， 数据产品的“开发者”用户群体也同样重要 ，我们在下面一节来展开描述。

4.3 Analytics as Software

在产品思维之外，数据产品从技术角度也给了我们很多不一样的思考角度。作为软件工程师，我们应该对敏捷开发，持续集成，DevOps 这些工程实践都非常熟悉了。而报表、仪表盘这类数据产品的开发，目前大都还处在一种非常“原始”的状态：

• 瀑布式的开发模式，在交付给最终用户时才发现需求并没有得到很好的满足，重新做需求变更与返工带来大量的资源浪费。
• 缺乏工程化的管理，在项目复杂度上升之后经常因为业务逻辑，数据质量问题消耗大量的排查修复时间。
• 以单一的数据可视化分析为主，用户只能在产品中完成部分需求，没有嵌入到业务流程中形成决策闭环。

因此新一代的分析软件都开始借鉴很多软件工程的思想，提出了“Analytics as Software”的新主张。

4.3.1 软件工程的启发

典型的例子如 dbt，Looker 等产品中，都支持通过代码（DSL）来构建数据处理逻辑和数据模型。使用代码来定义看起来像是提高了使用门槛，跟自助式分析的初衷相违背，但我认为实际上并不矛盾。面向数据产品的“开发者”用户，以及对分析应用的底层构建来说， 需要有足够的复杂逻辑表达能力和简洁性 ，代码是一种非常理想的表达形式。

以代码为核心逻辑的载体，我们就可以利用上很多软件工程的最佳实践 ，例如版本控制，Code Review，代码包复用，自动化测试，持续集成发布，易于自动化集成等。在企业级应用中对数据的需求和重视程度的不断提升， 数据产品项目中涉及到的各种数据源，获取方式，指标定义，数据处理逻辑等各类信息的复杂度已经完全不亚于常规的软件系统了 。不借助这些优秀的工程实践，仅仅靠项目规范把控会很容易积累起数据产品的技术债，效率低下且难以持续。例如 dbt 就是一个非常优秀的以代码为核心的数据转换框架，这两年非常火爆，风头超过了很多主打无代码的拖拽式 ETL 工具：

以代码为核心的数据处理转换

除了以代码为核心，我们还可以 将产品的核心能力通过 public API 进行开放 ，方便各类分析需求与业务流程的深度集成串联，并进行持续的监控和运维，不断优化数据产品的性能，效率和用户体验。前面举了大众点评的例子，可以想象一下如市场投放，风控，客户营销，供应链优化等方面，都会有类似的业务流程结合数据分析的需求。通过开放 API 的 composable 能力，我们就可以 让分析产品的形态更加多样化，更好的满足用户从分析到决策动作的全流程 。这对于构建 data-driven 的企业文化来说也是至关重要的一点。

以代码为核心，分离了“定义”与“运行”，API 开放了底层能力，两者相结合，我们就可以构建一个更加开放的数据应用生态平台 ，让更多的分析工程师，社区爱好者来贡献各类数据插件与应用，基于统一的数据平台，打破企业的数据孤岛，覆盖更多的业务领域。想象一下 如果 Facebook，Uber 这些软件如果诞生在现在，可能就会成为数据平台上的一个应用，甚至两者之间的信息也能做到互通 。这种数据应用市场的未来想象空间是非常巨大的，极有可能颠覆很多现有的企业级业务软件系统，我们也已经观察到不少相关的案例出现。

4.3.2 低代码

如果只是以代码为核心，那么自助式分析的门槛就会变得更高。即使面对开发者用户，我们也需要注意 将业务逻辑跟执行细节能够很好的区分开来 ，例如应该把底层技术细节进行隐藏，无论用的是 OLAP 数据库还是时序数据库，无论是批处理还是流式处理，用户都只需要关心业务的核心逻辑即可，所以数据产品中比较流行的代码基本都是 DSL 形式，降低学习门槛。

而面向业务用户，需要进一步隐藏细节，低代码仍然是一个重要的产品形态 。在 DSL 的基础上，构建业务用户容易理解和使用的低代码产品，也是非常自然的一步。接下来主要讨论下两者之间的关系。

我们日常使用的代码，大都是经过精心设计的通用语言或领域特定语言（如 SQL），可以类比成我们日常使用的汉语，具有非常高的灵活性和扩展性，可以表达任何内容。但缺点是有一定的门槛，就好比大家都认识字，但是写作文的沟通表达能力就可能天差地别。

而低代码的产品则是在代码的基础上做了一层封装，从技术角度来说就是只能调用一些相对固定的 API，通过不同参数，API 的组合来表达业务逻辑。类比到日常生活中，可能比较像手势，或者 emoji 这类符号，对自然语言也是做了一定的封装，好处在于门槛极低，大家都很容易使用和理解如 这样的 emoji。但扩展性和灵活性就会比较低了，我们很难把一堆 emoji 组成一篇复杂的文章。

值得注意的是，并不是说汉语掌握的很好的人就完全不需要 emoji 了， 能够流畅做代码开发的专业人员，也完全可以利用低代码工具来辅助提升其开发效率 ，主要是看应用场景是否是高度需要定制化的。例如我们在做数据模型开发时，如果每次微小的修改都需要人工 pull 代码，checkout 分支，做修改，commit，提 PR，跑测试，review 完成后合并发布，显然是很不友好的。所以可以看到像语雀文档这样的产品里，就隐含集成了一些版本控制的能力，以无代码的方式提升了文档的开发和运维效率。

从前面的用户分层来看，业务决策者和业务分析师在面对很多相对固定的场景时，完全可以使用低代码的方式来实现其相关需求，甚至不需要了解很多底层运作的细节，其易用性和用户体验会明显更优。即使是分析工程师和数据科学家，也可以利用低代码的工具来辅助提升效率。但在一些定制化程度很高的场景，例如业务场景中的 AI 模型开发，很可能需要做很多的特殊处理，这时候如果强行套用低代码工具，可能反而给自己的工作增加了束缚。这也是为何之前很多拖拽式建模开发工具没有得到大规模应用的原因之一。

最后， 代码和低代码工具应该做到紧密结合，这样才能让不同角色的用户能够紧密协作，且在产品体验上能够体现一致性与流畅度 。因为代码的表达能力更强，所以个人认为核心逻辑的存储应该以代码为准，这样也能同时享有前面提到的软件工程实践所带来的各种优越性和便利。通过低代码的方式开发的 ETL，流程编排，可视化，机器学习等逻辑，应该都能直接转化为代码来进行存储，这样就能同时享受到两种方式所带来的优势。这方面的一个优秀的例子是 Looker，业务用户可以用低代码的方式来创建可视化：

通过用户界面编辑可视化

而这些可视化的背后都自动生成了相应的代码，用户完全可以用管理代码项目的方式来管理整个项目，如创建分支，测试，提交 PR，合并发布等。

自动生成 LookML 代码

4.4 增强分析

沿着数据产品的思考逻辑，最后我们再来看下如何提升分析产品的易用性和用户体验。这对于扩大产品的用户渗透率来说是非常关键的一点。近年来一个非常重要的趋势就是 通过 AI 的能力，来辅助用户使用数据分析产品，降低门槛并提升效率 。

其中一些典型的场景包括：

• 数据准备增强，包括 schema 的自动发现，基于数据字典、血缘、profiling 元数据等信息，向用户提供处理建议，提升数据问题排查效率。例如我们可以在 ETL 工具中实现自动的数据 join 操作，或者对引入的数据集做自动化的数据质量检查诊断，提供处置建议。
• 数据分析增强，包括数据解释，基于统计模型的洞察，自动特征工程，自动算法模型构建等能力， 提供场景化的数据见解和决策建议 。例如通过算法来自动查找数据中的隐含 pattern 或异常点，生成相关报告推送给用户，省去繁琐的交互式分析流程。
• 产品交互增强，通过自然语言查询，自然语言结果生成，嵌入式 BI 等能力，提供更简单易用的交互方式。同时支持用户反馈，提供个性化的结果推荐。这个就很好理解了，就像我们使用淘宝那样， 通过搜索和推荐的方式来找到我们感兴趣或者可能有用的数据洞察 。

数据问答与推荐

以业务决策用户为例，要做到数据分析与最终的决策结合，比较自然的步骤是先了解发生了什么，再了解为什么会发生这个变化，最终再给出如何提升的建议。传统的做法一般是通过监控发现问题，然后再由业务分析师进行深入的交互式分析，通过查看海量的看板，执行不同的筛选条件，下钻上卷，最终形成一些结论与决策者讨论。

增强分析的一个核心目标就是为了提升这个流程的效率。当发现公司的销售额出现了预期外的波动时，可以自动进行关键因子的分析，找出引起变化的业务根源，例如是因为某个客群的销售额下降了，再进一步实现客群转化率，续约率，增购的自动建模分析，从几个方向上给出操作建议。这三个步骤可以直接形成一个图文并茂的“数据故事”推送给客户，快速形成感知，理解和决策。

数据分析增强

这背后具体的功能点包括：

• 数据解释
• 自然语言生成
• 自然语言查询
• AutoML
• BI 与 AI 计算范式的支持

通过这些能力，可以大大提升分析应用的实时性，分析深度，个性化场景化的诉求满足，降低产品使用门槛，更好的实现分析与决策建议的结合。用户可以把更多的精力放到提出更好的业务问题和设想上来，而减少在重复性分析工作上的投入开销。

增强分析另外一大方向是扩展数据分析的能力范围，实现 operational analytics 支撑业务决策。我们会在后面的决策智能部分再展开这部分。

4.5 现代自助分析产品

这一节的内容比较多，我们围绕数据产品这个中心点，阐述了多个现代自助分析产品所需要具备的核心能力，包括：

• 对于多种用户角色需求的满足，良好的协作能力，极致的用户体验。
• 代码和低代码两种开发模式的支持，无缝切换，提升数据产品的开发，运维效率。
• 开放 API 的支持，composable 能力，支持分析与业务流程集成。
• 开放架构，应用市场生态的支持，满足各种垂直化场景需求。
• AI 能力加持，实现增强分析能力，迈向智能化、更易用的数据分析产品。

国外已经有很多产品在这些方面走在了前面，例如这几年非常火的 Looker，Mode，GoodData 等 BI 产品，以及在增强分析领域的先驱 ThoughtSpot，Pyramid 等，有很多值得我们借鉴之处。

我们观远数据在这几个方面也有了不少的探索实践：

• 我们的 SmartETL 和 Universe 产品，就实现了代码和低代码开发模式的支持 ，嵌入了如版本控制，自动化测试，代码插件打包，集成发布的能力，对于各阶段的企业，各类角色用户的需求都能有比较好的满足。
• 观远也 提供了完善的 public API 支持，还内置了非常多的行业数据连接器 ，在很多决策智能项目中实现了分析，预测与业务流程的无缝整合，实现决策闭环。
• 观远的数据应用市场从 2019 年开始设计开发，也 逐渐形成了一系列的行业垂直数据应用 ，未来还会不断迭代优化，致力于打造国内最好的分析师开发生态。
• 今年我们也将 正式推出经过了多次内部迭代的增强分析产品 ，目前在金融风控，电商销售分析，客户复购分析等场景上实现了 10 倍以上的效率提升及明显的业务决策效果回报，未来有望形成更多的场景化智能应用。

5 受管控的自助分析

随着自助式数据产品形态的成熟，接下来一个比较明显的挑战是应用场景数量的爆炸，大量的用户和大量的数据内容两者自由组合，就会出现很多管控上的挑战。 一方面自助分析的确给我们带来了灵活，敏捷，可以快速满足业务需求，但如果缺乏系统性的管控又会很快陷入低效和混乱的泥潭之中 。

在很多企业级分析项目中我们都会看到，相关的参与者需要耗费 50-80% 的时间来处理各种数据问题，检查数据源，核对计算口径，处理各类数据质量问题。

项目上线运行后，也需要持续保证数据的可靠性，一旦出现没有及时更新，数据质量出错或者服务不可用等问题，都会影响到公司的日常运作。这也是我们之前提到的 数据产品需要有相应的 SLA 的要求，而且数据的不可用（不仅仅是服务不中断，而数据质量也要得到保证）相比软件系统来说会更加的难以发现和处理 。这里一个典型的指标是“data downtime”，等于 出问题的次数 * （发现数据问题的耗时 + 解决数据问题的耗时） 。

如果 data downtime 的指标居高不下，那么很容易进入数据混乱，缺乏信任，用户各自构建更多的缺乏保障的数据的恶性循环，最终大家会逐渐抛弃现有系统，回到之前通过 Excel 取数和分析的时代。这一节我们就来讨论下如何应对这个挑战，实现受管控的自助分析。

5.1 应用场景的扩展性

当前的很多自助分析产品，大都处于“野蛮生长”的状态。用户可以自由的接入数据，做处理，构建指标，创建可视化分析等，但对于什么是可信的数据源，如何确保指标的一致性和复用，如何持续确保看板数据的正确性，如何找到跟业务最相关的分析内容等问题缺乏考虑。很多企业在这方面的实践还处于建设“数据门户”的阶段，可以想象一下 如果没有搜索引擎，回到 internet 早年的“门户时代”，我们获取和利用信息的效率肯定是大打折扣的 。

在数据处理和计算方面，我们已经有了 SQL 标准，但在元数据领域缺乏统一标准，这也是数据管控需要解决的核心问题。很多时候 我们可以获取数据，也可以获取到 schema 信息，但这份数据是什么时候更新的，有多少用户在使用这份数据，是否通过了相关的数据质量检查，企业统一的指标认证等问题，我们都不得而知 。数据的上游和下游只管读取和写入数据，但却彼此不知道具体的生产和使用情况，想想就是一个很不可靠的状态。

为了解决这个问题，越来越多的 Modern Data Stack 中，都把数据管控，元数据管理作为一等公民来看待，出现了非常多的新兴产品专门针对这个问题，如 Data Observability 领域的 Monte Carlo，BigEye，Data Catalog 领域的 Atlan，DataHub 等。接下来我们对这个领域做一些简单的探索。

5.2 元数据类型

由于本身还没形成行业一致的标准，所以在元数据这块的功能分类也是非常模糊，有非常多的名词，如 catalog，governance，observability，discovery 或者干脆就叫 metadata 等。为了简单起见，这里我们就分为两类：

• Data catalog：以数据静态属性的管理为主，如数据定义，权限控制等。
• Data observability：以数据的动态内容管理为主，用于数据质量的监控与可用性的保证。

元数据功能分类

下面来看下具体的元数据类型，具体的分类方法有很多，我们这里参考的是 DevOps 中对软件系统 observability 的分解，分别是 metric，trace 和 log。我们的产品中应该 支持用户或者系统自动的生成，记录和更新这些版本化的信息，并提供统一的对外服务标准接口 ，且这些能力需要与整个 Data Stack 中的各类组件进行很好的结合，具备数据产品的可编程、可组合能力。

5.2.1 Metric

包含了各种数据的属性信息，很多也属于“数据质量”的范畴，如：

• Schema
• 数据量
• 数据新鲜度
• 数据分布，统计信息
• 数据的完整性
• 数据的准确性
• 数据的合理性
• 是否有重复数据
• 是否有敏感信息

5.2.2 Lineage

顾名思义，血缘关系主要指的是数据之间的依赖信息，包括数据表，字段，算法模型以及分析应用等。

5.2.3 Log

数据与生产消费者间的交互关系，包括：

• 内部数据交互，如数据生成，更新，数据转换的时间点，所耗费的时间等。
• 外部数据交互，用户访问，分析查询，AI 建模等访问信息。

5.2.4 业务元数据

涉及业务的各类信息，如拥有者，所属组织，访问权限，业务定义与说明等。

5.3 元数据应用

关于元数据系统的设计可以参考我们之前云原生数据平台一文中的内容。有了这些元数据的系统性记录和相应的查询服务，我们可以用于各种应用。而且在元数据积累的量达到一定规模后，我们还有机会利用元数据做各类更加智能化的产品功能，如自动数据异常探测，修复建议，更智能的数据发现等。

5.3.1 数据管控

对数据的访问权限，数据安全，合规，一致性与可信度等方面提供支持 。

有了合理的管控，我们能够形成更加清晰、一致的数据架构，减少不必要的复杂依赖。当上游数据发生变更时，也能及时通知下游，避免出现数据误用或其它的质量问题。当然最重要的是，通过数据管控来实现安全与合规方面的要求。尤其在合规方面，大数据架构设计之初并没有很好地考虑用户可能有删除个人数据的诉求，这方面对于数据湖仓及后续数据转换方面的工作都提出了很大的挑战。

5.3.2 数据发现

在数据产品开发过程中，能 让用户更加完整，深入的了解数据相关信息，来判断应该使用什么数据集 。典型的信息包括：

• 哪些数据集已经很久没有被使用了，而哪些数据集有很多消费者。
• 数据最近更新的时间点是什么，是否符合业务预期。
• 数据集中各个字段的业务含义是什么。
• 数据的上下游依赖如何，从哪来到哪去。
• 数据质量以及过去的可用情况如何。
• 数据是否满足相关的业务假设与消费需求。
• 与之类似的数据集有哪些。
• 数据版本随时间推移发生的变化有哪些。

在数据发现服务过程中，如何设计高效且智能的搜索系统，综合相关性，热门程度对结果进行排序展示等都是非常重要的话题。

5.3.3 数据可观测性

最后，在数据被使用起来之后，我们需要持续关注数据的可观测性。相比于软件系统，数据内容非常容易出现“静默失败”的情况，虽然报表还能展示，模型也能正常输出预测，但其实里面所使用的数据可能已经有了很多问题。如果你也是一名数据从业者，肯定碰到过类似的情况：突然有一天用户说数据好像看起来不对，然后经过了几个小时甚至几天的排查，终于找到了问题所在，然后还发现有个处理逻辑已经持续错了几周甚至几个月了。

可观测性主要就是为了解决此类“data downtime”的问题 ，主要包括几个步骤：

• 检测数据问题，当数据出现问题时，能第一时间在最上游感知到问题，影响范围就越小，越容易修复，而不是等着几千份报告发出去之后由用户来报告数据是错的。
• 解决数据问题，当某个环节发现了数据问题时，能够在复杂的数据链路中快速定位到问题原因，并进行修复。这也是我们常说的“对数”问题，如果缺少产品的辅助，经常要耗费大量的时间精力。
• 预防后续的数据问题，在解决问题之后，还需要能很方便的加上相关的自动检查，告警或自动修复机制，避免问题再次出现时需要反复投入时间来进行类似的排查工作。

解决数据问题

以算法自动决策类项目为例，构建相关的数据完整性，质量检查，数据分布漂移检查，对于项目的持续运维来说是至关重要的。如果发现了上游数据出现了巨大的数据分布变化，我们就应该及时停止下游预测输出流程的执行，并告警通知用户，避免产出错误的决策建议，影响业务正常运作。另外也需要持续进行决策效果的追踪和半自动化的误差分析，不断完善整个数据流程中重要部分的可观测性。

Observability 中关心的元数据

5.3.4 综合应用

传统架构中，元数据经常分散在各个组件中，例如数据库，ETL 工具，BI 等。 有了统一管理的元数据中心，就可以提供给 Data Stack 中的各种组件进行综合性应用 ：

• 对于流程编排组件，可以通过获取数据使用情况，来设定编排运行的优先级，让重要的数据优先得到计算生成，提高整体效率。
• 数据产品的自动化测试，持续集成与发布也可以与各类元数据信息结合，帮助我们更好的判断变更带来的影响和潜在风险。
• 在前面增强分析部分有提到，我们可以根据用户的使用习惯，推荐其它相关的数据集或者分析报表内容，这部分的用户行为信息获取，就需要通过元数据方面的获取与分析来完成。
• 支持不同角色用户的协作，例如在数据处理系统中做的各类数据集，指标等信息，也能被数据分析与决策的产品组件获取到；或者通过与工作 IM 系统的集成发送各类通知，实现信息互通。

5.4 自助分析与决策中的元数据

把元数据的话题延展到自助分析与决策方面，除了数据集，对于分析资产的元数据管理也非常重要，市面上也有类似的产品支持：

• Metric store 产品，如 dbt，Transform，LookML 等都希望能构建一个标准的“语义层”，让消费者都能获取到统一定义的可信数据，而不是将逻辑散落在各个报表、可视化内部。
• Model store，feature store，evaluation store 等算法相关的元数据管理产品，之前在聊MLOps 的文章 里有所提及。不得不说大家起名的想象力真的是非常丰富 :)
• Analytics catalog 产品，提供分析资产的元数据管理与各类应用，代表厂商如 Metric Insights。

观远在服务了多家月活分析师数量上千的企业后，也遇到了很多分析资产管控，数据可靠性，安全等方面的挑战，并开发了若干产品进行应对：

• 针对数据质量，可观测性，我们在产品中内置了数据血缘，数据质量检查等功能模块 ，可以支持数据 schema，新鲜度，数据量，分布情况，异常值的自动探测，以及自定义的业务检查规则的撰写，并支持相关报告的自动生成与推送。在进行数据架构重构或数据问题排查时，也可以充分利用血缘功能提高效率。
• 为了在企业中推广数据驱动文化，同时也尽可能优化云计算资源的开销，我们开发了云巡检产品 ，对数据用户活跃度，分析资产的使用率，计算开销等元数据进行了细致的监控记录，并在实际客户场景中发挥了很好的作用。
• 针对数据安全要求较高的行业，我们还推出了敏感信息探测，自动脱敏等相关能力 。结合强大的企业级权限体系，同时支持 RBAC 与 ABAC，提升企业的整体数据安全水平，满足各类合规要求。
• 我们也开始 着力打造指标平台产品，与算法行业特征库一起，提升大型项目中指标管理的标准化程度和运作效率 ，探索未来企业级受管控的自助分析的最佳实践。

6 迈向决策智能

观远对于自身使命的定义是“ 让业务用起来，让决策更智能 ”。前半句对应的是前面提到的数据产品以业务为核心，提供自助化服务，不断提升用户体验。而后半句对应的就是通过产品来不断提升不同角色的分析能力，迈向决策智能。

6.1 什么是决策智能

在完成了基础架构，产品体验，自助式分析的有效管控几方面的基础夯实之后，企业的数据分析成熟度自然就会开始逐渐上升， 从现状分析，到原因诊断，再到未来预测，最终到达辅助决策智能的处方建议 。尤其是后面两点，需要深度结合 AI 能力来进行赋能，实现数据驱动的高质量决策。

分析成熟度

从另一个角度看，迈向决策智能也不仅仅是分析能力的提升，还有一个重要的考量是 要解决“最后一公里”问题，实现由数据驱动的业务流程 。这个方向上也有很多相关的产品能力设计，如实时数据分析，开放 API，嵌入式分析（js，iframe），以及近两年很火的“反向 ETL”。

决策智能维度

这几类决策智能的典型场景包括：

• 当决策的频率较低，且决策的影响较大，或决策动作空间比较灵活时，可以 通过增强分析的方式，将数据诊断结果或决策建议提供给用户，再由人工来决定最终决策动作 。例如周度经营分析会场景，可以通过增强分析给出业务问题诊断和提升建议，帮助业务做出更高质量的决策。
• 当决策的行为在下游系统发生，有比较固定的业务规则时，可以 实现数据驱动的流程自动化，完成业务闭环 。例如通过反向 ETL，将客户相关的统计信息传输到 CRM 系统中，触发相应的客户关系维持动作。
• 决策的频率高，数量大，且每个具体决策造成的影响较小时，可以 利用数据与决策模型流程闭环来实现自动化决策 ，比较典型的场景如导航软件中的路径规划与行程时间预估，电商购物场景中的推荐系统等。

Gartner 对决策智能的分类

从上面的场景举例可以看到，很多决策的最终形成都是在“业务系统”中的，那么是否意味着在业务系统中去构建数据分析能力也就足够了呢？这也是我们经常看到很多客户会直接使用例如 ERP，CRM 系统或者“生意参谋”这类产品中的数据分析模块，而没有另外构建所谓的“数据产品”。这种做法在企业发展的某些阶段或许是适用的，但从长期来说，单一系统内能够获取到的信息是相对有限的，在进行电商营销类决策时，我们也需要引入生产，物流，仓储，供应商管理，财务，人力资源等等方面的信息辅助，否则就 容易在数据孤岛状态下做出一些“局部最优”的决策 。利用数据平台加上决策应用产品的设计思路，能够减少很多重复建设的工作，并且保证决策信息输入的完整和一致性。

6.2 决策智能产品能力

为了实现决策智能，现代数据产品也需要配备相应的关键功能点：

• Notebook 开发集成，对于机器学习预测能力的落地，往往需要深入业务流程做模型逻辑的特定实验与开发。因此 notebook 开发能力的集成是非常重要的，支撑数据科学家完成相关的工作。例如 Mode 中就有很好的 SQL editor 和 notebook 支持。
• AutoML 能力，对于特征预处理，特征选择，模型选择，参数调优方面的任务，大都已经可以用 AutoML 的能力来满足，而不需要再花费数据科学家的额外时间，也可以赋能分析工程师来做一些自助建模。具体可以参考之前 关于 AutoML 的介绍文章 。
• 模型解释能力，单纯的模型预测输出很难与人工的判断进行结合，尤其是增强分析的辅助决策场景中，我们需要提供一定的模型解释能力，让业务理解模型给出预测建议背后的原因，便于进一步的分析与判断。
• 运筹优化引擎，利用运筹或强化学习技术来满足业务决策中的仿真和优化诉求。典型场景如工厂排产，仓网规划，运输计划生成等。这方面 IBM 的 CPLEX 是一款比较知名的工具，也很好的集成在了他们的产品体系中。
• 因果建模与推理，目前的算法模型绝大多数都是以统计学为核心的，无法真正实现认知决策中所需要的知识表达，逻辑推理方面的能力。当然这方面的发展还处在比较早期，业界相关的探索与应用还比较有限。
• 用户交互与反馈，在人机协同场景中，数据产品需要收集各类人工判断反馈，并作为输入数据的一种，实现算法的不断迭代优化。
• MLOps(AI Engineering) 能力，在决策智能逐渐普及的情况下，数据产品中需要越来越多处理跟特征服务，模型服务，模型指标监控，自动重训练，以及模型元数据管理等方面的问题。这也是一块非常新兴和活跃的产品市场，有很多相关的创业公司都瞄准了这个方向。
• 实时数据分析，业务决策的环境是快速多变的，因此我们需要支持实时的数据流和分析预测能力，才能更好的服务对时效性要求很高的场景。比如我们在看一些电竞比赛时，教练在做 Ban/Pick 时就需要非常实时的阵容信息更新，并以此推算不同英雄的选择胜率等。
• 开放 API，这一点也在前面有提到，为了实现决策落地，数据的最终消费形式需要非常灵活，可以通过 API 的方式让各类垂直应用来获取相关信息。在这个领域也出现了很多新兴的低代码 App 构建厂商，如 retool，Appsmith 等。
• 反向 ETL，让分析工程师开发和维护数据到业务系统的对接还是件比较麻烦的事情，需要考虑同步进度，失败重试，checkpoint，rate limit，以及 API 变更等问题。因此出现了一批类似于反向 ingestion 的产品，提供更加流畅，低门槛，低运维成本的用户体验，比较知名的如 Census，Hightouch 等。

在决策智能方向，观远从成立之初就一直倡导 BI + AI 结合的产品形态，提供了丰富的产品功能支持，也在很多 500 强头部企业实现了项目落地。例如：

• 观远在 Universe 平台中提供了非常强大的 notebook 集成，SQL 开发能力 ，可以无缝与 BI 用户协作，共享相关的模型产出与业务指标追踪分析。
• 观远的 AutoML 模块与模型解释能力可以同时为模型开发，增强分析等场景进行服务，让业务分析师也能快速构建预测模型，并理解模型预测背后的参考因素 ，应用在金融风控，用户营销，需求计划，门店选址等热门场景中。
• 为了完成决策的最后一公里闭环， 观远的主要产品线都提供了丰富的开放 API 能力，通过 Atlas 应用市场可以实现多个流程的串联打通 ，配合垂直场景的应用，解决了很多现有业务系统、流程中的效率痛点，比如面向供应链场景的计划助手系列产品。

7 总结

前面我们从产品技术趋势和企业分析成熟度两条线穿插介绍了关于 Modern Data Stack 中的自助分析与决策产品的一些思考，如果把演进时间线加上，大概是如下的形态：

未来的自助分析与决策产品

不同的企业在不同的阶段可以根据这个思路来设计自己的产品技术栈和相应的数据产品用户群体和应用范围。《The Self-Service Data Roadmap》一书中还给出了很具有实操性的计分卡和相关提升手段，来帮助评估企业当前的数据自助服务能力水平，并设计相应的 roadmap。

企业数据平台记分卡样例

从实现数据赋能决策的最终目标出发来看，好的产品技术肯定是其中的重要一环。如果你对于如何做代表未来的企业级 BI 产品选型有兴趣，欢迎领取下载由我们观远出品的企业级 BI 平台白皮书。据说企业级移动 BI 白皮书也已经在路上了，值得期待一下。