大数据平台的服务内容以及猛犸大数据平台近期的思考

猛犸大数据平台经过去年一年的快速发展，已成为公司内多个产品的大数据开发工具的首选，作为一个当初定位为开发门户的这样一个平台网站，以调度管理为核心，将公司内已有的大数据工具进行了整合，提供了可视化的操作界面、统一的用户权限管理机制。洞悉原油开发流程的用户可以在猛犸上找到很熟悉的感觉，DS接入，MR任务的上传与调度控制，HIVE的查询等等。随着用户不断反馈，猛犸也在不断的进化，越来越多的组件涵盖了进来，交互和流程在不断改善。然而目前这样的框架这就是猛犸的终极形态吗？

答案自然是否定的，可以说，眼前的猛犸只是窥探到了大数据生态的冰山一角，组件的堆积无法成为真正的生态系统，只是工具的累积。只有将各个组件有机的结合在一起，形成完整的工作流方案，同时辅以更靠近业务的公共服务，才能使得平台在整个大数据开发使用流程上发挥更大的作用。

本文主要从平台的服务对象、核心、服务形态等几个不同的方面来对理想的大数据平台进行探讨。

细分服务对象

大数据平台真正应该服务的对象是哪些人，这是个人在接手项目之初就在不断思考的问题。

猛犸最早的名称是“猛犸大数据开发平台”，这也意味着从最早的版本开始，猛犸的主要目标就是服务公司内各个项目的数据开发人员。数据开发的工作在公司内主要是ETL（Extract-Transform-Load），细的来说就是同步各个数据源，利用MR或者Hive做数据的抽取转换，结合调度系统维护一整套数据流的运转。数据开发可以说是整个数据体系的核心。他们是数据的加工者，在客观的数据和最终的数据应用之间架起了一座桥梁。

然而随着猛犸上用户越来越多，平台与底层系统间的依赖越来越重，平台管理员也是猛犸中重要的一类用户。猛犸平台另外一个目标是作为整个大数据平台的唯一入口，所有的任务和调度都通过猛犸提交，由猛犸来接管审计权限之类的管理。随之而来的一些hadoop管理员、DBA等等平台管理角色也有很强的意愿在猛犸中加入管理以及统计查询功能，能够方便的进行一些运维操作以及查看系统的负载，任务提交的状况等等。

除了数据开发、系统管理员之外还有第三类用户，也是目前猛犸尚未照顾到的用户——数据使用者，随着数据在产品运营中所占的比重越来越大。越来越多的人开始使用数据，包括数据分析师以及普通的运营决策人员。具有一定数据常识的人如果能自助化的获取一些简单的数据，将大大解放数据开发人员的压力。现今过往那种数据开发人员统一处理所有数据获取请求的模式是不合理，也是不可扩展的。在这种模式下，数据响应会变得非常缓慢，数据开发也很容易成为瓶颈，他们宝贵的时间容易被各种业务所淹没，而真正的数据建设任务反而容易被搁置起来。

服务细分，这是未来的趋向，不通的用户的需求是不尽相同的，如何让所有的角色都感到方便易用是平台急切需要考虑的问题。根据不同分类的用户来划分平台的功能模块是一个可行的方法，猛犸在最新的版本中将数据开发和数据使用者进行了划分，通过不同的入口进行引导，

数据平台的核心

大数据平台真正的核心价值是什么，是基于底层系统的一套交互UI吗？当然不是。 是任务调度？仅仅是如此吗？究竟什么才是一个大数据平台真正的核心？

数据仓库，是的，我认为数据仓库是数据平台真正的核心。这里所指的数据仓库是一个广泛的定义，应该这么说，数据仓库是用来保存从多个数据库及其它来源的数据，经过转换处理并为上层应用提供统一的用户接口完成数据的查询以及分析的一套体系。Inmon对数仓的定义：数据仓库是一个面向主题的、集成的、时变的和非易失的数据集合，支持管理部门的决策过程。

数据仓库是一个数据管理的范畴，围绕数据仓库这个中心，在数据开发层面最重要的流程就是ETL了，关于ETL以下的几点总是绕不开，却又很容易被忽视的话题。

元数据管理

首先就是元数据的管理。元数据的作用体现在这几个方面，首先元数据是数据集成的必需品，其次元数据能帮助用户理解数据，再其次元数据是保证数据质量的关键，能帮助用户了解数据的来龙去脉。最后元数据是支持数据需求变化的基础。具体来讲，需要元数据管理系统来管理这些对数据的描述，包括技术层面的元信息以及业务层面的元信息。例如纪录数据仓库的分层模型，哪些表哪些数据是属于明细层，哪些是属于聚合层。每张表的每个字段分别对应的是什么含义，格式标准是什么，多维分析模型中哪些是事实表，哪些是维度表，维度的层次、级别、属性，度量的定义、筛选条件。数据流的情况，数据的血缘关系等等都是必须要追踪到的。在这些元数据的基础之上需要有一套快速检索的机制，帮助不熟悉数据仓库的使用者快速定位到想要获取的数据。

