编者按：
9 月 10 日晚，七牛云主办的「云加数据，智驱未来」数据科学系列论坛如期举行。在直播中，Kyligence 创始合伙人 & 研发副总裁马洪宾为我们带来了主题为《大数据分析的云原生趋势》的精彩分享。
嘉宾简介
马洪宾，Kyligence 创始合伙人 & 研发副总裁，Apache Kylin 核心开发者及项目管理委员会成员 (PMC)。专注于大数据相关的基础架构和平台设计。在从事大数据和数据仓库相关工作之前，曾经是微软亚洲研究院的图数据库 Trinity 的核心贡献者。目前担任 Kyligence 企业级产品的研发负责人，帮助客户从传统数据仓库升级到云原生的、低 TCO 的现代数据仓库。
首先为了让大家有一个更强的代入感，马老师先介绍一个典型客户。这是一个快速增长的 SaaS 公司，在 40 多个国家有 1800 多个客户，其中覆盖了世界 500 强的 1/3，这些客户会每年带来超过 80 亿条的交易记录，所以说它是有一个非常大量的数据需要进行分析和挖掘。那么对他来说，他需要为这1800个客户提供丰富的报表来供他的这些客户进行分析。
他们把所有的数据放在了 AWS 的 RDS 中。显然 RDS 是没有办法满足目前的并发和性能需求的，所以这位客户不得不做了很多物化视图来加速它的 Dashboard。即便如此，现状仍然是有很多的查询需要花五秒以上的时间。因为这些报表都是由终端客户去使用，所以五秒的时间并不是特别可以被接受。除此之外，每天还需要花四个小时以上的时间去刷新所有的物化视图，数据准备的时间也会非常的长。更主要的是，目前 1800+ 的客户有可能是会在每天的差不多同时间去访问他的这些报表，但是基于目前的方案，可能只能支撑十个左右的并发。这意味着它的大部分的这个客户可能需要进行排队或者是花很长的时间才能刷出他的报表。
这个客户的核心需求是在云上做核心数据分析。这些需求主要包含以下几点。第一点是希望能够给终端用户一些灵活的报表。第二点是希望所有的报表能够提供一个比较好的性能，而且能够提供比较好的并发度。期望可以实现 100 个左右用户的并发。接下来的比较大的诉求是希望这套新的这个方案能够比较好的 scale。客户同时也提出了对数据准备的时间和对数据安全的要求。最主要的，是希望整个方案仍然可以像过去一样是 totally 在 AWS 上运作的，这样他不需要考虑多个环境的问题。当然出于成本的考虑，也提到了希望就最后整个方案是有一个比较低的 TCO。最后也提到了对数仓或者数据平台的选型是一个开放式的平台，这样将来能够接入一些机器学习或者是数据挖掘的这个能力。
带着这个客户的基本情况，马老师为我们拓展到未来数据分析与云原生趋势的解读，分享在数据分析领域或者是在数仓里面看到的云原生的趋势。当今，要不要上云已经没有歧义，但是可能有的人还会想，数据分析或者是我的数据资产，我的数仓，要不要上云。
上图是从 Google Trend 上获取的近五年的关于 Data Warehouse（蓝色）、Data Lake（红色）、Redshift（黄色，AWS 的著名云原生数据仓库）和 Hadoop （绿色）这四个关键字的热度趋势。可以观察到，最近的五年内，Hadoop 关键字的热度迅猛下降，Data Warehouse 的热度保持稳定，而 Data Lake 和 Redshift 的热度都有显著提升。另外值得一提的是，早在 2016 年初前后，Redshift 的热度就已经超过了 Data Warehouse，并且在最近超过了疲态明显的 Hadoop。
这也与我们的观察和感受一致：越来越多的企业客户正在从 On-Premise 的数仓方案，转向基于云（包含公有云和私有云）的解决方案，这种趋势在美国 2B 市场已经被广泛接受，在国内 2B 市场也已方兴未艾。由于无可取代的弹性扩展性、容灾性、低 TCO 和几乎无限量的存储空间，基于云平台的数据仓库技术正在逐渐让所有人相信拥抱云原生才是数据仓库技术以及相关数据分析技术未来。云原生的巨浪正在席卷全球的软件产业，包括开源软件和商业软件。在数据仓库这个细分领域，我们能明显的感受到数据仓库正在经历以下几代体系的演进：
第一代：传统的数据仓库
最早出现的是数据库一体机，是由单独的硬件软件所构成，这种数仓的问题主要在两个方面：第一，它需要专有的硬件，成本较高；第二，它的扩展性不高。在过去这样的问题是可以被用户接受的，但是在现今的大数据时代，有很多开源的技术可以用来在普通硬件上构建大数据平台，不愿意被单独的供应商或者硬件平台绑定，所以一体机模式的数仓越来越难得到普及。
这样的背景很自然地催生了第二类数据仓库的兴起：
第二代：基于通用硬件的分布式数据仓库
这类的数仓方案通常可以基于通用硬件（Commodity Hardware），在可扩展性上相比较传统的数仓有了质的飞跃。在笔者看来，这类的数仓也可以分为两大类，即 MPP 数仓（在商用数仓软件的代表是 Greenplum，在开源数仓的代表有 Presto 等）和批处理数仓（典型代表是 Hive 和 Spark）。MPP 和批处理的区别有点超出本文的主要范围，在此就不展开了。值得注意的是，和 Hadoop 有近亲关系的 Hive 虽然非常有可能随着 Hadoop 的巨轮一起慢慢消失，但是它却为第二类数仓带来了一种极其通用的数据表元数据定义的标准，并被 Presto，Spark 等技术全面地沿袭，成为了事实上的标准。
第二类的数据仓库获得了巨大的成功，放眼国内，无论是一线大厂还是不知名的小公司，都围绕这类技术开发除了完整的数仓和分析平台，大大地提高了大小企业对数据资产的发掘能力。但是这类数仓的弊端也慢慢地暴露出来：因为数据不断增加，需要不断增加节点，导致企业不得不自行投入扩建机房，继而进行全面的迁移数据工作。运维团队和业务团队无奈承受着背后的繁琐和低效，苦不堪言。此时不断成熟的云厂商给大家带来了新的可能：
第三代：第一代云原生的数据仓库
以 Amazon Redshift, Azure SQL DW 为代表，在云计算开始之初，云厂商就为用户准备好了用于分析型业务的云上数据仓库产品。这类数仓产品一般都需要申请一个固定节点数量的集群，都配有列式存储技术、分布式查询等特性。但是，由于云上有无限的计算节点资源可以申请，用户可以随时调节集群中的计算节点数量。无论是集群的启停、扩容、升级，这些操作都可以在云厂商的界面上通过几次点击完成，已经在云原生度上与第二类数仓有显著差异。
这一类数仓依托云上无限扩容的基础硬件设施，免除了运维人员在集群规模扩容时的空间困扰，需要更多的资源只需要在网页界面上点击即可完成。但是这类数仓数据和计算没有完成分离，会导致什么问题呢？比如某个用户已经申请了一个 10 台机器的节点，这 10 个节点每个都有计算资源（CPU）和存储资源（磁盘）。由于 workload 的增加，用户发现需要增加更多的计算资源才能满足，于是不得不把数仓配置从 10 个节点升级为 15 个。但是，这额外的 5 个节点的存储资源也是要收费的，即便用户的数据在原来的 10 个节点中完全够存。在这种情况下，用户的诉求是买更多的计算资源，但实际情况是他不仅购买了更多的计算资源，还购买了用不上的存储资源。这就大大增加了这样的数仓方案的 TCO，限制了企业在数据资产的有效利用。
第四代：新一代的云原生数据仓库
以 Snowflake, Amazon Athena, Azure Synapse, Amazon Redshift Spectrum（严格地说 Amazon Redshift Spectrum 只是一个 Redshift 的插件）为代表的新一代云原生的数据仓库，进一步实现了云上数仓计算与存储的分离。在第三类数仓中，即使用户已经在对象存储中准备好数据，仍然需要将数据导入到数仓后，才能进行查询。而第四类数仓可以直接查询用户在对象存储中的数据。在第三类数仓中，用户如果发现集群空间不足，不得不对集群进行扩容，这样不仅是在为更多的存储支付成本，而且在为更多的计算支付成本，即使他不缺少计算资源。而在第四类数仓中，用户在对象存储中的数据按量计费，在数仓节点中的计算按量计费，两者相互独立。
这种新一代的存储和计算分离的数仓架构催化了我们耳熟能详的数据湖数仓架构体系。在这种架构下，所有的数据都可以可靠、廉价、方便地存储到对象存储上（Amazon S3，Azure blob storage, ADLS），云厂商提供了完整的配套工具来确保用户的应用数据库、日志、APP 的数据可以顺利地落地到对象存储上。这种区别于块存储和文件系统的存储方式从根本上决定了云原生数仓的存储形态乃至设计形态：数据不再保存在某个节点的磁盘中，存储和计算天然分离，计算所需的一切存储，都来自遥远的、无限的、透明的对象存储中。
那总结一下，我们观察到数仓或者是数据分析在云上的趋势，首先是充分的利用云上的技术架构。不需要去操心机房的事情，不需要操心硬件的问题。第二点是会充分的利用云上的对象存储。第三点是会充分的利用云上弹性计算资源的这个特点，根据你的需要申请更多的资源或者是释放资源。经过一番梳理，我们可以看到数据仓库正在慢慢向云原生的、存储计算分离的方向上发展。企业做技术选型，以及我们自身做技术战略投入的时候，自然也需要尊重并拥抱这样的时代趋势。
现在，再回过头来看这位我们最开始提到的美国客户。通过云原生的方案，我们基本已经解决了大部分的问题，再结合 Kyligence 的方案，针对高性能、高并发的痛点，也给出了比较好的解决方案。
Kyligence 的方案主要给用户解决两大关键的问题。一个是在云原生解决方案当中的性能问题。一个是在云原生的解决方案中语义层的问题，也就是数据口径一致的问题。目的是为了确保同一个公司内大家对数据的理解是一致的。
通过我们在 Apache Kylin 上的积累与在新技术上的探索，以及在 Data Placement 的智能优化。从设备层面，会做 RAM，SSD 和对象存储之间的切换。从数据解决层面，在列式存储，多维数据集等为主的数据结构上进行切换。在服务层面，使用到Spark，ClickHouse 等计算中间件来完成用户的计算需求。同时也希望通过自动化的手段帮助用户减少手动调参或手动介入的必要。
