Abstract : At the 10th Meetup Hangzhou Station of the Chinese HBase Technology Community, Alibaba Cloud database technology expert Li Wei shared with you how to build an enterprise-level data processing platform based on the popular HBase and Spark systems, and for some specific landing scenarios. Introduced.
Speaker profile : Li Wei (name: Mu Yuan), Alibaba Cloud database technology expert. Focusing on the field of big data distributed computing and database, with 6 years of distributed development experience, he has successively developed Spark and independently developed in-memory computing. Currently, it provides professional cloud HBase database and computing services for the majority of public cloud users.
The following content is organized according to the speech video and PPT.
This article mainly focuses on the following four aspects:
current challenges,
platform architecture and case
principles and best practices
Alibaba Cloud HBase X-Pack service
1. Current Challenges
Many Scenario Requirements
At present, HBase is widely used in the data processing platforms of various companies. The problems that HBase can solve can be divided into five categories, namely, financial risk control, personalized recommendation, social feeds, time series, time and space, and big data. There are also many scenarios in the above various problems. For example, there is an anti-fraud system in financial risk control. For the anti-fraud system, the real-time inflow of data is first required, and certain processing is required after the inflow of data. For example, risk control during and after the event, the result of risk control is generally to provide online query capabilities through HBase. HBase can provide online query capabilities, but it is lacking in streaming data processing and machine learning algorithm analysis. Another example is the offline analysis scenario where big data is used. HBase is an online data repository. Data can flow in with high concurrency, but how to analyze this data has become a big problem. HBase itself does not have dynamic resources, so an external distributed computing framework is needed for data analysis. This capability is what HBase lacks.
HBase's new challenges
In the face of these problems, how should we deal with them? As we all know, HBase can be widely used in enterprises mainly because it is an excellent online query system. HBase has many excellent features, such as a loose table structure, good random query and range query capabilities, high throughput and low latency, the ability to store massive amounts of data, and the ability to multi-version, incremental import, and multi-dimensional deletion . But at the same time, HBase will also face many challenges in business scenarios. For example, streaming and batch warehousing require corresponding ecological support. It is currently difficult to achieve tasks such as complex analysis, machine learning, and graph computing, and it needs to be implemented with Redis, Integration of big data ecosystems such as MongoDB.
Why Spark？
In order to solve the above-mentioned challenges encountered by HBase, the first thing that comes to mind is Spark. The reason why Spark first thought of it was because of the following four main reasons:
Fast: Through query execution optimization, Cache and other technologies, Spark can quickly analyze data of any amount of data. Logistic regression scenarios are 100 times faster than Hadoop;
one-stop shop: Spark supports complex SQL analysis, stream processing, machine learning, graph computing and other models at the same time, and multiple models above can be combined in one application to solve scenario problems;
developer friendly: At the same time, it supports a variety of developer languages such as SQL, Python, Scala, Java, and R.
Excellent ecology: supports the use of Kafka, HBase, Cassandra, MongoDB, Redis, MySQL, SQL Server, etc.
Let's take a look at the popularity of Spark. From the figure below, we can see that the Spark project on GitHub has more than 20,000 Stars and more than 1,300 contributors, and it has been iterating. Here are two typical examples of using Spark in the industry. EBay used to build a data warehouse based on MPP, but later chose to migrate its 60PB data to Spark for data processing; SQL Server, a heavyweight database, is releasing its 2019 version At the time, it deeply integrated itself with Spark. This is because for a traditional database such as SQL Server, it also lacks the ability of streaming data storage, unstructured data analysis, and machine learning, so I chose Integrate with Spark to achieve complementarity. Similarly, HBase also has similar problems with SQL Server, so the Alibaba Cloud technical team is also implementing the deep integration of HBase and Spark.
2. Platform architecture and case
After having two big data tools like HBase and Spark, how to build a one-stop data processing platform for enterprises? As you can see from the example in the figure below, HBase no longer only provides online queries to the outside world. With the help of Spark, it can connect to message middleware such as Kafka through Spark Streaming, thereby realizing streaming message storage. At the same time, Spark is also a federated query engine. It has a set of DataSource APIs, so it can interface with various external data sources such as MySQL and MongoDB, and can import external data into HBase in batches through Spark jobs. When the data is deposited in HBase, the business will definitely not only perform simple online queries on the data, but may also need to perform certain analysis and machine learning tasks. Spark supports SQL and MLlib, so it can perform related analysis on the data. Realize business processing and data mining, and return the processed data to HBase to provide online query services to the outside world.
An architecture based on the above figure can very well support relevant business scenarios such as accurate advertising recommendation systems, big data risk control systems, real-time processing and calculation of the Internet of Things, refined operations of massive data, and log big data analysis. HBase+Spark can solve 90% of big data-related scenarios without the need to choose too many things to use together like using MapReduce, Storm, Pig, etc.
典型业务场景:爬虫+搜索引擎
接下来结合一些具体的场景和大家分享阿里云的一些客户是如何使用HBase+Spark来解决业务问题的。第一个场景就是某个用户构建了一个搜索引擎系统，其需要通过一个爬虫集群不断地从抖音、微博等爬取一些帖子和评论等内容，这些消息将会存储在Kafka中，而由于这些消息是非结构化的，并且还需要实时地对外提供服务，就需要接入一个Spark Streaming来消费这些Kafka的日志。Spark Streaming主要做两件事情，一件是将非结构化数据转成系统希望得到的结构，第二件事情就是在Streaming的过程中去反查HBase的维表，进行关联和去重，之后将一条完整的数据流入到HBase里面。目前HBase较为适合点查询，但是由于其需要对外提供检索服务，所以会缺少全文检索能力，因此其所作的事情就是将数据表同步到Solr里面，并基于Solr对外提供全文检索以及复杂查询的能力。与此同时，系统每天每月将HBase数据同步到Spark里面并归档到数据仓库中，并对于数据仓库中的数据做一些复杂的分析。
该场景的业务价值在于：基于Spark Streaming流，系统在性能方面，峰值能够达到每秒20万条的吞吐；在查询能力方面，HBase能够自动地同步到Solr对外提供全文检索的查询能力；从整个系统来看，就是基于HBase+Spark+Solr构建了一站式解决方案，从而解决了其业务问题。
典型业务场景:大数据风控系统
第二个比较典型的场景是一个2C的业务，平台需要暴露给外部客户，那么总会出现一些恶意的用户想要***系统，比如进行DDoS***或者发布恶意消息等，因此企业需要构建自己的风控系统。通过风控系统来识别异常行为，需要将异常行为检测出来并且进行拦截，而且在发现这些行为之后还需要在事后将损失降到最低。
对于风控而言，主要分为事中风控和事后风控。对于如上图所示的系统而言，登录、下单、支付等事件源的数据会流入Kafka，因为Kafka适合于流控，因此可以作为消息中间件，当然这里也可以选择其他的消息中间件。之后Spark Streaming将会消费Kafka里面的数据，在这个过程中会读取之前已经训练好的规则库，基于这些规则以及实时消息可以判断某个行为是否存在问题，因此基于Spark Streaming就可以实现事中风控。当识别出一些不良行为之后，大数据风控系统会提取这些不良数据的特征并将数据写入到HBase里面，之后可以通过Spark SQL查询出在某一段时间内哪些用户发生了不良行为，进而运营人员可以实现针对性的风控处理。另外一部分就是事后风控，由于Spark Streaming是实时的，因此如果处理逻辑比较复杂，就容易造成消息的堆积，因此就需要事后风控。事后风控所做的就是进行全量的计算进而发现不良行为，比如系统每天会将HBase、RDS以及MongoDB等数据全量地同步到Spark里面进行分析，比如像训练Spark MLlib模型也是需要全量数据的，需要读取全量数据库来训练模型并进行全量的分析，分析完成之后对运营提供查询，最终回流到HBase里面。这样的一套架构也是非常典型的，可以基于HBase+Spark实现事中和事后的风控，并且Spark还可以非常友好地对接各种生态和组件。
典型业务场景:构建数据仓库(推荐、风控)
第三个比较典型的场景就是构建数仓。之前构建数仓使用MPP架构基本可以实现，但是当数据量增大之后，MPP的扩展性远不如HBase+Spark。阿里云的一个用户之前基于Greenplum构建数据仓库，但是当数据量增大之后就会遇到很多问题，比如Greenplum运行数据量比较大的Join、Group By等操作会导致集群挂掉，并且集群扩容速度也会变慢。因此，该客户希望通过HBase+Spark构建数据仓库，这样构建之后，客户的数仓不仅降低了成本，还使得性能得以提升。
如上图所示的就是比较典型的数仓架构，其总体架构主要分为四层。从下向上来看，最底层是操作数据层，这里存储的是原始的数据，比如服务器日志、用户中心数据、广告监测等。原始的数据进入数仓之后，由于数据往往不够规整，因此需要进行一些ETL操作，在该方案中通过Spark Streaming消费Kafka的数据再写入到Phoenix里面，于是就到了数仓的第二层——数据明细层。所谓数据明细层就是说这些数据还是比较原始的，但是数据格式比较规范，已经可以对外提供查询能力了。在上图中也可以看到，在数据明细层就可以通过HBase直接对外提供业务查询能力。在这之上，实现了更为复杂的Join、Group By等操作和处理之后，就到了数据汇总层，在这一层更加希望数据能够聚合一下，不再是零散的数据，这时候就需要配合Spark SQL来聚合数据进而转换到Spark列存上来，进而实现数据归档。数据汇总层其实就可以看做是一个离线数仓，如果想要制作报表就可以通过这一层的Spark离线数据实现分析，并且可以将数据回流到Phoenix为运营同学提供查询能力，这就可以看做是应用数据层。数据仓库通过以上四层的结构最终为业务应用提供数据能力。
对于客户而言，上图的这套架构所带来的价值就是可以实现毫秒级识别拦截代充订单，并发能够到达十万量级。此外，Spark基于列式存储Parquet的分析在数据量大的情况下能够达到Greenplum集群的10倍性能。因为Spark服务原生支持通过SQL读取 HBase SQL(Phoenix)数据能力，因此提供了一站式解决方案。而全托管的Spark服务保证了作业运行的稳定性，释放运维人力，同时数据工作台降低了Spark作业的管理成本。
三.原理及最佳实践
从上述的几个典型场景可以看出，Spark+HBase能够帮助我们解决很多大数据领域的问题。接下来为大家分享Spark+HBase在大数据应用中的一些痛点、原理以及最佳实践。
Spark API发展
Spark最开始的API叫做RDD，RDD是不可变的数据集，无法删除和更新，只能做类似于Map、Group By等转换。RDD的优点在于用户可以基于其实现很多任务，但是其缺点就是所有的优化任务都交给了用户，对于不熟悉Spark的用户而言，用起来就会比较困难。因此，Spark在后来就推出了DataFrame，DataFrame对数据增加了Schema，通过Schema可以了解数据具有多少列，每列的类型以及名称等信息。拥有了Schema之后，Spark就可以实现和传统SQL引擎一样的各种优化，比如逻辑优化、执行计划优化等，可以通过引擎帮助用户实现优化，而无需用户自己进行优化。之后，Spark还提供了DataSet，从下图中也可以看出，DataSet所提供的功能是RDD和DataFrame的全集，其需要支持Type-safe以及Encode/Decode等功能，能够在编译阶段发现代码问题，并在Encode和Decode阶段提高效率。
DataFrame和DataSet在性能上的优化
如下图左侧所示的是DataFrame的API，也就是SQL，其含义就是两张表进行join之后在进行filter，其逻辑执行计划是先join再filter，而优化之后生成的物理执行计划则是先filter再join，这样就减少了需要join的数据量，更进一步在物理执行计划中可以将filter推到scan，这就是DataFrame对于Spark带来的优化能力。
DataSet主要是添加了一套Encode和Decode的机制，从上图中的序列化性能表现对比可以看出，DataSet的序列化能力具有显著提高。Spark在序列化能力上不断进行优化，这样才能更好地解决业务问题，获得更好的开发者基础。
Spark的架构如下图所示，其最底层是RDD，在RDD之上构建了优化器Catalyst，再之上就是DataFrame和DataSet API。目前SQL也是基于Catalyst优化器，在这之上Spark在推进其Structured Streaming、GraphFrames、TensorFrames以及DL Pipelines等上层组件。当然，老的Spark Streaming还是基于RDD的，并且还有很多企业在使用这样的方式。
Spark流式处理(DStream)
HBase的实时入库以及ETL都需要依赖Spark Streaming，接下来就为大家分享新老两种Spark Streaming的API。老的Spark Streaming所提供的就是DStream，新的Spark Streaming基于DateFrame构建的Structured Streaming。DStream使用的是Micro-Batch的方式，所谓Micro-Batch就是数据不断地流入的过程中，将数据截断，比如将几秒内的数据组成Spark的一个批处理运行，运行完成之后再将接下来几秒的数据进行处理，如此每次都通过小的批量作业来运行。如下图所示的架构，为了运行批处理，这里设计了Job Generator，通过定时器来设定时间间隔来构建批作业，如果这里的间隔越大，流的吞吐就越高，间隔越小，实时性就会越好。在下图中右侧所示的就是比如有一个Streaming作业，橙色的部分就是基于DStream进行转换，而在DStream底层实际的执行计划还是RDD。
DStream优化策略
在开发DStream的时候会遇到一些问题，比较常见的问题就像作业堆积、延迟高以及并发不够等问题。针对以上这些问题，这里也提供了一些最佳实践。针对于并发问题，一种解决方案将Kafka的Topic订阅的分区调大一些，另外一种就是调整Spark的streaming.blockInterval参数。针对于延迟高问题，或许的确是代码写的有问题，所以需要对于代码热点进行优化，由于Spark Streaming的UI设计比较好，因此在进行排查的时候可以通过查看堆栈等方式发现问题。如下图所示的代码其实可以完成所需功能，但是存在代码热点。
Spark提供了BroadCast能力，因为是并发的，所以可以在Spark的Master端构建一个Collection，然后进行BroadCast，这样的做法大大降低了创建Collection的次数，优化效果非常好。
Spark流式处理入库HBase(Structured Streaming)
Spark目前主推的是Structured Streaming，在之前介绍Spark API的时候也谈到，Spark的API从RDD发展到DataSet。最开始用户无法对于RDD进行优化，但是Spark却希望帮助用户进行优化，简化用户的使用，于是在后来就推出了Structured Streaming，其基于DataSet构建，因此就可以天然地享受Spark的优化。可以认为表的数据不断地流入，Structured Streaming按照表进行数据切分和分析。Structured Streaming具有两种运行模式，分别为Micro-Batch Processing和Continuous Processing，也就是批处理和真正的流处理。根据Spark商业公司DataBrick的测试数据显示，Micro-Batch Processing延迟将近100毫秒，而Continuous Processing的延迟约在1毫秒。
Spark复杂分析HBase
接下来为大家分享Spark可以在HBase的复杂分析上所能够做的事情。如下图所示的就是Spark复杂分析HBase的执行架构图。Spark是一个分布式计算框架，其在实际分析的时候是一个Master/Slave结构，既有Driver也有Executor。Executor上面会并发分布很多Task，每个Task都会去读取HBase Region的某一个片段，这样基于Spark这种外部资源，就可以提高对于HBase的分析能力。
那么在实现方面，如何让Spark具有分析HBase的能力呢？其实Spark提供了一套DataSource的API，很多外部的生态可以基于Data Source实现自己的Collector，然后就可以实现相关的分析优化。在下图中，最左边的一条SQL想要读取HBase的一张表，做一些Map、Group By以及Count等操作，那么首先需要进行Analysis，这里需要基于Catalog类实现HBaseTableCatalog类来做SQL Schema到HBase Column的映射。有了表的优化之后，Spark就会生成逻辑执行计划，进而生成物理执行计划，而在这个过程中会执行一些优化，比如分区裁剪、列裁剪、谓词下推等，实现尽量少地从HBase读取数据。在生成物理执行计划的过程中需要HBaseRelation，HBaseRelation能够实现将逻辑执行计划推到HBase里面，进而使得流出来的数据比较少，这样不仅降低了存储的压力，也降低了Spark分析的压力。在生成物理执行计划级之后，可能需要实现RDD以及之后如何去创建和复用Collection以及如何Scan，Spark对接MongoDB或者Redis都需要做这些事情。
Spark复杂分析样例及优化
接下来通过讲解一个Spark复杂分析样例为大家介绍Spark分析HBase是怎么实现的。如下图上部所示的是一个建表语句，比如在Spark里面需要建一张表，这张表需要指定去关联HBase或者其他数据源。此外，还需要一个映射，将Spark表里面的Schema和HBase如何映射。在完成上述关联之后，只需要执行相应的SQL语句就可以产生下图中所示的逻辑执行计划，从红框里可以看出，Spark构建了HBase的Scan，并且filter条件都已经推移到HBase端了。
以上分享的最佳实践的代码和文档都在GitHub上，大家可以下载并进行实践。
四.HBase X-Pack服务
最后和大家分享关于HBase X-Pack服务的内容。因为HBase+Spark在很多企业中都得到了广泛的应用，很多企业也希望能够使用全托管的HBase+Spark，因此阿里云技术团队就构建了HBase X-Pack服务，能够帮助客户更好地解决业务场景。
Spark服务
下表对比了阿里云所提供的HBase X-Pack里面Spark和开源的Spark之间的区别，阿里云的HBase X-Pack提供了很多开源版本Spark没有的功能，并且可以实现全托管。
多数据源关联
阿里云HBase X-Pack可以关联多种数据源，比如HBase、Phoenix、MongoDB和RDS等，只需要在阿里云控制台上点击几下按钮就可以实现关联。
数据工作台
阿里云HBase X-Pack的数据工作台集成资源管理、作业管理、工作流、会话管理、集群管理以及告警等多种功能。
云HBase X-Pack
阿里云HBase X-Pack是基于Apache HBase及HBase生态构建的低成本、一站式数据处理平台，其支持Spark、二级索引、全文查询、图、时序、时空、分析等能力。
The following figure shows the architecture of Alibaba Cloud HBase. In fact, there are still some differences between HBase on the cloud and HBase offline. For example, HBase on the cloud has many options in terms of underlying storage. You can choose SSD, HDD, OSS, etc., and you can choose according to the specific needs of your business. On top of Alibaba Cloud HBase, it also supports multiple capabilities such as SQL, timing, time and space, and analysis.
