共计 3771 个字符，预计需要花费 10 分钟才能阅读完成。
近日，Google Cloud、Kyligence 和 WebEye 独特举办了「智能数据助力企业数字化转型」的线上研讨会，Kyligence 技术合伙人兼副总裁李栋在会上分享了主题为「Kyligence Cloud 简化数据湖多维分析」的演讲。
以下为李栋演讲实录
大家好，我是李栋，Kyligence 是 Google Cloud ISV Partner，往年咱们最新的云原生多维数据库产品 Kyligence Cloud 也反对了 Google Cloud，明天我将会给大家介绍企业如何通过智能多维数据库，从业务视角治理数据湖。
1. 数据湖剖析典型痛点
越来越多企业都开始在云上搭建数据湖，撑持企业外部的数据分析和数据决策，但在数据湖和真正的数据利用之间往往存在很多痛点。现在，少数企业面临的不再是数据量过少，而是数据量太多，这导致业务用户在查找和应用数据时，难以精准定位到想要的数据。
从数据入到数据湖，再到被业务用户应用，不仅时效性较差，而且整个过程依赖数据工程师去进行 ETL，数据开发流程比拟沉重。所有 ETL 都须要耗费大量计算资源和存储资源，会大大晋升数据平台的老本；而随着数据的增大，TCO 也会逐步增长。这些可能是每一位在应用数据湖相干技术的用户都会遇到的问题。
这里举 Kyligence 服务的一线互联网电商企业作为例子，这家企业在 2019 年开始搭建本人的数字剖析平台，正式进入数字化转型的阶段。其所有数据要通过数据库，落到数据湖，上游是各种数据产品、报表以及 BI、AI 的利用等，用户从数据湖中剖析数据，应用一段时间就会发现数据湖逐步进入“浑水期”。
企业所有数据加载到数据湖上，起初可能只有 5700 多张贴源层 ODS 表。然而随着业务应用越来越多，每一个数据分析需要或每一个数据产品背地都须要从源表进行一系列的加工和解决，就变成超过 100 万张的宽表或聚合表。尽管现阶段数据分析和数据利用的业务能够失常发展，然而企业在数据湖的数据管理方面会逐步地进入凌乱的阶段。
举个例子，这里的 order 表就是订单表，它被业务援用的次数很多，咱们能够看到它的整个后继节点。在数据血统上来看，一个 order 表的后继节点至多有超过 1 万多张表。 同样的一份原始数据，可能被加工成了一万多张宽表，利用在不同的业务和数据分析场景中，后续就会带来很多问题 。
如果这里 ETL 的计算逻辑、指标加工的逻辑、数据时效性等这些生命周期的治理不统一，很容易造成同样一份数据进去的指标后果是不一样的。那么对于这家企业而言，他们就会面临“宽表爆炸”的状况。其实当初很多企业都面临相似的挑战，这大大影响了数据分析的 ROI，短期来看数据分析的指标兴许达到了，然而背地的投入和老本其实是过高的。
1.1 数据口径不统一
一个 order 表就衍生出上万张宽表，宽表间是短少信赖的。用户在应用时，很难说哪张表的数据是最可信的。对于这家电商而言，不同区域或者部门计算出来的 revenue 指标累加在一起，很可能和间接从贴源数据里加工算进去的 total revenue 是不一样的，这种状况可能在很多企业并不少见。
1.2 浑浊的数据湖
对于整个数据湖而言，数据存储方面上会变得更加浑浊。每个业务部门或者 BU 都会有一些属于本人的数据集。对于一个订单数据而言，财务部、经营部门、市场部门都会基于这个数据去来打造本人的数据集。其实，这背地的很多数据指标往往是共享或者是逻辑统一的，然而这些数据自身却很难被复用。而这些问题的积攒就会导致宽表爆炸更加强烈，这些 ETL 和宽表的快速增长会带来大量存储和计算资源的冗余。
1.3 IT 老本过高
如果企业的用户数增长了 100 倍，那 IT 的老本难道也须要增长 100 倍吗？其实这样增长是难以管制的，不同业务的复杂程度是不一样的。如果因为某些业务很简单，就把整个 IT 老本进步，而其余业务并不需要，就会产生老本节约。
2. Kyligence 智能多维数据库产品
Gartner 2022 年报告指出，以后数据湖上的很多企业，在引入数据仓库等技术去撑持数据分析时，也心愿通过数据仓库的实践改善数据管理方面的痛点。通过 Kyligence 智能多维数据库，企业能够把数据集市或者是 OLAP 实践引入到数据湖，解决数据管理类的问题。
2.1 产品架构
下图是 Kyligence 产品的架构，从整个技术架构上来看，只有数据曾经接入到 Google Cloud，比如说云存储、Google SQL、Google BigQuery 等，企业就能够从该平台接入数据并创立数据模型来搭建数据集市。
Kyligence 智能多维数据库中最外围的概念就是多维数据模型，从数据源中接入数据，创立出多维数据模型，而后通过规范的 SQL 或 MDX 接口，将多维数据模型在 BI 工具或 Excel 等数据分析的工具中进行生产。
Kyligence 以 Apache Kylin 为外围，交融了 ClickHouse 等技术，来撑持数据分析中高性能和高并发的场景。同时，Kyligence 的 AI 加强引擎，能够依据查问模式的变动，主动优化数据模型，一方面节约老本，另一方面优化性能。Kyligence Cloud 反对无缝兼容 Google Cloud，只有数据在 Google Cloud 上就能够间接应用，从而减速数据洞察和剖析的过程。
因为多维数据模型的存在，每个模型外部会对立存储所有数据的指标，对立数据指标口径的治理，自动化和简化数据开发的过程。同时，Kyligence 的 OLAP 引擎能够针对大数据量进行优化，企业能以更低的 TCO 来撑持更大的数据量。
2.2 外围概念
在关系型数据库中，数据往往是两维的，表要么是行，要么是列。然而理论的业务往往是多维的，比方业务剖析，大家会从不同维度和属性查看指标及数据洞察。如果想要从业务视角来治理和剖析数据湖，多维数据库会是更好的形式。因为在多维数据库里外围概念是多维数据模型，而不是表。
传统关系型数据库中的原始表可能只有 DBA 或者懂技术的共事能力了解，但多维数据模型用的是业务语言，裸露的间接是维度和指标，业务人员可能更好地了解数据和应用数据。
同时， 多维数据库把所有的业务语义和指标进行对立的治理 ，而不是扩散地存储在各个宽表外面。从接口上，其实只有定义好一个模型，通过 SQL 或者 MDX 把指标给裸露进来，就能够间接在 BI 工具当中应用。
接下来，通过一个例子来看多维数据库如何解决上述问题。
对于电商企业而言，不同的部门有不同的剖析需要。比方，美国和国内的销售团队，会去做数据加工，生成一张宽表，再进行聚合。以此类推，因为不同的团队数据分析需要不同，都会进行相似操作。缓缓平台里就会呈现八张表，至多有四张大宽表，四张聚合表。但通过多维数据模型，就能够把这些表的数据模型定义在多维数据库中，把所有的数据进行整合。
从存储和计算资源上看，这里其实是从八张表变成三张表的过程，须要生成四次大宽表的超大规模数据集下计算的 ETL 工作，当初只须要一次。 所以整个的存储和计算资源的耗费都会大大的升高，这也是如何通过多维数据模型解决宽表爆炸。
在多维数据库上，企业能够去定义业务剖析应用的指标，并造成指标体系，如根底指标、衍生指标等。如果不同的指标背地对应的数据模型是同一个，那么指标的加工和计算过程是能够复用的。如果同一份数据按不同口径、服务不同业务，则通过衍生指标灵便响应业务需要，既能满足业务多变的需要，又能防止数据冗余导致的宽表爆炸。
在多维数据库中，企业能够对立治理所有业务指标的口径来实现 Single Source of Truth；其次，多维数据模型能够把所有宽表收纳在一起，缩小冗余的存储；除此之外，预计算索引还能够优化查问性能，进一步升高单条 SQL 查问的应用老本。
对于客户而言，通过 Kyligence 多维数据库把最后 5700 多张 ODS 表，逐步变成 2000 多个根底指标和一万多个衍生指标，以治理指标的形式来去治理这些数据，更好地晋升数据服务的 ROI，升高冗余存储。业务人员能够更容易地应用所有指标，实现自助式数据分析；同时，整个架构又是云原生的弹性架构，在 Google Cloud 上能够实现动静的伸缩。
3. Kyligence 指标中台产品实际
Kyligence 基于指标中台实践经验和云原生 OLAP 根底能力，上线了智能指标驱动的治理和决策平台 Kyligence Zen，李栋从以下四个方面介绍了指标中台的能力：
- 指标目录：对立治理所有业务指标口径从数据湖的表开始定义指标，包含根底指标和衍生指标，并将所有指标治理在一个平台中，实现业务指标的对立治理。
- 指标自动化：以指标治理数据，打消宽表操作依据指标定义的逻辑对底层数据进行加工、预计算，并依据指标所在的数据模型进行合并，打消宽表爆炸。若是指标很少被拜访或是不再被拜访，能够主动清理指标数据的预计算后果。此外，零碎也会智能向用户举荐罕用或关联度高的指标，晋升找指标的效率。
- 指标治理：用指标治理指标，造成指标体系治理指标的目标是帮忙企业实现业务指标治理，因而通过治理指标的形式治理指标，造成指标体系，可帮忙企业更好地达成指标。
- API 集成：构建数据利用，统一生产指标数据当指标和指标实现定义，零碎须要一个进口。通过规范的指标 API，让用户轻松构建数据利用，为利用提供统一的数据起源，打消指标割裂和数据孤岛。
如果您对 Kyligence Zen 感兴趣，欢送点击 Kyligence Zen 指标平台申请试用。