​现代数据栈中的消费层 BI+AI 产品的演进

  • ITPUB社群

    2023-01-31 13:51:45
  • 服务器/存储
  • 转载

导读 本文将分享现代数据栈中的消费层 BI+AI 产品的演进，从数据栈整体的起源开始，介绍一些数据栈当中的消费层，并展望 BI+AI 的发展趋势。

全文目录：

1. 什么是现代数据栈

2. 现代数据栈中的自助分析

3. Analytics AS Software

4. 增强分析与决策智能

分享嘉宾｜周远 观远数据 首席科学家

编辑整理｜张了了 聚水潭

出品社区｜DataFun

01

什么是现代数据栈

1. 传统数据栈的问题

传统数据栈的典型架构如上图所示，企业中会有各种的数据源，如文件、数据库、业务应用等，这些数据通过 ETL 软件进行处理后漏斗到数据仓库中，最后再提供给报表或者 BI 等应用。
传统数据栈中最大的一个问题是性能受限、成本很高；在上世纪 90 年代左右，大多数企业都使用类似 MySQL 或 PostgreSQL 这种 OLTP 数据架构做为数据仓库，当数据量特别大时性能就会出现瓶颈，这时就需要去做一些横向拓展；也可以去采购一些类似 Teradata 的商用数据库。因此在当时来看，数据仓库的软件及硬件都非常贵，而且性能也不够好。在这种情况下，数据应用的输入及输出都需要做优化。输入需要用 ETL 工具将数据做一些清洗转换聚合等操作，来减少无效数据；对于报表等输出层如果并发过大的话也会有性能瓶颈，同时一些自主分析也可能会产生慢 SQL，因此在 BI 层会做缓存、查询优化或者建立一些 cube 预计算等优化。间接导致了在 ETL 层还是 BI 层使用门槛都很高，软件需要做的非常复杂才可以支撑某些场景的分析，所以分析人员需要向 IT 部门提申请来满足自己的分析需求，经过排期处理后才能看到想要的数据，整体流程也很长。
从场景来看拓展也比较困难，当数据源新增加了业务应用时，在数仓既想做可视化分析、同时也想做数据科学的分析时，在当时这些商用软件都是一体式的解决方案，因此导致了拓展的局限性。
2. 数据仓库的发展

数据作为企业竞争力的核心，只有将数据的核心价值发挥出来才能做更好的决策。正是因为之前数仓有诸多局限，后面出现了大数据、云原生、AI 等技术来推动数仓向前发展。
从 90 年代的 OLTP 到 MPP 架构，到 2010 年代的数据湖、hadoop，这些概念及技术的变化已经可以支撑很大的数据量了。但当时的数据湖存储的数据还需要做 MapReduce ETL 的工作来将数据导到数仓中去，处理起来比较麻烦，当后面出现了类似 hive 这种框架时，就可以使用 SQL 来做一些批处理。对于实时的交互式查询还没法支持，同时消费层做的也不是特别好。
到 2016 年左右 Snowflake、Redshift 等云数仓开始成熟后，性能、拓展性都有了很大的提升后，就可以基于云数仓架构做一些自助查询操作，包括后面 Databricks 提出的 Data Lakehouse（湖仓一体）概念，本质上也是想将数仓和数据湖的优势结合起来。
3. 现代数据栈的起源：拆分

因为云数仓的逐渐成熟，在 2020 年左右现代数据栈概念开始兴起。
当传统数仓的瓶颈被去掉之后，就可以进行一些模块的拆分；基于云数仓存算分离的架构，当存储不够时就可以只购买 S3 这种的对象存储，当计算不够时就可以只买计算资源；同时 ETL 过程可以拆分，E主要是对接各种数据源，当 API 变更后跟着做一些变更即可，L 是将处理后的数据 load 到数仓中，这两个过程相对固定，而 Transform 因为后面的应用场景不确定，导致了 T 的不确定性。因此后面提出了可以先将 EL 这两块完成，T 这块分析师在需要做分析的时候再完成。从 ETL 变成了 ELT，这个拆分对后面的敏捷迭代有很大提升。
4. 现代数据“栈”

上图是 a16z 公司目前的数据栈的架构，中间的 storage 和 Query And Processing 就是提到的存算分离，前面的 Ingestion and Transport 是 EL 层，而 transform 就是在后面一层。当这些组件都拆开后，就类似微服务的概念了，单体应用拆分成多体应用后就会出现很多需求。
在我们的数据栈中，EL 和 T 拆开后，当编排也被拆开后，就需要另外的组件来跨组件去协调这些工作，因此源数据就分散在各处，就需要有专门的组件去做监测，里面有各种组件，就变成了栈。
其中图中一些高亮和灰的部分是为了区分企业在不同的阶段的需求不同；在前期只有 BI 需求的时候很多栈的东西就不用放进来，如果都是结构化的数据表只有个 warehouse 就可以了；随着产品的迭代演进，组件就可以不断去加，而且组件也可以替换，灵活适配性更强。
5. 现代数据栈的发展趋势