做好一套元数据管理系统有以下几件事必须要完成：

1. 完整的数据字典repository
2. 数据血缘关系

数据仓库中包含着原始数据、中间过程数据、宽表数据、集市数据等等。一个合理的数据仓库必须做到快速准确的追踪和管理所属的数据，对数据按主题，按更新周期，按照粒度级别进行区分，或者说以较高的层次对数据进行完整、一致性的描述。 过往，数据开发的同学往往是用Wiki或者是git等工具记录对于数据表、数据文件的描述。这样做有两个问题，首先是描述的格式比较自由，数据没法根据数据仓库元数据的要求进行统一描述；其次，这份元数据很难得到及时的更新，一旦有其他使用者在数据仓库中对元数据进行了修改，很难及时可靠的反应出来，最终会导致元数据的滞后、失效以及混乱。

对于猛犸来说，目前最新的版本已经加入了部分数据管理的功能。对于帮助用户理解数据这一层，猛犸对表，对表字段都提供了纪录、搜索、收藏等功能，猛犸可以对Hive中已存在的表进行关联，数据开发同学可以将Hive表关联至数据字典Repository中，对这些数据进行分类、tag以及进一步的描述和说明。普通数据用户能够快速的进行数据字典的检索，获取对自己有帮助的数据表、数据列。未来，猛犸也会附带上数据血缘关系的功能，数据血缘是在数据开发的基础上对数据做的纵向追踪。血缘关系的核心是任务调度系统，根据任务调度系统的每个Job获取输入输出、执行日志等等。将项目中每个任务的输入输出进行关联组织成一个有向无环图（DAG），DAG的节点就是输入输出的文件，DAG的边就是一个个注册在调度系统中的JOB。 从实现来说，MR Job 或者 Spark RDD中都包含有血缘的关系，Hive也有专门的 org.apache.hadoop.hive.ql.tools.LineageInfo 工具能够获取上下文的输入输出表。

数据质量管控

除了元数据管理之外，数据质量的监控也是一个非常重要的方面， 数据的质量可以由完整性、一致性、准确性和及时性4个基本要素来构成。包括了Profiling，Auditing，Correcting三个重要的流程：

profiling：数据的概要分析， 检查数据是否可用，并收集数据的统计和其他信息。 类似于传统数据库中的Analyze， 比较全面的profiling包括收集记录数、最大最小值、最大最小长度，cardinality，null个数，平均数、中位数，唯一值的分布信息等等。从一些关键的量化指标中获取数据的特征，捕捉潜在的异常点， 部分工具甚至可以给出数据质量的评分。

Auditing：数据审核，基于数据质量的4个基本方面进行校验，及时性方面比较直接，是通过对ETL任务的监控来完成，完整性包括字段完整性和记录完整性。字段完整性最常见的异常就是在统计信息中空值的数量过多，记录完整版的常见异常包括记录数量过多、过少等反常情况。一致性包括编码规则一致以及逻辑规则一致，编码规则可以基于既定规则进行判断，而数据逻辑一致性相对复杂，有属性内的规则，也有属性间的规则。准确性的问题一般是数据数量级、字符乱码、字符截断之类的错误，可以通过该要分析的中位数、平均值以及数据分布来发现异常，

correcting：数据修正，包括填补缺失值、删除重复记录、一致化数据以及修正异常数据。 对于记录缺失，需要重新从原始数据获取，字段的缺失需要对缺失的值进行预测或者估计，去重需要根据唯一值的约束去判断，不一致记录就需要依赖对数据源的熟悉度，指定一枝花的规则。总的来说大部分的异常数据是很难修正的，很多异常数据是不可能百分百进行还原。最后的手段是对异常数据进行吧过滤，将异常的数据排除出数据仓库，避免干扰。

猛犸在数据质量管理方面目前只有ETL任务的监控，猛犸可以对ETL的各个Task，Job甚至是对Hadoop的Job进行监控，对于失败或者超时的任务进行报警。但是在一致性、完整性、准确性方面是空白的，这一块也是猛犸下一阶段的发力重点。考虑到数据correcting的主观性以及不确定性，猛犸的数据质量保证着重于profiling以及audition，希望能尽早的帮助用户发现数据的异常，让用户尽早开始补救措施。猛犸的数据质量保证是一个插件化的模块，允许可选式的集成在任务调度系统中。对于数据重要性高，计算资源相对宽裕的用户，数据质量保证能够很好的提高服务体验，保证数据仓库体系的正常运转。

数据开发模式的变化

