Salesforce大数据平台产品管理产品经理Ram Sangireddy和Kartik Chandrayana撰写，来自Salesforce同事的贡献：Andrew Torson，William Earl，Vincent Poon和Lars Hofhansl
几十年前，与数据和支持技术相关的业务需求已远远超出了世界。 那时是小数据时代，数据可以存储在单个商店中，而基于设备的数据仓库（DW）解决方案可以满足大多数业务需求。 随着大型组织中数据量迅速增长到PB规模，基于设备的DW解决方案的局限性（例如，数据整合，存储和计算的耦合，维护成本，数据敏捷性不足等）很快就开始出现并开始出现。 扼杀了交互式分析解决方案的有效性。
因此，行业开始建立新的模型，其中包括存储和计算的分离-通过根据工作负载对计算和存储进行有效的独立扩展，以实现对大数据的更有效的临时交互式分析。 随着分析涉及查询越来越多的多维大数据，以列格式存储数据也变得越来越普遍。
这些趋势为类似数据仓库的功能带来了技术创新，而没有基于设备的传统数据仓库解决方案的限制，从而可以实现更广泛的用例-例如，查询日益分散的数据源，临时交互分析而不是预先创建的报告和仪表板，以及对非聚合数据的处理需求，以获取更精细，更细化的见解。 这些用例需要更多具有低成本临时查询处理的大规模并行处理（MPP）技术。
在Salesforce中，大规模数据被广泛分发。 事务性存储中有数十PB的数据，数据中心每月累积的日志数据超过5PB，到目前为止，Hadoop存储中累积了近200PB，每分钟将近2亿个指标存储到时间序列数据库中， 其他属性中的数据。 此外，许多数据也是按地理分布的。 在这样的规模和复杂性下，Salesforce在B2B企业中是无与伦比的，可以与最大的B2C规模的公司媲美。 我们需要支持对这些数据集进行批处理，流处理和交互式即席查询处理； 虽然Apache Spark是我们在各种大数据计算用例中的首选解决方案，但我们仍需要找到一种适用于临时交互式查询处理的合适解决方案。
考虑到上述所有因素，MPP计算引擎将非常适合其在高度分布式的数据源上进行临时的，交互式的，人工的时间分析的能力，同时也与托管基质无关。 该引擎应支持SQL中的分析查询（这是分析人员进行数据探索的主要来源），还应支持新兴用户（如打算直接在大数据上发现见解的公民数据科学家）。
简而言之，我们的评估旨在通过即席查询找到适合我们围绕交互式分析的需求的技术，其中包括以下几个关键标准：
· 对peta字节规模数据的临时查询的人员时间响应延迟
· 对标准SQL查询的成熟支持，能够连接不同的数据集
· 连接到各种数据源，轻松添加新的连接器
· 计算引擎，具有查询的分布式处理，可独立于存储进行扩展
· 具有活跃社区的开源软件
我们根据上述标准评估了多种技术，并希望与我们分享最终发现的解决方案以及我们发现的解决方案。
· Drill：Apache Drill是一个高度可扩展的开源应用程序框架，其中包括一个SQL查询引擎。 它可以从各种主要的非关系数据存储区（例如NoSQL数据库）中获取数据。 它基于用于数据的无模式JSON文档模型，因此它比基于基于模式的列式数据格式的引擎更灵活，但速度较慢。
· Impala：Apache Impala是用于大数据的高度可扩展的开源分布式SQL查询引擎，主要面向Hadoop集群上的数据。 它权衡了容错性以提高速度，将中间结果保留在内存中以提高性能，并且从某些指标来看，它是最快的交互式查询引擎。 它使用256 MB的文件针对Parquet列式数据格式进行了优化。 对于相同数量的数据，它在处理大量小文件时可能效果不佳。
· SparkSQL：Apache SparkSQL是用于大数据的高度可扩展的开源分布式SQL查询引擎，具有许多数据存储的连接器。 它可以为基于模式的列式数据格式提供非常高的吞吐量。 对于非常大的查询（在许多处理器上运行数小时至数天），这是一个不错的选择，因为它可以将临时结果捕获到临时文件中，并且可以以较少的时间开销重新启动失败的零件。 另一方面，非常小的查询的最短时间相对较长； 同样，如果查询计划无法将中间结果保存在内存中，则保存中间结果的成本会增加中小型查询的资源使用和服务时间。
· Presto：Presto是具有成熟SQL支持的大数据开源开源查询引擎。 Presto绕过MapReduce并在内存中使用特定于SQL的分布式操作。 该体系结构的设计使所有阶段都流水线化，因此没有等待时间，不需要在中间写入磁盘，也不需要将所有数据放入内存，也没有磁盘IO延迟。 Presto将某些操作委托给其查询的基础数据存储，从而利用其固有的分析功能。 此外，Presto可以执行跨平台联接，从而为跨不同数据源查询历史数据提供集中支持。 Presto具有高级SQL支持，其功能包括动态过滤，动态解析函数，SQL定义的函数（CREATE FUNCTION）。 像Impala一样，Presto牺牲了速度的容错能力。
· Druid：Druid在相关技术中是独一无二的：它既是OLAP数据库（可以与Vertica，RedShift和Snowflake进行比较），又是分布式查询处理器，时间序列数据库，具有流处理功能以及具有支持透视图的UI可视化 。 Druid利用数字和时间序列数据提供了最佳功能，并且其连续摄取实时业务事件流的能力使其更适合实时查询。 需要查询大量历史数据的长时间运行的BI查询将必须进行冷存储上传，并且处理时间更长。
· Kylin：Apache Kylin构建为在HBase中管理OLAP多维数据集以支持快速SQL查询。 OLAP多维数据集需要存储许多二级索引（每个维度一个），然后使用快速随机访问来检索记录。 数据仓库文件面向全表扫描（"对于干草堆中的每个项目，如果看起来像针一样，请添加到结果集中"）。 Kylin最适合较小的基数数据，并且对于非常大的数据集而言可能是成本更高的选择。
总而言之，考虑到Salesforce上用于跨不同数据源的peta字节规模数据的人机交互的即席分析的用例，具有连接这些数据集的能力和成熟的SQL支持，我们确定Presto是我们需要的解决方案。 现在，Presto已成为我们大数据计算平台不可或缺的一部分，该平台需要支持数据分析师，数据科学家和开发人员。 借助Presto，数据分析人员和开发人员可以同时从云或本地的多个数据源访问数据，并可以通过自定义的应用程序界面或所选的BI工具运行临时查询。 数据科学家可以将笔记本电脑连接到Presto，以对数据进行大规模的探索和ML建模，而无需处理一部分数据。
随着我们继续在Salesforce上构建大数据计算平台，我们将分享更多的工程经验和业务成果。 敬请关注！
(本文翻译自Ram Sangireddy的文章《Big Data, Big Decisions: Finding the Right Technology for Interactive Analytics at Salesforce》，参考：https://engineering.salesforce.com/big-data-big-decisions-690a00fad88d)
閱讀更多 聞數起舞 的文章
關鍵字: 国创上头条 Ap Salesforce
