Kyligence 联合创始人兼 CEO 韩卿:从数据分析到企业级指标中台

Author
韩卿
Kyligence 联合创始人兼 CEO
2022年 3月 07日

Kyligence 联合创始人兼 CEO 韩卿:从数据分析到企业级指标中台 近日,Kyligence 春季线上论坛成功举办。本次论坛上,Kyligence 联合创始人兼 CEO 韩卿发表了题为《从数据分析到企业级指标中台》的演讲,分享了数据管理分析领域的一些发展和变化,并介绍了OLAP on 数据湖、云上数据分析代运营和企业级指标中台三大解决方案。

各位朋友大家好!非常高兴今天能给大家介绍我们观察到的数据分析领域的一些趋势。在过去的几年内,数据分析的基础架构层出不穷,出现了一些新的变化。 Kyligence 成立于2016年,由 Apache Kylin 的创始团队成立,Apache Kylin 是第一个由中国人贡献到 Apache 软件基金会的顶级开源项目,今天在全球有超过1500多家企业级的客户在使用。 在过去的几年里,Kyligence 收获了来自世界 500 强和各行业领导者的信任,覆盖金融、制造、零售等各个行业。特别是在金融行业,我们在银行、保险、基金、证券中,都沉淀了一些头部客户和案例。Kyligence 在整个数字化的解决方案中有很多亮点,比如业财一体化、实时营销、数据服务、客户旅程、零售行业供应链、也有类似实时库存等能力。这些场景都是基于我们底层超大规模的 OLAP 数据分析能力为客户提供整个的数据分析和访问的快速的能力

数据管理与分析的趋势

数据基础架构,从中心化走向去中心化架构

大家看到,数据基础架构自“数仓”在1980年开始被提出到现在,已经经历了不同的变化。但在过去的几轮变化中,有一样东西没变——它们都是集中式的。也就是说,过去在构建数据仓库时,企业往往是把业务系统的数据从各个地方汇集过来,进行标准化的处理,再存放在一个地方。不管是 Teradata 还是 Hadoop,或是今天的 Snowflake、Redshift 等,都是类似的构建方式。 但是在过去的一到两年,行业开始出现了一个更大的变化——去中心化,并且已经成为当下最热门且发展最快的基础架构变化,在整个数仓的发展方向上,去中心化是如今云和 SaaS 时代的未来。 同时,咨询机构在近两年提出的 Data Mesh 核心就是去中心化。数据仓库不再按原来的方式收集到一起,而是能够连接到不同的数据源,实时地把数据汇过来,去服务一定的数据服务的应用。

Kyligence 的产品和架构其实是非常符合 Data Mesh 这样的架构和方向,我们现在已经能够做到虚拟化不同的数据源。同时,我们在中间构建了一整套抽象的数据集市层,即传统意义上的统一语义层。 通过统一语义层,我们将企业内部和外部所有的数据当成一个更大的数仓或者说数据湖,然后在上面构建了整体的能力,能够连接相应的数据。同时我们有 OLAP 的引擎,为特定的业务场景去构建相应的数据集市和索引,从而确保下游在访问这个数据的时候够快、够安全等。 如今 Kyligence 的平台已经可以跑在纯云的架构上,不再有任何 Hadoop 的依赖。从公有云到私有云,我们都在不断地推进和演化。

数据即产品

同时我们也观察到,公司以前都会把数据当成资产去运营和管理,但是任何资产其实都是成本。在 咨询机构最新的报告提出了一个非常重要的概念叫数据即产品,这是我们非常认可的未来趋势和方向。我们现在有非常多的客户基于 Kyligence 构建的其实是一个数据产品,通过这样的数据产品,我们已经能够帮客户直接对外提供数据的价值,然后做一些变现,甚至已经可以成为他们核心的业务收入和来源。 在整个过程中,公司的数据文化产生了变化,数据团队不再仅仅是“表哥”、“表姐”,而是跟业务团队组成了数据业务领域团队,更好地为客户的业务目标进行服务,为更好的收益提供数据服务的产品,而不仅仅只是一个数据处理的工作。 基于这些数据管理分析领域的大方向,接下来我将介绍 Kyligence 的三大解决方案:OLAP on 数据湖、云上数据分析代运营和企业级指标中台。

