至少与数据有关的所有组织迟早都会面临存储关系型和非结构化数据库的问题。 同时找到一种方便，有效和廉价的方法来解决这个问题并不容易。 并确保数据科学家可以成功地使用机器学习模型。 我们做到了-尽管我不得不修改它，但最终利润甚至超过了预期。 我们将在下面讨论所有详细信息。
随着时间的流逝，任何银行中都会积累大量的公司数据。 可比较的数量仅存储在Internet公司和电信中。 发生这种情况的原因是监管要求很高。 这些数据并不是闲散的-金融机构的负责人早就想出了如何从中获利的方法。
我们都从管理和财务报告入手。 基于这些数据，我们学习了如何制定业务决策。 通常，需要从银行的多个信息系统中获取数据，为此我们创建了合并的数据库和报告系统。 由此逐渐形成了现在所谓的数据仓库。 很快，在此存储的基础上，我们的其他系统开始工作：
- 分析型CRM，可以为客户提供更便捷的产品；
- 贷款传送带，可帮助您快速准确地做出贷款决定；
- 忠诚度系统根据复杂程度不同的机制计算现金返还或奖励积分。
所有这些任务都可以通过使用机器学习模型的分析应用程序来解决。 从存储库中获取的信息模型越多，它们将越准确地工作。 他们对数据的需求呈指数增长。
关于这种情况，我们来到了两三年前。 当时，我们使用SAS Data Integration Studio ELT工具基于MPP Teradata DBMS进行存储。 自2011年以来，我们与Glowbyte Consulting一起建立了这个仓库。 集成了15个以上的大型银行系统，同时，为实施和开发分析应用程序积累了足够的数据。 顺便说一下，就在那时，由于许多不同的任务，商店主要层中的数据量开始呈非线性增长，高级客户分析已成为银行发展的主要方向之一。 是的，我们的数据科学家渴望支持她。 总的来说，为了构建数据研究平台，恒星应按预期方式形成。
规划解决方案
这里有必要进行解释：工业软件和服务器即使对于大型银行来说也是一种昂贵的娱乐。 并非每个组织都能负担得起在顶级MPP DBMS中存储大量数据的能力。 您始终必须在价格和速度，可靠性和数量之间做出选择。
为了充分利用可用机会，我们决定这样做：
- ELT负载和CD历史数据中最需要的部分应留在Teradata DBMS上；
- 将整个故事发送到Hadoop，这使您可以便宜得多地存储信息。
大约在那个时候，Hadoop生态系统不仅变得流行，而且变得足够可靠，便于企业使用。 有必要选择一个分发工具包。 您可以构建自己的数据库，也可以使用开放的Apache Hadoop。 但是在基于Hadoop的企业解决方案中，来自其他供应商（Cloudera和Hortonworks）的现成发行版已经证明了自己更多。 因此，我们还决定使用现成的发行版。
由于我们的主要任务仍然是存储结构化的大数据，因此在Hadoop堆栈中，我们对与经典SQL DBMS尽可能接近的解决方案感兴趣。 这里的领导者是Impala和Hive。 Cloudera开发并集成了Impala和Hortonworks-Hive解决方案。
为了进行深入研究，我们为两个DBMS组织了负载测试，同时考虑了我们的配置文件负载。 我必须说，Impala和Hive中的数据处理引擎有很大的不同-Hive通常提供几种不同的选择。 但是，选择权取决于Impala-以及相应的Cloudera发行版。
我喜欢Impala的地方
- 由于与MapReduce相关的替代方法，分析查询的执行速度很高 。 计算的中间结果不会在HDFS中折叠，从而显着加快了数据处理速度。
- 镶木地板中镶木地板数据存储的高效工作。 对于分析任务，通常使用具有许多列的所谓的宽表。 所有列很少使用-从HDFS中仅增加工作所需的列的功能可以节省RAM并显着加快请求的速度。
- 带有运行时过滤器 （包括布隆过滤器）的优雅解决方案。 由于HDFS文件存储系统的性质，Hive和Impala在使用经典DBMS通用的索引方面都受到很大限制。 因此，为了优化SQL查询的执行，即使在查询条件中未明确指定可用分区，DBMS引擎也应有效使用可用分区。 此外，他需要尝试预测需要从HDFS中提高最少数据量以保证对所有行的处理。 在Impala中，这非常有效。
- Impala 使用LLVM （一种具有类似RISC指令的虚拟机编译器）来生成最佳的SQL查询执行代码。
- 支持ODBC和JDBC接口。 这使您几乎可以立即将Impala数据与分析工具和应用程序集成。
- 可以使用Kudu来规避HDFS的某些限制，尤其是可以在SQL查询中编写UPDATE和DELETE构造。
Sqoop和其他架构
Hadoop堆栈上的下一个最重要的工具是Sqoop。 它使您能够以各种格式（包括Parquet）在Hadoop集群中的关系DBMS（我们当然对Teradata感兴趣）和HDFS之间传输数据。 在测试中，Sqoop显示出很高的灵活性和性能，因此我们决定使用它-而不是开发自己的工具来通过ODBC / JDBC捕获数据并将其保存到HDFS。
对于数据科学的训练模型和相关任务，这些模型和相关任务可以更方便地直接在Hadoop集群上执行，我们使用了Apache
Spark 。 在其领域中，它已成为标准解决方案-原因如下：
- Spark ML机器学习库
- 支持四种编程语言（Scala，Java，Python，R）；
- 与分析工具集成；
- 内存中数据处理可提供出色的性能。
购买了Oracle Big Data Appliance服务器作为硬件平台。 我们从生产电路中的六个节点开始，每个节点具有2x24核CPU和256 GB内存。 当前配置包含18个相同的节点，最大可扩展到512 GB的内存。
该图显示了数据研究平台和相关系统的顶级体系结构。 中央链接是基于Cloudera（CDH）分发的Hadoop集群。 它既可以用于Sqoop接收，也可以用于QFS数据以木地板格式存储QCD数据，从而可以使用编解码器进行压缩，例如Snappy。 集群还处理数据：Impala用于类似ELT的转换，Spark用于数据科学任务。 Sentry用于共享数据访问。
Impala具有几乎所有现代企业分析工具的界面。 此外，可以将支持ODBC / JDBC接口的任意工具连接为客户端。 为了使用SQL，我们将Hue和Hadoop的TOAD作为主要客户端。
由SAS工具（Metadata Server，Data Integration Studio）组成的ETL子系统，以及基于SAS和Shell脚本编写的ETL框架，使用存储用于存储ETL流程元数据的数据库，该ETL框架用于管理图中箭头所指示的所有流程。 。 根据元数据中指定的规则，ETL子系统在QCD和数据研究平台上启动数据处理过程。 因此，我们拥有一个端到端系统，用于监视和管理数据流，而与所使用的环境（Teradata，Impala，Spark等，如有必要）无关。
通过耙到星星
卸载QCD似乎很简单。 在输入和输出处，关系型DBMS通过Sqoop接收和溢出数据。 从上面的描述来看，一切对我们来说都很顺利，但是，当然，这并非没有冒险，这也许是整个项目中最有趣的部分。
鉴于我们的数量，我们不能希望每天都完全传输所有数据。 因此，必须从每个存储设施中学习如何区分可靠的增量，当历史业务日期的数据可以在表中更改时，这并不总是那么容易。 为了解决此问题，我们根据加载和维护历史记录的方法将对象系统化。 然后，针对每种类型，确定了Sqoop的正确谓词以及加载到接收器中的方法。 最后，他们为新对象的开发人员编写了说明。
Sqoop是一种非常高质量的工具，但并非在所有情况下以及系统组合中都绝对可靠地工作。 在我们的卷上，与Teradata的连接器无法最佳工作。 我们利用了Sqoop的开源代码，并对连接器库进行了更改。 移动数据时连接的稳定性提高了。
由于某些原因，当Sqoop调用Teradata时，谓词不能完全正确地转换为WHERE条件。 因此，Sqoop有时会尝试提取一个巨大的表并在以后对其进行过滤。 我们无法在此处修补连接器，但找到了另一种方法：强制为每个卸载的对象创建一个带有强制谓词的临时表，并要求Sqoop对其进行超填。
所有MPP（尤其是Teradata）都具有与并行数据存储和指令执行相关的功能。 如果不考虑此功能，则可能会发现所有工作都将由集群的一个逻辑节点接管，这将使查询的执行速度大大降低，一次为100-200。 当然，我们不能允许这样做，因此，我们编写了一个特殊的引擎，该引擎使用QCD表的ETL元数据并选择Sqoop任务的最佳并行化程度。
存储的历史性是一件很棘手的事情，尤其是如果您使用
SCD2 ，而Impala不支持UPDATE和DELETE。 当然，我们希望数据研究平台中的历史表看起来与Teradata中的表完全相同。 这可以通过组合通过Sqoop接收的增量，突出显示更新的业务密钥并删除Impala中的分区来实现。 为了避免每个开发人员都编写这种复杂的逻辑，我们将其打包到一个特殊的库中（在ETL lang语“加载程序”上）。
最后-有关数据类型的问题。 Impala可以自由进行类型转换，因此我们仅在类型TIMESTAMP和CHAR / VARCHAR中遇到了一些困难。 对于日期时间，我们决定将数据以文本（STRING）格式存储在Impala中，格式为YYYY-MM-DD HH：MM：SS。 事实证明，这种方法可以使用转换日期和时间的功能。 对于给定长度的字符串数据，事实证明，Impala以STRING格式存储并不逊于它们，因此我们也使用了它。
通常，为了组织Data Lake，他们将半结构化格式的源数据复制到Hadoop的特殊阶段区域中，然后Hive或Impala为此数据设置反序列化方案以用于SQL查询。 我们以同样的方式。 重要的是要注意，不是所有内容，而且将其拖到数据仓库中并不总是有意义，因为文件复制过程的开发和方案的安装比使用ETL过程将业务属性加载到QCD模型中要便宜得多。 当仍不清楚需要多少源数据，需要多长时间以及以何种频率使用时，上述方法中的Data Lake是一种简单且便宜的解决方案。 现在，我们定期将主要生成用户事件的来源上载到Data Lake：应用程序分析数据，Avaya自动拨号器和答录机的日志和过渡方案，卡交易。
分析师工具包
我们没有忘记整个项目的另一个目标-使分析师能够利用所有这些财富。 以下是指导我们的基本原则：
- 使用和支持工具的便利性
- 数据科学任务中的适用性
- 使用Hadoop群集而不是应用程序服务器或研究人员的计算机的计算资源的最大可能性
这是我们停止的地方：
- Python + Anaconda。 使用的环境是iPython / Jupyter
- R +闪亮。 研究人员在R Studio的桌面版或Web版中工作，Shiny用于开发Web应用程序，这些应用程序通过使用R中开发的算法进行了改进。
- 火花 为了处理数据，使用了Python（pyspark）和R的接口，它们在前面的段落中指定的开发环境中进行了配置。 这两个接口都允许您使用Spark ML库，这使得可以在Hadoop / Spark集群上训练ML模型。
- 可通过Hue，Spark以及使用标准ODBC接口和特殊库（例如implyr）从开发环境访问Impala数据
当前，Data Lake包含来自零售存储的约100 TB数据，以及来自多个OLTP来源的约50 TB。 该湖每天更新一次。 将来，我们将增加用户的便利性，在Impala上引入ELT负载，增加上载到Data Lake的源数量，并扩大高级分析的机会。
最后，我想向刚开始创建大型存储库的同事提供一些一般性建议：
- 使用最佳做法。 如果我们没有ETL子系统，元数据，版本存储和易于理解的体系结构，那么我们将不会精通此任务。 最佳实践可以收回成本，尽管不是马上就能做到。
- 记住数据量。 大数据可能会在非常意外的地方造成技术难题。
- 请继续关注新技术。 新的解决方案经常出现，但并非所有解决方案都有用，但有时会找到真正的宝石。
- 尝试更多。 不要只相信解决方案的市场描述，请自己尝试。
顺便说一句，您可以在另一篇文章中了解我们的分析师如何使用机器学习和银行数据来处理信用风险。