从上图可以看出每个细分的小块里面都有大量的创业公司和产品在里面，也体现了数据发展的趋势有以下几点：

  • 以业务为中心，通过数据的处理去更好的服务业务产生价值；
  • 拥抱云原生来降低企业成本;
  • 模块化产品；
  • 通过 DevOPS 的实践，DataOps 成为”第一公民”。

02

现代数据栈中的自助分析

1. 传统数据分析流程

传统的数据分析流程是业务部门提出问题->向IT部门提出取数需求->数据返回->BI工具制作报表、看板->导出形成报告->展示给决策者，整个流程链路比较长，而且最后如果决策者对数据提出疑问后，可能迭代数月才能解决业务问题，因此传统数据分析的痛点是：

  • 技术：数据处理执行速度慢，可拓展性差
  • 流程：门槛高，依赖 IT 团队的开发实施
  • 产品：BI 侧要做很多优化的额外工作
  • 落地：应用场景少，无法流畅完成决策闭环

2. 现代数据分析流程

当前理想情况下的数据分析流程是提出业务问题后->在数据分析产品中搜索相应关键词->选择经过认证的相关数据->自助式分析->开发“数据故事”，嵌入业务系统->与决策者会面讨论，会上即时分析->快速形成决策；整体流程可能在数小时就能完成，为了达到这样理想的状态，需要实现以下几点：

  • 基础能力：融入现代技术栈，基于云原生架构发挥云计算的优势
  • 以业务为中心：数据分析作为软件产品，以业务为中心
  • 数据管控：合理的数据治理及数据管控，业务可以信任数据

  • 决策闭环：从分析为主到数据驱动决策全流程支持

03 

Analytics as Software

1. 用户体验+决策流程

人们收集到的数据核心还是希望数据能发挥价值，从生活中的很多例子可以看出人们已经用数据在做决策了；上图左边的场景看人们吃饭的时候可能会先打开大众点评，然后根据附近餐厅各个维度的评分来进行筛选，当根据评分产生判断后，就会产生去哪家餐厅的决策，并直接可以在 APP 里完成直接订座并打车。
从上图右边的场景来看，如果是想开饭店的话，用 APP 做分析就比较困难了，这时就需要像 dashboard 这种可视化的东西来展示出附件的餐厅数、消费水平、服务指标等来满足决策的目的。因此 IT 部门就可以主动的去打造这种一体化的数据产品，从而优化用户体验，同时可以完成决策流程的闭环。
2. 数据产品的典型用户

数据产品的典型用户一般分为 4 种，最上面的业务决策者和业务分析师只要做业务监控和决策；到更复杂的业务问题时，需要业务分析师来进行交互式探索分析；最下面的两类人偏向做开发，完成数据和算法的建模。
3. 软件工程的“入侵”

对于开发者而言，从原来的瀑布式开发要转换为敏捷开发，需要让整个开发流程更高效起来；同时 API-first 设计的时候，需要有非常好的开放性和可组合性来满足可以在各种场景把同一份数据提供出去；基于代码开发还是 GUI 操作也是值得讨论的话题，传统的 ETL 开发工具为了更加易用会做成可视化，而有的则提倡代码为中心完成 Transform，两种方式各有优劣；如果把看板当做是分析软件来看的话，插件化的架构来形成数据的应用市场，可以让整个生态做的非常丰富。
4. 代码和低代码的结合

从代码来看，不同开发者在不同的场景下使用的编程语言也是不同的，类似data transform 相对固定的场景，可以直接使用 DSL 语言来完成；而数据科学的开发，则需要使用像 python 这种更通用的编程语言。
而在数据产品中，目前大多数使用的还是 DSL 形式为主。至于代码和低代码的区别是代码有很高的灵活度和表达能力，可以做很多软件工程上的实践，可以实现包括版本控制、自动化测试、code review 等；而低代码入门门槛很低，但是拓展性和灵活性就差很多。两者并不冲突，相反可以互相补充，如上图是产品名为 looker 的 BI 软件，通过可视化的拖拉拽就可以实现对应的效果，而底层通过代码来实现，并通过代码的版本控制来实现敏捷迭代，最终提高用户的使用体验。
04