OLAP on 数据湖

第一个解决方案是 Kyligence 提供基于云上数据湖的企业级 OLAP 能力。在整个云的架构下, Kyligence 只依赖云的存储和计算资源。只要把数据打到类似 S3 这样的云数据的存储上,把我们的服务应用起来,你就拥有一个 SQL on S3 的能力了。用户可以直接使用各种各样的 BI 工具,包括 Excel 等。整个数据的管道变得非常的简洁。 同时,我们相应的能力能够大大地降低中间的存储成本、计算成本和数据使用成本。我们通过标准的 SQL 对接各种各样的前端数据工具,通过企业级的管控,也能更好、更安全地管理好客户在这上面的数据。

通过统一的语义层,Kyligence 为客户在云上构建了整个多维的数据集市。业务用户只要消费这样的数据集市,而无需关心这些是数据是来自 Oracle、Hadoop、Snowflake 还是 Kafka 的。用户甚至都不需要关心这是历史数据还是实时数据,通过 Kyligence 批流一体的能力,呈现给客户的就是业务数据的语义,业务人员只需要使用数据就可以了。

Kyligence 提供整个云上统一数据的访问入口,通过 Smart Pushdown (智能查询下压) 的能力,可以将 ANSI SQL 翻译成其他数据源。也就是说,即使你的数据集市没有被我们管理起来,也可以访问原始的数据源,将相应的 SQL Pushdown 过去,拿到相应的记录返回给客户端。 在这个过程中,Kyligence 的 AI 增强引擎也能发挥大量作用。比如用户有越来越多 SQL 历史记录时,Kyligence 发现这是一个热点数据集时,就能推荐给用户,管理员就能够将数据集更好地运维和治理起来。 如今 Kyligence 已经支持非常多的数据源,既包括 ClickHouse、Presto、Oracle 等等传统的数据源,也包括像 Elasticearch 这样的非结构化的数据源,我们也有 SDK 可以给到我们的客户或者是合作伙伴扩展整个的数据连接能力。

此外,Kyligence 统一的数据集市层能够更好地为业务部门去使用。「一次定义,多次使用」企业定义了一个统一的语义层,可以用到 Excel、Power BI、Tableau 以及其他更多的 BI 和数据消费工具里面,用户通过标准的 SQL 语句都可以访问。 在这个过程中我们为客户提供的就是一个统一管控能力。客户所有的数据的定义、安全管理,甚至审计,在 Kyligence 这个平台都可以被管理起来,避免了像在 Excel 的场景中,大量地将数据导出来之后,各处不受控地分发。 在今天,整个数据安全领域安全法的规范之下,企业对于这方面的数据安全管理管控是尤其重要的。Kyligence 能够提供上述能力,同时具有相应的审计接口可以帮企业知道是谁、什么时间、访问了什么数据,帮助客户能够更好地做内部的数据合规工作。

我们在云上一直在做的是:不断地为客户去降低云端数据分析的总体拥有成本。如前面提到的,用户直接可以把数据刷到 AWS S3,或者 Azure Blob Storage 上,Kyligence 直接可以提供 SQL 能力。在这个过程中我们提供弹性伸缩的能力,可以根据集群的使用量在高峰期拿更多的数据资源出来,在这些消费的低谷,可以更好地释放出相应的资源出来,更经济地利用好集群。我们还做到了定时的启停集群,尤其是晚上,我们完全可以把它关掉,从而进一步降低这方面的拥有成本。 在去年年底的时候,Kyligence 支持了 AWS 的 Spot Instance,帮助客户降低了70%以上的云上成本,Spot Instance 的采购可以通过策略,更好地去管理好成本和应用。 我们现在越来越多地在帮助客户把数据分析,从云上的 Hadoop 甚至是本地的 Hadoop 迁移到了整个云上,以更加经济、高效、高并发的方式,为我们的客户提供云上数据分析和管理的能力。

