1. 数据入库流程
一、规范数据入库流程
规范化的操作流程是避免操作错误产生的有效手段。据此，对航空物探数据入库过程中的数据质量检查内容和方法进行了分析，归纳出系统检查9项和拓扑检查5项（表5-5）。考虑到在数据入库过程中，需要给数据采集人员授予数据库数据编辑和删除权限（以便编辑录入的错误数，删除导入的不正确数据），在编辑或删除数据库数据时，有可能错误地编辑或删除已归档数据，破坏归档数据的完整性和正确性等因素，提出了航空物探数据库入库数据质量检查的规范化流程（图5-2）。
表5-5 入库数据系统检查和拓扑检查
1）创建项目，在数据入库前先创建项目，按项目导入或录入数据。
2）入库前系统检查，导入或录入的入库数据必须通过系统的入库前检查（数据唯一性、数据类型、缺项检查），才能保存到采集库中。
3）数据进入采集库后，须接受入库后系统检查。若是空间数据必须接受拓扑检查，再与原数据文件进行逐字节比较检查，均通过后，进人工检查。
4）人工检查与人工复核，对项目概况数据、空间要素类数据（图形和属性）、文字数据、图件数据、可制成图件的对象类数据应进行人工检查与人工复核。检查方法是人工比对。该方法劳动强度大，检查人员要有较强的责任心才能发现其中的错误。人工检查与人工复核的工作内容相同，系统要求人工检查与人工复核必须由不同人员完成，加强数据检查力度，尽量消除人为因素造成的错误。
图5-2 规范化的数据入库流程
5）系统归档检查，对入库数据的非空字段进行的检查。系统归档检查通过后，入库数据可归档存入资料库。
经测试，严格按照该数据入库流程开展数据入库工作。航空物探资料库数据与入库前原数据文件数据的一致性可达100%。
该流程将入库数据与资料库数据分离，单独建立一个数据采集数据库（简称“采集库”），把待入库数据暂存在采集库中。入库数据在采集库中接受各项质量检查和编辑，或删除操作，直至达到数据入库质量要求，归档进入资料库（进入资料库的数据除数据库管理员外其他用户是无权对其实施编辑或删除操作的），保证资料库数据的一致性和完整性，为整体提高航空物探数据库的质量提供了保障。
二、规则化数据检查方法
50多年来航空物探取得大量的基础资料和成果资料，这些资料在地学基础研究、油气资源评价等领域发挥的重要作用日益显现。人们越来越重视利用航空物探资料来解决所遇到的地质问题等，同时人们也很想了解所用资料的来源、质量等信息（如资料的测量年代、测量方法、仪器精度、飞行高度、定位精度，数据处理方法等），来评价问题解决的可信度。这也正是本信息系统建设者想要给用户提供的。历史已既成事实，许多与资料质量有关的信息，例如在使用数字收录以前有不少项目的测量仪器精度、飞行高度、定位精度等现已处可寻。
过去的不足证明现在的进步，尊重历史尽力适应未来的技术发展，是本信息系统建设所遵循的宗旨。因此，根据资料的实际情况，提出了入库数据有效性检查的规则化方法，较好地解决了不同年代资料信息不齐全的数据入库质量检查问题。
按照通常做法，在软件代码中直接编写出每个数据库表需要做检查字段的有效性检查代码。
航空物探信息系统建设
本系统采用规则化方法检查入库数据。在完成数据库结构设计之后，针对每张数据库表中每个字段制定了入库数据正确性的检查规则，建立动态检查规则表，针对不同的检查规则编写检查函数，从数据库中获取被检查表数据库字段的检查规则，对入库数据进行检查的。规则化方法代码实现的示例如下：
航空物探信息系统建设
系统检查采用传统检查方法实现代码量约15345行（表5-6），代码开发工作量很大，且灵活性差，不利于后期代码维护和扩展，如添加表或表添加检查字段后都需要对代码进行重新修改和编译。而本系统的规则化方法代码量仅495行（表5-6），只有传统检查方法代码的3.22%，且添加表或表添加检查字段后不需要修改代码；用户在数据入库时，根据实际需要直接修改检查规则表即可。
表5-6 系统检查两种实现方式代码量对比表
2. 数据安全怎么做，安全性更高
随着大数据的蓬勃发展，大数据的安全问题越来越受到业界的重视。不久前，中国信息通信研究院发表了《大数据安全白皮书》，指出了当前大数据发展面临的安全问题，并提出了促进大数据安全技术发展的具体建议。
白皮书认为，大数据已经对经济运行机制、社会生活方式和国家治理能力产生深刻影响，需要从“大安全”的视角认识和解决大数据安全问题。无论是商业策略、社会治理还是国家战略的制定，都越来越重视大数据的决策支撑能力。但业界同时也要看到，大数据是一把双刃剑，大数据分析预测的结果对社会安全体系所产生的影响力和破坏力可能是无法预料与提前防范的。
大数据安全是涉及技术、法律、监管、社会治理等领域的综合性问题，其影响范围涵盖国家安全、产业安全和个人合法权益。同时，大数据在数量规模、处理方式、应用理念等方面的革新，不仅会导致大数据平台自身安全需求发生变化，还将带动数据安全防护理念随之改变，同时引发对高水平隐私保护技术的需求和期待。
白皮书认为，大数据安全威胁渗透在数据生产、采集、处理和共享等方面，大数据产业链的各个环节，风险成因复杂交织；既有外部攻击，也有内部泄露；既有技术漏洞，也有管理缺陷；既有新技术新模式触发的新风险，也有传统安全问题的持续触发。对于未来大数据安全技术发展，白皮书给出了具体建议：
第一，站在总体安全观的高度，应构建大数据安全综合防御体系
安全是发展的前提，必须全面提高大数据安全技术保障能力，进而构建贯穿大数据应用云管端的综合立体防御体系，以满足国家大数据战略和市场应用的需求。一是建立覆盖数据收集、传输、存储、处理、共享、销毁全生命周期的安全防护体系，综合利用数据源验证、大规模传输加密、非关系型数据库加密存储、隐私保护、数据交易安全、数据防泄露、追踪溯源、数据销毁等技术，与系统现有网络信息安全技术设施相结合，建立纵深的防御体系；二是提升大数据平台本身的安全防御能力，引入用户和组件的身份认证、细粒度的访问控制、数据操作安全审计、数据脱敏等隐私保护机制，从机制上防止数据的未授权访问和泄露，同时增加大数据平台组件配置和运行过程中隐含的安全问题的关注，加强对平台紧急安全事件的响应能力；三是实现从被动防御到主动检测的转变，借助大数据分析、人工智能等技术，实现自动化威胁识别、风险阻断和攻击溯源，从源头上提升大数据安全防御水平，提升对未知威胁的防御能力和防御效率。
3. 如何建立一个完整可用的安全大数据平台
“
要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。
1
计算框架篇
大数据的价值
只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：
报表生成（比如根据用户历史点击行为的跟踪和综合分析、 应用程序活跃程度和用户粘性计算等）；
诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；
决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。
图 1
进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图1）：
在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间， 例如分析一个站点为何变缓慢并尝试修复它；
在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策， 例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在1.3秒内攻击1百万台主机）；
更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策， 例如图数据处理、异常点检测、趋势分析及其他机器学习算法。
蛋糕模式
从将数据转换成价值的角度来说，在Hadoop生态圈十年蓬勃成长的过程中，YARN和Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架, 流数据，图数据，机器学习）。
它使得用户不再受到MapRece开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是HDFS和Yarn, 而MapRece就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。
在这一架构体系中，总体数据处理分析作业分三块（图2），在HBase上做交互式查询（Apache Phoenix, Cloudera Impala等）， 在历史数据集上编写MapRece程序抑或利用Hive等做批处理业务， 另外对于实时流数据分析Apache Storm则会是一种标准选择方案。
虽然Yarn的出现极大地丰富了Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。
图 2
一统江湖
Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图3），同时Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通过启用内存分布数据集，优化迭代工作负载， 用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。
有三个最主要的原因促使Spark目前成为了时下最火的大数据开源社区（拥有超过来自200多个公司的800多个contributors）：
Spark可以扩展部署到超过8000节点并处理PB级别的数据，同时也提供了很多不错的工具供应用开发者进行管理和部署；
Spark提供了一个交互式shell供开发者可以用Scala或者Python即时性试验不同的功能；
Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。
当然Spark也和当年的MapRece一样不是万灵药，比如对实时性要求很高的流数据处理上Apache Storm还是被作为主流选择， 因为Spark Streaming实际上是microbatch（将一个流数据按时间片切成batch,每个batch提交一个job）而不是事件触发实时系统，所以虽然支持者们认为microbatch在系统延时性上贡献并不多，但在生产环境中和Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。
比如在实践过程中， 如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似service assurance（确保某条消息在毫秒基本能被处理完成）的指标， 系统的瓶颈有时还是不能避免。
但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的, 例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。
由于Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、SQL语言API、GraphX）, 使得用户可以在每一批流数据上进行灵活的Spark相关操作，在开发上提供了许多便利。
Spark的成熟使得Hadoop生态圈在短短一年之间发生了翻天覆地的变化， Cloudera和Hortonworks纷纷加入了Spark阵营，而Hadoop项目群中除了Yarn之外已经没有项目是必须的了（虽然Mesos已在一些场合替代了Yarn）, 因为就连HDFS，Spark都可以不依赖。但很多时候我们仍然需要像Impala这样的依赖分布式文件系统的MPP解决方案并利用Hive管理文件到表的映射，因此Hadoop传统生态圈依然有很强的生命力。
另外在这里简要对比一下交互式分析任务中各类SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中历史最短的，论文发表在15年的SIGMOD会议上， 原文对比了数据仓库上不同类型的查询在Shark（Spark最早对SQL接口提供的支持）、Spark SQL和Impala上的性能比较。
也就是说， 虽然Spark SQL在Shark的基础上利用Catalyst optimizer在代码生成上做了很多优化，但总体性能还是比不上Impala, 尤其是当做join操作的时候， Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。
不过Spark SQL的Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的Benchmark评测中Impala一直比其他SQL on Hadoop框架性能更加优越，但同时Hortonworks评测则指出虽然单个数据仓库查询Impala可以在很短的时间内完成，但是一旦并发多个查询Hive on Tez的优势就展示出来。另外Hive on Tez在SQL表达能力也要比Impala更强（主要是因为Impala的嵌套存储模型导致的）， 因此根据不同的场景选取不同的解决方案是很有必要的。
图 3
各领风骚抑或代有才人出？
近一年比较吸引人眼球的Apache Flink（与Spark一样已有5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继MapRece, Yarn，Spark之后第四代大数据分析处理框架）。 与Spark相反，Flink是一个真正的实时流数据处理系统，它将批处理看作是流数据的特例，同Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。
Flink有一些设计思路是明显区别于Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而Spark一直到1.5版本都还是试用java的内存管理来做数据缓存，这也导致了Spark很容易遭受OOM以及JVM GC带来的性能损失。
但是从另外一个角度来说, Spark中的RDD在运行时被存成java objects的设计模式也大大降低了用户编程设计门槛， 同时随着Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理， 具体表现为Spark生态圈内从传统的围绕RDD（分布式java对象集合）为核心的开发逐渐转向以DataFrame(分布式行对象集合)为核心。
总的来说，这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些，但Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。
2
NoSQL数据库篇
NoSQL数据库在主流选择上依旧集中在MongoDB, HBase和Cassandra这三者之间。在所有的NoSQL选择中，用C 编写的MongoDB几乎应该是开发者最快也最易部署的选择。MongoDB是一个面向文档的数据库，每个文档／记录／数据（包括爬取的网页数据及其他大型对象如视频等）是以一种BSON（Binary JSON）的二进制数据格式存储, 这使得MongoDB并不需要事先定义任何模式, 也就是模式自由（可以把完全不同结构的记录放在同一个数据库里）。
MongoDB对于完全索引的支持在应用上是很方便的，同时也具备一般NoSQL分布式数据库中可扩展，支持复制和故障恢复等功能。 MongoDB一般应用于高度伸缩性的缓存及大尺寸的JSON数据存储业务中，但不能执行“JOIN”操作，而且数据占用空间也比较大，最被用户诟病的就是由于MongoDB提供的是数据库级锁粒度导致在一些情况下建索引操作会引发整个数据库阻塞。一般来说，MongoDB完全可以满足一些快速迭代的中小型项目的需求。
下面来主要谈谈Cassandra和HBase之间的比较选择。Cassandra和HBase有着截然不同的基因血统。HBase和其底层依赖的系统架构源自于着名的Google FileSystem（发表于2003年）和Google BigTable设计（发表于2006年）， 其克服了HDFS注重吞吐量却牺牲I/O的缺点，提供了一个存储中间层使得用户或者应用程序可以随机读写数据。
具体来说，HBase的更新和删除操作实际上是先发生在内存MemStore中， 当MemStore满了以后会Flush到StoreFile, 之后当StoreFile文件数量增长到一定阈值后会触发Compact合并操作，因此HBase的更新操作其实是不断追加的操作，而最终所有更新和删除数据的持久化操作都是在之后Compact过程中进行的。
这使得应用程序在向内存MemStore写入数据后，所做的修改马上就能得到反映，用户读到的数据绝不会是陈旧的数据，保证了I/O高性能和数据完全一致性； 另一方面来说， HBase基于Hadoop生态系统的基因就已经决定了他自身的高度可扩展性、容错性。
在数据模型上，Cassandra和HBase类似实现了一个key-value提供面向列式存储服务，其系统设计参考了 Amazon Dynamo (发表于2007年) 分布式哈希（DHT）的P2P结构（实际上大部分Cassandra的初始工作都是由两位从Amazon的Dynamo组跳槽到Facebook的工程师完成)，同样具有很高的可扩展性和容错性等特点。
除此之外， 相对HBase的主从结构，Cassandra去中心化的P2P结构能够更简单地部署和维护，比如增加一台机器只需告知Cassandra系统新节点在哪，剩下的交给系统完成就行了。同时，Cassandra对多数据中心的支持也更好，如果需要在多个数据中心进行数据迁移Cassandra会是一个更优的选择。
Eric Brewer教授提出的经典CAP理论认为任何基于网络的数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。实际分布式系统的设计过程往往都是在一致性与可用性上进行取舍，相比于HBase数据完全一致性的系统设计，Cassandra选择了在优先考虑数据可用性的基础上让用户自己根据应用程序需求决定系统一致性级别。
比如：用户可以配置QUONUM参数来决定系统需要几个节点返回数据才能向客户端做出响应，ONE指只要有一个节点返回数据就可以对客户端做出响应，ALL指等于数据复制份数的所有节点都返回结果才能向客户端做出响应，对于数据一致性要求不是特别高的可以选择ONE，它是最快的一种方式。
从基因和发展历史上来说，HBase更适合用做数据仓库和大规模数据处理与分析（比如对网页数据建立索引）， 而Cassandra则更适合用作实时事务和交互式查询服务。Cassandra在国外市场占有比例和发展要远比国内红火， 在不少权威测评网站上排名都已经超过了HBase。目前Apache Cassandra的商业化版本主要由软件公司DataStax进行开发和销售推广。另外还有一些NoSQL分布式数据库如Riak, CouchDB也都在各自支持的厂商推动下取得了不错的发展。
虽然我们也考虑到了HBase在实际应用中的不便之处比如对二级索引的支持程度不够（只支持通过单个行键访问，通过行键的范围查询，全表扫描），不过在明略的大数据基础平台上，目前整合的是依然是HBase。
理由也很简单，HBase出身就与Hadoop的生态系统紧密集成，其能够很容易与其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）进行整合，而不需要重新部署一套分布式数据库系统，而且可以很方便地将同样的数据内容在同一个生态系统中根据不同框架需要来变换存储格式（比如存储成Hive表或者Parquet格式）。
我们在很多项目中都有需要用到多种SQL on Hadoop框架，来应对不同应用场景的情况，也体会到了在同一生态系统下部署多种框架的简便性。 但同时我们也遇到了一些问题， 因为HBase项目本身与HDFS和Zookeeper系统分别是由不同开源团队进行维护的，所以在系统整合时我们需要先对HBase所依赖的其他模块进行设置再对HBase进行配置，在一定程度上降低了系统维护的友好性。
目前我们也已经在考虑将Cassandra应用到一些新的客户项目中，因为很多企业级的应用都需要将线上线下数据库进行分离，HBase更适合存储离线处理的结果和数据仓库，而更适合用作实时事务和并发交互性能更好的Cassandra作为线上服务数据库会是一种很好的选择。
3
大数据安全篇
随着越来越多各式各样的数据被存储在大数据系统中，任何对企业级数据的破坏都是灾难性的，从侵犯隐私到监管违规，甚至会造成公司品牌的破坏并最终影响到股东收益。给大数据系统提供全面且有效的安全解决方案的需求已经十分迫切：
大数据系统存储着许多重要且敏感的数据，这些数据是企业长久以来的财富
与大数据系统互动的外部系统是动态变化的，这会给系统引入新的安全隐患
在一个企业的内部，不同Business Units会用不同的方式与大数据系统进行交互，比如线上的系统会实时给集群推送数据、数据科学家团队则需要分析存储在数据仓库内的历史数据、运维团队则会需要对大数据系统拥有管理权限。
因此为了保护公司业务、客户、财务和名誉免于被侵害，大数据系统运维团队必须将系统安全高度提高到和其他遗留系统一样的级别。同时大数据系统并不意味着引入大的安全隐患，通过精细完整的设计，仍然能够把一些传统的系统安全解决方案对接到最新的大数据集群系统中。
一般来说，一个完整的企业级安全框架包括五个部分：
Administration: 大数据集群系统的集中式管理，设定全局一致的安全策略
Authentication: 对用户和系统的认证
Authorization：授权个人用户和组对数据的访问权限
Audit：维护数据访问的日志记录
Data Protection：数据脱敏和加密以达到保护数据的目的
系统管理员要能够提供覆盖以上五个部分的企业级安全基础设施，否则任何一环的缺失都可能给整个系统引入安全性风险。
在大数据系统安全集中式管理平台这块，由Hortonworks推出的开源项目Apache Ranger就可以十分全面地为用户提供Hadoop生态圈的集中安全策略的管理，并解决授权(Authorization)和审计(Audit)。例如，运维管理员可以轻松地为个人用户和组对文件、数据等的访问策略，然后审计对数据源的访问。
与Ranger提供相似功能的还有Cloudera推出的Apache Sentry项目，相比较而言Ranger的功能会更全面一些。
而在认证（Authentication）方面, 一种普遍采用的解决方案是将基于Kerberos的认证方案对接到企业内部的LDAP环境中， Kerberos也是唯一为Hadoop全面实施的验证技术。
另外值得一提的是Apache Knox Gateway项目，与Ranger提高集群内部组件以及用户互相访问的安全不同，Knox提供的是Hadoop集群与外界的唯一交互接口，也就是说所有与集群交互的REST API都通过Knox处理。这样，Knox就给大数据系统提供了一个很好的基于边缘的安全（perimeter-based security）。
基于以上提到的五个安全指标和Hadoop生态圈安全相关的开源项目， 已经足已证明基于Hadoop的大数据平台我们是能够构建一个集中、一致、全面且有效的安全解决方案。
我市再ITjob管网上面找的
4. 航班管家开放平台——打造航空铁路出行行业的企业级SaaS服务平台
“ 本项目案例由 航班管家 投递并参与 由数据猿&上海大数据联盟联合推出的“行业盘点季之数智化转型升级”大型主题策划活动之《2021中国企业数智化转型升级创新服务企业》榜单/奖项的评选。
航班管家开放平台是航空铁路出行行业首个SaaS级服务平台，聚焦大交通出行服务行业数字化升级，基于民航局空管局授权的官方动态数据，整合航空、铁路、场站、旅客、货运等多维度数据，结合拥有自主知识产权的算法模型与行业Know-how，面向行业提供多种数据服务产品和数据解决方案，赋能行业合作伙伴、帮助其提效降本。
如数字化程度有待提高的旅行社、票务代理、TMC、企业差旅部门等，用户在其平台购票后，需要通过其他第三方平台查询航班/列车动态信息，用户体验感和便利程度大大降低，航班管家面向这些企业，提供SaaS级产品【行程服务H5】，客户可根据自身需求进行页面个性化配置，然后将配置好的页面直接嵌入自有APP、公众号、小程序等产品中，方便用户在自有平台完成购票、动态查询等服务，形空乎成服务闭环，提高用塌扰户体验，同时降低企业开发成本。
面向数据分散在各个部门、协调难度大，但正在进行数字化转型的航司、机场等企业，还有需要分析数据的金融、券商、媒体、院校、咨询公司、研究机构等行业，航班管家提供【智数出行】服务，包括数据分析平台、可视化大屏、大数据分析报告等产品，分析行业数据、洞察行业发展，提供有价值的分析结果与行业洞见，以满足行业日常工作及决策支撑需要，助力企业数字化转型升级。
实施时间
开始时间：2021年1月初完成项目立项
里程碑节点：
2021年1月25日
·官网V1.0版本上线。
·华为云上代码部署，正式环境搭建完成。
2021年4月8日
·平台V1.0版团亏旦本上线，支持账号认证、产品服务开通。
2021年5月31日
·平台V2.0版本上线，行程服务产品支持套餐包购买，H5版本官网、产品介绍页上线。
·首批客户上线，分贝通、公务之家、QQ浏览器、UC浏览器等。
2021年6月30日
·平台V3.0版本上线，官网全新改版、行程服务产品支持功能模块可配置化、支持在线扫码支付。
截止时间：2021年年8月底
依托于航班管家多年的数据积累及服务B端、C端用户经验总结，打造一站式开放平台，致力于为多种行业用户提供民航、铁路、航空货运大交通数据及其衍生产品与服务，如行程服务H5、API接口、大数据分析报告、数据分析工具及可视化等，助力企业提升服务水平、降低成本、提高效率，并为企业决策提供辅助支持。
行程服务H5
为OTA/TMC/旅行社/企业差旅部门等，提供基于H5页面的航空/铁路行程全流程信息服务，企业可将H5页面直接嵌入自有移动端产品中，如APP、公众号、小程序，让出行旅客/员工不再依赖其他第三方产品，在自有产品中即可掌握行程动态信息，方便旅客/员工合理安排规划行程，提升出行体验，提高服务满意度，增强用户黏性，同时降低企业开发维护成本。
API接口
为各类需要航班/列车动态信息、航班/列车准点率、飞机/列车基础参数、机场/车站基础设施信息及其他相关数据的企业，提供API接口服务。如用车行业，基于实时的航班/列车动态信息，做好机场/车站接送业务支持，合理安排车辆调度，提高服务效率；保险业，基于准点率数据，实现延误险动态定价，基于航班/列车动态数据，自动判断航班延误/取消是否达到赔付标准，实现自动理赔，提高理赔效率；OTA，提供飞机/列车基础参数数据，如机型、车型、座椅间距、 娱乐 设施配备等，供用户在选择航班时做参考，提升服务体验感。
数据报告
基于航班管家多年的民航铁路数据积累，分析民航铁路交通运输和旅客出行状况，提供定期、专题等多种类型的专业分析报告，还可基于行业专家团队能力提供深度行业咨询服务，从整体上把握市场趋势，为日常工作及生产经营决策提供支持。如为发动机制造商，围绕机队数据、飞机利用率、停场时长等指标，提供机队分析报告，帮助其快速掌握航司机队状况；为机场、航司、金融、证券、媒体等行业，围绕计划/实际航班量、航班执飞率、航班座位数、航班拥挤度、旅客运输量等指标，提供民航运行周报，从整体上把握民航运行状况，了解行业趋势；节假日时发布专题报告，分析旅客出行数据， 探索 旅客出行规律，为航司、旅行社、酒店等企业，在制定节假日产品时，提供数据支持。
数据分析工具及可视化
基于行业领先且专业的民航铁路出行大数据及拥有自主知识产权的算法模型，通过可视化平台，将分析、预测数据深入浅出的展现出来。如Mapping System（航线网络图），提供航司、机场航线布局，并对数据进行分析展示，方便用户直观便捷的查机场/航司航线状况、通航点状况、空铁联运衔接状况；大数据平台，提供官方统计、机场分析、航司分析、航线分析、铁路分析等分析模块，帮助航司/机场快速掌握民航铁路整体运行状况，了解对标机场/航司运行状况，为机场/航司运行、服务提升、产品优化提供数据支撑；为文旅厅，提供空铁联运实时监测系统，帮助文旅厅实时掌握机场/火车站实时旅客流量、航班运行状况、旅客运行状况，提前做好景区开放、接待筹备等工作。
海量数据实时处理，及时准确对外输出。我们的数据覆盖全球1100+家航空公司，5000+座机场，境内航班数据覆盖率达100%，全球航班覆盖率达98%，每天处理超过20万趟航班的动态信息，智能推送40多类旅客行程关怀信息，国内航班实际起降时间准确率达99%。同时，自建铁路数据库已覆盖国内3138个车站，10000+班车次，每日覆盖中国国内90W+进出站车次。
航班动态的数据是由数据生产者实时解析的，数据生产者将解析的数据发送到Kafka，由消费服务对数据进一步消费处理，最终由消费服务将有效的数据同步到MySQL数据库中存储。
全球每天约有10万次航班的起降，预计每分钟产生5万条航班动态数据合计14M，每天产生的数据约20.4G，每月612G，每年7.2T ; 航班管家数据覆盖全球1100+家航空公司，5000+座机场，境内航班数据覆盖率达100%，全球航班覆盖率达98%，每日处理超过20万趟航班的动态信息。
为了面向行业提供多种数据服务产品和数据解决方案，赋能行业合作伙伴、帮助其提效降本，2021年01月06日，公司领导召集部分员工，确定了项目的大致方向，提出了依托现有的航班、高铁数据接口，开发一个“航班管家开放平台”的SaaS平台。
01
项目设计
研发人员根据项目提出的需求，第一时间画了简单的设计图。
航班管家开放平台可主要分为3个大模块和15个子模块：3个大模块分别是控制台模块、数据服务模块、数据中心模块。15个子模块分别是：用户模块、鉴权模块、产品模块、网关模块、API数据模块、H5数据模块、控制台模块、管理后台模块、账单模块、余额模块、批价模块、支付模块、时间轴模块、行程中心模块、行程消息模块。
控制台模块：
提供用户专属账号登陆“航班管家开放平台”的控制台，开通“行程服务”中的产品获取航班、高铁服务的专属API接口数据和下载“数据报告”产品中有价值的大数据分析报告等。
数据服务模块：
数据中心模块：
基于民航空管局授权的官方动态数据，整合航空、铁路、场站、旅客、货运等多维度数据，结合拥有自主知识产权的算法模型与行业Know-how，构建有价值的数据。
02
技术选型
技术团队了解完业务的需求，考虑到用户的类型和规模，为了保证系统的安全性、可用性、稳定性、可伸缩性和可维护性，确定了以下的架构模式：
2.1、分层模式：
控制台模块采用的是分层模式：表示层、应用层、数据访问层。
表示层：
使用Vue.js等进行前端展示，完成集成和数据展示功能。
应用层：
使用Spring Cloud、Log4j、MyBatis等开源框架，Spring Cloud使用的计算机编程语言是Java，保证了系统代码的可移植性、安全性、可维护性，同时它也是一个分布式系统，保证了系统的可伸缩性、可维护性、可用性。
数据访问层：
综合使用Kafka、MySQL、Redis等多种开源技术，高效完成数据存储、资源调度、数据计算等，为业务及其他环节做支撑。
2.2、主从设备模式
数据中心模块中的数据库MySQL采用主从设备模式：主设备储存数据最终的计算结果，从设备中返回主设备中的计算结果。
MySQL使用主从设备模式，实现了实时灾备，在单台机器发生故障的时候，可以迅速的切换到其它机器，即实现了数据的备份，又保证了服务的高可用，同时从设备可以有多个，也保留了服务的扩展性。
2.3、代理模式
采用Nginx服务器的反向代理，防止主服务器被恶意攻击，确保数据的安全，提供数据的防护能力。同时Nginx服务器提供有负载均衡和动静分离的实现支持，可以极大的提高服务的安全性、稳定性，可用性。为了进一步保证网络安全，所有的服务均采用HTTPS加密协议进行网络资源传输，为用户良好的体验效果提供保障。
03
实施过程
2021-01-18
以下模块分别完成了服务器端文档编写和接口开发并发布测试环境：
1. 产品模块完成了H5资源和API资源的在线配置相关接口；
2. 鉴权模块完成了资源访问的鉴权相关接口；
3. 用户模块完成账户信息的维护相关接口；
4. API数据模块完成了航班数据输出接口、高铁正晚点数据输出接口；
5. H5数据模块完成了航班详情页和高铁详情页服务器端接口；
6. 控制台模块完成产品列表、应用列表相关接口。
2021-01-25
1. 控制台模块和产品模块、鉴权模块、前端完成联调和上线；
2. 网关模块和鉴权模块、产品模块、H5数据模块、API数据模块完成联调并上线；
3. 管理后台模块完成了基础框架的搭建和权限系统的开发、测试和部署到线上华为云。
2021-02-25
以下模块分别完成了服务器端文档编写和接口开发并发布测试环境：
1. API数据模块完成高铁动态、列车时刻表输出相关接口；
2. H5数据模块完成航班详情页内部跳转链接页面、高铁详情页内部跳转链接页面；
3. 时间轴模块完成卡片元数据和阶段卡片关联的相关接口；
4. 控制台模块完成用户注册、找回密码、更换手机号、主题配置相关接口；
5. 管理后台模块完成产品货架的展示、产品上下架，用户信息，系统配置。
2021-03-08
1. API数据模块和网关模块完成高铁动态、列车时刻表输出的联调、上线；
2. H5数据模块和网关模块、前端完成航班详情页、高铁详情页内部跳转链接页面的联调、上线；
3. 时间轴模块和管理后台模块完成卡片元数据和阶段卡片关联的联调、上线；
4. 控制台模块和用户模块、前端完成户注册、找回密码、更换手机号、主题配置的联调、上线；
5. 管理后台模块完成产品货架的展示、产品上下架、用户信息、系统配置的上线。
2021-03-26
以下模块分别完成了服务器端文档编写和接口开发并发布测试环境：
2. 行程消息模块完成消息推送、消息列表展示的相关接口；
3. 控制台模块完成用户的认证、应用的动态配置、银行卡对公转账充值的相关接口；
4. 批价模块完成了产品的批价处理相关接口；
5. 账单模块完成了生成产品的消费订单相关接口；
6. 余额模块完成了消费订单的扣费相关接口
7. 支付模块完成了企业账户信息的维护、银行卡对公转账充值到余额、余额支付、余额查询的相关接口；
8. 管理后台完成用用户认证审核、户充值的订单和充值处理的相关接口。
2021-04-08
1. 行程中心模块和网关模块、控制台模块完成了联调、上线；
2. 行程消息模块和网关模块、控制台模块完成了联调、上线；
3. 账单模块和批价模块、余额模块、支付模块完成了联调、上线；
4. 控制台模块和支付模块、管理后台模块、前端完成了联调、上线；
5. 管理后台模块和控制台完成了联调、上线。
2021-05-15
以下模块分别完成了服务器端文档编写和接口开发并发布测试环境：
1. 支付模块完成支付宝、微信扫码支付的相关接口；
2. 账单模块完成了日账单、月账单统计和明细查询的相关接口；
3. 控制台模块完成了用户账单的汇总和明细的展示和导出、行程服务产品套餐包展示和购买和订单的支付、查询相关接口；
4. 批价模块完成行程服务产品套餐包的批价；
5. 管理后台模块完成产品套餐的录入、上下架，用户购买套餐的展示、用户订单的相关功能。
2021-05-31
1. 支付模块和控制台完成扫码支付的联调、上线；
2. 账单模块和控制台完成账单统计和明细查询的联调、上线；
3. 控制台模块和支付模块、前端完成套餐的展示、购买和订单列表的查询的联调和上线；
4. 批价模块和控制台模块完成套餐包相关产品的计费调整的联调和上线；
5. 管理后台模块完成了测试和上线。
2021-06-18
以下模块分别完成了服务器端文档编写和接口开发并发布测试环境：
1. 控制台模块完成支付宝、微信扫码充值到余额，航班详情页、高铁详情页支持功能模块可配置化；
2. H5数据模块完成航班详情页、高铁详情页功能模块的动态展示。
2021-06-30
1. 控制台模块和支付模块、前端完成扫码充值联调、航班/高铁详情页的功能模块动态配置的联调、上线；
2. H5数据模块和前端完成航班详情页、高铁详情页功能模块的动态展示的联调、上线；
3. 前端完成官网的全新改版上线。
民航局空管局官方授权数据，为航班信息提供了官方来源的数据，充实、完善了底层数据库。
·与交通行业专业院校、科研院所、金融券商等展开合作，特聘各领域专家组成专家团队，为客户提供深度的行业咨询服务及分析报告产品。
一、项目定位
1. 概述：大交通数据及服务开放平台，为多种行业用户提供民航、铁路、航空货运大交通数据及其衍生产品服务，并根据各行业特色和需求，提供个性化、配套完善的解决方案。
2. 目标：封装航班管家的各项能力，向平台用户输出多种类的产品服务及解决方案。提供一站式自助化线上服务，降低自身人力成本投入。
3．提供成熟稳定的行程服务H5页面，企业可在自有移动端产品中嵌入航班、列车行程服务及行程管理页面，以企业自己的品牌，在自有产品中一站式全流程服务出行用户，让用户能轻松管理自己的行程。帮助企业显着提升用户出行体验，更好服务用户，创造更多商业价值。
4. 可为企业高效快速对接以下成熟型行程服务产品降低企业开发成本、提升用户出行服务满意度，如行程管理、航班行程服务、列车行程服务、全场景服务信息推送。用户可随时查看已有行程/ 历史 行程
用户可自主添加航班、列车行程，支持航班号/起降地查询航班信息、车次号/出发到达站查询火车信息，航班行程服务，围绕用户航空出行场景，提供精准的航班动态信息，并将航空出行全流程划分为多个阶段，在不同阶段提供不同的数据和服务，企业可通过H5页面将服务嵌入自有产品中，为用户提供一站式全流程服务。不同行程阶段，给用户提供的服务，可以在平台进行配置。实时、精准呈现航班动态相关信息，大数据预测起飞及到达时间，准确告知值机柜台和登机口信息，详细指引登机路线，确保用户顺利登机，航班近期准点率及平均延误时长统计。
二、目标群体
1. 短期目标群体：
有数据使用需求的中小型用户，如券商、咨询公司、学者学生、创业开发者等（对标API接口产品）。
有数据分析需求，需要数字化分析工具的用户，如机场、航司、政府、制造商等（对标数据平台、数据报告产品）。为C端提供行程服务需求的用户如中小型OTA、TMC等（对标行程服务产品）。
2. 长期目标群体：
有货运数据需求的用户，如物流、货运代理等（对标货运服务产品）
为服务的各领域提供专业的解决方案，如OTA、物流、航司、机场、制造商、用车、保险、车联网、集成系统开发、云服务等。
成效：
保险：行业数据分析核算，实时核保，赔付周期提升99%，赔付率降低50%，优化用户服务体验。
网约车：合理优化网约车资源利用率，平均减少接送机司机空等时间75分钟/年。
酒店：为酒店提供用户行程管理，6小时酒店航班信息同步，提高房源利用率，提升“机+酒”服务体验。
物流：为物流快递行业提供发货前中后数据信息参考，航班管家为中国90%的航空快件服务商赋能提效。
航班管家
航班管家是国内领先的智能出行平台，以“航班+高铁”的行程服务为核心，服务全面覆盖航班、高铁以及专车接驳三大出行场景，服务所有大交通出行用户。面向C端，航班管家为用户提供航班/列车动态信息、票务/酒店预订、专车接送、出行攻略内容等在内的一站式出行服务，让出行成为美好的生活方式；面向B端，航班管家构建覆盖航班和铁路出行全场景的企业级SaaS平台，聚焦大交通出行服务行业数字化升级，为OTA、TMC等行业提供多场景服务解决方案，赋能合作伙伴，提效降本。