近期实践及完成了一些比较针对性的大数据相关的设计和开发，为了备忘，特汇总记录如下：

1) 大数据平台的选择

不管使用HDP或CDH，再或者使用基础的Hadoop方式的HDFS及HBase等的手工部署，但是对于一个企业级开发或规模较大的项目，最好选用稳定及成熟的平台套装。

例如Ambari的HDP，再或Cloudera的CDH。

在全部开源的前提限制条件下，应该尽量考虑版本的稳定性。免费的不一定不稳定，但是除了问题要自己Google。付费的不一定贵，关键是服务质量和支持。

另外关键选择因素是DevOps的涉及深度。任何大规模的大数据开发，肯定不能单纯到手工Shell方式添加DataNode和部署服务，大量的配置文件及网络设置，如没有全面和有经验的专家支持下，将是梦魇。

可是单纯追逐最新版本的部署和使用，往往也会适得其反。由于测试和使用力度的原因，最新版本在实际生产环境部署和使用过程中，往往会出现一些exception和unexpected的事情。很多情况下不得已要降版本重新部署。

所以考虑Ambari为依托的HDP的2.5／2.6全免费版本还是相对可行的。

2）操作系统的选择

由于大数据还是要跑在以Linux为内核的操作系统上，所以合适合规合要求的Linux版本事关重要。如生产发布环境使用RHEL，则尽量在设计／开发／测试环境选用CentOS对应版本。从而避免不同Linux版本对于内核及Shell和服务的定制化。

之前和现在的一些开发，均使用CentOS 6.5为主的操作系统。其也没有完全使用CentOS 7.x的最新版本。

因为大量组件，服务，以及一些特殊要求，往往对于最新版本的操作系统缺乏测试和相应支持，同时部分需要Python的特定版本。

3）实体机／虚拟化／容器化

我现在依然认为低配或适配的实体机是最好的方式，但是经过实践和之前1／2年一些同事的反馈，可考虑以VM为主的虚拟化技术也是比较成熟的。

然后虽然容器化Docker成熟并火热到一定程度，个人认为还不适合全部容器化方式部署Hadoop的全套环境和支持日常开发。

虽然已经整理并全部安装调试成功全Docker容器化的Hadoop平台，并有全套的安装部署脚本，但是其中的安装困难确实很大。紧紧是Bridged Network和Port，以及FQDN的配置，就很繁琐了。而且由于选择的大数据平台的支持框架不同，大量的“坑”就不一一罗列了。

4）数据流

在给建好的大数据平台注入血液（数据）的时候，Apache的Nifi还是比较灵活和方便的可视化工具。同时如果有一定Python和Java开发能力，可以很好的通过开源模式，编写自定义的Processor，高效处理更多的更精准的个性化数据处理流程。

但是其对于内存和日志的管理，需要针对性的调优，否则单独Queue的Bucket的阻塞，无条理的日志输出，是非常危险的。

我之前和现在的一些场景，Nifi都是通过Docker容器化的方式部署和使用。同时自行开发客制化的Processor和Python脚本提高处理和维护的高效。

5）数据清理

即使有好的数据可视化处理的Nifi数据流工具，乃至Kettle等传统SQL的数据ETL。但是大量的数据，尤其是非结构化的数据文件，例如Excel／CSV等，必须需要预先处理，清洗，规整等操作后再进入大数据平台，或者数据流处理平台。否则一些数据精度，空值等等数据项的问题，将造成数据处理的异常和错误，同时很难在数万数亿的原始数据中排查和修正。

因为绝大部分这些数据都是来自手工和半手工的非结构化或半机构化的源头，并且即使很规整的数据，总有异常情况。

所以个人认为原始数据的清理和Preprocess事关重要。

例如使用Spring Batch进行数据的预处理，充分使用其对于Tokenizer等配置化定义，集合自动化作业工具（譬如专业的UC4，或简单的Jenkins），同时相应的一些代码支持，构建一个文件预处理的小平台。

将预处理的原始数据，进入到Stage数据库（关系型），后续让Nifi等数据流工具介入。

6）数据关联

处理完毕的数据必然进入大数据平台，譬如HBase，或ElasticSearch／Solr等，合理的规划数据存储逻辑将对于后续的数据使用和应用需求起到很重要的作用。

譬如HBase的Row Key的定义，尤其是关联数据的Row Key模式。尽量通过合理的设计Row Key，提高未来查询时通过RowPrefixFilter进行HashTable的主键过滤，提高查询速度和命中率。

另外关联数据集合／Table间，对于Column Family的定义必须有清洗的数据字典和依存关系，方便对于Column较多的大数据集合进行维护。

7）直接数据服务暴露

特殊情况可以适当开发一些基于HBase Thrift和HappyBase的数据访问API，乃至通过Flask等暴露成API。是集团型企业应用的一个微服务的概念和实现。

8）编程开发

一般可采用Aanconda或Jupyter Notebook等支持的文档编辑及开发和管理工具平台或工具集，这样将会减少日后开发平台和开发包维护的力度。同时某些场景可以被复用管理工具。

但是单纯编程，开始要考虑一些专门的Python的开发工具。

譬如我现在使用的是Eclipse和PyDev。

另外一定要维护好PIP的安装包信息。由于大量开源package的存在，和Python版本的变化，需要认真将第三方Package的安装和部署与Python的开发及上线环境记录好。

9）应用隔离

通过Docker的容器化方式，将大数据平台上及开发平台的应用工具单一隔离部署，是个很好的习惯和能够提升DevOps能力的关键。

譬如即使使用Ambari部署HDP，其管理配置节点，可以统一考虑使用MySQL的Docker容器，将Ambari／Hive等关键服务的配置全部集中到MySQL的Container上。

或者其它相关开发工具。

但是不推荐将直接作用于大数据平台的应用容器化部署。譬如Hue，因为这样至少HDFS将无法remote访问DataNode上的HDFS等服务。

10）端口

大数据平台和应用将有大量的软硬件及应用部署，所以大量的端口需要明确记录。尤其是某些使用容器化方式部署的应用，对于容器与宿主机，和外网的端口映射更要规划和记录好。

最好有一个很清晰的端口／FQDN／网络等相关资源的excel表格记录。

11）FQDN／IP ADDR

大数据平台不一定需要标准的FQDN，譬如TNT-ITS.COM，但是命名还是需要的，因为这样会大大减少部署和配置过程中的难度。

另外一点是最好全部采用固定IP地址方式，甚至容器化的Bridged Network都要固定IP地址。

12）Python

最近使用较多的就是Python下面，Excel／Oracle／Mongo／Redis／Flask RESTful API／Flask Caching／HappyBase等Package。

同时使用Flask为主的uWSGI和Nginx承载HBase上的Direct Data Service API。

13）IaaS／PaaS

如果条件，尤其是经费足够，可以考虑以Amazon的AWS为主要资源的云化客制化部署方式，不简单使用其EC2单独作为VM方式部署，更关键使用其EC2 Container Service。

但是由于现在资源有限，AliYun和AWS上的配置手册和Demo环境还没有完全配通。

14）Hue

为了更方便日常运维大数据平台，Ambari只提供了Dashboard和Service Controller，但是对于文件和数据运维，管理，及使用，还是最好有图形化的工具。HBase Shell还是太原始。所以Hue是个比较好的选择。但是其部署和大数据平台的集成，需要很多精力。

15）大数据／人工智能／深度学习

近期期望将在大数据的基础上，把特定领域的人工智能（预测）部分实现几个微应用和成果，设计图和AI元素都已经规划，但是数据和模型还未就位，稍后再罗列。

如下附图（大数据的逻辑部署图）