云上数据分析代运营

过去一年中,我们发现 Kyligence 所服务的很多中小型客户,更多需要的是数据能力而不是自己去搭建一整个的数据团队。毕竟整个的数据分析栈、技术栈以及技术架构等还是比较复杂,企业需要有专业的人士和团队去掌握和使用。针对上述痛点,Kyligence 今年也推出了全新的解决方案——云上数据分析代运营。

现在已经有部分客户选用全托管,甚至是半托管的方式和我们合作。我们可以确保数据不走出客户的 VPC(虚拟私有云),保障数据的安全性。由 Kyligence 提供专家服务能力,我们的专家服务团队已经服务了各行各业的领先客户,客户无需构建运维团队,甚至可以进一步降低数据工程师团队。 大家知道,如果您建立了一支大规模的数据技术和分析团队,而工作不饱和的情况下,成本是相当高的。这就是 Kyligence 代运营服务中非常重要的价值,就是将我们的核心能力,通过代运营的方式赋能客户。 与此同时,我们还提供超过 99.9% 的 SLA 的保障,客户整个系统的监控运维、整个的技术栈的升级、相应的其他能力都由 Kyligence 来承担和服务,用户只要关心 API,和数据服务能够给到你什么即可。

我们有一个非常成功的案例是来自 Strikingly (上线了)。他们原来是我们开源 Kylin 的用户,构建了非常好的、类似于 Google Analytics 的网络流量分析的平台,在过去一段时间里用得非常不错。去年,我们不仅仅把这样的应用迁移到了 Kyligence Cloud 上来,还提供了代运营能力,帮我们的客户省掉了 50% 以上的云的成本,在这个过程中帮他们去掉了云上的整个 Hadoop,同时省掉了运维团队。 目前 Strikingly 整个的运维是由 Kyligence 团队进行承担和保障,在这个过程中我们提供24×7的支持,我们现在也收到了来自客户非常好的反馈,也看到了成本的进一步的降低,我们希望能够将这样的能力赋能到各位客户。关于这个案例更多精彩的内容,我们将在 Kyligence 公众号分享给大家。

企业级指标中台

第三个解决方案,给大家介绍的是企业级的指标中台。 我们观察到,在过去构建整个基础建设的过程中,尤其是大规模的企业客户群体,比如银行、保险行业,沉淀下来的企业级指标中台能力是非常通用,也是一个非常普遍的需求。在这个过程中,我们也服务了很多领先客户搭建了企业级指标中台,有非常好的落地实践以及平台能力,所以今天展开为大家分享。

1. 为什么要建指标中台?

在过去的几年里面,很多 CIO 是非常焦虑的。如果企业使用了一个中等规模以上的 BI 或者是数据仓库的技术栈,就会有几百到几千张的报表,每张报表如果有十个以上的指标,那就意味着有几万甚至几十万的业务指标。这些口径是不是统一?这些数据是不是在被人使用?这些相应的价值其实已经非常复杂了。

更焦虑的是,其实是整个的过程会让 ETL 任务和中间表进行大量的膨胀。我们有一个客户,一张原始的表产生了几万张的衍生表,同时在整个数仓里面有几百万张表。这不仅仅是存储的问题,它带来更大的挑战在于,它有无数的 ETL 的任务其实在不断地做着重复性的工作,不断地消耗整个数据集群的资源。 其实在这个过程中,通过 Kyligence 的 AI 增强引擎的能力,和统一的数据集市能力,是可以解决一部分问题的,可以帮助我们的客户达成一些碳中和的目标。

2. Kyligence 如何支撑企业搭建指标中台

在 Kyligence 的解决方案里,我们会更多地关注整个数据集市层,关注以表为中心的方向。今天我们会从原来关注的以数据集市为中心,过渡到以数据集市及指标为中心的方向上来。我们希望通过这样的多维集市能够为上层的指标提供更好的能力。我们也希望能够更好地跟其他的上下游进行合作,能够将这一块内容做得更好。