在传统的数据处理、数据集成、ETL或者是ELT开发中，有专业的数据公司提供专业的辅助工具来完成，比如Oracle的OWB，MS的SSIS等等。而在大数据时代，以hadoop作为核心数据仓库的时候，并没有合适的开源ETL工具来辅助作业。我们能看到大量的数据开发同学手写MapReduce来完成从数据清洗、数据转换等等一系列。要维护这一套代码以及使之正常运转是一项大工程，这好比在现代的程序开发中，开发者维护一套汇编代码一样！

手写MapReduce的短板是显而易见的，作为底层的API其复杂度较高，相对的自由度也比较高。在很高的自由度下，代码的规范以及可读性、可维护性就成为了一个问题。虽然MapReduce的代码想对来说在优化的情况下性能比较好，但是相比可读性、可维护性来说，这些许的性能优势并不是最为重要的。在实际的项目中常常能看到在工作交接中，一堆的MR工程代码是非常难维护的，接手的同事在修改的时候畏手畏脚。好不容易接手的代码扩展它又想对比较麻烦，开发效率非常低下。

为了解决这样的问题，社区有了各种各样的工具。Hive，Cascading等等，Hive能使用SQL语言来概括复杂的MR任务，辅以Hive可扩展的UDF、UDAF，可以说SQL作为一种更简练、概括性更高的语言能承担所有的ETL开发任务，维护SQL可以有效的解决手写MapReduce的不足，而且作为受众面非常广的SQL，入门门槛进一步降低，可以让数据开发更多的集中于处理业务，而不是疲于维护一堆底层代码。

猛犸也将尝试提供一系列的SQL化ETL工具，希望这种便捷的开发方式能帮助开发更快的入门进行数据仓库的建设。这样的改造将从数据入库开始，将“数据结构化“ 这个核心思路贯穿整个开发流程。在Hadoop中数据流转的单位将从HDFS文件变成一张张二维表，这也能够和传统的以关系数据库作为数据仓库基础的ETL流程更好的衔接起来。在新的开发模式下，猛犸需要努力将背后的分布式文件系统HDFS隐藏起来，杜绝以文件的视角去看待数据仓库。从Datastream导入日志数据之前用户需要指定日志的Serde、表定义，以及借助Storm或者Spark Streaming这样的流式处理工具对数据做预处理。联系到上一节提到的数据血缘分析，利用Hive工具可以利用SQL语句快速对表和表建立联系。数据开发之间可以共享UDF以及UDAF，猛犸需要对用户编辑的UDF和UDAF进行统一的管理，允许组内共通，同时猛犸也能够提供UDF／UDAF的开发框架，方便用户快速编写自定义函数。

数据平台的管理

这里说的数据平台管理不止是对于平台系统的管理，猛犸目前即成的管理功能包括有用户资源分配。用户目录权限审批，用户组管理等等。只有这些是远远不够的。

平台管理功能，更应该暴露出平台上的每个用户、每个项目的运行情况。具体包括：

用户资源占用量

用户资源包括存储、计算等等，存储资源比较好理解，即用户所有的文件占用了多少分布式文件系统的空间，这份数据有助于更好的来规划集群的存储资源，发现用量增长过快的用户，帮助其合理的规划资源。各种表、各种项目的top排名能够使运维人员一目了然当前集群的负载状况。 计算资源相对更难衡量，只能根据用户队列的使用情况来获取。

用户任务运行情况

用户任务运行情况由任务调度系统来获取，用户由多少Task， 每个Task包涵多少Job， Job是什么类型，每个Job／Task分别需要多少时间执行，哪些Job失败的概率最高，失败的原因是什么等等，这些统计都非常的重要。猛犸目前使用的Azkaban调度系统可以说是一套难以规划用量与资源的系统，目前所有的用户使用一套调度系统，这套调度系统本身缺乏调度隔离，可以说在资源不足的情况下用户之间很容易受到影响，作为平台管理合理规划任务调度资源就需要依赖以上的这些统计信息。其中Job失败原因分析是急需解决的问题，经验不足的数据开发人员往往定位错误原因的效率不高，而平台可以提供一套行之有效的规则体系，提取错误日志信息，推断错误原因。结合起来。假如出现用户的某些JOB非常高的频率因为内存不足而提交失败，则可以促使系统扩容或者是协助用户调整触发时间来达到修正。假如多次出现数据库权限导致的Sqoop任务失败，则可以联系DBA尽早排查出ACL或者白名单的缺失问题。

未来

一个大数据平台的完善是根据底层技术以及用户的需求更新不断地发展的，猛犸需要以提供完整的解决方案为思路，引入更多更好的功能和工具满足不同人群对于数据的需求。实时数据处理、更丰富数据同步、日志检索、KeyValue系统、算法模块都是未来打算引入的内容。用户对于数据的需求是越来越丰富的，在大数据时代已经没有一招鲜的解决方案了，只有见招拆招，有针对性的主打细分的场景，逐个击破才是近期的发展方向。猛犸的初衷不会改变，降低大数据的门槛，提供更全面、易用的大数据服务。