回顾数据平台建设整体思路
在上一篇文章中，我们聊到了对数据平台的理解以及企业数据平台的建设思路。
经过分析，可以了解到，数据平台应该是一定程度的中心化的系统，是团队对于数据接入、数据建模、数据清洗、数据开发过程的工程化经验的沉淀。
它可以：
- 解决数据管理问题。如数据安全问题，包括访问控制、数据脱敏等；如数据质量问题，包括数据一致性、数据正确性等，如数据发现问题，包括数据查找、元数据管理等
- 为数据开发提供支持，包括代码编写、调试、测试、分布式运行、大数据量下的代码性能分析与优化、数据任务调度等
- 为数据分析提供支持，帮助数据分析师、建模师解决开发环境及资源调度问题，提供友好的界面辅助他们进行探索式数据分析，让他们可以集中精力于数据分析过程
要在企业环境中进行数据平台建设，可以采用精益的思想作为指导，采用以下步骤：
- 基于开源软件搭建具备基本功能的数据平台，可以采用的软件如如
CDH系列组件（基于Hadoop分布式计算和存储构建） - 在需求拉动下进行数据平台功能完善。如基于指标开发、客户画像开发或机器学习模型开发等某一具体需求，以一种类似软件重构的方法进行平台功能抽象、沉淀与复用。
在项目中落地
以上是关于数据平台的一些基本的思考，如何将这些想法进行落地呢？本文希望借着最近在一个客户项目上的数据平台方面的探索和实践，给大家分享一下我们的一些经验。
开源数据平台方案
前面提到的数据平台包含了非常丰富的功能，比如分布式数据计算、安全控制、元数据管理等。得益于数据应用已经有数十年的发展过程，特别是近十年来分布式数据存储和计算发展的拉动，这些方面大多有不错的开源产品支持了。
当下业界首选的基础开源数据平台要数基于Hadoop分布式技术的CDH和HDP了。CDH是由Cloudera公司出品的一个Hadoop大数据平台发行版，它内部集成了多个数据工具，如元数据管理工具、数据探索工具、任务调度工具、数据安全工具、数据开发工具等。同时CDH提供了一整套可视化的安装界面，可以让我们通过在网页操作就能实现一套分布式大数据环境的搭建。HDP来自曾经的Hortonworks公司，HDP其基本功能与CDH类似，但提供版本更新的Hadoop相关组件，且全部基于来源软件进行构建（CDH部分软件没有开源）。当前Hortonworks已与Cloudera合并，两者相互促进，想必会让整个大数据生态的发展提速不少。
在这个项目里我们选择了完全开源的HDP大数据平台作为基础平台进行客户企业数据平台的构建。
HDP数据平台简介
HDP数据平台长什么样包含什么样的功能呢？这里简单介绍一下。
HDP搭建好之后，可以打开集群管理的界面（Ambari），一个示例如下：
HDP有一个docker版本的实验环境，通过启动容器即可体验HDP基础数据平台的功能（需要预先准备足够的内存和硬盘空间）。如果大家想快速体验一下，可以参考这里的文档：https://www.cloudera.com/tutorials/getting-started-with-hdp-sandbox.html。
HDP搭建好了之后，通过Ambari可以实现集群管理，比如组件添加，服务的配置修改、重启等。Ambari是专门为简化Hadoop相关分布式组件的管理而开发的，提供基于web的UI界面及Rest API。除了管理集群组件，Ambari还支持集群服务的监控，比如磁盘空间不够用了，从Ambari的界面上可以看到，也可以配置为通知发出来。
HDP数据平台组件
底层的分布式数据存储和计算通过HDFS和Yarn来实现。HDFS设计为一套高可用的分布式存储，可以理解为把多台计算机的存储抽象为一个逻辑上的大的文件系统，它包含NameNode组件用于存储文件目录树，DataNode组件用于存储具体的文件内容。由于文件是分布式的存储在多台计算机上，那如何访问这些文件才是最高效的？当然是本地磁盘访问了。HDFS的基本设计思想就是基于这一点。这一点也可以换个说法，即，移动程序比移动数据更快。所以，为了实现分布式程序的高效运行，需要一套资源管理和调度系统来支持，它就是Yarn。
有了基本的分布式存储和计算的抽象之后，我们可以在这一套系统上面开发很多的应用。常见的Hive（分布式数据库）、Spark（通用分布式计算引擎）、HBase（分布式列式存储NoSQL数据库）等都是运行于这套抽象之上。一个更有野心的说法是，这套系统可以称为分布式操作系统。
HDP数据平台企业级功能
除了这些基本的存储和计算组件之外，HDP还集成了一定的企业级数据平台功能，比如中心化的账号管理、认证授权、数据的访问控制等。这些功能是中心化数据平台的基本安全要求。
这是如何实现的呢？一般企业内部都会部署一套经典的目录服务来实现内部账号统一管理，常见的目录服务是来自微软的活动目录Active Directory，或者开源的OpenLDAP。目录服务以树形结构保存企业内部员工的账号信息，支持灵活的账号分组以适应不同的企业组织结构。目录服务为统一的登录授权提供支持，数据平台如果对接了目录服务，便可以实现使用同一账号来登录和使用不同的系统。
当开启HDP数据平台的安全机制并对接好目录服务之后，数据平台就可以同步目录服务中的账号到数据平台的账号系统，然后数据平台就可以对不同的账号进行权限控制了。HDFS本身的安全机制设计借鉴了Linux下的文件系统安全设计，对于某一个目录或文件，我们可以对某个用户或组授予读、写、可执行的权限。文件系统权限是整个分布式系统的基本安全保障，而上层的数据库服务以及各类计算任务的权限则是由上层系统各自独立实现。由于每个组件都有自己独立的权限控制机制，所以要在一套分布式数据平台上面实现完善的方便的权限管理是比较棘手的。
为了降低权限管理的复杂度，Ranger被开发出来。Ranger是专门为了实现大数据平台上面进行集中式权限管理的系统。使用Ranger，我们可以在同一个web系统中对HDFS、Yarn及运行于大数据平台上面的各类组件进行权限管理。
在我们的项目中，部署了OpenLDAP目录服务来管理所有的系统账号和组，使用Ranger来进行集中式的权限控制。一个典型的授权使用流程如下：
在LDAPAdmin(一个较老的OpenLDAP目录服务Web管理应用，虽然界面很过时，但是功能还够用)上面创建账号、组，并设置对应账号的用户组：
在Ranger控制台上面选择HDFS -> Hadoop即可针对HDFS进行权限策略配置：
当希望对Yarn、Hive、HBase等组件进行权限控制时，我们可以都可以在Ranger控制台完成。
企业数据工作流程
看完上面的HDP大数据平台，有人可能会说这不就是一套完整的大数据平台了吗？其实，我们认为可能将这套平台定位为基础大数据平台比较合适，因为这套平台只是提供了一套分布式存储和计算的技术方案，并不能直接解决企业内部的数据应用问题。要想解决这样的问题，需要每个企业（或数据团队）根据自己的背景、文化基于自身数据情况定义一套适合自己的数据工作流程。
什么是企业数据工作流程？我们可以认为是企业内部数据应用开发和迭代的流程。比如要基于客户数据开发一个客户画像的数据应用，可能会经历以下几个流程：
- 考察哪些业务系统存有客户数据并可以作为数据源
- 将这些业务系统的数据导入到数据平台存储
- 对导入的数据进行清洗、加工、重新建模（如维度建模），处理为便于分析的数据
- 基于可用的数据及客户画像需求设计客户标签
- 在便于分析的数据上面进行进一步的组合分析，计算出前面设计的客户画像标签
- 设计用于展示或搜索的客户画像应用UI，将计算出来的客户标签进行展示
我们可以把上述流程做一下抽象，得到一般的企业数据工作流程：数据接入 -> 数据建模 -> 数据计算 -> 数据应用或服务开发。
通过HDP构建企业数据工作流程
HDP如何支持上述流程呢？下面分析一下有哪些工具可以提供帮助。
数据接入
数据接入是把数据从源系统导入到数据平台的工作。源系统通常是企业中面向内部或外部的业务系统，源系统的数据存储多种多样，比如常见的关系型数据库、NoSQL数据库、日志文件等等。
从技术上我们需要一套可以很容易从各类不同数据源读取数据的方案。开源的专门用于导入数据的工具是Sqoop，它可以分布式多线程的读取不同类型源系统的数据。安装好HDP之后，每个集群节点都会安装Sqoop的客户端工具。使用Sqoop导入数据时，只需要在任意集群节点运行Sqoop命令就可以了，Sqoop将会在集群中启动一个分布式计算任务来进行数据导入。
除了Sqoop之外，Spark其实可以作为一个不错的进行数据导入的工具。Spark不仅同样可以分布式读取多种不同种类的数据源，同时，Spark开源生态非常活跃，稳定性扩展性支持度都非常好。比如，一般而言，我们会主要基于Hive来构建数据仓库，由于框架在设计上的兼容性，Spark将数据写入Hive是轻而易举的事情。在项目上，我们考察了Sqoop和Spark，最终选择了Spark的方案，使用Spark可以让我们减少一种数据工具的引入，同时我们也从Spark的稳定性扩展性上收益很多。
如果需要实时的进行数据接入，我们一般需要借助一个消息系统，这时分布式消息系统Kafka是一个很好的选择，HDP对Kafka也进行了集成。
数据建模
数据进入数据仓库之后，首先需要做的一件事就是进行一定程度的清洗加工，将数据变成高质量且易于分析的数据。这个过程我们一般称为数据建模，在这里使用的建模方法一般是维度建模方法。维度建模将数据表分为事实表和维度表，一般的数据分析会从事实表出发进行分析，在不同的维度进行聚合得到不同的指标，如销量、新客户数量等。
这一部分是数据仓库的核心，但却不是工具能帮到多少的，因为每个企业的数据需求不一样，数据质量不一样，建模过程要完成哪些数据清洗标准化过程也不一样。这样一来，我们很难去定义一套通用的抽象来解决这个问题。关于数据建模的经验，我会在后续的文章中给大家做进一步的分享。
从基础技术上讲，这里需要一套非常灵活的数据开发运行环境做支持，当前的情况下，Spark可能是最成熟最好的选择了。在我们项目中也是选用了Spark+Hive的方案。
数据开发
数据开发是为了支持数据应用而编写的一些数据加工、聚合或转换程序，这些程序的输出通常是一些数据指标或标签。通常为了能在不同的指标计算之间复用一些计算过程，我们会将数据仓库进行分层，比如常见的dwd（数据仓库明细层） dwb（数据仓库初级汇总层） dm（数据集市层） ads（数据输出层）等，公共的数据计算代码会逐步下沉到更低的层级。这里的不同的分层在技术上可以直接对应到数据库。
这一部分同样需要一个通用的计算框架的支持，我们依然是首选了Spark的方案。
在使用Spark的过程中我们遇到的一个问题是，Spark本身提供的API过于通用，如果使用这些API来进行数据开发，将导致代码难以阅读。Spark同时提供了SQL的接口，使用SQL可以让一些数据开发的代码更清晰易懂，但是在逻辑比较复杂的场景下，只使用SQL又将丢失Spark强大的编程能力。关于我们项目上是怎么做的，我会在后续的文章中给大家做进一步的分享。
数据应用和服务开发
我们常见的数据应用形式是BI报表和数据API。HDP中集成了轻量级的BI工具Superset，如果对数据报表呈现有更高的要求，Superset可能难以满足需求，这时可以考虑对接其他商用的BI工具，或者基于前端UI库自主开发。
由于数据开发是基于Spark+Hive完成的，如果BI工具直接对接Hive进行数据查询，那么查询响应时间将会成为一个问题。考虑到这类数据量会大大减少，我们一般的做法是将计算出来的指标数据存入一个可以支持快速查询的分析型数据库中。
使用Spark可以将数据轻松的导出到PostgreSQL、ClickHouse等分析型数据库中。
总结
经过以上的分析可以了解到，对于团队的数据工作流程而言，基于HDP的数据平台可以提供很多帮助，但是要想让整个流程运转起来，实际上还需要我们选择配合其他的工具或自研一部分工具才行。
最后简要总结一下，本文简单介绍了如何基于HDP来构建企业数据平台，包括一些HDP相关软件系统的基本介绍及我们项目上的具体技术选型。我们还从企业数据工作流程的角度阐述了如何在基础数据平台上面构建适合自身的工作流程。有了基础数据平台及数据工作流程定义，我们就可以说企业的数据平台初步搭建起来了。