基于现有的 SQL,Kyligence 可以通过 AI 增强引擎推荐或者识别出相应的一些数据集市。基于这些数据集市可以进一步推荐出一些相应的重要指标。以前你可能需要人工使用它,今天可以通过系统自动化地进行推荐和治理。 这是一个被深入使用的技术和能力,尤其在平安银行。在这个过程中大大地降低了整个 ETL 的调度任务以及人力的干预。Kyligence 不仅可以从现有的其他系统里把这个指标抽取出来、管理起来,我们也能够以一个宽表的形式,让你在后面自动化、或者半自动化地过渡到以维度为模型的一个经过治理的平台。

我们可以看一个简单的细节。在这个过程中你可以看到在最左边有我们的维度表和事实表。在中间我们会构建一堆数据集市,供我们上层的应用去使用。我们管理好了原子指标之后,我们的业务人员就可以基于这些原子指标不断地去创建、衍生它的业务指标。 在这个过程中,我们的系统就会匹配到后面相应的一些共同的能力。要么跟现有的数据集市或者 Cube 合并,要么创建新的数据集市,从而一方面能够支撑业务高速的数据使用和自助化的能力,同时在 IT 端有很好的治理,避免整个后台的失控。

在这个过程中也看到,我们可以通过推动指标治理来做到更好的数据治理。因为只有指标被使用、被消费,数据才能发挥更大的价值。Kyligence 可以帮助企业管理口径的规范,比如重复的指标、异动的指标,还有一些空值分布的异常等。通过在指标层面上的应用,我们可以帮助客户去进一步地治理好整个背后的数据和能力。

3. 客户案例

这部分来自平安银行对外宣布的案例,Kyligence 目前帮平安银行管理了超过1.1万多个指标,这个指标里面 IT 团队只管了非常少的原子指标,其他的衍生指标全部是由业务团队自助进行制作和管理的。在这个过程中我们甚至减少了超过30%以上的 ETL 的任务,为整个的平台的优化和使用带来了非常大的保障。 可以看到不管是基于个性化的指标推荐,还是基于 AI 能力的指标的治理和预警等等,包括归因分析,为业务人员提供了非常丰富的指标分析和管理能力,在整个 IT 端,我们还帮客户降低了大量的运维任务,通过 AI 的增强引擎,通过自动化的能力,更好地把平台管理好。

同时,我们还助力了建设银行的经营作战指挥室等基于指标的应用,从大屏到作战指挥室到整个的应用。同时,我们还服务了宁波银行,通过手机端的智慧经营来进行基于指标的业务管理模式,能够更好地去服务到业务增长和服务一线的业务人员去使用数据。

在整个指标过程中,我们希望向各位更好地沉淀指标构建的建设方法论。在当今时代,我们希望基于指标为中心去构建整个建设的方法论。

大部分企业的痛点是非常相通的,这些痛点我相信各位应该都会有感触,尤其是类似规模或者类似行业的。在几百万张表,在几百万个 ETL 交流的过程中,其实非常痛苦和非常有挑战。回过头来,所有的点都是从管理开始的,任何指标平台一定是一个管理系统,这也是为什么我们三步走的原因。

第一,我们一定要从高层开始建立共识,而不只是建立一个可视化的平台,我们一定是为了服务某个管理目标。

第二,我们希望更加聚焦、更加快速地去做闭环。所以我们从一个部门或者从一条产品线完成整个闭环链路,能够看出来效果。尤其是在分部门的过程中,我们会发现指标的定义,其实它的口径是不一样的。其实在这个过程中,技术是解决不了这类问题的,会带来很大的挑战。我们的方法论就是在一个部门或者在一条产品线内把它打通。因为在这个过程中,指标口径基本上是一样的,整个指标治理的目标应该是一致的,最后的效果也是非常容易被量化的。当我们有这样的比较好的产出之后,我们就可以不断地去进一步地上更多的应用,能够边使用、边治理,不断地看到这样的价值。