现代数据栈中的消费层

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 产品需要满足多种数据消费者角色的需求，包括业务人员，数据分析师，数据工程师，数据科学家等 。不同角色对于产品能力上会有不同的要求，且整个流程的串联与协作也需要非常细致深入的考量，并以先进的架构设计进行配套服务。
• 业务的自助分析获得初步成功后，很快随之而来的就是 面对大量的分析场景和业务应用，我们如何进行有效的管理，编排，监控，运维和持续优化 。这对于传统的高门槛的分析软件来说是全新的挑战。很多一开始推崇完全自助分析的产品也都在大规模应用后，遇到了这方面的问题。
• 随着数据分析成熟度的提升，数据消费的覆盖范围也会开始拓展， 从单一的分析，到之后的决策，业务流程打通，形成