增强分析与决策智能

1. 数据分析渗透率

对于上层用户体验来说，会涉及到增强分析和决策智能。
而看板和大屏这种对于用户的体验来说是有门槛的，用户怎么理解数据，怎么操纵数据需要有一个复杂的流程，可能需要很长时间的培训才能看懂。使用户理解数据最自然的方式是不断提升企业里面数据分析的渗透率，从开始 10% 的分析师用，要提升到 35% 包括更多业务人员用的时候就需要往 TOC 的体验去演进，演进最直接的方式就是有交互，可以在看板上搜索和推荐。类似在看板上问一个问题，就可以直接展示对应的图表，或者说软件对已经使用了一段时间的用户应该看什么数据可以直接进行推送，告诉用户要基于这些数据做什么处理，同时支持场景化和个性化配置，可以定时定制化推送报告，这样不仅能很好的提升用户体验，而且还能降低用户使用门槛。
2. 数据洞察推荐

而产品实现推荐内容的方式是基于数据洞察。
当使用传统的方式判断商品的销量变化时，一开始只有门店和商品两个影响因子，则需要根据这两个影响因子交叉组合生成各种报表来进行分析；当影响因子有三个、四个的时候，这时候各种组合的报表的数量是巨大的，需要根据这些报表来找到影响业务变化的因素所花的时间也是很多的。
而目前的产品则可以通过一些算法找到报表中最关注的点并进行推送，这样就可以大大降低使用者的门槛，同时可以节省很多时间。推送的内容可以是有趣的数据故事，通过读故事可以很直观的了解整个发生的事情，关注到需要在哪些方面做改进，极大的提升了用户的使用体验。
3. 决策智能：分析能力+自动化

对于分析能力来说，也可以做各种进阶，从原先的基于历史数据的分析，到后面的未来预测类分析。而这种能力的拓展，则需要 AI 技术的加持来实现。我们经常提到的决策智能也分为两个维度来看，从上面大众点评的例子来看，选中了餐厅后提供了打车的按钮可以直接去打车，就是分析和决策结合在一起了，流程更加自动化；而目前出现的反向 ETL，将分析完的数据再反向写回到业务系统中来对业务产生价值，对决策也会起到很大的帮助；而推荐系统不需要人工干预就会根据不同的用户生成个性化的推荐也体现了决策智能。
对于这种增强分析的产品，需要具备模型开发能力、模型解释能力及模型运维的能力，而机器学习更多的是从数据出发去做一些统计，当需要更多的和决策结合的时候则需要具备因果推理、仿真优化、知识图谱等能力，需要更实时的数据分析时 OPEN API 和 Reverse ETL 能力要提升。
05

广告与提问环节

1. 观远数据的实践

观远在实践过程中也做了很多探索，一步一步的把产品的分析成熟度提升。

  • 支持云原生，并且开发出云巡检来检查各种数据的处理、运算所消耗的计算资源，来节省优化企业云资源的开销
  • 多用户角色的支持，同时支持 no-code 和 full-code
  • 开放数据应用市场能力，用户可以搭建各种数据应用，做到开箱即用；
  • 开放API，提供API能力支持业务系统中涉及到的决策场景；
  • 增强分析，通过数据洞察可以发现数据异常点并推送，产生决策建议；

  • 数据安全、数据质量及数据管控。

06
问答环节

Q1：DataOps 实际场景中包含哪些？
A1：通过可观测性来进行数据质量的校验，可观测性体现在业务中的数据的用户隔离、数据表的总览及数据的血缘，对刚加载进来的数据进行检查，如果发现有大的波动变化，结合数据血缘就可以提早介入。
Q2：怎么评估智能分析效果量化值？
A2：借鉴 The Self-Service Data Roadmap 这本书中来说，数据整个应用的流程分成了四个步骤，然后每个步骤里面它都做了一些评分卡的设定，你可以根据企业的现状去做一个打分，打完分之后，接下来再基于这个这现状基础上做一些提升，这样的话整体可以去评估对企业数据产生的价值、链路的时效性、以及人工成本的效率等。
Q3：产品界面问答返回结果是通过 NLP 实现的吗？
A3：目前 ThoughtSpot 这块做的比较好，我们直观的理解返回结果是通过 NLP 实现的，但是 ThoughtSpot 底层使用的是偏编译器的技术，去解析自然语言中的某些关键词，通过映射到实体领域上然后做编译的转换再形成具体的查询。，而在数据分析领域中的问答问题相当复杂，感兴趣的同学可以去看下分享。

请使用浏览器的分享功能分享到微信等